views:

213

answers:

5

How awful is that, after an hour of hunting and pecking, I figured I might as well contribute to the world the awful truth that the only reason your javascript failed to work in IE is because you thought you could pull a fast one on it and use your fancy xHTML shortcut.

I've read the dtd and I can't really find any basis for IE being so persnickity.

+3  A: 

XHTML 1 specification says:

С.3. Element Minimization and Empty Element Content

Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />).

XHTML DTD specifies script tags as:

<!-- script statements, which may include CDATA sections -->

<!ELEMENT script (#PCDATA)>

Hope it helps,

This is from : http://stackoverflow.com/questions/69913/why-dont-self-closing-script-tags-work

Andrew Clark
However if you're sending content to IE you're going to have to be sending html, not x[ht]ml so the xhtml spec is actually irrelevant :D
olliej
What did you search for to find that link? I'm trying to broaden my abilities to answer my own questions, but I didn't find that.
Peter Turner
The XHTML spec is relevant because the particular appendix being quoted is all about what constructs have to be avoided for HTML compatbility.
bobince
Appendix C of the XHTML spec, which is where this comes from, is all about ensuring backwards compatibility with HTML. XML would not otherwise prohibit non-empty element minimisation.
thomasrutter
+8  A: 

You're not using xhtml, you're using html, and html does not support the self closing tag syntax of xml -- in html using the self closing tag syntax will result in an attribute '/' being place on the element, not in closing the tag.

Now depending on the context of the <script> tag the browsers will typically correct this, so you're in effect relying on the browsers autocorrection to make everything work properly.

olliej
+2  A: 

While the answer marked "correct" in Andrew Clark's linked question is technically correct, the other browsers (which support XHTML sent as application/xhtml+xml) treat anything that's sent as text/html (even with an XHTML doctype) as HTML. In the case of tags that are unclosed in HTML (eg <img>), the parser (correctly) treats self-closed tags (eg <img />) as a syntax error, and ignore the slash. In the case of <script> tags, which are meant to be closed in HTML (text/html), the parser simply does not find the close tag, and treats the following content as part of the script.

See: http://webkit.org/blog/68/understanding-html-xml-and-xhtml/

(Or if the server is flaky for you like it is for me, here's the Google cache: http://209.85.173.132/search?q=cache:WFDCo2hoRnAJ:webkit.org/blog/68/understanding-html-xml-and-xhtml/+script+tag+surfin-safari&amp;hl=en&amp;client=safari&amp;gl=us&amp;strip=1)

eyelidlessness
+5  A: 

Is IE the only web browser that requires <script></script> and hates <script/>?

No, all current browsers behave the same when being served XHTML as text/html. There is only a difference between browsers unless you are sniffing for IE and sending it a different Content-Type to other browsers. (Top tip: don't do that. There is nothing to gain and plenty of weirdness to get bitten by.)

The empty element syntax is not understood as anything special by HTML browsers, it is only there to paper the cracks between HTML's unclosed elements and XHTML's empty elements. So you can't ever use one as a ‘shortcut’; empty elements can-only-and-must be used for empty elements, as specified in the XHTML Appendix C guidelines.

You can verify this as simply as:

<p style="color: red" />html

All browsers I have tested colour ‘html’ in red.

bobince
Definitely true, and yes that is a good demonstration of how browsers in HTML mode see "XHTML".
thomasrutter
+1  A: 

You do not want to be constantly testing these waters, because you are depending on the browser coders to imagine your creativity in advance.

You are depending too much on the target browser to auto-translate. I see similar code in View Source all the time, where extra "/" are red-lined by Firefox, but they happen to be in places where the HTML parser allowed it.

Having worked for a browser vendor, I can tell you that many of the weird-little-things-that-happen-to-work were (reluctantly) added because a situation required the support of something weird and incorrect. Each of these funny cases adds bloat, increases the testing requirements, and is avoided by developers whenever possible.

benc