Login/Register
What DOCTYPE should I target today?
Asked Answered
Solved asp.nethtmlasp.net-ajaxdoctypew3c-validation
K

5

12

I'm refactoring a .Net web application that is in 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >

Right now the approach is just to aim for the stars and go for the latest doctype just because it's latest, I would like to make a wiser choice and target a specific one and for good reasons.

There are similar questions existing but the answers might be outdated now.

What is the difference, advantages, disadvantages between standards and quirks mode, what are some quirks I may run into with differently set doctypes?

I have been told that an XHTML doctype is preferable to integrate AJAX since the UpadtePanel serializes it and to do so needs to have a XHTML do type, to what extent is this true?

And for browser compatibility, in which direction are browsers going in terms of DOCTYPE, is there a common thrend or do they differ?

Konikow answered 14/7, 2010 at 20:6 Comment(2)
possible duplicate of What DOCTYPE is recommended for my HTML output for IE7/IE8/FF3+? and how can I update my HTML validation in Visual Studio to reflect that change? – Kiefer
I found the HTML5 validation plugin for Visual Studio it adds intellisence and property window for HTML5 element attributes. blogs.msdn.com/b/webdevtools/archive/2009/11/18/… – Konikow
A
17

HTML5 doctype, which is

<!DOCTYPE html>

XHTML is largely dead as a standard, and never was implemented correctly in most cases.

