ChatGPT解决这个技术问题 Extra ChatGPT

Why don't self-closing script elements work?

What is the reason browsers do not correctly recognize:

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

Only this is recognized:

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

Does this break the concept of XHTML support?

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

Works in Chrome and Opera
Some recent version of Chrome appears to have broken this, self-closing script tags no longer work in Chrome
It isn't just script tags. I don't believe self-closing div tags work either.
As of July 2011, Chrome and Firefox have this problem. "It's not a bug, it's a feature" - really annoying.
The more general version of this was asked two days later: stackoverflow.com/questions/97522/…

u
user3840170

The non-normative appendix ‘HTML Compatibility Guidelines’ of the 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

and not

).

XHTML DTD specifies script elements as:

<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>

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.
Actually, I can't find any use for this restriction :) It seems completely artificial.
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.
It's not a normative part of specification. It's only appendix about how to deal with browsers that do not support XHTML
The problem with <script /> is not that the spec disallows it, but that browsers don't interpret it as "non-tag-soup" if the content type is not application/xhtml+xml. See: stackoverflow.com/questions/348736/… @shabunc: browsers may appear to understand it, but what's actually happening is it's putting the content after the <p/> inside the paragraph, due to interpreting squadette's quote to mean that since <p> is non-empty, it can't be self-closing. In XHTML 1.1, it can be self-closing.
J
John

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 elements, 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 />.


Is it correct then to conclude that if you drop support for IE7, sending text/xml will get you broad browser support for Thanks Joe ;-)
Excellent explanation. Another point worth noticing is that Firefox will also have local .html files rendered as a tag-soup regardless of meta tags, for similar reasons. For XHTML files, Firefox will only render them accordingly if they're named .xhtml.
@ChrisMoschini. Probably, but use application/xhtml+xml, not text/xml.
S
Sheepy

Others have answered "how" and quoted spec. Here is the real story of "why no <script/>", after many hours digging into bug reports and mailing lists.

HTML 4

HTML 4 is based on SGML.

SGML has some shorttags, such as <BR//, <B>text</>, <B/text/, or <OL<LI>item</LI</OL>. XML takes the first form, redefines the ending as ">" (SGML is flexible), so that it becomes <BR/>.

However, HTML did not redfine, so <SCRIPT/> should mean <SCRIPT>>.
(Yes, the '>' should be part of content, and the tag is still not closed.)

Obviously, this is incompatible with XHTML and will break many sites (by the time browsers were mature enough to care about this), so nobody implemented shorttags and the specification advises against them.

Effectively, all 'working' self-ended tags are tags with prohibited end tag on technically non-conformant parsers and are in fact invalid. It was W3C which came up with this hack to help transitioning to XHTML by making it HTML-compatible.

And <script>'s end tag is not prohibited.

"Self-ending" tag is a hack in HTML 4 and is meaningless.

HTML 5

HTML5 has five types of tags and only 'void' and 'foreign' tags are allowed to be self-closing.

Because <script> is not void (it may have content) and is not foreign (like MathML or SVG), <script> cannot be self-closed, regardless of how you use it.

But why? Can't they regard it as foreign, make special case, or something?

HTML 5 aims to be backward-compatible with implementations of HTML 4 and XHTML 1. It is not based on SGML or XML; its syntax is mainly concerned with documenting and uniting the implementations. (This is why <br/> <hr/> etc. are valid HTML 5 despite being invalid HTML4.)

Self-closing <script> is one of the tags where implementations used to differ. It used to work in Chrome, Safari, and Opera; to my knowledge it never worked in Internet Explorer or Firefox.

This was discussed when HTML 5 was being drafted and got rejected because it breaks browser compatibility. Webpages that self-close script tag may not render correctly (if at all) in old browsers. There were other proposals, but they can't solve the compatibility problem either.

After the draft was released, WebKit updated the parser to be in conformance.

Self-closing <script> does not happen in HTML 5 because of backward compatibility to HTML 4 and XHTML 1.

XHTML 1 / XHTML 5

When really served as XHTML, <script/> is really closed, as other answers have stated.

Except that the spec says it should have worked when served as HTML:

XHTML Documents ... may be labeled with the Internet Media Type "text/html" [RFC2854], as they are compatible with most HTML browsers.

So, what happened?

People asked Mozilla to let Firefox parse conforming documents as XHTML regardless of the specified content header (known as content sniffing). This would have allowed self-closing scripts, and content sniffing was necessary anyway because web hosters were not mature enough to serve the correct header; IE was good at it.

If the first browser war didn't end with IE 6, XHTML may have been on the list, too. But it did end. And IE 6 has a problem with XHTML. In fact IE did not support the correct MIME type at all, forcing everyone to use text/html for XHTML because IE held major market share for a whole decade.

And also content sniffing can be really bad and people are saying it should be stopped.

Finally, it turns out that the W3C didn't mean XHTML to be sniffable: the document is both, HTML and XHTML, and Content-Type rules. One can say they were standing firm on "just follow our spec" and ignoring what was practical. A mistake that continued into later XHTML versions.

Anyway, this decision settled the matter for Firefox. It was 7 years before Chrome was born; there were no other significant browser. Thus it was decided.

Specifying the doctype alone does not trigger XML parsing because of following specifications.


@AndyE When you write self-closing

You should see Hello, true XHTML. Nice to meet you! below textarea.

For incapable browsers you can copy content of the textarea and save it as a file with .xhtml (or .xht) extension (thanks Alek for this hint).