I'm a Blogger blog user. I once see a template locating script inside CDATA tag like this:
<script type='text/javascript'>
/*<![CDATA[*/
------script------
/*]]>*/
</script>
While, I before see a similiar code like this:
<script type='text/javascript'>
//<![CDATA[
------script------
//]]>
</script>
The only different is that /*<![CDATA[*/ and //<![CDATA[. I wonder whether those both have different effect, or advantages. I also wonder the purpose of differing those. Here is always waiting insight from you, and your answer is appreciated.
There is no difference.
// comments out the line
/* comments out code until it finds a */ … which is at the end of the line in your example.
// comments out the text until the end of the line
/* comments out everything, irrespective of line endings, until it encounters */
Since the */ is at the end of the line in your example, there is effectively no difference. However, there is a reason why you sometimes see /* */ comments instead of // comments for a CDATA section. Specifically, if the HTTP response body was being assembled programmatically, and you didn't have control over it, and the process removed line break characters it deemed unnecessary (in order to minimize the size of the output), and your script immediately followed the CDATA comment (because the process overzealously removed a line break it shouldn't have), it might look like this:
//<![CDATA[var MyVariable = 'This statement does something.';
In this case, MyVariable would not be declared or assigned because the statement is really just part of the comment. But if /* */ were used, as in this example:
/*<![CDATA[*/var MyVariable = 'This statement does something.';
...the comment ends before the code begins and the code would be executed as intended.
It's a fine point, but that's the reason you see it done.
Related
I am trying to parse a HTML code in order to extract all links in it. To avoid unavailable links I remove the commented code that begins with <!-- and ends with --> .Here comes the problem: In the HTML code I may find some JavaScript code, for example:
<html>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">
<!-- Begin
if (document.images) {
var pic2 = new Image(); // for the inactive image
pic2.src = "pic2.jpg";
var title2 = new Image();
title2.src = "title2.jpg";
}
...
-->
and the weird thing is that the js code is commented but it still works. So, if I remove that code, the result won't be as expected. What should I do in order to identify when I'm facing with unused commented code and when that commented code is functional?
the weird thing is that the js code is commented but it still works
Those aren't comments. Is is just syntax allowed inside script (and style) elements that follows the comment syntax so that browsers which predate script and style don't render the code as text.
What should I do in order to identify when I'm facing with unused commented code and when that commented code is functional?
Write a real HTML parser, following the parsing specification, and then remove any comment nodes from the generated DOM.
As a dirty (but possibly quick) solution, you could just ignore comments inside elements marked as containing CDATA in the HTML 4.01 DTD.
the weird thing is that the js code is commented but it still works
There is nothing weird about it. The comments <!-- --> only work in HTML, not JavaScript. Your above code will still work since you've put these comments within the <script> tags.
The only difference it makes is that if the user has disabled JavaScript on his/her browser, he won't see the code printed on the browser (since HTML will parse those comments in the absence of JavaScript).
You need to comment out the whole <script> block. e.g.
<!-- <script>
...some javascript code...
</script> -->
I'm trying to make a HTML/JS/CSS script that counts the number of days until some birthdays.
Last year, I made one, it still works, I copied and pasted the same script, and changed the names/dates and now it doesn't work.
Working one: http://jsbin.com/iFItOYo/16/edit
Broken one: http://jsbin.com/iFItOYo/14/edit
You made a couple of mistakes:
You forgot the closing bracket at this point:
fatima = new Date(thisYr,2,7)
if (fatima.getTime() < now.getTime()) {
fatima.setYear(nextYr)
} <-- this one is missing
In the beginning you state now = new Date, which should be now = new Date()
You forgot to close the <!-- that you begin in the top of your code
It's quite simple, you are missing the the closing tag of the comment '-->', and thus you get an unexpected end of input error.
Also putting your script inside of a comment is not such a good practice, use cross browser CSS if comments
Also, use indenting, and lower case HTML, with indenting as well.
In addition, your script tag is not valid in any HTML \ XHTML spec.
Hope this helps.
Another issue:
<SCRIPT LANGUAGE=JAVASCRIPT TYPE="TEXT/JAVASCRIPT"> which comes after the h3 opening tag is also missing.
Perhaps this question belongs to code review.
You deleted the <script ...> tag right after the opening <body> tag.
There is a lot of mistakes in your code. You should do something to view it clearly so that you can see your mistake easily like indent code, write all in lowercase (both javascript and html), comment and closing code more exactly...
To fix the one not run you must do these 3 points:
1 Like koenp answer, closing this :
falisha = new Date(thisYr,2,20)
if (falisha.getTime() < now.getTime()) {
falisha.setYear(nextYr)
} <== add this bracket
2 Missing the script tag before calling the document write function in body
<H3>The following are the numbers of days until class birthdays (2011-12):
<SCRIPT LANGUAGE=JAVASCRIPT TYPE="TEXT/JAVASCRIPT"> <== add this
3 Wrong variable in this line
if (anahi.getTime() < now.getTime()) {
anihi.setYear(nextYr) <== change it to anahi (of course)
}
I've just run into a pathological case with HTML parsing. I've always thought that a <script> tag would run until the first closing </script> tag. But it turns out this is not always the case.
This is valid:
<script><!--
alert('<script></script>');
--></script>
And even this is valid:
<script><!--
alert('<script></script>');
</script>
But this is not:
<script><!--
alert('</script>');
--></script>
And neither is this:
<script>
alert('<script></script>');
</script>
This behavior is consistent in Firefox and Chrome. So, as hard as it is to believe, browsers seem to accept an open+close script tag inside an html comment inside a script tag. So the question is how do browser really parse script tags?
This matters because the HTML parsing library I'm using, Nokogiri, assumed the obvious (but incorrect) until-the-first-closing-tag rule and did not handle this edge case. I imagine most other libraries would not handle it either.
After poring over the links given by Tim and Jukka I came to the following answer:
after the opening <script> tag, the parser goes to data1 state
if <!-- is encountered while in data1 state, switch to data2 state
if --> is encountered while in any state, switch to data1 state
if <script[\s/>] is encountered while in data2 state, switch to data3 state
if </script[\s/>] is encountered while in data3 state, switch to data2 state
if </script[\s/>] is encountered while in any other state, stop parsing
All the examples are invalid as per the HTML 4.01 specification: the content of script is declared as CDATA, and the description of CDATA says:
“Although the STYLE and SCRIPT elements use CDATA for their data model, for these elements, CDATA must be handled differently by user agents. Markup and entities must be treated as raw text and passed to the application as is. The first occurrence of the character sequence "</" (end-tag open delimiter) is treated as terminating the end of the element's content. In valid documents, this would be the end tag for the element.”
As you have observed, browsers might not enforce this rule but instead recognize pairs of start and end tags, in some situations. From the spec perspective, this is handling of invalid documents, i.e. error processing. It is not clear what exactly they are doing here and why. It seems to depend on the presence of <!--, which should not have any effect on HTML 4.01 parsing (it is not a comment opener in CDATA content).
In XHTML, partly different rules apply, because in XHTML, <!-- opens a comment within the content of a script element.
As an aside, all the examples are invalid HTML 4.01 and invalid XHTML due to the lack of the type attribute in script. The attribute is not needed (browsers default to treating the content as JavaScript), but it’s required by those specs.
In HTML5, other rules apply. They are rather complicated, and they are supposed to describe browser behavior. In addition to imposing restrictions on content (forbidding e.g. <!-- without matching -->), HTML5 also specifies parsing rules.
Content of tags is still HTML, unless you mark it as not being HTML. In HTML, <word> is taken to be a tag, < needs to be written as < to avoid this behaviour. Alternately, you want to make the contents of <script> a text node; use this formula:
<script type="text/javascript">
//<![CDATA[
// your code, with < and & and "", woohoo!
//]]>
</script>
<![CDATA[ ... ]]> delineates a part of the document as pure text, without markup. Slashes are there so JavaScript wouldn't get confused; the first set of slashes is outside CDATA, but they're HTML-safe, so there's no problem.
EDIT: Just realised the question is about parsing, not writing HTML. Oops.
Hypothetically, if the tags are parsed first and the comments are parsed later, the HTML parser would give you those results.
(I don't mean this is necessarily the case, just a possible explanation only.)
1st case
<script><!--
alert('<script></script>');
--></script>
There is a set of <script></script> inside another <script></script>. The parser may ignore the name of the tags first and just checks for proper opening and closing of those tags. Then it parse the comments.
<script><!--
--></script>
So this is valid.
2nd case
<script><!--
alert('<script></script>');
</script>
There is a set of <script></script> inside another <script></script>. Then it parse the comments.
<script><!--
The comment extends all the way to the end of the document. This is not strictly valid, but the browser handles it correctly.
3rd case
<script><!--
alert('</script>');
--></script>
There is a single closing tag inside the set of <script></script>. It is invalidated before it parse out the </script> as comments.
4th case
<script>
alert('<script></script>');
</script>
There is a set of <script></script> inside another <script></script>, and there are no comments. The first pass is valid but then it really looks into the tags to see what they are. It may not accept a pair of <script> tags inside another one so it invalidates the case.
I have an external javascript file that I want to, upon include, write some HTML to the end of the web page.
Upon doing so though I get the error Missing } in XML expression on the line that uses dropdownhtml.
Here is my code
var dropdownhtml = '<div id="dropdown"></div>';
$(document).ready(function(){
//$(document).append(dropdownhtml);
alert(dropdownhtml);
});
The XHTML webpage that includes this file does so like this:
<script type="text/javascript" src="/web/resources/js/dropdownmenu.js"></script>
Doing either append or alert throws up the same error, what is going wrong?
I got this error because I called an external JavaScript within an existing JavaScript, so ended up with:
<script type="text/javascript">
<script type="text/javascript">
code
</script>
code
</script>
Edit Your update changes the question a bit. :-)
There's nothing wrong with your quoted Javascript or with the script tag that includes it, the problem must lie elsewhere on the page.
The old answer:
If you're including Javascript inside an XML document, you must wrap it up in a CDATA section, or you'll run into trouble like this because the XML parser neither knows nor cares about your Javascript quotes, and instead seems markup (your <div>s in the string).
E.g.:
<foo>
<bar><![CDATA[
var dropdownhtml = '<div id="dropdown"></div>';
$(document).ready(function(){
//$(document).append(dropdownhtml);
alert(dropdownhtml);
});
]]></bar>
</foo>
Naturally you need to ensure that the ]]> sequence never appears in a string (or comment, etc.) your script, but that's quite easy to do (for instance: "Be sure to interrupt the end sequence with a harmless backslash like this: ]]\>; that escape just resolves to > anyway.")
There's definitely a missing ); at the end of your code sample. Don't get where there may be a missing } though.
I have empty script on my page
<script src=""></script>
And this leads to such error
I see so many things like this:
S = "<scr" + "ipt language=\"JavaScript1.2\">\n<!--\n";
Why do they do this, is there an application/browser that messes up if you just use straight "<script>"?
Have a look at this question:
Javascript external script loading strangeness.
Taken from bobince's answer:
To see the problem, look at that top
line in its script element:
<script type="text/javascript">
document.write('<script src="set1.aspx?v=1234"
type="text/javascript"></script>');
</script>
So an HTML parser comes along and sees
the opening <script> tag. Inside
<script>, normal <tag> parsing
is disabled (in SGML terms, the
element has CDATA content). To find
where the script block ends, the HTML
parser looks for the matching
close-tag </script>.
The first one it finds is the one
inside the string literal. An HTML
parser can't know that it's inside a
string literal, because HTML parsers
don't know anything about JavaScript
syntax, they only know about CDATA. So
what you are actually saying is:
<script type="text/javascript">
document.write('<script src="set1.aspx?v=1234"
type="text/javascript">
</script>
That is, an unclosed string literal
and an unfinished function call. These
result in JavaScript errors and the
desired script tag is never written.
A common attempt to solve the problem
is:
document.write('...</scr' + 'ipt>');
This wouldn't explain why it's done in the start tag though.
The more appropriate way to append scripts is to use the DOM.
Create an element of type <script>. See documentation for document.createElement.
Set its attributes (src, type etc.)
Use body.appendChild to add this to the DOM.
This is a much cleaner approach.