Asexual answered 14/7, 2010 at 20:9 Comment(8)
-1 I'll alert the thousands of REST applications, the W3C, and WHATWG that XHTML is dead and drop all four current projects my company is working on. – Monogamous
The W3C is hardly an impartial third party. They wrote the freaking spec, and they still love them some XHTML and push it every chance they get, but they pretty much doomed it with 2.0. (Not backward compatible? WTF, y'all.) XHTML 2.0 is probably a huge part of why there even IS an HTML 5. – Cytoplasm
@Rob: Most XHTML is actually served as text/html and therefore parsed as HTML (NOT XHTML). If you serve it correctly you may find that what you thought was valid XHTML no longer works because it depended on the leniancy of the HTML parsing. XHTML had benefits, but was also extremely fragile (and, despite what DOCTYPEs say, it is used very little)--leading to it being a largely dead standard. – Blessed
@Blessed - Despite misuse by amateurs and the unknowing, XHTML is alive and well for those of us who know how to use it. The real problem is with Internet Explorer, as everything on the internet is, not XHTML, since IE is the only browser that does not work with it (or much of anything else for that matter). – Monogamous
@Rob: about Internet Explorer, it's not compatible with XHTML? is it that it can't interpret markup that complies to XHTML or it's the use of a XHTML doctype that breaks something, because I have noticed the layout of my pages getting messed up when I changed the doctype to XHTML, and had to do alot of fine tunning espcialy removing attributes from HTML elements and replacing them with CSS either inline or in a external file – Konikow
@: cHao XHTML is part of HTML5 @GenEric35: using an XHTML doctype (provided its valid) should never break anything that worked in HTML - browsers don't differentiate between different (valid) doctypes. Unless you're referring to the W3C validator, which does. – Turgite
@GenEric35: XHTML support in IE 6/7/8 is very limited, the W3C has a recommended hack to get IE to treat XHTML as XML (normally it will either treat it as HTML, or it will prompt the user to download the file): w3.org/MarkUp/2004/xhtml-faq#ie – Blessed
XHTML is dead, Jim, but not as we know it. – Rooster
B
4

Any Doctype:

  • HTML 4.01 or XHTML 1.0
  • Strict or Transitional

served as html (not html+xml) should be OK. There's no such thing as a better doctype, you just have to choose one filling your needs and then stick to its rules.

  • Avoid Frameset, but if you've to, use the title attribute to describe the role of each frame to a screen reader user (same with iframe btw).
  • Quirks mode (no Doctype) is a PITA, avoid it at all cost. This was OK 8 years ago.
  • No XML prologue unless you're serving html+xml (good luck with that! If you like complicated things when it's not needed, that's your choice)
  • If you are forced to use attributes that are forbidden in Strict mode (target="_blank" for example) than use Transitional mode: this is why it was created! And please indicate to your users that the link will open in a new page, whether in the text of your link or in its title. This is important from an accessibility point of view.

HTML 5 is the next big thing, we're waiting for it but as long as it won't work in every browser (I mean IE without JS) it's not advisable to use it in "serious" public sites. Is it even a Draft? What if entire part of it are rewritten in a couple of months?
My web agency uses it for its website but we won't use it on a client site anytime soon: it's just too soon.

Sidenote: I often see catch phrases like "a modern website in HTML5 and CSS3" implying that CSS3 is made for HTML 5. CSS3 has nothing to do with HTML5 and can already be used, as long as it degrades gracefully on old browsers.
You can design HTML5 with CSS2.1 or HTML4.01 Transitional with the latest CSS3 animations that only work in webkit nightlies, no problem.

Baldpate answered 14/7, 2010 at 20:53 Comment(2)
Serving XHTML as text/html is a bad idea--but unfortunately a hugely common problem. Serving it as HTML leads to browsers using their HTML rendering--and valid XHTML isn't necessarily valid HTML. For example, a self-closing <div/> is valid XHTML but invalid HTML (it parses it as "DIV/". Placing a space before the '/' (<div />) is a hack to let it be valid XHTML and quasi-valid HTML (the parse treats the '/' as an invalid attribute and ignores it. – Blessed
@Blessed Trailing slashes are no longer invalid HTML - they're perfectly valid. The space hack is purely a legacy SGML measure, but HTML has moved on from SGML at this stage. – Turgite
C
3

The new thing is HTML 5.

<!DOCTYPE html> is what you use to specify it. That's it. No DTD name or URL or whatever.

If you're using something that likes XML, like .net, then you might want to use XHTML. But don't do it for any other reason; XHTML never was really popular as a standard, or at least it was almost never used correctly.

Cytoplasm answered 14/7, 2010 at 20:10 Comment(2)
+1 for .Net considerations, this is indeed a ASP.Net 3.5 application with some WCF calls made from the Web app, and some AJAX.The app is likely to migrate to ASP.Net 4.0 soon. I am trying to find the implications of XHTML for .Net, so far I heard only rumors about it being required for AJAX, do you know of any specific XHTML requirements or benifits for .Net? – Konikow
@GenEric35: I'm not sure about how required it is, but i do know Visual Studio really, really wants your code to be XML. I also read somewhere that there are a couple of controls that don't mind unclosed elements, which implies to me that almost all of them do. As long as you close your tags, it shouldn't matter much -- but ASPX tags are pretty much XML, so you may as well just go with XHTML and save yourself a bunch of hassle. – Cytoplasm
T
1

Browsers have never actually used DOCTYPE to determine the markup language of your document (they use HTTP Content-type instead), so which DOCTYPE you chose was never hugely relevant - just as long as you are using a valid DOCTYPE of some description. Whichever you choose is up to you.

If you're writing HTML, <!DOCTYPE html> is the shortest to type, and puts all browsers into standards mode (which is what you want).

If you're writing XHTML, <!DOCTYPE html> is also perfectly legitimate (XHTML actually requires no DOCTYPE at all, as it relies entirely on HTTP Content-type, but there's no harm putting a DOCTYPE in for portability.

Don't use <!doctype html> - while this is technically valid HTML, it's invalid XHTML so will break if you ever try to parse your page as XML.

Slightly OT sidenote: Some people here have commented that XHTML is a "dead" standard - this is false. XHTML has been integrated into the upcoming HTML5 spec. The spec is entitled "HTML5: A vocabulary and associated APIs for HTML and XHTML"

See:

Turgite answered 15/7, 2010 at 14:35 Comment(12)
Not true at all. Absence of a doctype puts browsers into quirks mode. hsivonen.iki.fi/doctype – Monogamous
@Monogamous Where did I say to exclude DOCTYPE? I explicitly said in the first paragraph that you DO need a valid doctype. Sorry if you mis-read my post, but nothing I said is untrue. – Turgite
@Turgite - I'm contesting that you said a doctype is not used to determine the markup language and evidence of that is my example. However, re-reading that paragraph, I see you didn't say what I was more alarmed about; that people might think you were saying the doctype is not important. – Monogamous
@Monogamous Thanks for replying, but I'm afraid I must contest again. If you set an XHTML DOCTYPE with a HTML content-type, the browser will render HTML, not XHTML - that is what I meant when I said DOCTYPEs don't determine markup language. The link you provided details many different "rendering modes" all for the HTML markup language - none of them apply in any way to any other markup language. – Turgite
+1 -- lucideer is exactly right on this -- ContentType takes precedence, of course a fun fact is that IE 6/7/8 only quasi-supports XHTML: w3.org/MarkUp/2004/xhtml-faq#ie – Blessed
@Blessed true, but IE9 has finally added support, so it's day may come yet. AmpleSDK also provides some interesting levels of support for the older IEs. – Turgite
@Turgite lol, only 11 years after the party :) personally, I'd have preferred a full-blown HTML-5 implementation over XHTML. Then again, it's Microsoft, and no matter how much I hate it my sites will still need to support their bass-ackward business decisions. – Blessed
11 years and still more powerful than anything that's come in the interim :D As for coming "after the party" - with the likes of Facebook (Graph API), Drupal (version 7), Yahoo (SearchMonkey) and Google (RichSnippets) only now jumping on XHTML's extensibility, the party seems to be just getting started. HTML5 is a great set of APIs (DOM/canvas/etc.), but as a markup-language, it's a bit out of touch with reality. – Turgite
@Blessed - except lucideer is wrong. reference.sitepoint.com/css/doctypesniffing Content type does not determine standards mode and having the wrong doctype can still trigger quirks. Also, IE has zero support for XHTML despite any trickery to make it work. – Monogamous
@Monogamous lucideer is correct that ContentType is a higher-order directive than DOCTYPE, he might be off a bit by saying DOCTYPE doesn't specify what markup you're using but his main point is correct (if you use the wrong ContentType then you'll never be parsed as you'd expect from the DOCTYPE). So, DOCTYPE is only effective within the provision that the Response has the correct ContentType--as for your IE concerns: yes, IE uses it to determine what mode to render--and yes, IE9 will be the first version with true XHTML support. So the bottom line is any DOCTYPE of XHTML is almost certainly wrong. – Blessed
@Monogamous I think we're both correct actually - we're just using different terms. DOCTYPE's trigger "Standards mode" (as opposed to "Quirks mode") which are two different modes in the SAME markup-language (HTML). Content-type chooses the markup-language. For example - if you use an XML content-type, and no DOCTYPE at all, you don't get "Quirks mode" - because it's a different markup language (XML) - quirks mode is a rendering mode, not a markup language. – Turgite
@lucideer, yes, that's what I was getting at and might not have been clear. – Monogamous
B
1

Whatever you choose, make sure your MIME-Type is compatible with your DOCTYPE

The browser will use the MIME-Type (the HTTP Header ContentType) to determine how to treat your page. For example: A DOCTYPE of XHTML 1.1 Strict served as ContentType Text\HTML is parsed as HTML.

DOCTYPE is important, but largely irrelevant if the wrong ContentType is used.

Blessed answered 15/7, 2010 at 20:48 Comment(1)
I'm not 100% sure what you mean by your emboldened comment - all (valid) DOCTYPEs are compatible with both text/html and application/xhtml+xml (and other content-types). A DOCTYPE of XHTML 1.1 Strict served as text/html is a valid polyglot (provided the markup validates obviously). – Turgite

© 2022 - 2024 — McMap. All rights reserved.