missing ) after argument list
markar...@gmail.com
------------------------------------------------------------
missing ) after argument list
setTimeout('breakOut',5000);
------------------------------------------------------------
Here is the HTML that I'm producing:
<html>
<head>
<script type="text/javascript">
<!--
function breakOut() {
top.location.href = 'https://foo.com';
}
// -->
</script>
<body onLoad="setTimeout('breakOut()',5ØØØ);">
You have been logged out of the control panel due to inactivity for
your security.
</body>
</html>
Thomas 'PointedEars' Lahn
> Why is Firefox complaining with this error:
>
> ------------------------------------------------------------
> missing ) after argument list
>
> setTimeout('breakOut',5000);
> ------------------------------------------------------------
>
> Here is the HTML that I'm producing:
>
> <html>
> <head>
<URL:http://validator.w3.org/>
> <script type="text/javascript">
> <!--
^^^^
Unnecessary and potentially harmful.
> function breakOut() {
> top.location.href = 'https://foo.com';
top.location = 'https://foo.com/';
is sufficient and not prone to the Same Origin Policy.
> }
> // -->
^^^^^^
Unnecessary.
> </script>
> <body onLoad="setTimeout('breakOut()',5ØØØ);">
^^^
This is not the zero ('0') character. ---'
> [...]
PointedEars
markar...@gmail.com
Why are the <!-- //--> considered harmful? Aren't they supposed to help
JS-crippled browsers degrade?
- Mark
Randy Webb
> That worked!
>
> Why are the <!-- //--> considered harmful? Aren't they supposed to help
> JS-crippled browsers degrade?
They aren't harmful in an HTML document. They simply aren't needed is
all. There are no modern browsers that do not understand the script tag
and what to do with it in the absence of script. Whether that absence is
caused by disabling or the lack of script support at all.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Thomas 'PointedEars' Lahn
> Why are the <!-- //--> considered harmful?
/Please/, ask Google (Groups) before you ask here. I am tired of explaining
that over and over again.
> Aren't they supposed to help JS-crippled browsers degrade?
No. All UAs have to recognize the `script' element since HTML 3.2 and to
ignore it if not applicable.
PointedEars
Thomas 'PointedEars' Lahn
> markar...@gmail.com said the following on 12/14/2005 12:55 PM:
>> Why are the <!-- //--> considered harmful? Aren't they supposed to help
>> JS-crippled browsers degrade?
>
> They aren't harmful in an HTML document. [...]
Wrong.
PointedEars
Randy Webb
> markar...@gmail.com wrote:
>
>
>>Why are the <!-- //--> considered harmful?
>
>
> /Please/, ask Google (Groups) before you ask here. I am tired of explaining
> that over and over again.
Then obviously you are failing in your endeavors to pedantically explain it.
It is pedantic because it is irrelevant.
Randy Webb
Wrong again PointedHead. Unless of course you can name a modern browser
that with *Valid HTML* has a problem with it. Your move.
There is a very good reason why I wrote "in an HTML document".
Zoe Brown
> explaining
> that over and over again.
you mentioned it in teh first place !!
Matt Kruse
> No. All UAs have to recognize the `script' element since HTML 3.2
> and to ignore it if not applicable.
Your assumption is that everyone is using a browser which supports HTML 3.2
or higher.
While this may be a realistic assumption, in theory any user could be using
an ancient browser. And you like theory quite a bit.
--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
VK
Matt Kruse wrote:
> Thomas 'PointedEars' Lahn wrote:
> > No. All UAs have to recognize the `script' element since HTML 3.2
> > and to ignore it if not applicable.
>
> Your assumption is that everyone is using a browser which supports HTML 3.2
> or higher.
>
> While this may be a realistic assumption, in theory any user could be using
> an ancient browser.
... or have a personal reason to support an ancient browser. If I like
to have my page rendered nicely in NCSA Mosaic then why should it be
prohibited by anyone? - while supporting not too much younger IE 4.x is
supposed to be a valid (or even welcomed) action?
Also let do not mix the terms "harmful" and "not necessary".
<!-- --> tag is valid HTML comment tag since the first draft and till
now and for forever. (Unlike by the way [CDATA] block which is *XML
tag* and has nothing to do with HTML). So <!-- --> is no more "harmful"
than <html> or <body>
Is it necessary? - *Mostly* no. But if one likes to use it - let's not
make a crime from it. It is an overkill precaution, but no more
*criminal* or *overkill* then checking
if (document.getElementById)
The chances to be useful in both cases are equal (somewhere around
0.001%) but still above zero.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> No. All UAs have to recognize the `script' element since HTML 3.2
>> and to ignore it if not applicable.
>
> Your assumption is that everyone is using a browser which supports HTML
> 3.2 or higher.
>
> While this may be a realistic assumption, in theory any user could
> be using an ancient browser. And you like theory quite a bit.
Both in theory and in practice, RFC2854 as of June 2000 (that is 5 years
and 6 months ago), obsoletes _all_ HTML versions prior to 3.2 (which was
introduced on January 14, 1997, 9 years and 11 months ago!), hence
obsoletes all pre-3.2 UAs (which would not be usable today anyway). And
even if there were such an obsolete UA still in use (which includes that
it would need to be usable on current operating systems and hardware), it
would not (be allowed to) render content within the `head' element as that
has not changed since HTML 1.0.
I am completely sure I mentioned that before.
BTW: A nice resource I have found is
<URL:http://www.yourhtmlsource.com/starthere/historyofhtml.html>
PointedEars
Thomas 'PointedEars' Lahn
> Also let do not mix the terms "harmful" and "not necessary".
>
> <!-- --> tag is valid HTML comment tag since the first draft and till now
> and for forever.
Nonsense! `<!' introduces an SGML declaration, `--' starts and ends a
comment within an SGML declaration, and `>' ends the declaration. It
is basically `<!>' to an SGML parser, an empty declaration. Everything
else is tag soup behavior that cannot be assumed. Which is why Mozilla/5.0
will not consider <!------> a closed comment in Strict Mode and does not
render the adjacent markup.
> (Unlike by the way [CDATA] block which is *XML tag*
Nonsense! CDATA (Character DATA) is an SGML data type and it is possible
to declare data CDATA using the respective declaration in XML, which is an
SGML subset:
<![CDATA[
This is declared CDATA content if it was not CDATA
]]>
> and has nothing to do with HTML).
Which is why it is harmful in XHTML, too.
> So <!-- --> is no more "harmful" than <html> or <body>
Within CDATA, which is BTW the _default_ for the content of the `script'
element in HTML, '<!-- ... -->' is _not_ an empty declaration which is why
an SGML parser would pass it to the script engine could be passed it as-is
which would be a syntax error. As neither a HTML UA nor a script engine
is required to ignore that, the label "potentially harmful" is justified.
Even if the voices in your head tell something different.
Sigh. [psf 10.1]
PointedEars
VK
Thomas 'PointedEars' Lahn wrote:
> VK wrote:
>
> > Also let do not mix the terms "harmful" and "not necessary".
> >
> > <!-- --> tag is valid HTML comment tag since the first draft and till now
> > and for forever.
>
> Nonsense! `<!' introduces an SGML declaration,
What in the holly name any SGML issues have to do with someting loaded
as "text/html" content type?
But I'm glad you brought some twilight "shining" on this question. Now
I will never use any doctype declarations and I will stop *anyone* from
suggesting them. Really: how can we imply a desclaration written with
brute violation of ... uhm... *SGML* standards plus potentially
*harmful*?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
where:
<http://www.w3.org/TR/html4/strict.dtd>
...
<!--====== Imported Names ==========-->
... etc.
DOCTYPE - simply say NO!
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> VK wrote:
>> > Also let do not mix the terms "harmful" and "not necessary".
>> >
>> > <!-- --> tag is valid HTML comment tag since the first draft and till
>> > now and for forever.
>> Nonsense! `<!' introduces an SGML declaration,
>
> What in the holly name any SGML issues have to do with someting loaded
> as "text/html" content type?
Because HTML is an SGML application. If you had read _any_ HTML Spec,
you would have known.
> But I'm glad you brought some twilight "shining" on this question. Now
> I will never use any doctype declarations and I will stop anyone from
> suggesting them.
That is typical of you. Why avoid mistakes when it is possible to mask
them and get away with it? You are nothing but a poser, and your advice
is harmful or potentially harmful most of the time. Go away.
PointedEars
Patient Guy
news:2127874.T...@PointedEars.de:
> VK wrote:
>
>> Also let do not mix the terms "harmful" and "not necessary".
>>
>> <!-- --> tag is valid HTML comment tag since the first draft and till
>> now and for forever.
>
> Nonsense! `<!' introduces an SGML declaration, `--' starts and ends a
> comment within an SGML declaration, and `>' ends the declaration. It
> is basically `<!>' to an SGML parser, an empty declaration.
> Everything else is tag soup behavior that cannot be assumed. Which is
> why Mozilla/5.0 will not consider <!------> a closed comment in Strict
> Mode and does not render the adjacent markup.
What a load of unadulterated bandwidth waste yet again from you!!!
Take note of the following reasoning:
The letters 'c', 'a', 's', and 'e' by the themselves have certain
properties and characteristics which have meaning as characters to
Javascript, but when I put them together like this: "case"
then they become a reserved word in this interpreted language.
Isn't it funny how that works?
What would you do by your "reasoning" as exemplified above: you would
insist the characters must be considered IN and OF themselves and not be
considered in a context of "grouping" them thusly, and thus, in effect, you
would forbid the notion of words and even of Javascript itself. (I
sometimes wonder if I shouldn't do a search to see if you have already
commented on the logical non-existence or impossibility of Javascript
itself, among other ruminations involving contemplation of the navel.)
But if you don't believe me, maybe you'd like to argue with the standards-
making body called the W3 Consortium:
[from http://www.w3.org/TR/REC-html40/intro/sgmltut.html]
3.2.4 Comments
HTML comments have the following syntax:
<!-- this is a comment -->
<!-- and so is this one,
which occupies more than one line -->
White space is not permitted between the markup declaration open
delimiter("<!") and the comment open delimiter ("--"), but is permitted
between the comment close delimiter ("--") and the markup declaration
close delimiter (">"). A common error is to include a string of hyphens
("---") within a comment. Authors should avoid putting two or more
adjacent hyphens inside comments.
Information that appears between comments has no special meaning (e.g.,
character references are not interpreted as such).
Note that comments are markup.
CC: your response to this particular discussion to
toomuchtime...@w3.org.
>> (Unlike by the way [CDATA] block which is *XML tag*
>
> Nonsense! CDATA (Character DATA) is an SGML data type and it is
> possible to declare data CDATA using the respective declaration in
> XML, which is an SGML subset:
>
> <![CDATA[
> This is declared CDATA content if it was not CDATA
> ]]>
>
>> and has nothing to do with HTML).
>
> Which is why it is harmful in XHTML, too.
>
>> So <!-- --> is no more "harmful" than <html> or <body>
>
> Within CDATA, which is BTW the _default_ for the content of the
> `script' element in HTML, '<!-- ... -->' is _not_ an empty declaration
> which is why an SGML parser would pass it to the script engine could
> be passed it as-is which would be a syntax error. As neither a HTML
> UA nor a script engine is required to ignore that, the label
> "potentially harmful" is justified.
Why would an HTML user agent be parsing/interpreting content it has no
business parsing/interpreting (such as script element content)?
As for script interpreters, if they interpret HTML comment tags within
their own comment blocks, then they deserve to choke on whatever it is they
are voluntarily swallowing and should not be swallowing.
The model for creating a universal standard was set long ago with the
development of the handgun. As long as the developers agree to stick to
the standards where they exist, why will they intentionally produce
something that goes beyond the constraints of the framework set for them,
especially when in all likelihood they may do more harm than good in
"adding features" where none are called for? Why claim to render HTML
documents and not claim to interpret Javascript, but put an interpreter in
your product anyway and not tell the user, i.e., refuse to ignore what you
should be ignoring as a developer?
> Even if the voices in your head tell something different.
If a parser doesn't get an indication of the type of document it is
parsing, should it even be exposing itself to "danger" or "harm" in the
first place by attempting to read it? Seriously....
> Sigh. [psf 10.1]
>
>
> PointedEars
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> wrote [...]:
>> VK wrote:
>>> Also let do not mix the terms "harmful" and "not necessary".
>>> <!-- --> tag is valid HTML comment tag since the first draft and till
>>> now and for forever.
>>
>> Nonsense! `<!' introduces an SGML declaration, `--' starts and ends a
>> comment within an SGML declaration, and `>' ends the declaration. It
>> is basically `<!>' to an SGML parser, an empty declaration.
>> Everything else is tag soup behavior that cannot be assumed. Which is
>> why Mozilla/5.0 will not consider <!------> a closed comment in Strict
>> Mode and does not render the adjacent markup.
>
> What a load of unadulterated bandwidth waste yet again from you!!!
> [...]
> [from http://www.w3.org/TR/REC-html40/intro/sgmltut.html]
| 3.2 SGML constructs used in HTML
|
| The following sections introduce SGML constructs that are used in HTML.
| [...]
> 3.2.4 Comments
>
> HTML comments have the following syntax:
>
> <!-- this is a comment -->
> <!-- and so is this one,
> which occupies more than one line -->
>
> White space is not permitted between the markup declaration open
> delimiter("<!") and the comment open delimiter ("--"), but is permitted
> between the comment close delimiter ("--") and the markup declaration
> close delimiter (">"). A common error is to include a string of hyphens
> ("---") within a comment. Authors should avoid putting two or more
> adjacent hyphens inside comments.
> [...]
Now where is the contradiction, you address-munging, namespace-spoiling,
top-posting fool?
PointedEars
Patient Guy
news:1335752.m...@PointedEars.de:
Poster VK: <!-- --> tag is valid HTML comment tag since the first draft
and till now and for forever.
You: Nonsense! `<!' introduces an SGML declaration, `--' starts
and ends a comment within an SGML declaration, and `>' ends
the declaration.
W3 document: HTML comments have the following syntax:
<!-- this is a comment -->
Now what was hard about following that?
> , you address-munging,
the address I gave was an obvious attempt at humor....
> namespace-spoiling,
Okay...I give up...what are you trying to say here?
> top-posting
It would be true had I really in truth top-posted. But all my responses,
interspersed or otherwise, were placed BELOW the text they were responding
to.
But then you already knew that....
> fool?
Well, I have to admit that even I can occasionally be wrong and humbled.
Even by the likes of you.
The question before us is whether you have ever admitted to being wrong
and/or humbled, irrespective of the fact that you have been wrong and
humbled at times.
> PointedEars
Duncan Booth
> Poster VK: <!-- --> tag is valid HTML comment tag since the first draft
> and till now and for forever.
>
> You: Nonsense! `<!' introduces an SGML declaration, `--' starts
> and ends a comment within an SGML declaration, and `>' ends
> the declaration.
>
> W3 document: HTML comments have the following syntax:
> <!-- this is a comment -->
>
>
> Now what was hard about following that?
You missed another bit of the HTML standard:
W3 document: HTML 4 is an SGML application conforming to International
Standard ISO 8879 -- Standard Generalized Markup Language SGML (defined in
[ISO8879]).
and SGML defines a comment declaration differently than HTML.
So the question is which definition of a comment do you believe? The one
you quoted is a 'discussion' and therefore it is reasonable to assume it is
not normative. If taken literally it implies that HTML comments must
contain the text 'this is a comment', or 'and so is this one, which
occupies more than one line' so it is obvious that the statement 'HTML
comments have the following syntax' is wrong: they are giving some
examples, not specifying syntax. For the actual comment syntax you have to
fall back on the SGML standard.
VK
Duncan Booth wrote:
> You missed another bit of the HTML standard:
>
> W3 document: HTML 4 is an SGML application conforming to International
> Standard ISO 8879 -- Standard Generalized Markup Language SGML (defined in
> [ISO8879]).
>
> and SGML defines a comment declaration differently than HTML.
>
> So the question is which definition of a comment do you believe? The one
> you quoted is a 'discussion' and therefore it is reasonable to assume it is
> not normative. If taken literally it implies that HTML comments must
> contain the text 'this is a comment', or 'and so is this one, which
> occupies more than one line' so it is obvious that the statement 'HTML
> comments have the following syntax' is wrong: they are giving some
> examples, not specifying syntax. For the actual comment syntax you have to
> fall back on the SGML standard.
You guys are something else...
You serve a page with MIME type "text/html"
You even link DTD document in the header in case if "some browser"
doesn't know how to tread <table> or <body> or comment tags.
But you are still all in worry that something can go wrong and browser
may read the source as pure SGML. The only solution you see by not
using anything of SGML, or better do not use any tags at all....
Sorry for you but please keep beginners out of discovers like "HTML
comments are harmful" or "textarea doesn't have and never had WRAP
property" etc. (WRAP property indeed doesn't exists by W3C).
Stop reading W3C obscure crap, get some fresh air and make a couple of
real world web-projects (best of all - for money). You'll come back as
all new better people, trust me.
:-)
P.S.
<quote>
<http://www.w3.org/MarkUp/html-spec/html-spec_3.html#SEC3.2.5>
To include comments in an HTML document, use a comment declaration.
A comment declaration consists of `<!' followed by zero or more
comments followed by `>'.
Each comment starts with `--' and includes all text up to and including
the next occurrence of `--'.
In a comment declaration, white space is allowed after each comment,
but not before the first comment.
The entire comment declaration is ignored.
</quote>
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> wrote [...]
>> Patient Guy wrote:
>>> Thomas 'PointedEars' Lahn <Point...@web.de> wrote [...]:
>>>> VK wrote:
>>>>> Also let do not mix the terms "harmful" and "not necessary".
>>>>> <!-- --> tag is valid HTML comment tag since the first draft and
>>>>> till now and for forever.
>>>>
>>>> Nonsense! `<!' introduces an SGML declaration, `--' starts and ends
>>>> a comment within an SGML declaration, and `>' ends the declaration.
>>>> It is basically `<!>' to an SGML parser, an empty declaration.
>>>> Everything else is tag soup behavior that cannot be assumed. Which
>>>> is why Mozilla/5.0 will not consider <!------> a closed comment in
>>>> Strict Mode and does not render the adjacent markup.
>>>
>>> What a load of unadulterated bandwidth waste yet again from you!!!
You call that line part of an attempt at constructive discussion?
Then do not be astonished by the replies you get for this.
Where you omit conveniently that the HTML Specification says nothing
different than I did, in fact, is says exactly the same as I did, while
it proves VK wrong.
> Now what was hard about following that?
`<!-- -->' is _not_ a "comment tag". It is an empty SGML declaration which
is parsed only as such in _PCDATA_ (Parsed Character DATA) content. The
`script' element's content, however, is CDATA in HTML. Therefore, every
standard HTML parser (that is, not a "tag soup" parser) will pass it
as-is to the script engine. The standard for script engine behavior, on
the other hand, is ECMAScript, where `<', `!' and `--' are defined as
_operators_. Occurrences of these operators without the respective
number of operands are a SyntaxError and will break the script.
Neither can it be safely assumed that a "tag soup" parser is used to parse
HTML nor can it be safely assumed that an ECMAScript compliant script
engine (and _all_ currently implemented script engines are ECMAScript
compliant) ignores operators just because they are arranged in a manner
that resembles delimiters of a _markup_ language.
Therefore, and because there is no usable UA left that does not support
(in terms of "recognize, and ignore if not applicable") the respective
feature of HTML 3.2 (which turns 10 next month), it is unnecessary and
potentially harmful to use those delimiters within the HTML `script'
element.
And because in XHTML the content model of the `script' element is PCDATA by
default, using comment delimiters there would most certainly result in an
empty `script' element. Properties that are supposed to be declared
there will not be declared and for example method calls referring to that
commented code will result in a ReferenceError and break the script. (And
if the content was declared CDATA using the respective XML declaration as
e.g. VK mentioned, it would be handled as in HTML, with an even greater
probability of failure as XHTML is an XML application which must adhere
to well-formedness.) Therefore, it is potentially harmful to use comment
delimiters within the `script' element in XHTML, too.
Which leaves us with the conclusion that SGML comment delimiters within
the `script' element are unnecessary and potentially harmful. Which is
in sharp contrast to VK's statement.
>> namespace-spoiling,
>
> Okay...I give up...what are you trying to say here?
You do not own the domain found.com, that is found.com, Inc. (as your
favorite WHOIS service tells you), which will also receive either all
the spam mails directed to your From header "address" or rather the
error messages about the non-existing mail account. Continued use by
you is domain abuse, a form of Network abuse disallowed by section 5
of your NetNews service provider's Posting policy and most certainly
by your Internet Service Provider's Terms of Use.
And if found.com would not be registered, anyone registering it later
will receive either that spam or the error messages, so that would not
make much of a difference.
Nuff said.
PointedEars
Thomas 'PointedEars' Lahn
> Duncan Booth wrote:
>> You missed another bit of the HTML standard:
>> W3 document: HTML 4 is an SGML application conforming to International
>> Standard ISO 8879 -- Standard Generalized Markup Language SGML (defined
>> in
>> [ISO8879]).
>>
>> and SGML defines a comment declaration differently than HTML.
How did you get that idea?
SGML does not define a "comment declaration" (well, maybe it does as a
shortcut for the lengthy [but more correct] expression "an empty
declaration with a comment"). It defines the syntax for a declaration and,
apart from other features, comments within that declaration. (As you can
see clearly when reading any HTML Document Type Definition [DTD] which is
of course written in SGML -- they contain a lot of comments in otherwise
empty and non-empty declarations).
HTML markup merely can make use of the combination of both SGML features
which I did not think was so hard to understand for you.
>> So the question is which definition of a comment do you believe?
So is is not a question of which definition to believe.
Either one tells the _same_ thing (with different and more or less words).
>> [...]
>
> You guys are something else...
Competent?
> You serve a page with MIME type "text/html"
> You even link DTD document in the header in case if "some browser"
> doesn't know how to tread <table> or <body> or
_treat_
> comment tags.
Will you understand that there are no "comment tags"? A tag is a part of
an element. Declarations, even those only _containing_ comments, are _not_
elements. (If not empty, they instead declare elements and other markup
features like Entities and attributes)
> But you are still all in worry that something can go wrong and browser
> may read the source as pure SGML. [...]
What you apparently are unable or unwilling to understand is that HTML is
an SGML application (as much as XHTML is an XML application, where XML is
a subset of SGML), that is, it is defined using SGML and (therefore)
follows SGML rules. Which is why the HTML Specification does not call
`<!-- ... -->' a "comment tag" like you do, but a "(HTML) comment".
BTW, the DOCTYPE declaration in HTML documents is an SGML feature itself:
`<!' opens the declaration, DOCTYPE is the keyword to identify the
declaration type, `html' is the type of the root element, `PUBLIC'
is the keyword for the following public identifier which can be
followed by the optional `SYSTEM' keyword and the system identifier.
`>' closes the declaration. See?
> [...]
> P.S.
> <quote>
> <http://www.w3.org/MarkUp/html-spec/html-spec_3.html#SEC3.2.5>
,-<URL:http://www.w3.org/MarkUp/#previous>
|
| HTML 2.0
| (RFC 1866) was developed by the IETF's HTML Working Group, which closed
| in 1996. It set the standard for core HTML features based upon current
| practice in 1994. Note that with the release of RFC 2854, RFC 1866 has
| been obsoleted and its current status is HISTORIC.
which I stated before, too, BTW.
PointedEars
Matt Kruse
> `<!-- -->' is _not_ a "comment tag". It is an empty SGML declaration
> which is parsed only as such in _PCDATA_ (Parsed Character DATA)
> content. The `script' element's content, however, is CDATA in HTML.
> Therefore, every standard HTML parser (that is, not a "tag soup"
> parser) will pass it
> as-is to the script engine. The standard for script engine behavior,
> on the other hand, is ECMAScript, where `<', `!' and `--' are defined
> as _operators_. Occurrences of these operators without the respective
> number of operands are a SyntaxError and will break the script.
I agree with you on the specifics of what you're saying.
However, browsers do not have pure ECMAScript engines. They have
Javascript/JScript/etc. In these implementations of ECMAScript, I've not
seen one yet that didn't treat
<!--
as a single-line comment. In fact, they document it as so.
Then the closing comment tag is written as
// -->
which is a valid ECMAScript comment.
So if your script content with "html comments" is passed to a pure
ECMAScript implementation, it could very well break. But in the world of
browser scripting, the ECMAScript implementations being used also recognize
<!-- as a comment, so there should be no problem.
In theory, it could potentially break something. In reality, it won't.
Just like in theory, someone could use a browser that doesn't support HTML
3.2, but in reality, they won't.
Dr John Stockton
2005 20:27:42 local, seen in news:comp.lang.javascript, Thomas
'PointedEars' Lahn <Point...@web.de> posted :
>markar...@gmail.com wrote:
>
>> Why are the <!-- //--> considered harmful?
>
>/Please/, ask Google (Groups) before you ask here. I am tired of explaining
>that over and over again.
This is a newsgroup, not the Web. Don't assume that Googling is equally
congenial to everybody.
There's no need for you to explain things over and over again[*]; you're
not the only person here, and you could try just keeping quiet. When
the majority find the point of minor significance, you should allow for
the probability that they are right.
Remember, if you're hoping to get a job in future, that potential
employer may well search the Net to see what Thomas Lahn is like - and
when they see that he's a pigheaded arrogant bastard, they'll probably
lose interest in him.
[*] Indeed, others would manifestly prefer that you did not do so.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
Constantinopolitanischerdudelsackpfeifenmachersgesellschaft.
John G Harris
Lahn <Point...@web.de> writes
<snip>
>`<!-- -->' is _not_ a "comment tag". It is an empty SGML declaration which
>is parsed only as such in _PCDATA_ (Parsed Character DATA) content. The
>`script' element's content, however, is CDATA in HTML. Therefore, every
>standard HTML parser (that is, not a "tag soup" parser) will pass it
>as-is to the script engine.
<snip>
Not quite. HTML 4.01, sec 6.2 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."
Therefore, in browsers that know what a script element is there is no
such thing as an HTML/SGML comment in the script. It's all passed on to
the language engine in blind ignorance and hope.
On the other hand, in browsers that don't know what a script element is
the element's contents are treated as HTML so <!-- x --> is then a real
HTML comment.
Whether the popular javascript engines will continue to ignore <!-- is
something we don't know. We do know that magazines aimed at web
designers still show it in many of their javascript examples :-(
John
--
John Harris
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> `<!-- -->' is _not_ a "comment tag". It is an empty SGML declaration
>> which is parsed only as such in _PCDATA_ (Parsed Character DATA)
>> content. The `script' element's content, however, is CDATA in HTML.
>> Therefore, every standard HTML parser (that is, not a "tag soup"
>> parser) will pass it as-is to the script engine. The standard for script
>> engine behavior, on the other hand, is ECMAScript, where `<', `!' and
>> `--' are defined as _operators_. Occurrences of these operators without
>> the respective number of operands are a SyntaxError and will break the
>> script.
>
> I agree with you on the specifics of what you're saying.
>
> However, browsers do not have pure ECMAScript engines.
I did not say they have (in fact, I said quite the opposite
not so long ago). I talked about ECMAScript implementations.
> They have Javascript/JScript/etc. In these implementations
> of ECMAScript, I've not seen one yet that didn't treat
> <!--
> as a single-line comment. In fact, they document it as so.
Where?
Not here:
<URL:http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Comments:comment>
Not here:
<http://msdn.microsoft.com/library/en-us/jscript7/html/jsconComments.asp>
(Side note: Microsoft appears to have nuked its JScript 5.6 website
<URL:http://msdn.microsoft.com/library/en-us/script56/html/js56jsoriJScript.asp>)
Not here:
<URL:http://www.opera.com/docs/specs/js/ecma/>
Not here:
<URL:http://developer.kde.org/documentation/library/3.3-api/kjs/html/>
> Then the closing comment tag
^^^^^^^^^^^^^^^^^^^
(Aaargh!)
> is written as
> // -->
> which is a valid ECMAScript comment.
Yes, _that_ should not matter in _CDATA_.
PointedEars
Duncan Booth
> SGML does not define a "comment declaration" (well, maybe it does as a
> shortcut for the lengthy [but more correct] expression "an empty
> declaration with a comment"). It defines the syntax for a declaration
> and, apart from other features, comments within that declaration. (As
> you can see clearly when reading any HTML Document Type Definition
> [DTD] which is of course written in SGML -- they contain a lot of
> comments in otherwise empty and non-empty declarations).
You may be correct, if you have a copy of the SGML standard available feel
free to quote from it. ISO seem to think differently. I can't find a copy
of ISO8879 online (unfortunately ISO charge for their standards), but see
ISO/IEC 15445:2000(E) (at https://www.cs.tcd.ie/15445/15445.html#COMMENT):
All comments in HTML document instances shall appear in comment
declarations. There shall be exactly one comment per comment
declaration.
Also http://groups.yahoo.com/group/libwww-perl/message/6830:
From ISO 8879 Section 10.3 declares a "comment declaration" (yes,
horrible term for it) as:
comment declaration =
"<!",
(comment
(s | comment)*
)?
">"
comment =
"--",
SGML_character*
"--"
There are plenty of other references to comment declaration which imply
that this is the term which ISO8879 uses to refer to a declaration
containing 1 or more comments and nothing else.
>
> HTML markup merely can make use of the combination of both SGML
> features which I did not think was so hard to understand for you.
>
>>> So the question is which definition of a comment do you believe?
>
> So is is not a question of which definition to believe.
>
> Either one tells the _same_ thing (with different and more or less
> words).
The SGML standard contains a definition. The HTML one is a woolly
description which is open to misinterpretation but which appears to be
further constraining the SGML definition.
Anyway, the point is that SGML allows multiple comments in a comment
declaration, HTML (and XML) do not, so if someone tries to put -- somewhere
inside a comment the result is undefined and the various browsers disagree
on how to interpret the resulting mess.
Matt Kruse
>> They have Javascript/JScript/etc. In these implementations
>> of ECMAScript, I've not seen one yet that didn't treat
>> <!--
>> as a single-line comment. In fact, they document it as so.
> Where?
I've seen it in the past, but I don't know of a current location. I'm not
going to waste time looking for it.
One reference to it is in Javascript: The Definitive Guide, 3rd edition,
page 30:
"In addition to C++ and C-style comments, client-side Javascript recognizes
the HTML comment opening sequence <!--. Javascript treats this as a
single-line comment, just as it does the // comment."
Just test it yourself in any browser:
<script type="text/javascript">
<!-- junk
alert('x');
<!-- more junk
<!-- even more
alert('y');
</script>
Point me to a single browser that fails that test.
>> Then the closing comment tag
> ^^^^^^^^^^^^^^^^^^^
> (Aaargh!)
Semantics games are boring. You look like a know-it-all jerk trying to
correct things that are perfectly clear and everyone understands, yet may
not be perfectly technically accurate terms. When someone says an animal
name, do you correct them and tell them to use the scientific classification
name? It's like people who correct every grammatical error made by others,
or correct minor factual errors when someone is telling a story. Nobody
likes those people, and they generally need to get a life. :)
Michael Winter
> Thomas 'PointedEars' Lahn wrote:
>
>> Matt Kruse wrote:
>>
>>> [...] I've not seen one yet that didn't treat
>>> <!--
>>> as a single-line comment. In fact, they document it as so.
>>
>> Where?
>
> I've seen it in the past, but I don't know of a current location.
> [...]
The old Netscape 1.3 JavaScript Guide does mention it[1] however, the
Reference documentation[2] does not. I would infer from that that the
mechanism was not specified as part of the language, but as one
supported by the browser.
> One reference to it is in Javascript: The Definitive Guide, 3rd
> edition, page 30:
But that's just a book, not a language reference or specification.
[snip]
> <script type="text/javascript">
> <!-- junk
> alert('x');
> <!-- more junk
> <!-- even more
> alert('y');
> </script>
>
> Point me to a single browser that fails that test.
And if no reader of this group can, that proves that it will always
work? I know you might want to argue that purely hypothetical arguments
aren't very practical - that's rather obvious - but that objection
doesn't really work here. No browser currently in use should need them.
Even the most recent browsers that are considered to be obsolete don't
need them, so why use something that /could/ break, when the necessity
isn't there?
Finally, though I'd be among the first to point out the general
pointlessness of using XHTML at the moment, the fact remains that
continuing this practice will break scripted XHTML documents. With an
eye for the future, shouldn't it be dismissed like other bad habits from
the past?
[snip]
Mike
[1]
<http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/guide/embed.html#1013248>
[2]
<http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/stmt.html#1014739>
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Matt Kruse
>> Point me to a single browser that fails that test.
> And if no reader of this group can, that proves that it will always
> work?
Nope, certainly not. I was just pointing out that the "potentially harmful"
argument is invalid, because it's not. No known browser will be harmed by
it, and I can't imagine why any future browser would. Browser-makers surely
aren't going to start causing many scripts to break (since it's so widely
used and recommended in the past) by removing the <!-- comment support. So I
do not believe that it is "potentially harmful" at all.
> No browser currently in use
> should need them. Even the most recent browsers that are considered
> to be obsolete don't need them, so why use something that /could/
> break, when the necessity isn't there?
I agree that they should not be used or recommended.
But I think the argument should be that they are unnecessary and potentially
confusing, not that they are potentially harmful.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>>> They have Javascript/JScript/etc. In these implementations
>>> of ECMAScript, I've not seen one yet that didn't treat
>>> <!--
>>> as a single-line comment. In fact, they document it as so.
>> Where?
>
> I've seen it in the past, but I don't know of a current location. I'm not
> going to waste time looking for it.
So you are refusing to prove your own assumption. That makes the assumption
worthless.
> One reference to it is in Javascript: The Definitive Guide, 3rd edition,
> page 30:
>
> "In addition to C++ and C-style comments, client-side Javascript
> recognizes the HTML comment opening sequence <!--. Javascript treats this
> as a single-line comment, just as it does the // comment."
Ahhh yes, bad old JSTDG. Not its first flaw and I am afraid not its last.
> Just test it yourself in any browser:
>
> <script type="text/javascript">
> <!-- junk
> alert('x');
> <!-- more junk
> <!-- even more
> alert('y');
> </script>
>
> Point me to a single browser that fails that test.
Logical fallacy of shifting the burden of proof.
>>> Then the closing comment tag
>> ^^^^^^^^^^^^^^^^^^^
>> (Aaargh!)
>
> Semantics games are boring. [...]
This is no game, it is fact that there is no "comment tag".
I have already explained why.
PointedEars
Thomas 'PointedEars' Lahn
> Michael Winter wrote:
>>> Point me to a single browser that fails that test.
>> And if no reader of this group can, that proves that it will always
>> work?
>
> Nope, certainly not. I was just pointing out that the "potentially
> harmful" argument is invalid, because it's not. No known browser will be
^^^^^^^^^^^^^^^^
> harmed by it, [...]
There is the flaw of your argument.
PointedEars
Randy Webb
Your flaw, both you and your arguments, is that you don't know the
difference between Reality and Theory.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn said the following on 12/17/2005 1:42 PM:
>> Matt Kruse wrote:
>>>Michael Winter wrote:
>>>>> Point me to a single browser that fails that test.
>>>> And if no reader of this group can, that proves that it will always
>>>> work?
>>> Nope, certainly not. I was just pointing out that the "potentially
>>> harmful" argument is invalid, because it's not. No known browser will be
>> ^^^^^^^^^^^^^^^^
>>> harmed by it, [...]
>>
>> There is the flaw of your argument.
>
> Your flaw, both you and your arguments, is that you don't know the
> difference between Reality and Theory.
Again only your usual ad-hominem rubbish. Here are some _facts_ for you to
think about regarding comment delimiters within `script' elements, whether
used as a means to "comment out" the entire script or as single-line
comment prefix:
0. That code should not be parsed by the markup parser, but by the script
engine. There is no documentation that script engines in current
HTML UAs regard markup comment delimiters als script comment delimiters,
and there is proof that at least one script engine, the JavaScript
Reference Implementation, known as SpiderMonkey and used in Mozilla/5.0
based browsers, does not (as using them in external scripts results in a
SyntaxError).
1. It is impossible to clearly define "known browsers", so you cannot
make sure all existing browsers "support" that, let alone all
existing HTML user agents. If you use it, inevitably you make code
non-interoperable, which is in sharp contrast to the purpose of HTML.
As usual, inference from the special case to the general case is
considered harmful.
2. You cannot make sure that future HTML user agents will still "support"
that. If you continue to use it, you make code non-future-proof, IOW
error-prone, which also is in sharp contrast to HTML, considering that
it has always been upwards compatible.
3. There is not a single HTML UA that is still usable today that does
not support the `script' element in terms of recognizing it and
ignoring it if not applicable; if there is one that also supports
HTML 3.2 and greater, it is _badly_ _broken_ (especially when it
considers CDATA content within the `head' element content to display)
and should not be supported at all.
4. Continuing that practice in XHTML either comments out the entire
script element (so that it is not even passed to the script engine)
or results in an invalid document; for XHTML that usually means that
the document cannot be used as XML applications must be well-formed.
So far for Reality, and your narrow perception of it, if that.
PointedEars
--
Learn to think clearly.
Learn to distinguish: What is, and what seems to be. -- Surak
Thomas 'PointedEars' Lahn
> 0. [...] there is proof that at least one script engine, the
> JavaScript Reference Implementation, known as SpiderMonkey
> and used in Mozilla/5.0 based browsers, does not (as using
> them in external scripts results in a SyntaxError).
I have to take that back and to state the opposite. That SyntaxError
was apparently caused by other code, so it appears that JavaScript-C
1.5 2004-09-24 (SpiderMonkey) [1] considers `<!--' the same as `//',
apparently as an undocumented extension to ECMAScript.
x <!-- y
z
yields "foo.js:1: ReferenceError: x is not defined".
/*x*/ <!-- y
z
yields "foo.js:2: ReferenceError: z is not defined". If `<!--' was
considered a SyntaxError by that implementation and not a prefix for
a single-line comment, that error message should have been regarding
it (because of the missing operand left-hand side), not `z'.
However, it is important to emphasize that this does not invalidate
the rest of this point or any of the other points I made. Other
conforming implementations, including future releases of the same
implementation, are not required to extend ECMAScript in the same way.
PointedEars
___________
[1] The stand-alone engine compiled here
with gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
from <URL:http://ftp.mozilla.org/pub/mozilla.org/js/js-1.5.tar.gz>
and fed with a plain text ISO-8859-1 .js file with both Windows
line delimiters (0x0D 0x0A; first test of both variants) and
UNIX line delimiters (0x0A; second test of both variants).
VK
Thomas 'PointedEars' Lahn wrote:
> I have to take that back and to state the opposite. That SyntaxError
> was apparently caused by other code, so it appears that JavaScript-C
> 1.5 2004-09-24 (SpiderMonkey) [1] considers `<!--' the same as `//',
> apparently as an undocumented extension to ECMAScript.
>
> x <!-- y
> z
>
> yields "foo.js:1: ReferenceError: x is not defined".
>
> /*x*/ <!-- y
What in the name are you talking about? What "foo.js" ?!? Naturally you
cannot insert HTML/XML/SGML/Hell-ML markup into stay-alone script file.
That will fail in any browser, no need to involve any monkeys.
This discussion (before it got a bit crazy atmosphere) was about script
source text directly inserted into HTML page (***HTML*** - not sick
sh** XHTML, not XML, not SGML, not SVG, not VML, not Perl, not PHP, not
anything else).
But even for XHTML:
"Defining Abstract Modules"
This section is normative.
<http://www.w3.org/TR/xhtml-modularization/abstraction.html>
<quote>
Script data can be the content of the "script" element and the value of
intrinsic event attributes. User agents must not evaluate script data
as HTML markup but instead must pass it on as data to a script engine.
</quote>
That removes the question out of the HTML/XHTML parsing engine
authority. Sorry if my language is not academical enough but I say as I
can: anything between <script>...</script> tags has to be taken *as it
is* and forwarded right to the script interpreter. But you already
admitted it.
Therefore any tag parser which would try to *anyhow* interprete <!--//
... //--> within the <script> tags is badly brocken or abusively
non-standard. From this point forward it doesn't matter what will it
see: an SGML block or Holy Marie with a bunch of angels.
"Hiding script data from user agents"
<http://www.w3.org/TR/html40/interact/scripts.html#h-18.3.2>
That is a very clear text written on surprisingly "human" language -
which is not so often for W3C.
Still hiding the script content into comment is obsolete and kinda
overkill precaution in the year 2005/2006 - but no one is arguing with
that.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> I have to take that back and to state the opposite. That SyntaxError
>> was apparently caused by other code, so it appears that JavaScript-C
>> 1.5 2004-09-24 (SpiderMonkey) [1] considers `<!--' the same as `//',
>> apparently as an undocumented extension to ECMAScript.
>>
>> x <!-- y
>> z
>>
>> yields "foo.js:1: ReferenceError: x is not defined".
>>
>> /*x*/ <!-- y
>
> What in the name are you talking about? What "foo.js" ?!?
The foo.js file I created to contain the above lines of script code.
(It really helps to think before you post once in a while.)
> Naturally you cannot insert HTML/XML/SGML/Hell-ML markup into stay-alone
> script file.
The point is that SpiderMonkey does not consider that to be markup.
> That will fail in any browser, no need to involve any monkeys.
It will not fail in _all_ browsers. I have sufficiently proven that it
will probably not fail in current Gecko-based browsers because AIUI they
will need to implement SpiderMonkey for XUL.
> This discussion (before it got a bit crazy atmosphere) was about script
> source text directly inserted into HTML page (***HTML*** - not sick
> sh** XHTML, not XML, not SGML, not SVG, not VML, not Perl, not PHP, not
> anything else).
So? If we assume that the markup parser is standards compliant in parsing
the CDATA content of the HTML `script' element, it depends on the script
engine to support this comment syntax. The same script engine would parse
external script files, and SpiderMonkey does support it, as I have proven.
> But even for XHTML:
>
> "Defining Abstract Modules"
> This section is normative.
> <http://www.w3.org/TR/xhtml-modularization/abstraction.html>
> <quote>
> Script data can be the content of the "script" element and the value of
> intrinsic event attributes. User agents must not evaluate script data
> as HTML markup but instead must pass it on as data to a script engine.
> </quote>
>
> That removes the question out of the HTML/XHTML parsing engine
> authority.
No, quite the contrary. Besides, you are citing from XHTML Modularization
used for XHTML 1.1 and newer which is a different thing.
> "Hiding script data from user agents"
> <http://www.w3.org/TR/html40/interact/scripts.html#h-18.3.2>
> That is a very clear text written on surprisingly "human" language -
> which is not so often for W3C.
Examples are not normative, and that section was written before RFC2854
was issued. Unfortunately, a clarification has not yet been added to the
errata:
<URL:http://www.w3.org/MarkUp/html4-updates/errata>
> Still hiding the script content into comment is obsolete and kinda
> overkill precaution in the year 2005/2006 - but no one is arguing
> with that.
Exactly. (Once in a while, even you have your bright moments.)
PointedEars
Randy Webb
> Randy Webb wrote:
>
>
>>Thomas 'PointedEars' Lahn said the following on 12/17/2005 1:42 PM:
>>
>>>Matt Kruse wrote:
>>>
>>>>Michael Winter wrote:
>>>>
>>>>>>Point me to a single browser that fails that test.
>>>>>
>>>>>And if no reader of this group can, that proves that it will always
>>>>>work?
>>>>
>>>>Nope, certainly not. I was just pointing out that the "potentially
>>>>harmful" argument is invalid, because it's not. No known browser will be
>>>
>>> ^^^^^^^^^^^^^^^^
>>>
>>>>harmed by it, [...]
>>>
>>>There is the flaw of your argument.
>>
>>Your flaw, both you and your arguments, is that you don't know the
>>difference between Reality and Theory.
>
>
> Again only your usual ad-hominem rubbish.
Coming from you, that is amusing.
> Here are some _facts_ for you to think about regarding comment delimiters
> within `script' elements, whether used as a means to "comment out" the entire
> script or as single-line comment prefix:
Give some references to your "facts". And please do not quote ECMA to
me, I don't buy it as a valid reference for web scripting. It is nothing
more than a theory about how things should be.
> 0. That code should not be parsed by the markup parser, but by the script
> engine. There is no documentation that script engines in current
> HTML UAs regard markup comment delimiters als script comment delimiters,
Fix your spell checker or your keyboard. It is "as", not "als". For you
to be so pedantic about others typos you seem to make them yourself.
People who live in glass houses shouldn't throw stones at the neighbors.
> and there is proof that at least one script engine, the JavaScript
The language is Javascript, not JavaScript.
> Reference Implementation, known as SpiderMonkey and used in Mozilla/5.0
> based browsers, does not (as using them in external scripts results in a
> SyntaxError).
Irrelevant. Give one browser, just one that produces a syntax error with
this code:
<script type="text/javascript">
<!--
//-->
</script>
And then you might have an argument. Its more Theory vs Reality. Theory
is that it should be an error, Reality is that no browser throws an
error with it. Never has and never will for no other reason than
backwards compatibility.
> 1. It is impossible to clearly define "known browsers", so you cannot
> make sure all existing browsers "support" that, let alone all
> existing HTML user agents. If you use it, inevitably you make code
> non-interoperable, which is in sharp contrast to the purpose of HTML.
> As usual, inference from the special case to the general case is
> considered harmful.
I didn't ask for all "known browsers". I ask for *one* browser that
throws an error with the above code. Until one is shown to throw an
error, it is irrelevant what the "specs" say. What is relevant is what
the browser does with the code.
> 2. You cannot make sure that future HTML user agents will still "support"
> that. If you continue to use it, you make code non-future-proof, IOW
> error-prone, which also is in sharp contrast to HTML, considering that
> it has always been upwards compatible.
That's your opinion, not a fact. It is a non-refutable opinion just as
me saying they will support backwards compatibility is irrefutable.
Neither can be proven, neither can be disproved. I can say this though:
Let's assume, for this argument, that IE7 balks on not having those
comments in a script block. Do you think people will stop supporting IE7
because it is not "standards compliant" or do you think people will
start adding them back? If you guess non-support, you couldn't be more
wrong.
Standards do not come from ECMA and W3C as they should. The standards,
browser behavior, and what is or is not supported is decided in Redmond
Washington in the USA.
Note the use of the term "should".
> 3. There is not a single HTML UA that is still usable today that does
> not support the `script' element in terms of recognizing it and
> ignoring it if not applicable; if there is one that also supports
> HTML 3.2 and greater, it is _badly_ _broken_ (especially when it
> considers CDATA content within the `head' element content to display)
> and should not be supported at all.
No argument there. With the exception of "should not be supported at
all". If you want to thumb your nose at potential customers because of
the browser, then that is your choice. I can give you a real world
example of that happening though.
2 years ago I was forced to use NN4 as a browser. No amount of begging
the higher-ups would let me upgrade the browsers. The Sales Department
wanted to use a web site to order from. The site used JS to submit forms
instead of a normal submit button. It wouldn't work for us. The cost to
the company that couldn't get our business? 100,000 US dollars.
Now, if you are told that you can gain 100,000 dollars US by supporting
an older browser you can bet anything you want that the pencil pushers
will have you bending over backwards to support that browser. That's
Reality. The Theory is : You should upgrade your browser.
> 4. Continuing that practice in XHTML either comments out the entire
> script element (so that it is not even passed to the script engine)
> or results in an invalid document; for XHTML that usually means that
> the document cannot be used as XML applications must be well-formed.
Considering that the #1 browser on the web doesn't support XHMTL to use
XHMTL as an argument is ridiculous.
Matt Kruse
> I have to take that back and to state the opposite. That SyntaxError
> was apparently caused by other code, so it appears that JavaScript-C
> 1.5 2004-09-24 (SpiderMonkey) [1] considers `<!--' the same as `//',
> apparently as an undocumented extension to ECMAScript.
This is standard behavior for every JScript/Javascript/ECMAScript
implementation I have ever seen.
Just because it is not documented in ECMAScript specs doesn't mean it is not
documented. In fact, for it to be documented in ECMAScript would be rather
odd, since its only need would be in a browser context. It's not the DOM,
either. So I'm not sure where it would be documented, other than in language
references for specific implementations.
Keep in mind, a browser implementing <script type="text/javascript"> doesn't
need to support ECMAScript either. If a browser implemented a pure
ECMAScript engine which followed specs and chose to make things like:
<script type="text/ecmascript">
<!-- x
</script>
a syntax error, I would agree with you that it's expected. But browsers
support Javascript/JSCript, which have functionality beyond ECMAScript. And
the <script> tag says text/javascript, not text/ecmascript.
The behavior of <!-- is most certainly documented. I just don't have links
archived, and unfortunately it's difficult to search for on the web. Current
documentation may omit the details of this special functionality because it
is usually no longer needed or recommended, but previously it was most
certainly there. Even archive.org is giving me errors tonight, so I'm not
going to waste time looking for the docs. It's kind of a moot point anyway.
Lasse Reichstein Nielsen
>> and there is proof that at least one script engine, the JavaScript
>
> The language is Javascript, not JavaScript.
Actually, the official name for the language used by the Netscape
browsers and inheriteed by the Mozilla based browsers, including the
Spidermonkey engine, is "JavaScript". This is also the name that is
trademarked by Sun Microsystems, Inc.
I personally use "Javascript" to refer to the group of languages
derived from JavaScript, including JScript and the ECMAScript
implementations in other browsers, but it's not an official name.
> Irrelevant. Give one browser, just one that produces a syntax error
> with this code:
>
> <script type="text/javascript">
> <!--
>
> //-->
> </script>
Can't find one. It would be stupid for a browser creator to not accept
this, since so many existing pages use it. That's not an argument for
using it, or advocating its use. It's not even an argument against
arguing for its abolishment.
Can you find one browser later than Netscape 2, i.e., one that
understands the script element, that doesn't work without the "syntax
of an HTML comment"?
> And then you might have an argument. Its more Theory vs
> Reality. Theory is that it should be an error, Reality is that no
> browser throws an error with it. Never has and never will for no other
> reason than backwards compatibility.
Correct. And there is no reason not to remove it.
It will be a problem when somebody unknowingly (which is the reason
people use it in the first place) adds XML comments to an XHTML
file, and removes their entire script before it ever reaches the
script interpreter.
> I didn't ask for all "known browsers". I ask for *one* browser that
> throws an error with the above code. Until one is shown to throw an
> error, it is irrelevant what the "specs" say. What is relevant is what
> the browser does with the code.
Are you arguing that standards are irrelevant and that we should just
go by what the browsers do? That validation is irrelevant, as long as
it works in all the current browsers?
> Standards do not come from ECMA and W3C as they should. The standards,
> browser behavior, and what is or is not supported is decided in
> Redmond Washington in the USA.
While IE is a de-facto standard, it is not the only standard. As I see
it, more and more people are writing pages to standards and adding
support for IE afterwards. That is probably why Microsoft admits that
standard support is one of the primary requests for IE 7.
Admittedly, if all browsers supported all standards equally well,
there wouldn't be any compelling reason to choose one over the other,
except the user interface. I can see Microsoft not wanting to compete
that way.
> Considering that the #1 browser on the web doesn't support XHMTL to
> use XHMTL as an argument is ridiculous.
It's not an argument for not using a deprecated practice in HTML
documents, where I agree that it will probably be supported forever,
but for trying to break the habit of the people using it in order
to avoid the problem when they eventually try to write an XHTML page
(especially when it seems to work in IE because it doesn't parse
it as XML).
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> I have to take that back and to state the opposite. That SyntaxError
>> was apparently caused by other code, so it appears that JavaScript-C
>> 1.5 2004-09-24 (SpiderMonkey) [1] considers `<!--' the same as `//',
>> apparently as an undocumented extension to ECMAScript.
>
> This is standard behavior for every JScript/Javascript/ECMAScript
> implementation I have ever seen.
Which does not count.
> Just because it is not documented in ECMAScript specs doesn't mean it
> is not documented.
Which does not count either. You really should have read the provision
attached to the posting you replied to.
> Keep in mind, a browser implementing <script type="text/javascript">
> doesn't need to support ECMAScript either.
Which does not count. The environment that scripts are operating in is
unknown most of the time, it is wrong and potentially harmful to infer
from the special case to the general one as you do.
PointedEars
Matt Kruse
> The environment that scripts are operating in
> is unknown most of the time, it is wrong and potentially harmful to
> infer from the special case to the general one as you do.
Listen, either way it's a guessing game. And I'm talking _only_ about the
statement that it's potentially harmful, not that it's a recommended
practice. There are two bets you can take:
1. A browser will be made in the near future with a javascript engine that
does not treat <!-- as a single-line comment.
2. Browsers will continue to treat <!-- as a single-line comment in
javascript, even though it's not part of standards
You're betting on #1. However, browsing the web with such a browser would be
a terrible experience because of all the syntax errors you would encounter.
I find it highly unlikely that such a browser would ever be made, much less
used. Maybe in 20 years ;)
I'm betting on #2, because a survey of the current browser world shows that
every browser behaves as expected and continues to do so in every update.
Even if not documented, the behavior remains.
Conclusion: If you bet on #1, you would consider it to be potentially
harmful. If you bet on #2, it's not potentially harmful.
I think #2 is the much more realistic bet. And one I would be willing to
take with you for any amount of cash ;)
John W. Kennedy
> Actually, the official name for the language used by the Netscape
> browsers and inheriteed by the Mozilla based browsers, including the
> Spidermonkey engine, is "JavaScript". This is also the name that is
> trademarked by Sun Microsystems, Inc.
By /Sun/?
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
Thomas 'PointedEars' Lahn
> Lasse Reichstein Nielsen wrote:
>> Actually, the official name for the language used by the Netscape
>> browsers and inheriteed by the Mozilla based browsers, including the
>> Spidermonkey engine, is "JavaScript". This is also the name that is
>> trademarked by Sun Microsystems, Inc.
>
> By /Sun/?
Yes, indeed by Sun. The programming language developed by Brendan Eich,
previously of Netscape Communications Corp., now working for the Mozilla
Foundation, formerly known as Mocha or LiveScript, was renamed to
"JavaScript" in a joint marketing effort of Netscape Communications Corp.
and Sun Microsystems, Inc.
<URL:http://www.sun.com/suntrademarks/#J>
<URL:http://wp.netscape.com/newsref/pr/newsrelease67.html>
<URL:http://en.wikipedia.org/wiki/JavaScript>
PointedEars
Matt Kruse
>> They have Javascript/JScript/etc. In these implementations
>> of ECMAScript, I've not seen one yet that didn't treat
>> <!--
>> as a single-line comment. In fact, they document it as so.
> Where?
Try this:
http://www.w3.org/TR/html401/interact/scripts.html#h-18.3.2
The most recent HTML 4.01 specs say this:
"User agents that don't recognize the SCRIPT element will likely render that
element's contents as text. Some scripting engines, including those for
languages JavaScript, VBScript, and Tcl allow the script statements to be
enclosed in an SGML comment. User agents that don't recognize the SCRIPT
element will thus ignore the comment while smart scripting engines will
understand that the script in comments should be executed."
Good enough for you?
Michael Winter
> Thomas 'PointedEars' Lahn wrote:
>
>> Matt Kruse wrote:
>>
>>> They have Javascript/JScript/etc. In these implementations
>>> of ECMAScript, I've not seen one yet that didn't treat
>>> <!--
>>> as a single-line comment. In fact, they document it as so.
>>
>> Where?
>
> Try this:
> http://www.w3.org/TR/html401/interact/scripts.html#h-18.3.2
[snip]
> Good enough for you?
Not particularly. It's an informative statement on the state of things
as the W3C saw them at the time of publishing. It in no way implies that
that's the way things /should/ be, and all that it confirms is what we
already know: most user agents will ignore the comments if they surround
code. However, what it doesn't say is what you wrote above.
The best solution to the problem always was, and still is, what is
written in the second paragraph of that section.
Mike
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>>> They have Javascript/JScript/etc. In these implementations
>>> of ECMAScript, I've not seen one yet that didn't treat
>>> <!--
>>> as a single-line comment. In fact, they document it as so.
>> Where?
>
> Try this:
> http://www.w3.org/TR/html401/interact/scripts.html#h-18.3.2
> [...]
FYI: You were stating that `<!--' is _documented_ as being a single-line
comment in a documentation for _"JavaScript/JScript/etc."_. It is not
the W3C that sets the standard for the former, and as I already pointed
out that section of the HTML 4.01 Specification, which is not normative
regarding ECMAScript implementations at all, was written and issued
before RFC2854 was issued, which obsoleted all HTML versions this section
was intended to create backwards compatibility to.
PointedEars
Thomas 'PointedEars' Lahn
> On 20/12/2005 06:24, Matt Kruse wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Matt Kruse wrote:
>>>> They have Javascript/JScript/etc. In these implementations
>>>> of ECMAScript, I've not seen one yet that didn't treat
>>>> <!--
>>>> as a single-line comment. In fact, they document it as so.
>>> Where?
>> Try this:
>> http://www.w3.org/TR/html401/interact/scripts.html#h-18.3.2
>
> [snip]
>
>> Good enough for you?
>
> Not particularly. [...]
> The best solution to the problem always was, and still is, what is
> written in the second paragraph of that section.
Where it is to be noted that in HTML 3.2 the `script' element has no
attributes at all.
<URL:http://www.w3.org/TR/REC-html32#script>
PointedEars
Michael Winter
> Michael Winter wrote:
[snip]
>> The best solution to the problem always was, and still is, what is
>> written in the second paragraph of that section.
'Always' is a little misleading. However, the time frame should be at
least seven years, which is certainly long enough.
[snip]
> [I]n HTML 3.2 the `script' element has no attributes at all.
In HTML 3.2, the SCRIPT element was nothing more than a placeholder,
though NN2 was using it. It wasn't defined until HTML 4.0, along with
STYLE elements. Both IE (3.022) and NN (3.0?) had support for the src
attribute before that time.
[snip]
Thomas 'PointedEars' Lahn
> On 20/12/2005 18:01, Thomas 'PointedEars' Lahn wrote:
> > Michael Winter wrote:
>> [I]n HTML 3.2 the `script' element has no attributes at all.
>
> In HTML 3.2, the SCRIPT element was nothing more than a placeholder,
It is declared as an element in the HTML 3.2 Document Type Definition.
> [...] It wasn't defined until HTML 4.0, along with STYLE elements.
Wrong. Both were already declared and defined as an element without
any attribute before HTML 4.0, in HTML 3.2.
> Both IE (3.022) and NN (3.0?) had support for the src attribute before
> that time.
The point is that we are trying to use Valid Markup and the argument for
obsolete "comments" is HTML 3.2. So there is no point in stating that
HTML 3.2 already supported the element and only now-obsolete or then-tagsoup
parsers require the "comment", but despite HTML 3.2 did not support the
`src' attribute, we use it anyway because some tagsoup parsers did.
PointedEars
VK
please.
Let's us take HTML markup block like:
<!-- Some comment -->
or
<!--
Some comment
-->
1) First of all it doesn't consist of <!-- and --> tags: there are not
such tags and W3C clearly state it and all browsers agree on it.
It consists of <! %content > tag which could be called
(non-academically but more visually) "non-rendering surprise". Thusly
it is not directly rendered but it may contain all kind of data which
can be treated very differently depending on the data type. Parser
determines what kind of surprise is waiting for by reading *the first
character* after the tag name - after the exclamation sign. It can be
DTD declaration, ASP tag, HTML comment, SSI tag and much more. If the
first character is score "-", parser read the next char to see if it's
a begin of comment block "--".
Double scores *are not* parts of tag syntacs. They denote comment
blocks withing the tag: <!-- Comment 1 -- Comment 2 -- Comment 3 -->
should be treated by specs as three comment blocks
Comment 1 --
Comment 2 --
Comment 3 --
where opening scores must be omitted and closing scores included into
comment block value. On practice I did not find any browser yet which
would follow this part of specification. All of them see one comment
block "Comment 1 -- Comment 2 -- Comment 3 --"
Also it is interesting (?is it really? well, just form of speach) that
IE properly reports tagName as "!" while Firefox reports something
strange: this tag has no name (undefined).
But all browsers agree that this is nodeName "#comment" and nodeType 8.
Because one have to place opening comment block declaration "--" right
after the tag name and also because no one is using multiple comment
blocks within one tag (because it's simply never was implemented):-
because of that everyone used to see comments as:
<!-- Comment --> and used to say "<!-- and --> comment tags" which is
nothing but convenience shortcut of more complicated picture.
2) About HTML comment within <script> tag.
W3C takes any authourity out from anything what could/should happen
after the opening <script> tag and up to the closing </script> tag
At the same time ECMA takes any authourity out from anything
browser-specific.
Therefore <script><!-- ... //--></script> question is out of any
official authority. What happens with <!-- ... //--> decided by the
particular browser producer and there are not *any* normative documents
which could be used to argue with the browser producer decision.
We may quote each other to death but no quote from any any source would
be relevant.
In this situation the legacy becomes the only autority, therefore <!--
... //--> will work fine forever - which *again* doesn't mean that one
must/should use it.
Thomas 'PointedEars' Lahn
> If you decided to be pin-point accurate in everything then be it
> please.
>
> Let's us take HTML markup block like:
> <!-- Some comment -->
> or
> <!--
> Some comment
> -->
>
> 1) First of all it doesn't consist of <!-- and --> tags: there are not
> such tags and W3C clearly state it and all browsers agree on it.
Finally you got that, did you not?
> It consists of <! %content > tag
That is a markup declaration, not a tag. In SGML-based markup languages,
tags are part of elements. Got that?
> which could be called (non-academically but more visually) "non-rendering
> surprise".
True, a declaration itself is never rendered. Only the markup
it declares may be rendered visually, and is parsed always.
> Double scores *are not* parts of tag syntacs. They denote comment
> blocks withing the tag: <!-- Comment 1 -- Comment 2 -- Comment 3 -->
^^^^ ^^ ^^^^^^^^^ ^^ ^^^
[0] [1] [2] [3] [4] [5][6]
[0] Markup Declaration Open (MDO) delimiter: <!
[1] start of comment: --
[2] end of comment: --
[3] invalid declaration keyword: Comment
[4] start of comment: --
[5] end of comment: --
[6] Markup Declaration Close (MDC) delimiter: >
> should be treated by specs as three comment blocks
> Comment 1 --
> Comment 2 --
> Comment 3 --
Wrong. Instead it is an SGML/XML _syntax error_, therefore also an (X)HTML
syntax error. To achieve what you falsely inferred, one needs to write
<!-- Comment 1 ---- Comment 2 ---- Comment 3 -->
That is why the HTML Specification makes the remark that `-' should not
occur in comments. Any sequence of `--' ends the comment previously
started (with `--').
> [...]
Non sequitur.
HTH
PointedEars
Thomas 'PointedEars' Lahn
> VK wrote:
>> Double scores *are not* parts of tag syntacs. They denote comment
>> blocks withing the tag: <!-- Comment 1 -- Comment 2 -- Comment 3 -->
> ^^^^ ^^ ^^^^^^^^^ ^^ ^^^
> [0] [1] [2] [3] [4] [5][6]
>
> [0] Markup Declaration Open (MDO) delimiter: <!
> [1] start of comment: --
> [2] end of comment: --
> [3] invalid declaration keyword: Comment
> [4] start of comment: --
> [5] end of comment: --
> [6] Markup Declaration Close (MDC) delimiter: >
>
>> should be treated by specs as three comment blocks
>> Comment 1 --
>> Comment 2 --
>> Comment 3 --
>
> Wrong. Instead it is an SGML/XML _syntax error_, therefore also an
> (X)HTML
> syntax error. To achieve what you falsely inferred, one needs to write
>
> <!-- Comment 1 ---- Comment 2 ---- Comment 3 -->
That is wrong as it is. The "comment blocks" would be " Comment 1 ",
" Comment 2 " and " Comment 3 " in that case. ISTM that because `--'
starts and ends comments, it is not possible to define a comment that
includes it. Maybe the rather ugly
<!ENTITY % doublehyphen "--">
<!-- Comment 1 %doublehyphen;---- Comment 2 %doublehyphen;---- Comment 3
%doublehyphen;-->
works, but I have not validated that yet.
Sorry for causing confusion.
PointedEars
VK
Thomas 'PointedEars' Lahn wrote:
> That is wrong as it is. The "comment blocks" would be " Comment 1 ",
> " Comment 2 " and " Comment 3 " in that case. ISTM that because `--'
> starts and ends comments, it is not possible to define a comment that
> includes it. Maybe the rather ugly
Read the specs please ;-)
Comment block value starts from the opening mark and up to *and
including* the closing mark.
<!--Comment 1-- --Comment 2-- --Comment 3-->
defines three comment blocks:
"Comment 1--"
"Comment 2--"
"Comment 3--"
But as I said this part of specification was never implemented by
anyone. Even W3C's "mission statement browser" Amaya fails on it.
So it is only for an abstract interest. Plus I'm feeling sadistic today
:-)
Michael Winter
> Michael Winter wrote:
[snip]
>> In HTML 3.2, the SCRIPT element was nothing more than a placeholder,
>
> It is declared as an element in the HTML 3.2 Document Type Definition.
Precisely. It is a declaration. The intent was to ensure that future
user agents would recognise a SCRIPT element. There were no defined
attributes or semantics, just an attempt to make sure that new user
agents wouldn't attempt to render the content as they should with
unknown elements.
>> [...] It wasn't defined until HTML 4.0, along with STYLE elements.
>
> Wrong. Both were already declared and defined as an element without
> any attribute before HTML 4.0, in HTML 3.2.
Defined? No. The phrases 'future use' and 'placeholder' don't appear in
five different locations for the fun of it. There was no attempt at a
definition.
>> Both IE (3.022) and NN (3.0?) had support for the src attribute
>> before that time.
>
> The point is
I know what the point is.
> that we are trying to use Valid Markup and the argument for
> obsolete "comments" is HTML 3.2.
The argument for the behaviour regards (in principle, at least) pre-3.2
user agents and anyone should (and in this thread, does) agree that this
argument has no merit any more. Why you want to argue over irrelevant
specifics is beyond me.
> So there is no point in stating that HTML 3.2 already supported the
> element [...]
I would like to remind you that I was not the one that introduced the
matter of, or initiated any reference to, HTML 3.2. If you feel that
there is no point in discussing it, you might want to ask yourself why
you decided to bring it up.
Michael Winter
[snip]
> Comment block value starts from the opening mark and up to *and
> including* the closing mark.
I don't know where you read that, and you could well be right, but it
seems odd to me.
> <!--Comment 1-- --Comment 2-- --Comment 3-->
> defines three comment blocks:
[snip]
> But as I said this part of specification was never implemented by
> anyone.
Not true. I recently came across a Microsoft document that contained
something like:
<!------->
and Firefox promptly ignored everything after that until it came across
something similar later.
In any case, it is undoubtely safer to take the XML approach: comments
start with '<!--', end with '-->' ('--->' is forbidden), and should
never include paired hyphens ('--').
Michael Winter
[snip]
> Also it is interesting (?is it really? well, just form of speach) that
> IE properly reports tagName as "!" while Firefox reports something
> strange: this tag has no name (undefined).
No, as usual Firefox is correct (as far as the W3C DOM is concerned).
The tagName property is defined only for elements (objects implementing
the Element interface). Whilst a Comment is a Node (it inherits from
CharacterData), it is not an Element and therefore possesses only the
node* properties.
> But all browsers agree that this is nodeName "#comment" and nodeType 8.
It might be worth noting that IE 5.x doesn't. A comment has values '!'
and 1, respectively.
VK
Michael Winter wrote:
> On 21/12/2005 11:27, VK wrote:
> > Comment block value starts from the opening mark and up to *and
> > including* the closing mark.
>
> I don't know where you read that, and you could well be right, but it
> seems odd to me.
<http://www.w3.org/MarkUp/html-spec/html-spec_3.html#SEC3.2.5>
<quote>
To include comments in an HTML document, use a comment declaration.
A comment declaration consists of `<!' followed by zero or more
comments followed by `>'.
Each comment starts with `--' and includes all text up to and including
the next occurrence of `--'.
In a comment declaration, white space is allowed after each comment,
but not before the first comment.
The entire comment declaration is ignored.
</quote>
> I recently came across a Microsoft document that contained
> something like:
> <!------->
> and Firefox promptly ignored everything after that until it came across
> something similar later.
Uuhm.... What Firefox did you use? Firefox 1.5 DOM Inspector shows
correctly #comment node with value "---" (should be "-----" including
the closing comment block mark - see above).
Truthfully I don't understand why anyone would try to insert "--" into
comment block. One cannot use "<" inside tag and no big deal but
impossibility to use "--" makes people all upset :-)
> In any case, it is undoubtely safer to take the XML approach: comments
> start with '<!--', end with '-->' ('--->' is forbidden), and should
> never include paired hyphens ('--').
There is not XML approach: there is SGML approach common for both HTML
and XML and commonly half-a** implemented by everyone including Her
holly standard crazyness Amaya.
You use <!> tag, start comment block with "--" where the first block
declaration has to be immediately after the tag name: <!-- and ends up
and includes the closing declaration.
Therefore <!-- Comment 1-- -- Comment 2-- -- Comment 3--
id="myComment"> in any SGML-based subset should produce three comment
blocks
Comment 1--
Comment 2--
Comment 3--
and named attribute "id" (comments are allowed to have attributes btw -
but because of broken implementation one cannot use this ability).
All this question is not really important for practical development. It
is enough to remember the "explanation shortcut": comment tag starts
with <!-- and ends with -->
This "explanation shortcut" is wrong from the first to the last word,
but it's easy to remember and it guarantees the oops protection.
But if one decided to have a profound evangelism discussion, let's talk
to the last dot over "i". :-)
VK
VK wrote:
> There is not XML approach: there is SGML approach common for both HTML
> and XML and commonly half-a** implemented by everyone including Her
> holly standard crazyness Amaya.
Thinking over it again - I'm filing right now non-standard behavior bug
report to www.w3.org about their browser.
Amaya clearly acts in violation of
<<http://www.w3.org/MarkUp/html-spec/html-spec_3.html#SEC3.2.5> and
must be fixed immediately.
PointedEars - your're a real a** rather often ;-) but this is a great
Christmas present I've got as a side issue of this discussion.
VK
Michael Winter wrote:
> No, as usual Firefox is correct (as far as the W3C DOM is concerned).
> The tagName property is defined only for elements (objects implementing
> the Element interface). Whilst a Comment is a Node (it inherits from
> CharacterData), it is not an Element and therefore possesses only the
> node* properties.
I guess PointedEars has moved something in my unstable brains so I
become like a documentation fighter :-) Just for a while! :-)
<!> tag has nothing to do with comments, it's a tag like any others: it
has name "!", it can have attributes.
--Comment block inside-- *is* #comment node with the node properties
only (no element properties).
Michael Winter
[snip]
> <http://www.w3.org/MarkUp/html-spec/html-spec_3.html#SEC3.2.5>
HTML 2.0 is obsolete, so it shouldn't be considered a normative
reference. Unless SGML states that a comment value includes the closing
delimiter (and I don't own a copy of ISO 8879), then I'll assume that
the idea was revised.
In any case, as far as the W3C DOM is concerned, a comment is delimited
by, but does not include, a pair of hyphens.
[snip]
>> I recently came across a Microsoft document that contained
>> something like:
>>
>> <!------->
>>
>> and Firefox promptly ignored everything after that until it came
>> across something similar later.
>
> Uuhm.... What Firefox did you use?
Fx 1.0.7, but that hardly matters. Not all user agents take a simple
approach to comments.
From some quick further reading[1], it seems that this is a 'Quirks'
versus 'Standards' mode issue, which I can confirm.
> Firefox 1.5 DOM Inspector shows correctly
Correctly?
> #comment node [...]
Because your test triggered 'Quirks' mode, perhaps?
[snip]
>> In any case, it is undoubtely safer to take the XML approach: comments
>> start with '<!--', end with '-->' ('--->' is forbidden), and should
>> never include paired hyphens ('--').
>
> There is not XML approach: there is SGML approach common for both HTML
> and XML [...]
You misunderstand both my point, and the facts. As we know, SGML
delimits comments with '--' inside many types of markup declaration.
However in XML, comments may /only/ appear as I described above. My
point: it is a safe formulation to use, so that's what I'd recommend.
[snip]
> Therefore <!-- Comment 1-- -- Comment 2-- -- Comment 3--
> id="myComment">
[snip]
> (comments are allowed to have attributes btw - but because of broken
> implementation one cannot use this ability).
Absolute rubbish. Try validating that with an SGML parser.
[snip]
Mike
[1] <http://www.howtocreate.co.uk/sgml/doctypeSGML.html>
Michael Winter
> Michael Winter wrote:
>
>> No, as usual Firefox is correct (as far as the W3C DOM is concerned).
>> The tagName property is defined only for elements (objects implementing
>> the Element interface). Whilst a Comment is a Node (it inherits from
>> CharacterData), it is not an Element and therefore possesses only the
>> node* properties.
[snip]
> <!> tag has nothing to do with comments,
Where, above, did I say it did?
> it's a tag like any others:
No it isn't. It is a markup declaration open delimiter, immediately
followed by a markup declaration close delimiter. In the SGML grammar,
that matches a comment declaration (the actual comment is optional).
> it has name "!", it can have attributes.
Utter nonsense.
VK
> On 21/12/2005 23:13, VK wrote:
> > <!> tag has nothing to do with comments
> Michael Winter wrote:
> Where, above, did I say it did?
That's gonna be my MD work "Philosophie of Comments in Modern Browsers"
:-)
<!> *is* an equivalent of comment tag - no "--" needed. I don't know
when did it happen by I guess it was made to keep the display out of
ASP / JSP / PHP tags
Tested on IE 6.0, FF 1.5, Opera 8.51
// CODE FOR FUN BELOW //
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Comment</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function test() {
var out = document.forms[0].elements[0];
out.value = '';
var coms = document.getElementsByTagName('!');
for (p in coms[1]) {out.value+= p+' = '+coms[1][p]+'\n';}
}
</script>
</head>
<body onload="test()">
<form method="post" action="">
<textarea name="out" cols="64" rows="16"></textarea>
</form>
<! My comment />
</body>
</html>
Also please note that parser still swallow two chars from each end: as
if "--" still there. Therefore
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
becomes nodeValue and data:
CTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dt
(try coms[0] instead of coms[1] in the code above).
which means that at least in IE it's impossible to set proper DTD and
the browser must be looking for some formal signs (like "w3.org"
substring?) while choosing compatible vs. strict mode.
Thomas! Some *serious* job to you.
VK
By "tested" I mean the same treatment of <! My comment /> as a
comment.
As comments have tagName in IE only, the script will work only for IE.
For FF use DOM Inspector to check.
Thomas 'PointedEars' Lahn
> On 20/12/2005 18:59, Thomas 'PointedEars' Lahn wrote:
>> Michael Winter wrote:
>>> [...] It wasn't defined until HTML 4.0, along with STYLE elements.
>>
>> Wrong. Both were already declared and defined as an element without
>> any attribute before HTML 4.0, in HTML 3.2.
>
> Defined? No.
[1] Document Type _Definition_
> The phrases 'future use' and 'placeholder' don't appear in
> five different locations for the fun of it.
I beg your pardon?
> There was no attempt at a definition.
Besides of [1], there is:
,-<URL:http://www.w3.org/TR/REC-html32#script>
|
| These are place holders for the introduction of style sheets and
| client-side scripts in future versions of HTML. User agents should
^^^^^^^^^^^^^^^^^^
| hide the contents of these elements.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That is not only a more detailed definition than the DTD already
provides --
| <!ELEMENT STYLE - - CDATA -- placeholder for style info -->
| <!ELEMENT SCRIPT - - CDATA -- placeholder for script statements -->
-- it is also the part of the specification that renders attempts
at "commenting out" `script' element content using empty markup
declarations nonsensical.
>>> Both IE (3.022) and NN (3.0?) had support for the src attribute
>>> before that time.
>> The point is
>
> I know what the point is.
No, you don't:
>> that we are trying to use Valid Markup and the argument for
>> obsolete "comments" is HTML 3.2.
>
> The argument for the behaviour regards (in principle, at least) pre-3.2
> user agents and anyone should (and in this thread, does) agree that this
> argument has no merit any more. Why you want to argue over irrelevant
> specifics is beyond me.
I do not argue over irrelevant specifics.
>> So there is no point in stating that HTML 3.2 already supported the
>> element [...]
>
> I would like to remind you that I was not the one that introduced the
> matter of, or initiated any reference to, HTML 3.2. If you feel that
> there is no point in discussing it, you might want to ask yourself why
> you decided to bring it up.
You snipped what brought meaning to this sentence in the context of
my counter-argument against your counter-argument. JFYI, you stated
that
,-[news:FuSpf.12055$iz3....@text.news.blueyonder.co.uk]
|
| The best solution to the problem always was, and still is, what is
^^^^^^^^^^^^^^^^^^^^^^^^
| written in the second paragraph of that section.
with which you referred to:
,-<URL:http://www.w3.org/TR/html4/interact/scripts.html#h-18.3.2>
|
| [...]
| Another solution to the problem is to keep scripts in external
| documents and refer to them with the src attribute.
I commented that there was no `src' attribute for the `script' element
in HTML 3.2, so following your recommendation would create invalid markup
when declaring HTML 3.2 (which is the earliest possible valid version),
which cannot qualify as being the "best solution [...] always was, and
still is" -- a contradiction:
,-[news:2469244.K...@PointedEars.de]
|
| [I]n HTML 3.2 the `script' element has no attributes at all.
Your counter-argument was that
| In HTML 3.2, the SCRIPT element was nothing more than a placeholder,
| though NN2 was using it. It wasn't defined until HTML 4.0, along with
^^^^^^^^^^^^^^^^^^^^^^^
| STYLE elements. Both IE (3.022) and NN (3.0?) had support for the src
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| attribute before that time.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
And my counter-argument was that this argumentation of yours contains
a contradiction in context of the reasoning for not using "comments":
,-[news:59749340....@PointedEars.de]
| [...]
| [...] there is no point in stating that HTML 3.2 already supported
^^^^^^^^^^^^^^^^^^^
| the element and only now-obsolete or then-tagsoup parsers require the
| "comment", but despite HTML 3.2 did not support the `src' attribute,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| we use it anyway because some tagsoup parsers did.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PointedEars
Thomas 'PointedEars' Lahn
>> Tested on IE 6.0, FF 1.5, Opera 8.51
>
> By "tested" I mean the same treatment of <! My comment /> as a
> comment.
That is not Valid markup, of whatever SGML-based markup language. A user
agent that recognizes that as a comment is badly b0rken. What really
happens is that IE probably does not care and FF ignores it because it
cannot make any sense of it; that does not make it any more a comment
than any other invalid markup ignored by the parsers of these UAs.
<URL:http://validator.w3.org/>
Would you please recognize the syntax for markup declarations in those
languages? Thanks in advance.
PointedEars
VK
Thomas 'PointedEars' Lahn wrote:
> That is not Valid markup, of whatever SGML-based markup language. A user
> agent that recognizes that as a comment is badly b0rken. What really
> happens is that IE probably does not care and FF ignores it because it
> cannot make any sense of it; that does not make it any more a comment
> than any other invalid markup ignored by the parsers of these UAs.
Did you run the test script in IE? It is not an ignored tag - it is
fully qualified #comment with all appropriate properties (as well as
DTD declaration)
Did you use DOM Inspector in Firefox? Tools > DOM Inspector (if
installed)
It is a fully valid #comment node.
Thomas! *Explain* the reality - do not *negate* it! ;-)
Michael Winter
[snip]
> [1] Document Type _Definition_
I would place the emphasis on "Document Type". The DTD does not define
elements themselves - that is what the prose of the specification is
meant to do - but rather which elements (and attributes) are included in
that 'version' of HTML.
[snip]
> | These are place holders for the introduction of style sheets and
> | client-side scripts in future versions of HTML. User agents should
> ^^^^^^^^^^^^^^^^^^
> | hide the contents of these elements.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you consider that to be a definition, so be it. I do not. To me, the
first sentence reads that the SCRIPT and STYLE elements are simply being
declared, but will not be defined until a future version. As such, "user
agents should hide the contents of these elements" because they should
be considered known and not subject to error correction procedures.
As for their presence in the DTD, it would be necessary to include them
for the benefit of an SGML parser.
[snip]
> JFYI, you stated that
>
> ,-[news:FuSpf.12055$iz3....@text.news.blueyonder.co.uk]
> |
> | The best solution to the problem always was, and still is, what is
> ^^^^^^^^^^^^^^^^^^^^^^^^
> | written in the second paragraph of that section.
>
> with which you referred to:
>
> ,-<URL:http://www.w3.org/TR/html4/interact/scripts.html#h-18.3.2>
> |
> | [...]
> | Another solution to the problem is to keep scripts in external
> | documents and refer to them with the src attribute.
>
> I commented that there was no `src' attribute for the `script' element
> in HTML 3.2 [...]
You seem to have completely ignored the fact that I amended my statement
in a follow-up.
[snip]
> ,-[news:2469244.K...@PointedEars.de]
> |
> | [I]n HTML 3.2 the `script' element has no attributes at all.
>
> Your counter-argument was that
>
> | In HTML 3.2, the SCRIPT element was nothing more than a placeholder,
> | though NN2 was using it. It wasn't defined until HTML 4.0, along with
> ^^^^^^^^^^^^^^^^^^^^^^^
> | STYLE elements. Both IE (3.022) and NN (3.0?) had support for the src
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> | attribute before that time.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
It was not a counter-argument, just a statement. In HTML 3.2, the SCRIPT
element did not have a src attribute, but then the intent of HTML 3.2
was to "capture recommended practice", which essentially meant to
document then-current features in existing implementations (such as the
SCRIPT and STYLE elements).
At that time, the use of comments would have been necessary to prevent
then-older (now obsolete) browsers from rendering SCRIPT element
content. However, since the introduction of the src attribute, its
implementation, and the general recognition of the SCRIPT element
(regardless of the ability to execute its contents), the use of comments
is not necessary, and has been so for many years.
> And my counter-argument was that this argumentation of yours contains
> a contradiction in context of the reasoning for not using "comments":
I was not, at any point, reasoning for using comments.
[snip]
Now hopefully no continuation of this discussion will be necessary.
Thomas 'PointedEars' Lahn
> On 22/12/2005 13:40, Thomas 'PointedEars' Lahn wrote:
>> [1] Document Type _Definition_
>
> I would place the emphasis on "Document Type". The DTD does not define
> elements themselves -
So a definition does not define things.
> that is what the prose of the specification is meant to do -
Rubbish.
> [...]
>> | These are place holders for the introduction of style sheets and
>> | client-side scripts in future versions of HTML. User agents should
>> ^^^^^^^^^^^^^^^^^^
>> | hide the contents of these elements.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> If you consider that to be a definition, so be it. I do not. [...]
You are free to think so.
>> JFYI, you stated that
>>
>> ,-[news:FuSpf.12055$iz3....@text.news.blueyonder.co.uk]
>> |
>> | The best solution to the problem always was, and still is, what is
>> ^^^^^^^^^^^^^^^^^^^^^^^^
>> | written in the second paragraph of that section.
>>
>> with which you referred to:
>>
>> ,-<URL:http://www.w3.org/TR/html4/interact/scripts.html#h-18.3.2>
>> |
>> | [...]
>> | Another solution to the problem is to keep scripts in external
>> | documents and refer to them with the src attribute.
>>
>> I commented that there was no `src' attribute for the `script' element
>> in HTML 3.2 [...]
>
> You seem to have completely ignored the fact that I amended my statement
> in a follow-up.
Fair enough.
> [snip]
>
>> ,-[news:2469244.K...@PointedEars.de]
>> |
>> | [I]n HTML 3.2 the `script' element has no attributes at all.
>>
>> Your counter-argument was that
>>
>> | In HTML 3.2, the SCRIPT element was nothing more than a placeholder,
>> | though NN2 was using it. It wasn't defined until HTML 4.0, along with
>> ^^^^^^^^^^^^^^^^^^^^^^^
>> | STYLE elements. Both IE (3.022) and NN (3.0?) had support for the src
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> | attribute before that time.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> It was not a counter-argument, just a statement.
Now come on, you used that for your argumentation, despite your "amendment".
>> And my counter-argument was that this argumentation of yours contains
>> a contradiction in context of the reasoning for not using "comments":
>
> I was not, at any point, reasoning for using comments.
And I did not say so.
> Now hopefully no continuation of this discussion will be necessary
Hopefully.
PointedEars