473,320 Members | 1,991 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

missing ) after argument list

Why is Firefox complaining with this error:

------------------------------------------------------------
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>

Dec 14 '05 #1
69 16733
ma**********@gmail.com wrote:
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
Dec 14 '05 #2
That worked!

Why are the <!-- //--> considered harmful? Aren't they supposed to help
JS-crippled browsers degrade?

- Mark

Dec 14 '05 #3
ma**********@gmail.com said the following on 12/14/2005 12:55 PM:
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/
Dec 14 '05 #4
ma**********@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.
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
Dec 14 '05 #5
Randy Webb wrote:
ma**********@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
Dec 14 '05 #6
Thomas 'PointedEars' Lahn said the following on 12/14/2005 2:27 PM:
ma**********@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
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 14 '05 #7
Thomas 'PointedEars' Lahn said the following on 12/14/2005 2:41 PM:
Randy Webb wrote:

ma**********@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.


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".

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 14 '05 #8
> /Please/, ask Google (Groups) before you ask here. I am tired of
explaining
that over and over again.


you mentioned it in teh first place !!

Dec 14 '05 #9
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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Dec 14 '05 #10
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.

Dec 14 '05 #11
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. 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
Dec 14 '05 #12
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.
(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
Dec 14 '05 #13
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!

Dec 14 '05 #14
VK wrote:
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
Dec 14 '05 #15
Thomas 'PointedEars' Lahn <Po*********@web.de> wrote in
news:21****************@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
to********************@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


Dec 15 '05 #16
Patient Guy wrote:
Thomas 'PointedEars' Lahn <Po*********@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
Dec 15 '05 #17
Thomas 'PointedEars' Lahn <Po*********@web.de> wrote in
news:13****************@PointedEars.de:
Patient Guy wrote:
Thomas 'PointedEars' Lahn <Po*********@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


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


Dec 15 '05 #18
Patient Guy wrote:
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.
Dec 15 '05 #19
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>

Dec 15 '05 #20
Patient Guy wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> wrote [...]
Patient Guy wrote:
Thomas 'PointedEars' Lahn <Po*********@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.
[...]
[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


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 -->


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
Dec 15 '05 #21
VK wrote:
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
Dec 15 '05 #22
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. 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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Dec 15 '05 #23
JRS: In article <14****************@PointedEars.de>, dated Wed, 14 Dec
2005 20:27:42 local, seen in news:comp.lang.javascript, Thomas
'PointedEars' Lahn <Po*********@web.de> posted :
ma**********@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.
Constantinopolitanischerdudelsackpfeifenmachersges ellschaft.
Dec 15 '05 #24
In article <15****************@PointedEars.de>, Thomas 'PointedEars'
Lahn <Po*********@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
Dec 15 '05 #25
Matt Kruse wrote:
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
Dec 15 '05 #26
Thomas 'PointedEars' Lahn wrote:
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.
Dec 16 '05 #27
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.
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. :)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Dec 16 '05 #28
On 16/12/2005 17:07, Matt Kruse wrote:
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.
Dec 16 '05 #29
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, 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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Dec 16 '05 #30
Matt Kruse wrote:
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
Dec 17 '05 #31
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.
PointedEars
Dec 17 '05 #32
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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 18 '05 #33
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. 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
Dec 18 '05 #34
Thomas 'PointedEars' Lahn wrote:
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).
Dec 19 '05 #35
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.

Dec 19 '05 #36
VK wrote:
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
Dec 19 '05 #37
Thomas 'PointedEars' Lahn said the following on 12/18/2005 5:56 PM:
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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 19 '05 #38
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.

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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Dec 19 '05 #39
Randy Webb <Hi************@aol.com> writes:
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 - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Dec 19 '05 #40
Matt Kruse wrote:
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
Dec 19 '05 #41
Thomas 'PointedEars' Lahn wrote:
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 ;)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Dec 19 '05 #42
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/?

--
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"
Dec 19 '05 #43
John W. Kennedy wrote:
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
Dec 20 '05 #44
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/interac....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?

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Dec 20 '05 #45
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/interac....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

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Dec 20 '05 #46
Matt Kruse wrote:
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/interac....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
Dec 20 '05 #47
Michael Winter wrote:
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/interac....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
Dec 20 '05 #48
On 20/12/2005 18:01, Thomas 'PointedEars' Lahn wrote:
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]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Dec 20 '05 #49
Michael Winter wrote:
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
Dec 20 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

8
by: Alex Vinokur | last post by:
Various forms of argument passing ================================= C/C++ Performance Tests ======================= Using C/C++ Program Perfometer...
4
by: Conrad Weyns | last post by:
vc7.1 has no problem with the following snippet: template <typename T> class TTest { std::list<T*>::iterator m_It; }; but metrowerks codewarrior 9.2 kicks my butt and online Comeau confirms:...
1
by: soup_or_power | last post by:
I'm passing the return from window.open as a function argument and getting the error "missing ] after element list" when tested with FireFox. Here is the relevant code. Many thanks for your help....
77
by: Ville Vainio | last post by:
I tried to clear a list today (which I do rather rarely, considering that just doing l = works most of the time) and was shocked, SHOCKED to notice that there is no clear() method. Dicts have it,...
2
by: ehsansad | last post by:
I have the following code. function updateTermsList() { var termDivBox = document.getElementById("termarea"); var terms = searchXMLHttp.responseXML.getElementsByTagName("term"); ...
5
by: Vv_vV | last post by:
Hi all, I try to call onchange a function and get "missing ) after argument list" error Probably systaxis issue Thanks in advance for any help! Code: var html = ""; var myurl =...
9
by: deedub65 | last post by:
I am getting a "Missing ) after argument list" on two different sets of commands in the same script - they are part of Dreamweaver MX's files, so i am not sure how they got altered - thanks for the...
4
by: Pasquale | last post by:
I am attempting to populate a few select drop down menus from the selection of the first drop down. I am using ajax to submit data via a PHP GET and from the response populate the other drop down...
8
by: A. Anderson | last post by:
Howdy everyone, I'm experiencing a problem with a program that I'm developing. Take a look at this stack report from GDB - #0 0xb7d782a3 in strlen () from /lib/tls/i686/cmov/libc.so.6 #1 ...
1
by: hariomt | last post by:
Hi, i have to create table's rows dynamically. I am using bellow code snipet... function copySelectedAttr() { var attrValue=...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.