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 elements as:
<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>
Every browser that supports XHTML (Firefox, Opera, Safari, IE9) supports self-closing syntax on every element.
<div/>
, <script/>
, <br></br>
all should work just fine. If they don't, then you have HTML with inappropriately added XHTML DOCTYPE.
DOCTYPE does not change how document is interpreted. Only MIME type does.
W3C decision about ignoring DOCTYPE:
The HTML WG has discussed this issue: the intention was to allow old
(HTML-only) browsers to accept XHTML 1.0 documents by following the
guidelines, and serving them as text/html. Therefore, documents served as
text/html should be treated as HTML and not as XHTML.
It's a very common pitfall, because W3C Validator largely ignores that rule, but browsers follow it religiously. Read
Understanding HTML, XML and XHTML from WebKit blog:
In fact, the vast majority of supposedly XHTML documents on the internet are served as text/html
. Which means they are not XHTML at all, but actually invalid HTML that’s getting by on the error handling of HTML parsers. All those “Valid XHTML 1.0!” links on the web are really saying “Invalid HTML 4.01!”.
To test whether you have real XHTML or invalid HTML with XHTML's DOCTYPE, put this in your document:
<span style="color:green"><span style="color:red"/>
If it's red, it's HTML. Green is XHTML.
</span>
It validates, and in real XHTML it works perfectly (see: 1 vs 2). If you can't believe your eyes (or don't know how to set MIME types), open your page via XHTML proxy.
Another way to check is view source in Firefox. It will highlight slashes in red when they're invalid.
In HTML5/XHTML5 this hasn't changed, and the distinction is even clearer, because you don't even have additional DOCTYPE
. Content-Type
is the king.
For the record, the XHTML spec allows any element to be self-closing by making XHTML an XML application: [emphasis mine]
Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY.
It's also explicitly shown in the XHTML spec:
Empty elements must either have an end tag or the start tag must end with />
. For instance, <br/>
or <hr></hr>
Best Answer
I'm assuming your question has to do with the red trailing slash on self-closing elements when you view source in Firefox. If so, you've stumbled into one of the most vehement, yet simultaneously passive aggressive debates in the browser maker vs. web developer wars. XHTML is NOT just about a document's markup. It's also about how documents are meant to be served over the web.
Before I begin; I'm trying hard not to take sides here.
The XHTML 1.1 spec says that a web server should serve XHTML with a Content-Type of application/xhtml+xml. Firefox is singling out those trailing slashes as invalid because your document is being served as text/html rather than application/xhtml+xml. Take these two examples; identical markup, one served as application/xhtml+xml, the other as text/html.
http://alanstorm.com/testbed/xhtml-as-html.php
http://alanstorm.com/testbed/xhtml-as-xhtml.php
Firefox flags the trailing slash in the meta tag as invalid for the document served with text/html, and valid for the document served with application/xhtml+xml.
Why this is Controversial
To a browser developer, the point of XHTML is you can treat your document as XML, which means if someone sends you something that's not valid, the spec says you don't have to parse it. So, if a document is served as application/xhtml+xml and has non-well formed content, the developer is allowed to say "not my problem". You can see that in action here
http://alanstorm.com/testbed/xhtml-not-valid.php
When a document is served as text/html, Firefox treats it as a plain old HTML document and uses the forgiving, fix it for you, parsing routines
http://alanstorm.com/testbed/xhtml-not-valid-as-html.php
So, to a browser maker, XHTML served as text/html is ludicrous, because it's never treated as XML by the browser's rendering engine.
A bunch of years ago, web developers looking to be more than tag monkeys (Disclaimer: I include myself as one of them) started looking for ways to develop best practices that didn't involved thrice nested tables, but still allowed a compelling design experience. They/We latched onto XHTML/CSS, because the W3C said this was the future, and the only other choice was a world where a single vendor (Microsoft) controlled the defacto markup spec. The real evil there being the single vendor, and not so much Microsoft. I swear.
So where's the controversy? There are two problems with application/xhtml+xml. The first is Internet Explorer. There's a legacy bug/feature in IE where content served as application/xhtml+xml will prompt the user to download the document. If you tried to visit the xhtml-as-xhtml.php listed above with IE that's likely what happened. This means if you want to use application/xhtml+xml, you have to
browser sniff for IE, check the Accepts header and only serve application/xhtml+xml to those browsers that accept it. This is not as trivial as it sounds to get right, and also went against the "write once" principle that the web developers were striving for.The second problem is the harshness of XML. This is, again, one of those flame prone issues, but there's some people who think a single bad tag, or single character improperly encoded shouldn't result in a user not seeing the document they want to. In other words, yes, the spec says you should stop processing XML if it's not well formed, but the user doesn't care about the spec, they care that their cat's website is broken.
Adding even more gasoline to the issue is the XHTML 1.0 (not 1.1) spec says that XHTML documents may be served as text/html, assuming certain compatibility guidelines are followed. Things like the img tag being self closing and the like. The key word here is may. In RFC speak, may means optional. Firefox has chosen NOT to treat documents served with an XHTML doctype but a content type of text/html as XHTML. However, the W3C validator will happily report these documents as valid.
I'll leave the reader to ponder the simultaneous wonder/horror of a culture that writes a document to define what they mean by the word may.
Moving Forward
Finally, this is what the whole HTML 5 thing is about. XHTML became such a political hot potato that a bunch of people who wanted to move the language forward decided to go in another direction. They produced a spec for HTML 5. This is currently being hashed out in the W3C, and expected to finish sometime in the next decade. In the meantime, browser vendors are picking and choosing features from the in-progress spec and implementing them.
Updates from the Comments
In the comments, Alex points out that if you're going to sniff for something, you should check the Accept header to see if application/xhtml+xml is accepted by the user agent.
This is absolutely correct. In general, if you're going to sniff, sniff for the feature, not for the browser.