HTML 본문에 JavaScript를 포함하는 것이 나쁜 습관입니까?
제가 작업중인 팀은 <script>HTML 페이지 본문의 임의의 위치에 태그 를 사용하는 습관을 갖게 되었습니다. 예를 들면 :
<html>
<head></head>
<body>
<div id="some-div">
<script type="text/javascript">//some javascript here</script>
</div>
</body>
</html>
나는 이것을 전에 본 적이 없었다. 내가 테스트 한 몇 가지 브라우저에서 작동하는 것 같습니다. 그러나 내가 아는 한, 이와 같은 곳에 스크립트 태그를 넣는 것은 유효하지 않습니다.
내가 잘못? 이와 같이 div 태그 내에 스크립트 태그를 넣는 것이 얼마나 나쁜가요? 알아야 할 브라우저 호환성 문제가 있습니까?
완벽하게 유효합니다.
마크 업에 큰 코드 블록을 섞고 싶지는 않지만 (외부 스크립트를 사용하는 것이 더 좋음) 다음과 같은 경우에 유용 할 수 있습니다.
점진적 향상을위한 추가 바인딩 정보를 추가합니다 (데이터가 클래스 이름에 적합하지 않거나 속성에서 확장 정보를 숨기는 다른 접근 방식). 또는
창로드 / 문서 준비를 기다리는 대신 가능한 한 빨리 스크립팅 된 향상을 시작해야합니다. 이것의 예는 너무 늦게 발사되면 짜증을 낼 수있는 자동 초점입니다.
<style>허용되지 않는 요소를 생각하고있을 수 있습니다 <body>(그러나 대부분의 브라우저에서 허용하지만).
사실 꽤 흔합니다. 예를 들어 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에 충분하다면 ...
이는 유효하며 서버 측 프레임 워크와 코드의 특성에 따라 때로는 피하는 것이 매우 어렵습니다.
여러 사람이 언급했듯이 유효하고 작동하며 널리 사용됩니다.
의미론에서 권장하는 (또는 최소한 권장하는 데 사용되는) 모범 사례는 헤더 내부에 스크립트 태그를 배치하는 것입니다.
성능을 고려한보다 현대적인 모범 사례에서는 스크립트 태그 (외부 및 인라인)를 본문 태그 바로 앞에 배치하여 JavaScript 코드가 실행되기 전에 마크 업이 완전히 렌더링 될 수 있도록하는 것이 좋습니다.
코드를 더 쉽게 이해하고 유지 관리 할 수 있도록 코드가 외부 파일에 있고 이벤트를 DOM (Google 눈에 잘 띄지 않는 JavaScript)에 바인딩하는 "눈에 잘 띄지 않는 JavaScript"가 권장됩니다.
JavaScript를 인라인으로 사용하는 것이 유용한 한 가지 경우는 서버 측에만 존재하는 값으로 변수를 초기화하는 것입니다.이 값은 나중에 외부 JavaScript 코드에서 사용됩니다.
나는 외부 스크립트에 대한 참조를 머리에 넣고 일을 시작하고 위젯을 초기화하는 스크립트를 본문에 넣는 것을 선호합니다.
실행하기 매우 쉬운 문제는 본문의 스크립트 요소가 그 뒤에 오는 요소에 액세스 할 수 없다는 것입니다. 또한 관련된 불쾌한 브라우저 호환성 문제는 IE가 스크립트 요소가 해당 요소를 수정하는 것을 허용하지 않는다는 사실입니다. 따라서 다음과 같은 경우 :
<div id="foo">
<script type="text/javascript">
document.getElementById("foo")... // do something to it
</script>
</div>
IE는 귀하의 페이지를 좋아하지 않을 것입니다. IE의 구 버전은 이것에 대해 매우 비밀스러운 오류 메시지를 제공하거나 전체 페이지를 비 웠지만 IE8은 설명적인 오류 메시지를 제공하는 것 같습니다.
스크립트가 액세스하기에 안전한 DOM에만 액세스하도록하는 한 스크립트 요소를 본문에 넣는 것이 나쁘다고 생각하지 않습니다. 사실, IMHO는 관련 요소 뒤에 위젯을 초기화하는 스크립트를 배치하는 것이 모든 것을 한곳에 배치하는 것보다 더 읽기 쉬울 수 있습니다 (그리고 이로 인해 더 일찍 실행될 수 있으므로 페이지가로드 될 때 항목이 더 적게 이동하게됩니다).
유효합니다!
당신이 사용할 수있는:
<script type="text/javascript">
//<![CDATA[
// Some JavaScript code that perfectly validates in the W3C validator
//]]>
</script>
나는 그것이 일반적으로 나쁜 관행이라고 말할 수 없다고 생각합니다. 사건에서 말해야합니다. 하지만 모든 자바 스크립트 코드를 한 곳에 두는 것이 좋습니다. HTML 파일 전체에 약간의 JavaScript 코드가 있으면 약간 지저분합니다.
I had not seen this before. It seems to work in the few browsers that I've tested. But as far as I know, it's not valid to put script tags in places like this.
It's valid, but not a good (or recommended) practice.
Am I wrong? How bad is it that we are putting script tags within div tags like this? Are there any browser compatibility issues I should be aware of?
There's no problem placing a <script> under any other elements (but it should be inside <head> or <body>). There's also no issue in terms of browser compatibility, however, embedding JS scripts on web pages presents serious disadvantages (how/why they are considered bad):
- Adds page weight
- Difficulty (or probably impossible) for minification
- Cannot be migrated or be used for other pages
- Cannot be cached (needs to be downloaded every time the page is loaded)
- No separation of concerns (harder to maintain)
However, it's also good in that you know the JavaScript code needed for a section of HTML is going to be there for it. Rather than having to assert and build up some inclusion at the top of the file.
So, rather than "if you're going to use this HTML, make sure you import xyz.js" you can just include the HTML and be done with it.
So, it's not necessarily horrible evil. Perhaps not spectacularly awesome, but not utterly terrible either. It kind of depends on the intent.
See the Yahoo UI for best practice: http://developer.yahoo.com/performance/rules.html (JavaScript at the bottom of the page)
It's certainly legal; I've seen it on a few pages here on Exforsys for example.
Now this is a tutorial site showing the basics of HTML and JavaScript so in that context it's perfectly understandable. However, I wouldn't like to see it in production code for anything more than a simple statement or two. Without seeing what you've replaced by // Some JavaScript code here I wouldn't like to comment.
There shouldn't be any browser issues with this though.
It is valid to add <script> in body, but Internet Explorer really doesn't likes it. So to be on the safer side, make sure you have your scripts inside the <head> tag.
That was really creating havoc (especially for Internet Explorer) in the project which we are working on.
I assume that your team is doing this either because they want to insert a script dynamically, or that they are writing a script that will fire at page load.
I wouldn't say there's anything wrong with doing this when ABSOLUTELY NECESSARY, (as long as it's in a CDATA block), but outside of that, I would recommend to your team that they use a script library like Prototype or jQuery, and keep the scripts external to the page. This is usually cleaner, and libraries will sometimes force a bit of cleanliness to the code, which I would bet isn't happening currently.
I also wouldn't run any time-consuming functions in inline script tags, as these happen on page load, and as Jason stated above, could slow the load of the page. All script libraries have neat functions that allow you to do things on load of the page, and will give you the option of when in the page load to fire them, such as after the DOM is loaded.
It's one of many, many best practices that's as much about improving performance as it is about improving your approach to programming.
Ultimately in web development, getting the product out matters the most!
It is perfectly valid, though it might hurt maintainability. See also Where should I put <script> tags in HTML markup? and Why does the call to this jQuery function fail in Firefox?.
The oft-stated recommendation that scripts should be kept in the header is to ensure that the script is loaded before it is called. This is only an issue for certain event handlers. For other types of script, it doesn't matter, and for some types (such as document.write), it doesn't make any sense.
If you have an editor that can handle both HTML and JavaScript syntax simultaneously. And if you like to first read a few lines of HTML and then JavaScript cpde...sure. Go for it.
A few things:
- It's completely valid code-wise.
- It's completely unrecommended.
Doing this slows down your page load considerably as the JavaScript code must execute before any of the rest of the page can render. If you're doing a lot of work in that JavaScript code, your browser could hang. You should try to (whenever possible) load your JavaScript code dynamically and at the end of your page (preferably before the </body> tag).
Purchase and read High Performance JavaScript. It will change the way you write JavaScript code.
'programing' 카테고리의 다른 글
| Python 사전에 해당하는 Java (0) | 2020.09.25 |
|---|---|
| 개체가 Entity Framework의 데이터 컨텍스트에 이미 연결되어 있는지 확인할 수 있습니까? (0) | 2020.09.25 |
| 자바 : for 루프 초기화에서 여러 변수를 초기화 하시겠습니까? (0) | 2020.09.25 |
| 시작시 Windows 7에서 관리자로 프로그램을 자동으로 실행하는 방법은 무엇입니까? (0) | 2020.09.25 |
| M_PI는 math.h에서는 작동하지만 Visual Studio의 cmath에서는 작동하지 않습니다. (0) | 2020.09.25 |