HTML 본문에 JavaScript를 포함하는 것은 나쁜 습관입니까?

84

제가 작업중인 팀은 <script>HTML 페이지 본문의 임의의 위치에 태그 를 사용하는 습관을 갖게 되었습니다. 예를 들면 :

<html>
    <head></head>
    <body>
        <div id="some-div">
            <script type="text/javascript">//some javascript here</script>
        </div>
    </body>
</html>

나는 이것을 전에 본 적이 없었다. 내가 테스트 한 몇 가지 브라우저에서 작동하는 것 같습니다. 그러나 내가 아는 한, 이와 같은 곳에 스크립트 태그를 넣는 것은 유효하지 않습니다.

내가 잘못? 이와 같이 div 태그 내에 스크립트 태그를 넣는 것이 얼마나 나쁜가요? 알아야 할 브라우저 호환성 문제가 있습니까?

javascript  html 
— 앤드류
소스
1
그것이 document.writes거기에서하고 있는가 아니면 그것이 어디에있을 특별한 이유가 없는가?
— Martin Smith
8
스크립트는 신체 어디에서나 발생하는 것이 합법적입니다. 그게 잘못이 아닙니다. 그것은 그 의미 (타이밍, 유지 보수성, 코드와 레이아웃의 혼합, 개인적 선호도)를 가지고 있지만 그렇지 않으면 괜찮습니다.
— Tomalak
@earlz-왜 나쁜지에 대한 내 대답을 참조하십시오. 여기서 생명을 구하려고합니다. 그리고 나는 옳다.
— Jason

답변:

88

완벽하게 유효합니다.

마크 업에 큰 코드 블록을 섞고 싶지는 않지만 (외부 스크립트를 사용하는 것이 더 좋습니다) 다음과 같은 경우에 유용 할 수 있습니다.

  • 점진적 향상을위한 추가 바인딩 정보를 추가합니다 (데이터가 클래스 이름에 적합하지 않거나 속성에서 확장 정보를 숨기는 다른 접근 방식). 또는

  • 창로드 / 문서 준비를 기다리는 대신 가능한 한 빨리 스크립팅 된 향상을 시작해야합니다. 이것의 예는 너무 늦게 발사되면 짜증을 낼 수있는 자동 초점입니다.

<style>허용되지 않는 요소를 생각하고있을 수 있습니다 <body>(그러나 대부분의 브라우저에서 허용하지만).

— Bobince
소스
12
자동 초점에 +1; 가끔은 저속 연결 상태이고 첫 번째 필드로 돌아갈 때 이미 다른 곳에있는 것은 (최악의 경우 : 암호 입력) 재미가 없습니다.
— Marcel Korpel
1
그러나 JS 포함은 페이지가 하나 뿐이고 서버 조회를 줄이는 데 유용 할 수 있습니다. 임베디드 CSS에 대해서도 마찬가지입니다. 그러나 일반적으로 동일한 javascript 및 css 요구 사항이있는 템플릿을 사용할 때 페이지로드 시간 (유효한 캐시 헤더 사용)을 줄이기 위해 분리 된 파일에서 javascript 코드와 CSS를 분리하는 것이 좋습니다.
— Codebeat 2011
17

사실 꽤 흔합니다. 예를 들어 Google의 분석 추적 코드 는 다음 구문 만 사용합니다.

<script type="text/javascript">
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
  document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>

Google에 충분하다면 ...

— Keltex
소스
37
-1-Google이 그렇게한다고해서 좋은 습관이되는 것은 아닙니다. 일반적인! = 좋습니다.
— Jason
3
어쨌든 Google Analytics는 지나치게 복잡하며 추적을 위해 JavaScript를 사용하는 것은 실제로 과도한 엔지니어링의 좋은 예입니다.
— Esko
또한 스크립트를 배치해야하는 경우 스크립트를 배치해야하는 중간이 아닌 페이지 하단에 배치 할 것을 권장합니다. 사람들이 일반적으로 넣는 헤더에는 없습니다
— Jason
2
주제에서 벗어남 : 나는 / Is Evil (그리고 훨씬 더 간단한 방법이었을 것임)을 unescape감안할 때 Google의 불필요하고 기괴한 사용에 항상 짜증이납니다 . escapeunescape\x3C
— bobince
3
@Keltex : 코드는 유효하지 않지만 일부 사람들이 사용하기 때문에 좋은 습관이라고 주장하는 것은 유효한 인수가 아닙니다.
— Matti Virkkunen
4

