3

I understand that <!DOCTYPE html> makes the browser render the page in standards mode, but that does not prevent your page from breaking when say, HTML 6 comes out.

Instead of making standards so generic, why don't they make it so that at the top of your page you explicitly specify the version of the standard you're targeting? Instead of <!DOCTYPE html>, do something like <!DOCTYPE html=5> so that when a future browser comes around with HTML 6, and they see the line <!DOCTYPE html=5> they know that this page has no idea about the HTML 6 standards, so to guarantee that the page will not break, the browser falls back to HTML 5 standards.

This is like a backwards compatibility approach, so that a page you write today, is guaranteed to work for decades. Of course, you should not wait decades to update your pages, but at least you know it won't break the moment a new version of the standard comes out, and at the same time your page supports older browsers without changing one line of HTML.

Why aren't things this way? What's wrong with that approach?

Dave Zych
  • 21,581
  • 7
  • 51
  • 66
AxiomaticNexus
  • 6,190
  • 3
  • 41
  • 61
  • Well you can't take web as it stays forever same you need to update it, this means also updating the compatibility. You can not make not much future proof pages. – Risto Novik Jan 10 '14 at 21:49
  • I think that always rendering in standards mode is the point. Any new standard will be backwards compatible. As a developer it's time to stop worrying about that nonsense. – johnnycardy Jan 10 '14 at 21:49
  • 1
    If it ever happens -- html6 breaks html5 pages -- it will be defined as ` ` and we are all fine. – Beterraba Jan 10 '14 at 21:52
  • @Beterraba but if that is a possibility, then why not make it ` ` starting NOW. – AxiomaticNexus Jan 10 '14 at 21:54
  • 1
    Future compatibility by definition does not exist. – deceze Jan 10 '14 at 22:07
  • @Beterraba - While having a different doctype for a future version of HTML has not been ruled out, should it become necessary, (see Quentin's answer for why that shouldn't happen) it won't be ` ` because that would cause all of today's browsers to render the html6 page in quirks mode. – Alohci Jan 10 '14 at 22:23
  • @Alohci I know. I'm justing saying that, in the scenario where it becomes necessary, all you have to do is define a new doctype for the future version. – Beterraba Jan 11 '14 at 02:01

2 Answers2

6

I understand that <!DOCTYPE html> makes the browser render the page in standards mode, but that does not prevent your page from breaking when say, HTML 6 comes out.

Yes, it does. Additions to HTML are designed to be backwards compatible so that browsers don't start rendering older pages incorrectly.

Instead of making standards so generic, why don't they make it so that at the top of your page you explicitly specify the version of the standard you're targeting?

They tried that, although for different reasons (HTML was designed as an SGML application, but browsers didn't implement it as such). Every version of HTML and XHTML prior to HTML 5 did that. Browsers didn't distinguish between versions (only between quirks / almost standards / standards modes, all of which had far more impact on the handling of CSS and DOM then of HTML). Most authors didn't write code to match the Doctype they used.

What is a browser supposed to do if it sees a Doctype it doesn't recognise? It can either refuse to render the page (which doesn't help users at all) or it can try to render it as best it can (which is what it does).

What is a browser supposed to do if it sees a Doctype that doesn't support elements that are in the document? It can either ignore them (which doesn't help any one), throw an error (which could help a developer, but only if the developer tested in the most restrictive browser on the market, otherwise it just harms users), or render them as best it can (which is what it does).

The point of Doctype Switching and Quirks mode isn't to support web pages designed for older versions of HTML, but for pages designed for early, extremely buggy browsers.

Today, browsers are much better designed, much more rigorously tested, and their authors are much better about writing specifications for new HTML/CSS/DOM features, creating test suites for them and having multiple implementations of the feature (in different browsers) before they get public, unprefixed implementations that aren't locked behind a config option deep inside the browser. This dramatically reduces the number of things that are likely to break as browsers are updated, so there aren't significant new bugs that they need to remain backwards compatible with.

they know that this page has no idea about the HTML 6 standards, so to guarantee that the page will not break, the browser falls back to HTML 5 standards.

See above re backwards compatibility.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • So what you are saying is that this approach didn't work because browser developers and web developers did not follow the standards, otherwise it would have worked? – AxiomaticNexus Jan 10 '14 at 21:51
  • No. I wasn't clear. That's why the use of the feature didn't work. The feature wasn't designed to solve the problem you are trying to solve (and it doesn't solve that for completely different reasons, which I've elaborated on in the answer). – Quentin Jan 10 '14 at 22:04
1

It doesn't really matter if the HTML content itself is "futureproof" as this still does nothing to enable/correct enhanced/changed functionality that might exist in browsers of the future. It is really up to browser developers to make sure their changes are backwards compatible. IMO, it is not reasonable to expect that something you right to current standards now should should behave the way you want 5 years down the line.

If the website is deemed important, it will have continuous development against it to stay reasonably current.

Mike Brant
  • 70,514
  • 10
  • 99
  • 103