missing ) after argument list

T

Thomas 'PointedEars' Lahn

VK said:
Duncan said:
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.
Click to expand...
Click to expand...

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 is is not a question of which definition to believe.

Either one tells the _same_ thing (with different and more or less words).
[...]
Click to expand...

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.
Click to expand...

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. [...]
Click to expand...

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>
Click to expand...

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

Dr John Stockton

JRS: In article <[email protected]>, dated Wed, 14 Dec
2005 20:27:42 local, seen in Thomas
'PointedEars' Lahn said:
/Please/, ask Google (Groups) before you ask here. I am tired of explaining
that over and over again.
Click to expand...

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

Matt Kruse

Thomas said:
`<!-- -->' 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.
Click to expand...

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

John G Harris

`<!-- -->' 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.
Click to expand...
<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
 
T

Thomas 'PointedEars' Lahn

Matt said:
I agree with you on the specifics of what you're saying.

However, browsers do not have pure ECMAScript engines.
Click to expand...

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.
Click to expand...

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:
Then the closing comment tag ^^^^^^^^^^^^^^^^^^^
(Aaargh!)

is written as
// -->
which is a valid ECMAScript comment.
Click to expand...

Yes, _that_ should not matter in _CDATA_.


PointedEars
 
M

Matt Kruse

Thomas said:
Where?
Click to expand...

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.
^^^^^^^^^^^^^^^^^^^
(Aaargh!)
Click to expand...

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. :)
 
M

Michael Winter

Thomas said:
Matt said:
[...] I've not seen one yet that didn't treat
<!--
as a single-line comment. In fact, they document it as so.
Click to expand...

Where?
Click to expand...

I've seen it in the past, but I don't know of a current location.
[...]
Click to expand...

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:
Click to expand...

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.
Click to expand...

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

Matt Kruse

Michael said:
And if no reader of this group can, that proves that it will always
work?
Click to expand...

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?
Click to expand...

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

Thomas 'PointedEars' Lahn

Matt said:
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.
Click to expand...

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."
Click to expand...

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.
Click to expand...

Logical fallacy of shifting the burden of proof.
^^^^^^^^^^^^^^^^^^^
(Aaargh!)
Click to expand...

Semantics games are boring. [...]
Click to expand...

This is no game, it is fact that there is no "comment tag".
I have already explained why.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Matt said:
Michael said:
And if no reader of this group can, that proves that it will always
work?
Click to expand...

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, [...]
Click to expand...

There is the flaw of your argument.


PointedEars
 
R

Randy Webb

Thomas 'PointedEars' Lahn said the following on 12/17/2005 1:42 PM:
Matt Kruse wrote:

Michael said:
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?
Click to expand...

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, [...]
Click to expand...


There is the flaw of your argument.
Click to expand...

Your flaw, both you and your arguments, is that you don't know the
difference between Reality and Theory.
 
T

Thomas 'PointedEars' Lahn

Randy said:
Thomas 'PointedEars' Lahn said the following on 12/17/2005 1:42 PM:
Matt said:
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, [...]
Click to expand...

There is the flaw of your argument.
Click to expand...

Your flaw, both you and your arguments, is that you don't know the
difference between Reality and Theory.
Click to expand...

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
 
T

Thomas 'PointedEars' Lahn

Thomas said:
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).
Click to expand...

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).
 
V

VK

Thomas said:
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
Click to expand...

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

Thomas 'PointedEars' Lahn

VK said:
Thomas said:
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
Click to expand...

What in the name are you talking about? What "foo.js" ?!?
Click to expand...

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.
Click to expand...

The point is that SpiderMonkey does not consider that to be markup.
That will fail in any browser, no need to involve any monkeys.
Click to expand...

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).
Click to expand...

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.
Click to expand...

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.
Click to expand...

Examples are not normative, and that section was written before RFC2854
was issued. Unfortunately, a clarification has not yet been added to the
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.
Click to expand...

Exactly. (Once in a while, even you have your bright moments.)


PointedEars
 
R

Randy Webb

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.
Click to expand...

Your flaw, both you and your arguments, is that you don't know the
difference between Reality and Theory.
Click to expand...


Again only your usual ad-hominem rubbish.
Click to expand...

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:
Click to expand...

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,
Click to expand...

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
Click to expand...

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).
Click to expand...


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.
Click to expand...


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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

Considering that the #1 browser on the web doesn't support XHMTL to use
XHMTL as an argument is ridiculous.
 
M

Matt Kruse

Thomas said:
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.
Click to expand...

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

Lasse Reichstein Nielsen

Randy Webb said:
The language is Javascript, not JavaScript.
Click to expand...

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>
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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
 
T

Thomas 'PointedEars' Lahn

Matt said:
Thomas said:
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.
Click to expand...

This is standard behavior for every JScript/Javascript/ECMAScript
implementation I have ever seen.
Click to expand...

Which does not count.
Just because it is not documented in ECMAScript specs doesn't mean it
is not documented.
Click to expand...

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.
Click to expand...

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
 
M

Matt Kruse

Thomas said:
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.
Click to expand...

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

How do I hide the modal after 5 seconds? 4
missing ] after element list 4
missing ) after argument list 1
Missing ) after argument list 8
missing ) after argument list error 4
Help with Visual Lightbox: Scripts 2
Help with my responsive home page 2
missing ] after element list 4

Members online

Total: 42 (members: 1, guests: 41)
Robots: 429

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top