이는 유효하며 서버 측 프레임 워크와 코드의 특성에 따라 때로는 피하는 것이 매우 어렵습니다.

— 뾰족한
소스
4

여러 사람이 언급했듯이 유효하고 작동하며 널리 사용됩니다.

의미론이 권장하는 한 (또는 최소한 권장하는 데 사용되는) 모범 사례는 헤더 내부에 스크립트 태그를 배치하는 것입니다.

성능을 고려한보다 현대적인 모범 사례에서는 스크립트 태그 (외부 및 인라인)를 body 태그 바로 앞에 배치하여 JavaScript 코드가 실행되기 전에 마크 업이 완전히 렌더링 될 수 있도록하는 것이 좋습니다.

코드를 더 쉽게 이해하고 유지 관리 할 수 ​​있도록 코드가 외부 파일에 있고 이벤트를 DOM (Google 눈에 잘 띄지 않는 JavaScript)에 바인딩하는 "눈에 잘 띄지 않는 JavaScript"가 권장됩니다.

JavaScript를 인라인으로 사용하는 것이 유용한 한 가지 경우는 서버 측에만 존재하는 값으로 변수를 초기화 한 다음 나중에 외부 JavaScript 코드에서 사용하는 것입니다.

— 여자
소스
3

나는 외부 스크립트에 대한 참조를 머리에 넣고 일을 시작하고 위젯을 초기화하는 스크립트를 본문에 넣는 것을 선호합니다.

실행하기 매우 쉬운 문제는 본문의 스크립트 요소가 그 뒤에 오는 요소에 액세스 할 수 없다는 것입니다. 또한 관련된 불쾌한 브라우저 호환성 문제는 IE가 스크립트 요소가 해당 요소를 수정하는 것을 허용하지 않는다는 사실입니다. 따라서 다음과 같은 경우 :

<div id="foo">
  <script type="text/javascript">
    document.getElementById("foo")... // do something to it
  </script>
</div>

IE는 귀하의 페이지를 좋아하지 않을 것입니다. IE의 구 버전은 이것에 대해 매우 비밀스러운 오류 메시지를 제공하거나 전체 페이지를 비 웠지만 IE8은 설명적인 오류 메시지를 제공하는 것 같습니다.

스크립트가 액세스하기에 안전한 DOM에만 액세스하도록하는 한 스크립트 요소를 본문에 넣는 것이 나쁘다고 생각하지 않습니다. 사실, IMHO는 관련 요소 뒤에 위젯을 초기화하는 스크립트를 배치하는 것이 모든 것을 한곳에 배치하는 것보다 더 읽기 쉬울 수 있습니다.

— Matti Virkkunen
소스
3

유효합니다!

당신이 사용할 수있는:

<script type="text/javascript">
    //<![CDATA[

    // Some JavaScript code that perfectly validates in the W3C validator

    //]]>
</script>

나는 그것이 일반적으로 나쁜 관행이라고 말할 수 없다고 생각합니다. 사건에서 말해야합니다. 하지만 모든 자바 스크립트 코드를 같은 위치에 두는 것이 좋습니다. HTML 파일 전체에 약간의 JavaScript 코드가 있으면 약간 지저분합니다.

— 메오
소스
2
일반적으로 나쁜 습관입니다.
— Jason
좋아요, 당신이 게시 한 글을 읽어주세요. 어차피 절대 안하는데 브라우저가 멈출 수는 없지만 ... ... 어떻게 되나요?
— meo
1
모든 JavaScript는 브라우저를 중단시킬 수 있습니다 (때로는 Firefox에서 '스크립트 중단'및 '스크립트 계속'옵션과 함께 해당 경고 상자가 표시되는 경우가 있습니다).
— Marcel Korpel
이것은 사실이며 모든 JS가 브라우저를 중단시킬 수 있습니다. 그러나 매달 리려는 경우 (obv는 권장하지 않음) 페이지가 콘텐츠로 완전히 렌더링되고 사용자가 페이지를 읽고 상호 작용할 수있게되면 수행하는 것이 좋습니다. JS가 브라우저를 중단하는 이유는 동기식으로 실행되기 때문입니다. 즉, JS가 수행 할 작업을 모르기 때문에 렌더링을 계속하기 전에 JS가 완전히 실행될 때까지 브라우저가 기다려야합니다. 기다리는 동안 렌더링되지 않아 매달린 것처럼 보입니다.
— Jason
CDATA를 사용하지 마세요. 말도 안 돼요. XML 검증 파서 만이 CDATA 섹션을 이해하므로 페이지가 HTML로 제공되는 경우 기능적 차이가 없습니다. 그러나 페이지가 XML로 제공되는 경우 여는 태그 앞에 "//"가 렌더링됩니다.
— brothercake 2013-08-27
2

