views:

7637

answers:

11

What is the reason browsers do not correctly recognize:

<script src="foobar.js" /> // self-closing script tag

Only this is recognized:

<script src="foobar.js"></script>

Is it breaking concept of XHTML support?

Note: This statement is correct at least for all IE(6-8 beta 2).

A: 

Make sure you have < /script> as well - XHTML does not recognize a self-closing script tag.

Rob Conery
I think he realizes this - he wants to know *why* though.
Jason Bunting
exactly, Why I can use ANY other tag with short type of syntax, bu not the script one?!
dimarzionist
XHTML *does*. It's the HTML parser that makes problems.
Konrad Rudolph
Yikes! Question editing is weird, especially after answers are given.
Rob Conery
The original intent of the question, before editing, was maintained even afterwards. Unless you looked at the code the original poster posted, via hitting "edit," you wouldn't know that because he didn't properly use the markdown editor. That is the source of the confusion which necessitated my edit
Jason Bunting
It's not true that you can use it for any tags. Self closing divs do not work in firefox
Juan Mendes
Is it cruel if I downvoted because it was a chance to downvote a legend (for a somewhat legitimate reason, though) and it makes me feel a little better about my inadequate self?
Atømix
+22  A: 

Please read: Sending XHTML as text/html Considered Harmful

Brad Wilson
+1, a very interesting read
Malfist
+42  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,

squadette
Still, “do not” isn't the same as “must not”. This is a guideline (for compatibility, as suggested by the section title), not a rule.
Konrad Rudolph
Actually, I can't find any use for this restriction :) It seems completely artificial.
squadette
The right answer was given by olavk. The Appendix C of XHTML 1.0 isn’t the reason why things are the way they are—it just how to work around the way things are.
hsivonen
It's not a normative part of specification. It's only appendix about how to deal with browsers that *do not support XHTML*
porneL
+2  A: 

Unlike XML and XHTML, HTML has no knowledge of the self-closing syntax. Browsers that interpret XHTML as HTML don't know that the / character indicates that the tag should be self-closing; instead they is interpret it like an empty attribute and the parser still thinks the tag is 'open'

Just as <script defer> is treated as <script defer="defer">, <script /> is treated as <script /="/">.

rpetrich
Elegant as this explanation is, it is in fact wrong. If it were true, there would be a "/" attribute for the script element in the DOM. I've checked IE, Firefox and Opera, and none of them actually contain such an attribute.
Alohci
+17  A: 

Note that IE does not support XHTML parsing. Even if you use an XML declaration and/or an XHTML doctype, IE still parses the document as plain HTML. And in plain HTML, the self-closing syntax is not supported. The trailing slash is just ignored, you have to use an explicit closing tag.

Even browsers with support for XHTML parsing will still parse the document as HTML unless you serve the document with a xml mime type. But in that case IE will not display the document at all!

JacquesB
+35  A: 

To add to what Brad and squadette have said, the self-closing XML syntax <script /> actually is correct XML, but for it to work in practice, your web server also needs to send your documents as properly formed XML with an XML mimetype like application/xhtml+xml in the HTTP Content-Type header (and not as text/html).

However, sending an XML mimetype will cause your pages not to be parsed by IE7, which only likes text/html.

From w3:

In summary, 'application/xhtml+xml' SHOULD be used for XHTML Family documents, and the use of 'text/html' SHOULD be limited to HTML-compatible XHTML 1.0 documents. 'application/xml' and 'text/xml' MAY also be used, but whenever appropriate, 'application/xhtml+xml' SHOULD be used rather than those generic XML media types.

I puzzled over this a few months ago, and the only workable (compatible with FF3+ and IE7) solution was to use the old <script></script> syntax with text/html (HTML syntax + HTML mimetype).

If your server sends the text/html type in its HTTP headers, even with otherwise properly formed XHTML documents, FF3+ will use its HTML rendering mode which means that <script /> will not work (this is a change, Firefox was previously less strict).

This will happen regardless of any fiddling with http-equiv meta tags, the XML prolog or doctype inside your document -- Firefox branches once it gets the text/html header, that determines whether the HTML or XML parser looks inside the document, and the HTML parser does not understand <script />.

joelhardi
+3  A: 

If you're serving XHTML as text/html, which you have to for Internet Explorer to do anything, it will be interpreted as HTML 4.01. You can only use the short syntax with any element that permits the closing tag to be omitted. See the HTML 4.01 Specification.

The XML 'short form' is interpreted as an attribute named /, which (because there is no equals sign) is interpreted as having an implicit value of "/". This is strictly wrong in HTML 4.01 - undeclared attributes are not permitted - but browsers will ignore it.

XHTML is largely pointless on the web at the moment, because you can't serve it to the majority browser. application/xhtml+xml is not supported in IE8 Beta 2 and I haven't seen anything saying they plan to support it. Stick with HTML 4.01.

Mike Dimmick
+2  A: 

The people above have already pretty much explained the issue, but one thing that might make things clear is that, though people use '<br/>' and such all the time in HTML documents, any '/' in such a position is basically ignored, and only used when trying to make something both parseable as XML and HTML. Try '<p/>foo</p>', for example, and you get a regular paragraph.

Marijn
A: 

I'm not sure I totally buy the fact that IE interprets HTML only and can't understand self-closing syntax. I use <br /> all the time just fine in IE. I also use <meta ... /> and <link ... /> and <hr />, all in IE, and all of them work just fine.

My guess would be it's something more to the point that maybe since <script> is sometimes used in the context of no inner content, and sometimes with inner content, that maybe IE requires the second of the two in kind of a lowest-common-denominator type thing.

Have you tryed those *without* /? At least <br> and <hr> work, have never tryed the others without /.
voyager
A: 

All that to say, it's better to leave XML to the wizards at large companies with oodles of resources and just stick with good old HTML / CSS for us 'regular' folks.

No Spam
+1  A: 

In case anyone's curious, the ultimate reason is that HTML was originally a dialect of SGML, which is XML's weird older brother. In SGML-land, tags can be specified in the DTD as either self-closing (e.g. BR, HR, INPUT), implicitly closeable (e.g. P, LI, TD), or explicitly closeable (e.g. TABLE, DIV, SCRIPT). XML of course has no concept of this.

The tag-soup parsers used by modern browsers evolved out of this legacy, although their parsing model isn't pure SGML anymore. And of course your carefully-crafted XHTML is being treated as badly-written tag-soup/SGML unless you send it with an XML mime type. This is also why...

<p><div>hello</div></p>

...gets interpreted by the browser as:

<p></p><div>hello</div>

...which is the recipe for a lovely obscure bug that can throw you into fits as you try to code against the DOM.

greim