People have already written a number of articles either for or against dropping the version number on HTML. Here are two contrasting views about this news presented by Bruce Lawson, and John Foliot.
The facts
Ian Hickson, editor of the HTML5 specification, announced that HTML is the new HTML5, meaning that the WHATWG will drop the numeral "5" and just call their spec "HTML". HTML will be a "living standard", with a mixture of widely-implemented features like <canvas>
or <video>
and wildly experimental features like <device>
. The W3C produces a spec called "HTML5". Ian Hickson (currently) edits both of them. They are different. The W3C creates a version of this technology which is under the W3C Royalty Free Patent Policy to give a better guarantee for developers against patents. This specification has the version number 5. (There's an interesting conversation to be had about the WHATWG, patent policy, and licensing, but that's not for today.)
TL;DR: nothing much changes (by Bruce Lawson)
So what does this mean? What changes for us developers? In practice: very little for most of us. Browsers process what they can process regardless of what mode they're in, what "version" of HTML is current, or what a document's DOCTYPE claims.
Take for example a document containing a <video>
element, using WebM, Ogg, and MP4 <source>
elements, with scripted controls using the media elements API, input type=range
, and CSS3 opacity and transitions. With an HTML2 (yes, HTML2!) DOCTYPE, it's a fine example of HTML2 video.
If you're using a modern browser, everything will work fine. Your browser knows how to show those HTML5 goodies, so it does, regardless of what the DOCTYPE claims. What would be the point of a browser looking up what elements are part of HTML2 and refusing to show the video since <video>
isn't part of that list? Such switching logic would take longer to process, delaying rendering for no practical benefit at all.
The only function of a DOCTYPE is to keep the browser out of Quirks Mode. The HTML5 DOCTYPE <!DOCTYPE HTML>
is the shortest string that does this reliably. And note that there's no version number on that.
If version-less HTML surprises you, it shouldn't. It's what CSS has used all along. We happily use some CSS 3 modules without vendor prefixes (border-radius
, for example) while we avoid some CSS 2 features because they have no support. So the version number has no practical use and we don't sweat it at all.
Here's an extract from a 2008 interview by xhtml.com with Bert Bos, who co-created CSS with Håkon Wium Lie (one of the core WHATWG members):
xhtml.com: I suspect many people haven't noticed that CSS has no version identifier….What drove the original decision not to include a version identifier and how has this affected the evolution of the CSS spec?
Bos: The working group has recognized since a long time that version numbers for document formats (as opposed to software) are a fallacy. HTML has version numbers (inside the DOCTYPE), but implementations either ignore them or use them for something else ("quirksmode").
Formats may evolve and be extended, as HTML and CSS are, but implementations won't provide different parsers for the different versions. They only implement the current version. The new version better be backwards compatible, or disaster will ensue. You might think that putting in a version number will cause old implementations to refuse documents that are too new, but it doesn't. None of the browsers written in the days of HTML2 will refuse to handle an HTML4 DOCTYPE. And none of the current HTML4 browsers will refuse an HTML5 document once HTML5 becomes a standard. No browser wants to admit it can't understand something and users don't want to use new features if that causes the whole file to fail.
The basic problem is that old and new software and old and new content have to coexist. It isn't possible to pick a day and switch all content and all software in the world over to the new version. And on the Web, some software, and especially some content, have very long life spans.
Sounds familiar, doesn't it?
(It's not the whole story. As I've mentioned above, all browsers use DOCTYPE to switch between parsing modes. Quirks mode is triggered by a line in the HTML, but it doesn't alter HTML parsing — it switches CSS parsing between IE5's broken box model or the W3C box model. Internet Explorer also has its compatibility mode which allows IE to mimic old, buggy versions. Note that these are switches to trigger buggy implementations; they are not switches between implementations of different versions of CSS or HTML. I may be splitting semantic hairs here.)
So HTML versioning will be the same as CSS versioning. With CSS, as it's only styling and not content or functionality, it doesn't matter much if something fails silently. With HTML5, we don't have vendor prefixes like CSS does, but most (if not all) new features can be feature-detected and poly-filled with JavaScript. It might not be beautiful, but it's the way of the world, and version numbers won't change that.
Ultimately, the presence or absence of a version number is less important than the fact that we have a spec that extends HTML without breaking backwards compatibility. That's what I celebrate in my Geek Song Living Standard.
Versioning isn't for browsers. It's for authors. (By John Foliot)
The main issue, as I see it, is that W3C Standards ("Recommendations" in their parlance) are not "snapshots". They're engravings, which implies a whole other level of stability and commitment. Engravings, for example, are used to print our paper currency.
The last standardized commit to HTML was over a decade ago with HTML 4.01 (Dec., 1999) (and/or the XML serialization of XHTML in January 2000, revised 1 August 2002), and HTML5 (the markup language), once finalized, will likely continue to be the benchmark a decade from now. While most would concede that HTML 4.01/XHTML 1.1 are somewhat dated today, you could (if you wanted) continue to build a site using <frames>
, and it would work, and all user agents would know what to do with that code. Team members could work on that code in a shared environment, using different types of editing tools (including WYSIWYG tools). That work could span cultures and geographies as the specification has been translated into numerous world languages and teaching curricula. It is that kind of permanence and stability that comes with an actual Standard.
Just look at <hgroup>
. Where are we with that today? Next week? April 2011? Who knows? (I sort of know. There's a bug filed, and it will likely be escalated to an actual issue in the Last Call process. <hgroup>
's future is under debate at this time, but with no firm timeline. The point is, you need to be on top of this stuff continuously, a task that many larger groups simply do not have the time or resources to do.) Then there is the accessibility of <canvas>
and <video>
— points I don't need to belabor, but issues that remain non-trivial today. Much of the current new "goodness" in the Draft HTML5 Specification has very little browser support. Look at the lack of complete support for Web Forms or many of the other newly introduced elements. It's gotten so bad that some of the less-informed think that the solution today is that all of the browsers should just move to WebKit and the problems will be solved — a suggestion so far-removed from any kind of reality as to be laughable. The answer is not to move to one rendering engine for stability, but rather for all to agree on one firm specification that works across all browsers.
My larger objection is around perception of the spec: developers who think that just because it's spec'ed at WHATWG this week that it's good to go, bring it on, to heck with permanence and legacy! It's a continued "fix-it-in-the-mix" attitude far-removed from the real world of large corporations and government. In the contest to be cool and cutting-edge, some developers forget that there is a world of commerce and actual Just-Like-Mom users out there who think that the latest advancement of the internet is Farmville on their cell phone.
I think the recent release of Drupal 7 is a great example. After nearly three years of intense community collaboration by nearly a thousand contributors, the latest version of this high-profile Open Source CMS was launched simultaneously with numerous plug-in modules re-factored for this next-generation build. Standards conformance was a huge driver for this version (as was accessibility support), so this large group of developers required an extremely stable benchmark to work towards. They couldn't rely on spec that changes monthly. Nobody wants to go back and re-write code they shipped four months ago simply because the current Draft Specification has changed the way things are done. Thus, the bulk of Drupal 7 sites I've seen to date (including those with custom themes) proudly sport the following under the hood:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
WHATWG serves a useful function, no doubt. Like the Fashion Houses of Paris, New York and London, they create and explore and push the boundaries. But they also often remain far-removed from the world of F&F Clothing at Tesco — Tesco by the way being an "Official Sponsor of London Fashion Week". I truly believe that the web community needs to be reminded of this fact. An evolving spec serves the needs of browser vendors, but it is no friend to many commercial developers as it hurts larger entities who need to share authoring responsibilities.
Like that paper currency made from those engravings, I want to be sure I can take it to the bank.
About John Foliot:
John Foliot is a Web Accessibility Specialist with over a decade of experience in that field. He manages the Online Accessibility Program at Stanford University, and is a co-chair of the W3C's HTML5 Accessibility Task Force, where he is focused on accessibility of the new media elements. When not ranting on the web about web accessibility and web standards, he enjoys riding his motorcycle, listening to and collecting Blues music, and sampling fine Single Malts with fellow geek friends. You can follow him on twitter at @johnfoliot.
In summary
We've given two opposing views on this matter, and now we want to hear your thoughts. Are you for or against a living HTML standard?
42 Responses on the article “HTML as a Living Standard — For and Against”
I work in the mobile space – so I tend to see things through that lens.
What bothers me with a “living” spec is that many browsers will never *ever* see an upgrade. It’s relatively easy for a desktop to upgrade the browser (corporates stuck on IE6 aside). Most phones are abandoned by their manufacturers long before their users abandon them.
Sure, the browser on my ancient GX-10i may be able to muddle-through an HTML5 document (it does, I checked), but is that the best thing to serve it? How do you identify what the browser does support? How does a customer know what their phone supports?
Versioning, imperfect as it is, gives some measure of confidence to developers and users.
Or, as with many things, am I hideously mistaken?
It doesn’t seem like there’s much actual conflict here: both sides are essentially saying that you can’t rely on a spec version and instead need to work with the browsers your users actually run, taking care to confirm that features both exist and work well.
John went off on a bit of an irrelevant tangent as e.g. it really doesn’t matter what DTD Drupal 7 sites use as so far I’ve yet to see a single Drupal site which actually validates – when I checked last fall, the W3 validator had a bug preventing *any* XHTML+RDFa site from validating – and this really hasn’t prevented anyone from building great sites.
The main benefits to “HTML5” conceptually was rejecting the XML tarpit and breaking from years of stagnation with a new wave of standard activity and a strong rejection of Microsoft’s horribly ungainly extension style and API design which were all we had during the dark ages when IE had 90% market-share. We’re always going to need to track feature maturity but at least now we can focus on more useful things than counting how many namespaces can dance on the head of a pin.
Terence: the problem I’ve always had is that browser lie about versions and anything non-trivial has always needed some sniffing to deal with bugs; the only way around that will be getting carriers and vendors to behave responsibly and ship updates – they’ve been happy to sit on security updates for years so it’s not as if this only affects web developers.
@John — your argument would make sense to me if browsers actually completely and interoperatively implemented W3 recommendations (/standards/engravings), but they don’t. Because of this authors use the specs as a guide to the way things should be, but browser testing as the sanity check of what actually works and what doesn’t.
Your example of
<hgroup>
is kinda irrelevant as it has no effect on anything in the browser, which is kind of the point of the complaints about it huh. Even if it was dropped from the HTML5 recommendation, supporting browsers would still support it. Also,<hgroup>
,<canvas>
and<video>
are all issues in the HTML5 spec, so how are they relevant to HTML# vs HTML?As the W3C is still providing recommendations/specifications/engravings I really don’t see the problem, apart from a kind of “WHATWG is what the kids like, and I don’t like kids” vibe :) If these young pups you’re talking about are web devs, it’s irrelevant if they try something that isn’t implemented yet because (duh) it isn’t implemented. If you’re talking about implementors O_o …
Sure there’ll be ppl who misunderstand, but they did that for HTML 4 and XHTML 1 and goshdarnit they’re doing that for HTML5 too. Personally I didn’t even notice when XHTML 1.0 went to second edition (OMG! it changed?!), because I used http://www.w3.org/TR/xhtml1 not http://www.w3.org/TR/2000/REC-xhtml1-20000126 (or http://www.w3.org/TR/2002/REC-xhtml1-20020801). How is the new WHATWG HTML world (that W3C isn’t partaking of) any different from XHTML 1 insidiously going to second edition?
It seems to me the only people this living spec thing inconveniences are (wait for it) book authors. The kicker is “HTML, the living spec” is the most versioned thing W3C has ever been involved with! :D
My very humble opinion is that I am for a living – versioned – HTML standard ;)
I think Bruce Lawson is going the wrong way. The problem isn’t newer elements WORKING in old versions or doctypes, but old elements BREAKING in the same doc-type after HTML6 or HTML5.1 depending on some browser update.
This could be a real problem with elements like video, audio and canvas, and less with elements we’ve had up up to HTML4 (basically text and images).
So… you can’t really break backwards compatibility If some future problem will be found, or some other change that will be needed (unless they’ll decide to add another doctype in the future, which will just shows how this is a bad move…). As we’ve seen with this version, elements can change (DL and all the i/b/u etc).
I don’t really get what this decision adds to the standard and what end users gain from this.
Imo, this is just a bad move from a group that just can’t really handle the monster that HTML/5 has become and is taking the easy way out, instead of deciding what goes IN and what stays OUT they’re just ‘well… err… living standard!’.
I don’t know exactly how HTML5 modules will be handled, but I assumed they will be similar to their CSS3 counterparts. As far as I know, no CSS3 module has been finalized yet, but what really annoys me is that I can’t find an exhaustive list of all the modules. Other than that I love that CSS3 can be modified one small piece at a time, so long as it remains backward compatible.
Although I expect to soon join the corporate club, I’m not in yet. But I have a mental picture of a normative list of all the stable modules; so long as we get that, does it matter that others are changing? We could look at the list for available features, and the spec authors would promise to leave those parts alone. (An additional browser-compatibility status for each module would be fantastic.)
The main browser problem with “living specs” is the lack of pressure. Hey IE/Mozilla/Opera/Apple/Google, why don’t you implement the full HTML5 spec? Because there is none…
Versions are a line in sand – only sand – but it’s still a line.
Look at the Acid tests. One of the critera used to make them was that the technologies tested were at REC level. Who could know what to include or exclude in a versionless world?
Specs that reach CR is a bargaining chip for web developers against browser manufacturers, and we desperately need that these days!
I am for the living standard because I think it is valuable to adapt to changing browsers, and the browsers followed the proposals, not the releases. After reading this, I am also for the standard, so serious coding organizations can make the latest stable code and move on to their other projects. I see the purpose of each, now. I must admit though that I don’t really believe a living standard restrains teams from developing the latest code, and I don’t think the necessity of a release should restrain teams who can keep up and flourish with a living standard.
“Browsers process what they can process regardless of what mode they’re in, what “version” of HTML is current, or what a document’s DOCTYPE claims.”
Unfortunately, a lot of the HTML4 enthusiasts/HTML5 opponents I’ve spoken with think the DOCTYPE actually qualifies as some kind of legitimate versioning mechanism, or is justified in being one. (Like that would even be beneficial or useful in the first place.)
“developers who think that just because it’s spec’ed at WHATWG this week that it’s good to go, bring it on, to heck with permanence and legacy! “
This sounds very wrong. Web developers who are savvy enough to be reading the specs probably understand what the WHATWG spec is…particularly because the WHATWG spec lays it out very clearly in the introduction.
I don’t see a conflict here. In reality what I see is WHATWG working with browser manufacturers to identify holes in the current published version (currently 4). The W3C takes those changes and vets them in a slow but hopefully quickening process and publishes the update (currently 5). Browser manufacturers now have a new litmus test that the development community will hold them accountable too. The circle is complete with WHATWG working with browser manufacturers to identify holes in the current published version (what will then be 5).
By the time (hopefully much sooner then 2022) W3C says HTML5 is “done”. The living HTML spec will have mature changes for the W3C to consider.
Browsers should always support at least the published W3C requirements for user agents (which are explicitly demarcated in HTML5) and be working on implementing parts of the Living HTML as they prioritize.
Developers should be able to rely on having certain features as a baseline (even IE will render this correctly without a hack). New Acid tests would be published for these baselines and a separate test suite for a snapshot of the Living spec.
We should all be designing with progressive enhancement in mind anyway. This should not affect how we code.
@CHJJ “Web developers who are savvy enough to be reading the specs..” presumes that those developers have the time and mandate to follow along with the daily happenings at the WHAT WG, something that is far from a reality in large organizations. Boutique developers can certainly dedicate time to doing that, but the “WalMarts” of the web don’t, and wont – they have deadlines and 8 month project deliverables and teams that include everyone from the bleeding edge aficionado to the 6 month temp filling in for the administrative assistant out on parental leave. These people aren’t rolling their own code in Textmate, they are looking to use a WYSIWYG editor such as Dreamweaver or an embedded editor such as CKEditor or TinyMCE – how can these tools remain up-to-date when the spec changes at whim?
@Lars Gunther Thanks for pointing out ACID… a series of CSS conformance tests that have, that’s right, versions… (both the tests *AND* the specifications). I wonder how many people have seen this: http://dev.w3.org/csswg/css4-background/ (“This draft contains the features of CSS level 4…” yes, CSS 4)
@Oli Studholme Hmmm… who said anything about age? There are a lot of edgy developers out there that have long since seen their 20’s that also cheer for Versionless HTML, and if you run your own shop or have a small connected team working on a project, then communicating what is meant by “HTML” becomes easier. I wonder however how an organization such as the United Nations (to pick a semi-random example) can maintain that same kind of cohesiveness across 24 time zones and a multitude of languages? Those logistics become significantly more problematic than 5 guys in a startup in a rented loft somewhere. I’m not saying that they can’t or shouldn’t be pursuing all the advances that the browsers offer, but there is also a need for a stable specification that is frozen, so that everyone has the same target to shoot for: not every web developer can be a sharp-shooter, but they all need to be able to fire their guns at a common target. We’ll all have more success if that target isn’t always moving…
Well said.
Consider trying to verify *anything* you produced industrially by applying formal testing procedures and modern testing practices without having the possibility to specify a formal “line in the sand” to use as baseline for constructing your test scripts/test cases… :(
@Chris “Jesdisciple” >> There are no modules in HTML5+, the spec is “monolitic” (i.e. it s a giant, all-inclusive document). The modular approach used in XHTML1.1/MP/Basic (and the ill fated XHTML2) was abandoned when” the markup language that was to be HTML5″ was first conceived several year ago.
I see nothing wrong in an unversioned spec for browser manufacturers. They will implement want they want to anyway, and the spec is just a description of what they have and where they are going. The practical situation for web authors is that where we are reliant on browser support we just have to work with what is supported now and caniuse.com is more useful than the spec is.
But not all of HTML is reliant on browser support. There’s conformance, and many things work interoperably that aren’t conformant, and there are many other aspects of conformant semantic mark-up that don’t require any specific browser support.
The problem is that the living spec is not only subject to constant mutation, but that it is edited on a process of Commit-then-Review. That means that conformance can change completely unexpectedly and even for short periods of time before reverting back. In practice, it means that the validity of an HTML document is effectively whatever Hixie happens to say it is at any given point in time. In effect, it will make HTML validity valueless.
Maybe that’s a good thing. Conformance criteria exist for a bag of different reasons and we don’t generally distinguish between them. Perhaps a replacement for simple validity could distinguish between those requirements that exist for browser implementation reasons (e.g. nested forms) and those that are bad semantics/layering violations (e.g. using the font element). The latter could then be maintained by web authoring groups away from the W3C or WHATWG in the interests of web authors rather than browser manufacturers, versioned or profiled if necessary. But we will need to decide if that’s what we want.
I will add another note. What stakeholders are there in this besides browser vendors and developers?
Publishers and certification bodies. They thrive on buzzwords and versions. “Teach yourself PHP 6” (as if there was one…) But they also do some more serious stuff, like certifications. Should a well known entity develop an HTML certification program, versions are needed. There is no better way to have a reasonable insurance that the contents of a book or a certification program is up to date and relevant. And yes, that glimpse must be available already in the title.
Educators, schools, universities. I have the last year written several curricula on behalf of the National Agency of Education in Sweden. They are supposed to be used in every school throughout the country. I was careful never to specify versions, since the documents are expected to have a 10+ years lifespan. HOWEVER: When I communicate the need for educators to upgrade their IMPLEMENTATIONS, versioning is a great communication tool. It really, really helps. Since I am about to meet several teachers this spring to talk about how to actually teach according to the curricula, I’ve bought myself 2 HTML5 t-shirts….
WHAT WG is a browser vendor interest group. To them versioning does not make much sense, since they have dozens of people who participate in the spec development process and they know all the nitty gritty details. Then we have a group of a few hundred clued in web developers who make the effort to track the process as well.
Outside of those 2 groups, versioning makes a ton of sense, though. Problem is, since outside of those 2 groups people do not submit feedback to neither the HTML5 WG at W3C or WHAT WG, that voice might not be heard.
@Jarvklo: I didn’t mean versioned modules; let me rephrase my understanding. Do we at least have a stable but still living copy of the spec at the W3C, consisting of all stable parts, even if none have versions per se? Hixie can have his own unstable WHATWG copy to play with for all I care; just give me my stable reference.
I do see the how versions could be valuable to outsiders per your previous comment. Perhaps if they’re that important we’ll just use dates: “HTML as of January 2011.”
Don’t forget: the W3C will still have versioned specifications under the W3C Royalty Free Patent Policy.
@Bruce – What use will that versioned spec be to web authors if Anne VK gets his way on ISSUE-140?
http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-140
@Chris “Jesdisciple” My point is – we had a modular and versioned system that could have been improved, but now we have none. Instead we have two competing monolithic versions – both claiming to be “HTML”
HTML versions based on dates will IMHO not suffice, since the W3C and the WHATWG spec versions already have started to differ, wich introduces another dimension to the mix – ie. the source of the document (since the owners of both versions seemingly considers their version to be the “master” version).
…And a situation where we would be forced to start taking into consideration (and be prepared to defend) eg. the pros and cons between “WHATWG HTML July 4th 2012 at 10 EST” versus “W3C HTML June 3rd 2012 at 2AM GMT” when we negotiate contracts with clients that insists on us producing code that is verifiable web standard compliant (including test cases and documented test results) seems plain silly to me.
@ Jarvkio
you wrote:
“Instead we have two competing monolithic versions – both claiming to be “HTML”
not really correct:
the W3C HTML5 specification is only a subset of what the WHATWG calls HTML
The W3C HTML5 specification does not include Microdata, webvtt, canvas 2d, etc these are either split out into seperate specifications or not (in the case of webvtt specced in the W3C space yet).
@bruce “Don’t forget: the W3C will still have versioned specifications under the W3C Royalty Free Patent Policy.”
But what makes you think that the W3C is going to continue to be a part of this grand scheme?
For all of this to work, the assumption has to be made that the WhatWG will continue to control the editing and creation of specs even vaguely associated with HTML and web applications, and the W3C will just go along for the ride, attaching a label and a patent policy now and again.
You can’t assume, though, that the W3C will go along with this scheme. I wouldn’t, if I were a responsible standards organization. To do so is to assign ownership of HTML to a handful of companies, none of which is really willing to do the work or enact the discipline necessary to ensure every impacted community has an equal say in the development of HTML.
The WhatWG wants to have all of the control but none of the responsibility that goes with the control.
When the W3C started the HTML5 group, the first thing it did was to try and develop teams to review specific sections of the HTML 4 document, in order to better understand what needs to change, and what can remain. However, several people in the working group at that tmie demanded that the W3C take on the WhatWG’s effort and appoint the WhatWG editor as editor. There wasn’t much that the W3C could do at that point but go along.
This wasn’t the best approach, though. All of the new elements should have been vetted, their use, scrutinized. Elements like hgroup. Instead, it’s almost impossible to get a significant modification into the spec that doesn’t agree with the gang-o-whatwg–including the removal of hgroup, The only way this will happen is if one of the gang-o-whatwg agrees. For all the talk of decision policy, this is the only relevant one.
We want this to continue in the future? Seriously?
So the living standard/snapshot thing has a significant requirement that no one has guaranteed will be in place. And it makes an assumption of ownership that isn’t necessarily in the best interests of the web.
@Steve Faulkner – huh ?
If I understand your reasoning, you’re saying that the spec of W3C HTML 5 doesn’t differ *at all* from the parts of the spec of – as you put it – “What WHATWG calls HTML” they have in common (ie that it is somehow guaranteed that it always will be a true subset)???
IMHO this “double standard situation” (pun intended) that seems to be created by the WHATWG and their constant battle for ownership of “HTML” that @Shelley outlines (a battle that is far to easilly spotted even from a spectator seat far away up in the rafters if you eg. follow the mailing lists for a while) is not optimal for the evolvment of a healthy living HTML (in singular) language.
Again @Steve – this is my *very* humble opinion!
… but unfortunately browsing the specs and comparing the common (and not to mention the introductory) sections between them every now and then seems to point to another conclusion than the one that you draw about the correctness of my observation of “the two battling monoliths”…
@ Jarvkio
” that it is somehow guaranteed that it always will be a true subset”
I thought there was a guarantee, but apparently there is not the only guarantee is that it will stay the same as long as the whatwg does not disagree with changes that result from the W3C HTML WG process…
btw I am not defending the current situation I think it stinks.
@Steve Faulkner – Sorry if I came across as somewhat harsh towards you (my frustration is with the situation – nothing else).
… and if anyone can point us participants in this discussion in the direction of a guarantee that any W3C changes applied to HTML5 in order to get it out the door will be mirrored verbatim by the WHATWG in “Web applications 1.0” (as the name of “what the WHATWG calls HTML” seems to be this week) even if the WHATWG spec editors should disagree with them would be great (if one such guarantee exists).
@jarvkio
no problem. in regards to guarantees, there are none, from the WHATWG FAQ:
Which group has authority in the event of a dispute?
Alright, I’m glad I apparently do have the right idea in general. To be honest I don’t consider the WHATWG copy a specification, but rather a “living draft” snapshots of which the W3C vets to produce the Recommendation. As such, I expect each W3C version to be separated from the previous by several months. If they’ll just keep the older versions published, we can call this one HTML 11.01 (using the Ubuntu versioning scheme).
I am less concerned about what happens with new sites as they are built. Developers will always find a way to work around quirks.
What I am EXTREMELY concerned about is what happens to the sites that I have already built. Will my clients call me and ask why their sites no longer works because Chrome just updated to Hixie’s latest view of HTML? Without having stability in a spec, how can I reasonably tell clients to use HTML.
@Gary: I think those are two sides of the same coin. Why develop a new site if it will break once it’s old?
But as far as browsers breaking sites, you’ll probably be protected by IE’s super-slow release cycle. ;-)
@Gary and Chris
“breaking the web” is not even possible anymore unless your site was coded your site to the IE HTML4 and not the W3C HTML4.
Now that IE supports W3C HTML4 since IE7 and we all have dropped support for IE6 anything we code that validates W3C HTML will not be broken by HTML5 (user experience may differ on assistive devices but not on screen, and certainly will not break even here) .
Hell IE7 doesn’t even understand HTML5 tags or the new CSS3 properties and the site doesn’t break as in give 404 error it degrades gracefully.
To up the ante even more how many people here use CSS 2.1 properties even though those are not supported and you have to use conditional statements in IE?
I say we validate to what W3C publishes and use what WHATWG publishes to enhance the experience for fully updated browsers.
@Michael and Chris
How can you be sure that WHATWG doesn’t introduce changes that break prior functionality? If it’s only incremental functionality, then there isn’t a problem.
I understand that you can validate to W3C, but it seems like using WHATWG just opens you up unpredictable behavior.
@Gary: That’s part of the reason for my “living draft” comment above. But mostly I just want a standard that *is* a standard – that is, that browsers are actually expected to have implemented by now. I won’t stop referring to the browsers’ respective documentations and testing in each one either way, but I like having something I can consider absolutely correct.
well the Standard is HTMl 4.01 and CSS 1. No one will stop you from coding to that and browsers that implement HTML5 will display it as intended.
Now when a client says “so and so’s” website has a nice video that doesn’t use flash or they ask for you to use a design without tables for accessibility requirements. Do you say you cant do that because those technologies are not “production ready”?
Where do we as developers draw the line between what works cross the board (even IE) and what the published W3C standard says we can safely rely on. CSS2.1 is still a working draft subject to changes!
@MIchael: CSS 2.1 is not, in practice, subject to change. As I recall it /was/ a Recommendation but got pulled back because the W3C changed thier procedures a bit. It’s been stable forever and CSS3 is under production, so no problem.
More fundamentally, compatibility is the purpose of standards; they shouldn’t prevent us from using compatibility that didn’t happen to be accomplished by them (although some very wrong things are compatible).
I absolutely agree with Bruce on this, and when I read the article I found most of John Foliot’s points at least off-topic. Drupal? hgroup? What’s that got to do with this? I ended up seeing many more good points in some comments (even though I haven’t changed my mind about the topic).
But today I watched (read, actually) an interview with John Foliot, in the People of HTML5 series, where he pretty much talks about the same things (but in a wider contest). And I seem to find a lot of what he says there extremely reasonable!
Weird, huh?
(Hope it’s okay to link that video!)
@Francesco
I often try to use examples to illustrate points, and sometimes those examples don’t always hit the mark 100%. Sorry if it seemed off-topic.
I used the example of as it is currently in the “living” Draft Specification (I think my friend Bruce even wrote about it in his book), and yet there is a very real possibility that it might get jettisoned from the specification before the next quarter. If you were managing a large multi-team project that was working to a January 2012 deliverable deadline, would you use hgroup today? And if it were obsoleted this July, what would be the impact on your project? These are the types of questions that large-scale projects must contend with – large scale projects such as Drupal.
For endeavors like that, having a stable specification makes production and milestone deliverables that much easier to achieve: your don’t have to keep checking the specification to see what was added last week. It’s a kind of stability and permanence that larger organizations need to be functional.
I don’t want progress to freeze, far from it. But having stable benchmarks that are intractable allows for everyone to build on progress with the assurance that things will work for them too.
@John, thanks for your reply.
I understand better what you mean, now. At first I admit it seemed to me you were saying “Versioning is good because you shouldn’t use HTML5 at all… look, here’s a tag that will probably be removed and here’s an important site that’s still using XHTML!”
And I agree I wouldn’t use hgroup today. But I use (for example) article, section, header and footer. And even in the extremely remote chance one of this will be removed… it’ll continue working anyway, so the actual impact on the project wouldn’t be huge. The code wouldn’t validate, it wouldn’t even make sense, but for the users nothing would change. I’m not advocating the use of hgroup now, of course, and I agree that you have to keep checking the specification every now and then… but why not? And it’s what we’ve already been doing with versioning, anyway. In theory, maybe, we wouldn’t have needed to, but in the real world, we did.
I also think that while I agree it can be a good idea for a big project like Drupal not to start using every single HTML5 element out there now, sticking to an XHTML doctype really strikes me as weird. They could have used the 100% safe parts of HTML5 today. (I admit I don’t know much about Drupal, but if it works like WordPress, I guess that users will be able to use/edit HTML5 themes/templates if they want to).
I do think web standards being a living thing is a good thing. It would be awful if we couldn’t adopt any new technology just because the spec it is in hasn’t been finalized.
On the other hand, numbered releases are necessary I think to push browsers to adopt all of the features. If the HTML5 spec remained the way it is now, it would be crazy to make sure browsers were up to date on all the features.
I suspect that part of the adoption of HTML5 right now is because it is expected to be finalized eventually. Numbers don’t mean anything, but getting adoption outside of the geekstream and into the mainstream does. People don’t want to deal with the latest live spec that could change on them tomorrow, they want to buy a book or take a course on things they can implement reliably and expect modern browsers to support. Considering the mainstream is something I fear could be overlooked.
I don’t think this is a relevant example, given it requires JavaScript to style in all released versions of Internet Explorer — the answer would be in almost every case “of course not”.
Given HTML5 is still a working draft, both W3C’s HTML5 and WHATWG’s HTML are equally irrelevant in this example.
And just to clear some things up:
I still don’t see how what WHATWG are doing is significantly different to the way previous specs were made, with the exception that it’s not behind closed doors. I still don’t see how this is anything but a good thing for authors. I also still don’t see why a name change on the same process WHATWG has been using since formation is news at all.
@Oli, I’m a bit confused when you say “of course not” about hgroup.
Since the reason you give is JavaScript being required by Internet Explorer, are you saying that “of course” we should not use any of the new HTML5 semantic elements, ever? I mean, I know hgroup might go, so it’s better not to use it…. but the others?
Of course I absolutely agree that JavaScript must not be necessary to see the content, but as long as users with IE and JavaScript disabled get to the content (and the layout doesn’t break) I can’t see the problem. (Also… who are these users? Do they really exist? I know lots of people that don’t use JavaScript, but not one using IE. If it’s true that, according to Yahoo, 1% of the users don’t have JavaScript… how many of them are using IE? I’d really like to know…)
Anyway styling is not the only reason to use an element, of course… hgroup does (did) seem like the kind of element where styling isn’t really the point, its goal is (was) to get a better outline. What I mean is that where I did use hgroup I never happened to actually style it at all. (I could, of course, but never found it necessary). In that case, nothing could possibly break. Or could it?
@Francesco — As you mention using <hgroup> would have zero impact if not directly styled, which is definitely the norm in using it. However the kinds of companies/web sites I suspect John is referring to tend to make blanket policy — as he suggests, this is easiest on a complex project. There’s nothing to stop you using it, but (given how things normally work) it’s unlikely the kind of multinational teams John is discussing would until the HTML5 spec is a recommendation.
In the YDN article you refer to with the “1-2% have JS off” figure, these are mostly A-grade and X-grade browsers. That doesn’t necessarily mean much tho as IE6 on XP is still A-grade :|
Sack ’em all and let’s have a WSO that can churn out a standards spec every two years instead of waiting eight years plus for them to finish naval gazing.
Two years is almost no time for browsers to implement a new standard… Especially if they have a slow (i.e., corporate) release cycle. We would have browsers all over the spectrum of how much of the current spec is implemented, and I don’t doubt they’d just skip some of them.
Pedantry: Although I suppose they are equally useless pastimes, the typical accusation is of gazing at belly-buttons (navels), not oceans (naval expanses).
Join the discussion.