나는 이것을 전에 본 적이 없었다. 내가 테스트 한 몇 가지 브라우저에서 작동하는 것 같습니다. 그러나 내가 아는 한, 이와 같은 곳에 스크립트 태그를 넣는 것은 유효하지 않습니다.

유효하지만 좋은 (또는 권장되는) 관행은 아닙니다.

내가 잘못? 이와 같이 div 태그 내에 스크립트 태그를 넣는 것이 얼마나 나쁜가요? 알아야 할 브라우저 호환성 문제가 있습니까?

<script>다른 요소 아래에를 배치하는 데 문제가 없습니다 (하지만 <head>또는 안에 있어야 함 <body>). 브라우저 호환성 측면에서도 문제가 없지만 웹 페이지에 JS 스크립트를 포함하면 심각한 단점이 있습니다 (어떻게 / 왜 나쁜 것으로 간주되는지) .

  1. 페이지 가중치 추가
  2. 축소의 어려움 (또는 불가능)
  3. 마이그레이션하거나 다른 페이지에 사용할 수 없습니다.
  4. 캐시 할 수 없음 (페이지가로드 될 때마다 다운로드해야 함)
  5. 우려 사항 분리 없음 (유지 관리가 더 어렵습니다)
2

그러나 HTML 섹션에 필요한 JavaScript 코드가 거기에있을 것이라는 점을 아는 것도 좋습니다. 파일 상단에 일부 포함을 주장하고 구축 할 필요가 없습니다.

따라서 "이 HTML을 사용하려는 경우 xyz.js를 가져와야합니다"대신 HTML을 포함하고 작업을 완료 할 수 있습니다.

따라서 반드시 끔찍한 악은 아닙니다. 아마도 놀랍도록 굉장하지는 않지만 완전히 끔찍하지는 않습니다. 의도에 따라 다릅니다.

— 윌 하퉁
소스
1

확실히 합법적입니다. 예를 들어 Exforsys 의 몇 페이지 에서 봤습니다 .

이제 이것은 HTML과 JavaScript의 기초를 보여주는 튜토리얼 사이트이므로 그 맥락에서 완벽하게 이해할 수 있습니다. 그러나 나는 단순한 문장 한두 개 이상을 프로덕션 코드에서보고 싶지 않습니다. 당신이 무엇을 대체했는지 보지 않고 // Some JavaScript code here나는 코멘트 하고 싶지 않을 것입니다.

그래도 브라우저 문제는 없어야합니다.

— ChrisF
소스
1

에 <script>를 추가하는 것은 유효 body하지만 Internet Explorer는 실제로 그것을 좋아하지 않습니다. 따라서 더 안전한 편이 되려면 <head> 태그 안에 스크립트가 있는지 확인하십시오.

그것은 우리가 작업하고있는 프로젝트에 (특히 Internet Explorer의 경우) 혼란을 초래했습니다.

— 아일랜드 사람
소스
1

팀이 스크립트를 동적으로 삽입하거나 페이지로드시 실행되는 스크립트를 작성하기 때문에이 작업을 수행하고 있다고 가정합니다.

절대적으로 필요한 경우 (CDATA 블록에있는 한)이 작업을 수행하는 데 문제가 있다고 말하지는 않지만 그 외에는 Prototype 또는 jQuery와 같은 스크립트 라이브러리를 사용하고 유지하는 것이 좋습니다. 페이지 외부의 스크립트. 이것은 일반적으로 더 깨끗하고 라이브러리는 때때로 코드에 약간의 청결을 강요합니다. 이것은 현재 일어나지 않을 것입니다.

