开发者

some general JavaScript questions

开发者 https://www.devze.com 2023-01-11 08:47 出处:网络
From the Flattr Javascript API description: <script type=\"text/javascript\"> <!--//--><![CDATA[//><!--

From the Flattr Javascript API description:

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

    (function() {
        var s = document.createElement('script'), t = document.getElementsByTagName('script')[0];

        s.type = 'text/javascript';
        s.async = true;
        s.src = 'http://api开发者_开发知识库.flattr.com/js/0.5.0/load.js';

        t.parentNode.insertBefore(s, t);
    })();

//--><!]]>
</script>

I am a bit curious about the <!--//--><![CDATA[//><!-- and //--><!]]>. I guess that are some hacks to trick old browsers who don't understand the <script>-tag. But isn't the <!-- enough? What exactly is the CDATA stuff about? And if I don't care about old browsers, all this is obsolete anyway, right? (Btw., does someone know any browser at all who would get confused if I would not put this stuff there?)

Then I wonder about the function definition. Why is it there? Why not call the code directly? Is it to not spam the global namespace? If so, aren't there easier, less hacky ways to do this, e.g. just putting the code into {}?


It is a combination of hacks that, between them:

  • Cope with browsers from before HTML introduced the script element (over a decade ago)
  • Cope with JavaScript that includes &, < and > in XHTML
  • Compensate for the XHTML solution when the XHTML is treated as HTML instead of XHTML (i.e. almost always)
  • Stops the other hacks from interfering with each other

Frankly, you can (and should) forget about browsers which don't understand <script> (note, this is not the same as not supporting JS, it means not recognizing the element at all so treating it (effectively) as a <span>). If you do that and use XHTML then you can just use CDATA flags prefixed with JS comments ( // ).

You should generally also avoid XHTML. Unless you are dealing with a server side system that insists of generating XHTML and it is more effort to convert it to HTML then it is to deal with all the issues of writing HTML-Compatible XHTML, then XHTML is almost never worth the cost.

If you aren't using XHTML or caring about browsers which don't even speak HTTP 1.1, then you just need the script tags and the script, without any wrappers at all.

In this particular example, you don't need the CDATA flags anyway - the script doesn't include any characters that have special meaning in XML, so you don't need an instruction to treat those characters as text instead of markup.


The CDATA is useless in today's HTML5 days, and the (function() {...})() wraps the code to make the var declarations local to that function.
Global variables could cause an unwanted interaction with another code on the page.


The comment stuff was required for netscape 1, since script tags where introduced in netscape 2. So yeah... not really needed anymore ;)

text="text/javascript"

Is not needed either, perhaps for IE3 or 4, but the default for script tags is always javascript.

{} block scope does not exist in JavaScript, there's only the global and function scope, so wrapping code inside a function and always using 'var' declarations to prevent global pollution is required.

(function(){}());

Cannot be called a hack anymore, it's a perfect legitimate technique although perhaps a bit scary to look out for layman. The following might be considered prettier...

function init(){
    // code
}
init();

But then you are introducing a global function called 'init'. Besides, most seasoned JS programmers are familiar with, and recognize the self calling anonymous function pattern, here's a more useful one.

(function(global, doc, undefined){
    //code
}(this, document));

the 'global' variable is now a reference to the window object, 'doc' variable now is a shorthand reference to document, and undefined is undefined. Why the 'undefined' paramater? Because it's possible that some nitwit assigned a value to the global 'undefined' variable... Might be redundant, but when writing libs/frameworks/toolkits, it is something to keep in mind ;)

0

精彩评论

暂无评论...
验证码 换一张
取 消