I am working on some pretty old code and in every jsp file where there is a javaScript block I see some bizarre Syntax. It goes like :
<script language="JavaScript">
<!--
here is the main code (mixed jsp and javaScript)
//-->
</script>
neccesity <!-- code here //-->
I don't find any necessity for <!-- //--> this syntax. But to remove these from the whole project I really have to be sure why these syntax was used.
Does those had any significance previously, I mean for browser issue or something?
Or,
Just a simple mistake which were carried on.?
HTML style comments in javascript date back to a time when not all browsers supported javascript, so would render the code as text. The <script> tag was just assumed to be just like any other unknown tag, so the tag itself was not rendered, but the contents were
I don't think any current browser would have a problem with it, but I would recommend getting rid of it, because who knows what the future will bring
Does those had any significance previously, I mean for browser issue or something?
Yes, it used to. Remember that a script tag embeds non-HTML inside an HTML document, in this case JavaScript code. Since the content of the script tag isn't HTML, but is being parsed by an HTML parser (while it looks for the ending tag), the idea was to use an HTML comment (<!-- ... -->) to contain the JavaScript code, so the HTML parser wouldn't get confused by HTML-like things within the JavaScript code, and so really old browsers that didn't understand script tags at all wouldn't show the "text" inside them.
The one you've quoted is one of many variations.
There's no need, at all, to do this in an HTML document, with modern browsers — or even with really old browsers, at this point.
In an XHTML document, you do need to do something, but what's shown there is likely to be insufficient; you'd need a CDATA section instead.
Assuming you're writing HTML5 documents (<!doctype html>), you can remove those comments from the JSPs.
As stated here: http://www.w3schools.com/tags/tag_comment.asp
You can also use the comment tag to "hide" scripts from browsers without support for scripts (so they don't show them as plain text)
Nowadays not really an issue I suppose. But may not be the best idea to get rid of them.
Those are comments, just removed if no documentation comments are there
Back in the days there were all sorts of tricks used to make sure that the content looked decent even if the user had javascript or cookies disabled.
This looks like it was meant for hiding the javascript, if the browser didn't understand Javascript.
Related
Javascript best practices & conventions, such as those emphasized by John Resig and by Nicholas Zachas, author of book Maintainable JavaScript, suggest using HTML comments or script tags with a custom type to store HTML templates.
Comment example:
<div id="myTemplate">
<!-- <ul><li>$item</li></ul> -->
</div>
<script>
var myTemplate = document.getElementById('myTemplate').childNodes[0].data;
var myHtml = myTemplate.replace(/\$item/g, itemValue);
</script>
Script tag example:
<script id="myTemplate" type="text/x-html-template">
<ul><li>$item</li></ul>
</script>
<script>
var myTemplate = document.getElementById('myTemplate').innerHTML;
var myHtml = myTemplate.replace(/\$item/g, itemValue);
</script>
I strongly dislike the comment-based templating because comments are supposed to be just that--comments, intended to be ignored by the functioning application--and as such I'm a little bewildered as to how it even gets to be suggested by JS gurus.
The script tag templating makes a lot more sense, and I'd normally call it a best if not wonderful practice because the purpose and initial non-function are well-delineated. My only issue is that in some modern editors the color highlighting, autocompletion, auto markup validation, etc., are all lost while working within the script tag.
An approach to templating I've taken in the past is to put it all in a container div, then classify the container div as class="template", then in CSS mark it as ".template { display: none; }".
<div id="myTemplate" class="template">
<ul><li>$item</li></ul>
</div>
<script>
var myTemplate = document.getElementById('myTemplate').innerHTML;
var myHtml = myTemplate.replace(/\$item/g, itemValue);
</script>
This has worked fine for me, although the DOM parser and renderer obviously processes the data up front unnecessarily, but I'm not sure whether this is really all that big of an issue or not, as long as the templating constructs do not break HTML validity rules.
My question, then, is, what am I missing? Is the only reason why this third approach to storing template markup--that is, putting it in the DOM as display:none--is discouraged because the DOM parser and renderer will process it anyway? Or are there other reasons, perhaps technical, that I haven't come across yet? I'd like to know because, again, I want to take advantage of my editor's ability to help me fine tune a proper HTML template.
I think that the best method is using the <script> tag. But for your editor,
it must has a solution to add HTML support into the <script> tag with type="html/template-something" too.
For example I code in Sublime Text, and when I want to write a script template tag,
my editor showed me something like this:
As you see, the h1 tag inside the script tag, is different from real h1 in my HTML.
So I search on the internet, and find a solution: finding a file name called HTML.tmLanguage and make this changes:
// change this line
<string>(?:^\s+)?(<)((?i:script))\b(?![^>]*/>)</string>
// to this line
<string>(?:^\s+)?(<)((?i:script))\b(?!([^>]*text/template[^>]*|[^>]*/>))</string>
And after that, I get this result in my editor:
I'm sure there must be a solution for your editor.
Visual Studio 2012
In Visual Studio 2012, if you use the script like this:
<script id="myTemplate" type="text/html">
it will parse the content within it as HTML.
display: none;
Your last solutions, using display: none isn't good, because Search Engines will index the content within it, see this:
Is hidden content (display: none;) -indexed- by search engines?
That unnecessary parsing is why the script tag method is used.
Stating some type other than JS makes the browser ignore that block entirely. Thus, you save processing time and memory. But you might think "Surely users have powerful machines". Not necessarily.
Page performance is a lot slower on mobile, than on the desktop. Mobile has limited memory and processing power. So parsing that hidden block of HTML is unnecessary.
Also, you'll never know what's in the template. It could contain tables with 10k rows. Scripts run in those hidden blocks. It could contain heavy scripts that may contain blocking elements like synchronous XHRs or loops that run 100k times. Who knows!
Additionally, you'd be creating DOM elements and getting them as strings. Why not make them strings in the first place? Skip the DOM building part.
They are templates, you should be running them as needed, not unnecessarily. Unless you know what's inside those hidden tags of yours, then sure, why not? But releasing to the public or making it a generic guideline, I'd stick to the safer method.
<script type="text/javascript" language="JavaScript">
<!--
alert('foo');
//-->
</script>
It's used all over in my company's grails app, but I know < is an illegal javascript character...
Should the <!-- be like //<!-- instead?
No, it is not illegal. From the specification:
The JavaScript engine allows the string "<!--" to occur at the start of a SCRIPT element, and ignores further characters until the end of the line.
It is, however, pointless. It is designed to stop browsers that do not recognise the script element rending the contents as text. The script element has been supported since Netscape 2! This makes the use of that syntax completely pointless today.
If, however, you are using XHTML then it is actively harmful. Since script elements don't contain intrinsic CDATA, markup inside them is treated as markup and not CDATA, so it would actually comment the script out (if the document was processed as XHTML and not tag soup, which would require an application/xhtml+xml content-type).
Should the <!-- be like //<!-- instead?
No, that would (partially) defeat the object.
It's allowed, but it shouldn't be used. It was originally to prevent the JavaScript text showing up in Mosaic FWIR.
It's the old way to make sure JavaScript didn't show up as text if the browser didn't support JavaScript.
See here.
It shouldn't be used.
It hasn't been required since Netscape 1.0
See http://javascript.crockford.com/script.html for what Douglas Crockford has to say about it.
<!-- is a special construct in Javascript, grandfathered in from the days when Javascript was new, and JS-unaware browsers were everywhere. In other words, Javascript understands and ignores the HTML comment opening tag. It's treated as whitespace, and serves only to hide the JS from ancient browsers which don't know Javascript, or don't even know what the <script> tag is.
The html comment closing tag, on the other hand, is NOT a Javascript language construct, and must be commented out with a JS // comment.
I've seen this tag used after javascript functions for over a decade now and never asked WHY. It's seen in most of the tutorials I've seen over this time, but I usually leave it out... it doesn't seem to have an effect one way or another. Can anyone enlighten me as to why this is used?
If it's just to signify the end of a javascript function, wouldn't the right brace be adequate? If it's for a series of functions, the ending script tag is used.
I doubt I need an example, but for all the other readers out there that are also wondering what it's for, here's some code:
function helloWorld() {
document.write('Hello World');
}
//-->
Thanks in advance!
It's a holdover from the days when browsers without JS support were reasonably common. If you were including JS code directly in an HTML file, you'd include HTML comment tags (<!-- -->) around the code so those browsers didn't display it as part of the page. The reason for // --> is so that browsers that do support JS didn't try to interpret the closing HTML comment as part of the JS code.
Back in the days, some browsers did not handle javascript so to avoid errors, you'd put the javascript code inside an HTML comment block "".
Today, the XHTML standards says you should escape your script like
<script type="text/javascript">
<![CDATA[
... unescaped script content ...
]]>
</script>
You don't have to do that for HTML. Refer to:
http://www.w3.org/TR/xhtml1/
http://www.w3schools.com/tags/tag_script.asp
It's to comment out the code, so legacy browsers that don't support JS won't see it.
That's probably pretty much useless nowadays.
Note that it also needs a <!-- in the beginning to make it a comment.
Read this: http://lachy.id.au/log/2005/05/script-comments
If you notice, you can also usually see a <!-- before the scripts.
That syntax is used so browser that don't support Javascript will ignore the body of those scripts.
In fact, in html, anything surrounded by <!-- and --> is considered to be a comment
It's also useful if you're validating your html code, so the js doesn't appear as invalid html markup. As everyone mentioned however, it's fairly obsolete. I personally try never to have inline javascript, always in an external file that can be cached, which makes this style of coding useless
For browsers that do not understand JavaScript or if JavaScript is manually turned off these start <!-- and end html_comment_tags --> will help the bad_data inside the script > / ? < & ^ % # ) ! - ( to be commented out
If a browser understands javascripts it will not parse the last comment_ending tag--> due to the // placed before the html_comment_end tag--> and if the browser does not understand the meaning of // comment tags of javascript(simply because jscript is turned off) then it obviously parses the --> in the usual way and comments out everything inside the <script></script> including the //
I 've got a very interesting thing with an html here.
<html>
<head>
<script language="Javascript">
var str="me&myhtml";
function delimit(){
document.write(str);
document.write("<hr>");
}
</script>
</head>
<body onload="delimit()">
</body>
</html>
You see 'me&myhtml' with a line beneath. However, if you comment //document.write("<hr>");
then you just see 'me', which is weird.
Thing is, javascript normally doesn't read '&', but rather interprets as a command. However, if you have any document.write() with at least 6 characters, or a 'br', or 'hr', then it displays '&' as it is.
Any ideas?
If there is no HTML tag after &myhtml JavaScript or the HTML rendering engine probably interprets it as an unrecognized or incomplete entity (lacking an ending ;) and does not render it. If you follow me&myhtml with an HTML tag, then JavaScript or the HTML rendering engine recognizes that &myhtml is not an incomplete entity because it is followed by an HTML tag instead of a ;.
It doesn't matter what HTML tag you follow the string with, <a> or <p> work just as well as <br>.
The behavior is not consistent across all browsers. IE 6, 7 & 8 and Firefox 2, 3 & 3.5 behave the way you describe, Safari for Windows 3 & 4 render nothing when you comment out the second document.write() or do something like document.write("abc");. Opera 9.64 & 10b3 render the text correctly regardless of the content of the second write().
Note that using document.write() in the onload event without writing out correctly formatted and valid HTML (complete with doctype and <html>, <head>, etc) is probably a bug anyway. Note the problem does not manifest itself if you do:
<html>
<head>
<script>
function delimit() {
document.write('me&myhtml');
}
</script>
</head>
<body>
<script>
delimit();
</script>
</body>
</html>
To answer your question, it is a bug in either the implementation of a specification, or an undefined part of a specification that each browser implements differently. What you are doing is slightly incorrect, the outcome of that slightly incorrect code is not defined and it can not be relied on to behave consistently across all of the major browsers in use today. What you are doing should be avoided.
Try str = "me&myhtml";
I just wanted to know why this is happening.
Well, the browser doesn't yet know whether your &myhtml is an entity reference you haven't finished writing yet, or just broken code it will have to fix up. For example you can say:
document.write('&eac');
document.write('ute;');
(Of course there is no entity reference like &myhtmlpotato; that you could be referring to, but the parser doesn't know that yet.)
If you let the parser know there's no more bits of entity reference coming, by document-writing something that couldn't possibly be in an entity reference, such as a <tag>, or spaces, it'll give up and decide your code was simply broken, and fix it.
Normally the end of the page would be a place where this would happen, but you don't have an end of the page, because the script isn't doing what you think it's doing.
Instead of calling document.write() during the original page loading process when it can write some content to your current page, you're calling it in the onload, by which time the document is completely loaded and you can't add to it. In this state, calling document.write() actually calls document.open() implicitly, destroying the current page and starting a new one, to which you then write ‘my&myhtml’. That new page you have opened stays open and not fully loaded until you call document.close() to tell it you aren't going to write any more to it. At that point your partial entity reference will be resolved as bad markup and fixed.
It probably has to do with the fact that & is essentially an escaping character in HTML. If you want to write out an ampersand to the page, you should use &
Frequently, I just want to drop a bit of jQuery on an individual page. Given my early understanding of Sitefinity, I think...
I can't easily put JS in the <head>.
I could put JS in a Generic Content control, but then my JS is sitting inline in the <body>. Maybe I need to relax, but I don't usually like to put much JS in the <body>.
It feels like this kind of scenario is an afterthought. Is JS a 2nd-class citizen in Sitefinity?
JavaScript does not live in the head. Yahoo even says it is better for performance
I agree with epascarello you really shouldn't be putting your javascript in the head anyway.
And just in case you didn't know about this the jQuery framework is part of Sitefinity. The article also shows you how you can include external libraries in sitefinity from anywhere withing your project whether it be master page or user control.
Why not have the jQuery code in a separate .js file and use unobtrusive JavaScript? With jQuery you can separate behavior and markup so nicely that you should never have to include JavaScript in your head or body ever again.
Just use the standard onLoad function in jQuery and put all of your initialization code in there.
Try it, I think that you will like it! If you like using CSS for separation of presentation and markup, then jQuery can do the same thing with behavior and markup.
This is an old question, but one way you can do it now is:
Add a Javascript block (under Scripts & Styles), and then paste the URL to the jquery code:
http://ajax.googleapis.com/ajax/libs/jquery/1.8/jquery.min.js
Then add another Javascript block with your jquery, like:
$(document).ready(function() {
alert("hello");
});
Or you can also paste the URL to your js file.