또한 인라인 스크립트 태그에서 시간이 많이 걸리는 기능을 실행하지 않을 것입니다. 이러한 기능은 페이지로드시 발생하고 Jason이 위에서 언급했듯이 페이지로드 속도를 늦출 수 있습니다. 모든 스크립트 라이브러리에는 페이지로드시 작업을 수행 할 수있는 깔끔한 기능이 있으며, DOM이로드 된 후와 같이 페이지로드에서 실행되는시기에 대한 옵션을 제공합니다.

— 제시
소스
1

이는 프로그래밍에 대한 접근 방식을 개선하는 것만 큼 성능 향상에 관한 많은 모범 사례 중 하나입니다.

궁극적으로 웹 개발에서는 제품을 출시하는 것이 가장 중요합니다!

— Heydenberk
소스
0

스크립트를 헤더에 보관해야한다는 자주 언급되는 권장 사항은 스크립트가 호출되기 전에로드되었는지 확인하는 것입니다. 이것은 특정 이벤트 핸들러의 문제 일뿐입니다. 다른 유형의 스크립트에서는 문제가되지 않으며 일부 유형 (예 : document.write)의 경우 의미가 없습니다.

— 토르 하우 겐
소스
0

HTML 및 JavaScript 구문을 동시에 처리 할 수있는 편집기가있는 경우. 그리고 먼저 HTML 몇 줄을 읽은 다음 JavaScript cpde를 읽고 싶다면 ... 확실히. 그것을 위해 가십시오.

— 기분 좋은
소스
둘 다 처리 할 수있는 Visual Studio 및 면도기보기처럼 들립니다. 이것은 경우에 따라 매우 편리 할 수 ​​있습니다 (한곳에서 편집해야하는 모든 코드). 물론 뷰에 자바 스크립트가 너무 많으면 코드를 읽고 이해하기가 어려울 수 있으며 출력 html이 부풀어 오르는 문제도 있습니다.
— jahu
0

몇 가지:

  1. 완전히 유효한 코드입니다.
  2. 완전히 권장되지 않습니다.

이렇게하면 나머지 페이지가 렌더링되기 전에 JavaScript 코드가 실행되어야하므로 페이지로드가 상당히 느려집니다. 해당 JavaScript 코드에서 많은 작업을 수행하는 경우 브라우저가 중단 될 수 있습니다. 가능한 한 자바 스크립트 코드를 동적으로 그리고 페이지 끝 (가급적이면 </body>태그 앞)에로드해야합니다 .

고성능 JavaScript를 구입하고 읽으십시오 . JavaScript 코드를 작성하는 방식이 바뀝니다.

— 제이슨
소스
3
내 반대 투표는 아니지만 야후를 생각할 때 YAHOO.util.Event.addListener효율적이고 간결한 자바 스크립트가 아니라고 생각 합니다. 나는 책을 읽지 않고 복음으로 취급하지 않을 것입니다. 때로는 페이지 자체에 자바 스크립트가 있어야합니다 . 예를 들어 동적으로 렌더링되는 변수, 외부에서는 할 수없는 일입니다 .js.
— Nick Craver
2
책 읽었 어? 그렇다면 최적화 기술을 가르친다는 것을 알 것입니다. 같은 것들은 YAHOO.xx.xx.xx로컬로 캐시됩니다. 경우에 따라 페이지에 변수를 렌더링하는 것은 괜찮지 만 서버에서 숨겨진 입력 값을 설정하면 일반적으로 외부에서 수행 할 수 있습니다. 그러나 나는 그것이 잘못된 것이 아니라 추천 하지 않는다고 말했다 . 또한 저자 인 nicholas zakas는 고용주가 누구인지에 관계없이 그의 똥을 알고 있습니다.
— Jason
2
"동적으로로드"와 "페이지 끝에서로드"는 서로 다르며 둘 다 사용하여 성능상의 이점이 있다는 것은 거의 불가능합니다. "책 읽어 봤어?" 그리고 "내가 맞다"는 건설적인 대화를 시작하는 가장 좋은 방법은 아닙니다. 또한 원래 질문은 "IE에서 결국 질식하기 때문에"로 대답 할 수 있습니다. 일부 작업은 스크립트가 본문의 직접적인 자식 인 경우에만 지원되기 때문입니다.
— Nacho Coloma 2014 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.