Marc, was your test document treated as HTML or as XML? In HTML, there are no self-closing tags - /> is not valid in HTML, particularly if it's tag soup HTML.
Alex - doctype as follows: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Not a bug. Safari is expected to fix this when they release with their HTML5 parser.
Henri, respectfully, how is this not a bug? If the script tag is closed, then the following text should be displayed because it its not a script. Marc
I note this function works as advertised in Chrome. The bug reported to me was that the function was not working at all in Firefox - but I am assuming that the user was using an earlier version of Firefox 3.x. This issue also affects other webkit browsers - no surprise there - but surely if a tag is closed, surely the script is invalid? The W3C validator agrees that the script is not open.
The page is served with which content-type ?
> If the script tag is closed It's not. The closing slash thing is XML syntax, but your file is HTML. The doctype doesn't matter; the parser is selected purely based on the MIME type. The W3C validator is just buggy if it claims this document is valid; if it's being served as text/html but claims an XHTML doctype, then it needs to comply with XHTML 1.0 Appendix C, which the above quoted snippet certainly doesn't do. As for Chrome, see comment 3. Chrome uses the same parser as Safari.
The snippet was buggy in and of itself - it even missed the type argument - the point was that with MY error, my Firefox (3.6.13) executed code which was not enclosed by a script tag. My user's Firefox (version unknown at this time) did not execute the block. They filed this as a bug and I spotted it immediately on checking in Webkit (Safari 4 and Android). Presumably, this was a bug in Firefox which has since been fixed? The W3C validator says the tag closing tag is present even when the opening tag was accidentally (in my buggy code) closed. Perhaps I should file this as a bug with the W3C people? Replacing the "/>" with ">" causes the real document to validate correctly. Boris - the effect is different in Chrome 9.0.x (current as of today) and Safari Mac Version 5.0.3 (6533.19.4). Presumably, these version numbers mean more to you than they do to me. As for the XHTML header, I get that directly from my software (Coda) clearly, if there is an error there, it needs to be addressed. Either way, I rely on the error console in Firefox to tell me when I screw up - as I had here - and it didn't. I find that standard's compliant code is better: this "bug/observation" began with something "quick and dirty".
(In reply to comment #4) > respectfully, how is this not a bug? In text/html <foo /> is equivalent to <foo > for HTML elements. The doctype doesn't matter on this point. See http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#acknowledge-self-closing-flag The self-closing flag only has error message effects for HTML elements. It has tree shape effects only for SVG and MathML elements. > The W3C validator says the tag closing tag is present even when the opening > tag was accidentally (in my buggy code) closed. Perhaps I should file this > as a bug with the W3C people? If you have the energy, please file a bug. Don't expect them to fix it any time soon, though. (Note that there's already http://www.w3.org/Bugs/Public/show_bug.cgi?id=4514 which touches this issue but doesn't address the root problem with the W3C Validator. The root problem being that they use an XML parser for text/html content depending on doctype.) > the effect is different in Chrome 9.0.x (current as of today) and > Safari Mac Version 5.0.3 (6533.19.4). Chrome 9 and Safari 5 have different parsers. Chrome has already shipped with WebKit's new parser. There isn't yet a Safari release with the new parser and Safari 5 is using the old one. I'd expect the next major release of Safari to use the new parser that they have on WebKit trunk.