W3C Considering An HTML 5

An anonymous reader writes "When the decision was initially made to move in the direction of XHTML, instead of a new version of HTML proper, it seemed like a good idea. Years later and the widespread adoption of CSS (among other things) has proven that things don't always develop the way we expect. As a result, HTML 5 has been revived by the W3C. After some lobbying and continued work by the Web Hypertext Application Technology Working Group, the old web markup language is getting an official face-lift. A post to the Webforefront blog explains the history behind the initial decision to move to XHTML, and why things are so different in the here and now."

Absolutely right

Because what the world really needs right now is another version of a web standard which has had hardly any full, correct implementations in any version that's ever existed.

Or are the W3C just trying to justify their existence?

Re:Absolutely right

Because this time people will code to it, dammit.

Re:Absolutely right

Because this time people will code to it, dammit.

You got coffee on my monitor.

Re:Absolutely right

HTML 5.0 = HTML 4 with some new sugar + XHTML parser strictness.

That is incorrect: the HTML5 parsing algorithm [whatwg.org] never just stops and returns an error message (like in XML) - it specifies how every single stream of bytes is parsed into a DOM, with error-correction where necessary, in a way that tries hard to be compatible with the ~10^11 existing HTML pages on the web (which, in most cases, means being compatible with the behaviour of IE6).

Almost all the content on the web today is invalid HTML, and it's never going to go away, which is why the browser developers have been pushing for a specification that describes how to handle invalid content instead of pretending it's not important.

Re:Absolutely right

You jest, but it is actually that simple. HTML 5.0 = HTML 4 with some new sugar + XHTML parser strictness.

The result is that browsers will show you the finger if you don't code to the standard.

I'm a participant in the HTML Working Group [w3.org] and I can tell you that this is incorrect. You're thinking of XHTML2, not HTML 5. XHTML2 has the XML parser strictness and pages will fail to display if they're not well-formed. HTML 5 is going the complete opposite direction, assuming that people will code poorly and defining failure modes for browser vendors to follow when that happens.

Re:Absolutely right

I'm very troubled by the implication that HTML5 will focus on the assumption that people will code poorly and the proper solution is to provide better failure modes for browsers. This is more likely to have the effect of lowering the standard than improving it as humans will simply take the easy road.

I would plead for a higher standard that would require strict compliance to well-formed rules that would lead to better overall web governance, security, and standards that benefit the authors and readers. I'm really fed up with not being able to use my favorite browser for everything because the code is broken on one browser brand or version, or because one browser vendor simply wants to make their own rules.

Let's do this generation of standards right. Make the coders comply with strict, well-formed rules or make them pay the price.

Re:Absolutely right

Wow. I hate you.

The working group is open to the public [hixie.ch] and costs nothing to join. If you don't like the state of HTML, come over and help make it better.

Re:Absolutely right

Imagine if C++ compilers could take the same liberties that web browsers could with the input!

Imagine if web browsers were anal retentive and refused to display anything with the slightest syntax error. Imagine if your blog suddenly became undisplayable because commenter number 32 input some broken HTML, and your not-quite-perfect blog software didn't quite know how to launder it. Imagine that the slightest syntax error from Google Analytics, Google AdWords, or anything else you embed into your site could make your site completely unavailable.

I know it's not satisfying, but being permissive on the web really is the best policy, as long as the results of the permissiveness are well-defined (which is what HTML5 does).

Re:Absolutely right

Yes there is, the browsers would be checking to ensure it's valid. If no browser accepts it, the developer will have to fix it or get fired.

Re:Absolutely right

If no browser accepts it, the developer will have to fix it or get fired.

More likely, the developer will stop using technology that makes their life harder, and will stick with invalid HTML4 and Flash and Silverlight and all the other possibilities, which defeats the aim of improving interoperability on the web.

Also, browsers have bugs. What happens when a user tests in one browser which accidentally accepts their invalid code, without noticing that other browsers don't? (Possible answer: other browsers will have to start accepting that invalid code too, else their users will stop using that browser and start using the one that can actually display the web. And since the specification would only say how to handle valid code, the other browsers will have to reverse-engineer each other to get mostly-compatible behaviour for invalid code, which results in a mess of incompatibilities - that is what has happened for HTML4, and is what HTML5 is trying to fix by defining how all invalid content must be handled in a way that is sufficiently compatible with the existing behaviour (and existing bugs) of browsers.)

Also, most content is generated dynamically, so you can't simply test the page before you upload it. Server-side code has bugs, and draconian error handling does not make things easy to fix [diveintomark.org].

Re:Absolutely right

Did you read the proposal, or anything around WHAT-WG's HTML5?

It's actually incredibly sensible, and is a very practical and natural extension of what we're doing with HTML now.

It has very little to do with browser bugs, or even web sites per-se. It's more about adding features to more naturally support web 'apps'.

Read up on it, it actually makes a lot of sense.

I just hope it can make some progress, but given that it was started by Mozilla, Apple and Opera, the people making the best browsers out there, it may actually have a chance of being supported.

Re:Absolutely right

Actually HTML5 is largely a result of work by the main browser makers, except Microsoft I believe. Hixie from Opera is the project lead of the WhatWG which was created to extend HTML to make it more applicable for web applications. It fixes a lot of the problems with both HTML 4 and XHTML, and its backwards compatible with *both*.

Re:Absolutely right

Actually HTML5 is largely a result of work by the main browser makers, except Microsoft I believe. Hixie from Opera is the project lead of the WhatWG which was created to extend HTML to make it more applicable for web applications. It fixes a lot of the problems with both HTML 4 and XHTML, and its backwards compatible with *both*.

Excuse me, but it must be pointed out.

When you start talking standards and you gather a group of browser/client makers to discuss new standards, you really do need to have the giant on the block represented. Otherwise, you get a set of standards that run the real possibility of being ignored, or worse, supplanted by the giant's idea.

When the combined numbers of the "others" don't even come close to trumping the giant's numbers, you are heading to failure. In this case MS, like it or not, is the giant. The easiest way to stop this crazy, "IE only partially implements html x.0/css x.1/xhtml x.x" crap is to involve them.

Of course, this is just crazy talk, right. Oh heavens, we might actually run into the problem of MS taking over the standard. You know what, when you have a formation marching down the street, and 70% are on one heel beat, and the other 30% are out of step with the 70% and aren't even in step with themselves, its the 30% that need to get with the beat.

Failure to accept this is only going to widen the gulf, unless MS, through largesse or coincidence follows the new standard.

Re:Absolutely right

Chris Wilson is a guy with his heart in the right place working for people who, in the past, put business strategy over standards support (I'm not editorializing, that's what they did). This is why MS's standard support is lame.

That being said, Chris Wilson (at least) talks the talk, and IE 7 was a (small) step in the right direction.

The more important, and encouraging, signal imo is MS hiring Standardista Molly Holzschlag. Given her history, I think we can expect more and better from MS on this front in the future.

Re:Absolutely right

Who modded this informative? Suv4x4 is incorrect. The W3C came up with their HTML5 standard by taking a dump of the WHATWG HTML5 standard and putting the W3C colors on it. Which isn't surprising as most of the WHATWG members are also W3C members. It was always their intention to make their standard more "legitimate" by submitting it to the W3C once it was ready.

Don't believe me? Here are the two standards. Compare:

WHATWG HTML5 [whatwg.org]
W3C HTML5 [w3.org]

Save for some slight divergences as the WHATWG's standard is updated, they're exactly the same.

Re:Absolutely right

WHATWG are the group that pitched W3C to consider HTML5. W3C's HTML5 isn't based on anything right now since it doesn't exist yet.

From the WHATWG list:

The W3C's HTML working group today resolved to start from the current WHATWG work. Specifically, the group resolved to review our work, and will probably build on it. They also resolved to call this work HTML5. Thus, the "Web Applications 1.0" spec is now officially named "HTML5"! I have also checked a copy of the two main WHATWG specs (but with the W3C boilerplate) into the W3C CVS server. Going forward, any changes will be committed to both the WHATWG and the W3C repositories simultaneously.

It may include in some form some HTML5 features, but don't delude yourself that W3C will beat the heck out of it, until it's a tortured mix of their XHTML2 standard and WHATWG's HTML5.

Well seeing as it's starting from their work I rather suspect it will include the bulk of it, because it's highly interdependent.

Then again you seem to have an axe to grind with the W3c, so don't let me stop you..

Re:Absolutely right

Or are the W3C just trying to justify their existence?

That's a bit cynical, don't you think?

HTML5 is the result of the hard work done by the Web Hypertext Application Technology Working Group [whatwg.org] (WHATWG). The WHATWG is composed of members from all browser makers, with the occasional public comment thrown in for good measure. As a result, the group has been removing or reducing the ambiguity about implementing the various standards (especially the parser!) and have added features that bring HTML up to a true application platform. Their work is represented in web browsers every time someone uses the Canvas tag, Audio object, Storage API, and other modern features.

The WHATWG was formed because the W3C was seen as too slow to execute such new technologies. Now that the WHATWG specs are stablizing, the W3C has taken a dump of the WHATWG HTML 5 standard and proposed it for ratification under W3C bylaws. This has several advantages over the WHATWG standardization, not the least of which is extracting patent waivers from companies like Apple who technically "own" some of the technologies behind the WHATWG standards.

Note that the HTML5 group at the W3C is a bit different from most. In an attempt to remain as open as the WHATWG, they are accepting just about anyone as an "invited expert" to provide input and comments on the standards process. This is a huge departure from the way that most W3C standards are handled, and is probably a good choice for a standard as comprehensive and complex as HTML5.

Re:Absolutely right

The canvas tag (originally from Mozilla, I believe, but now in WebKit and Opera)

Actually, it was originally from Apple Safari. Apple invented it for their desktop widget thingys. Opera and Mozilla have both embraced it with open arms. :)

my favourite is client-side storage.

I agree. I absolutely love this feature! Unfortunately, it's only implemented by Firefox at the moment. I was hoping that it would show up in Safari 3.0 so that richer iPhone applications could be written, but it was not to be. The feature request [webkit.org] is still sitting out there with no assigned implementer. I'm tempted to dive into Webkit and maybe see if I can add it.

Regress is the New Standard for Progress

TFA makes several great points about how this seeming sentiment of "we'll stick with the HTML we know and love" is more an unwillingness to change than it is to update a standard. The whole idea of XHTML was to provide a segueway into an altogether new way of distributing content. This really seems a regression more than anything. What does XHTML fail to deliver that would cause WC3 to shy away from the previously hardline (and appropriate, IMHO) stance of "this is the new HTML, get used to it"?

Don't you need power to be hardline?

What does XHTML fail to deliver that would cause WC3 to shy away from the previously hardline (and appropriate, IMHO) stance of "this is the new HTML, get used to it"?

First, having reviewed some of the things in the draft HTML5 standard Opera and Apple have been working on, I have to say that it is indeed worth standardizing.

Second, I wonder about this "hardline" approach. Who made the W3C gods of the internet? I mean, things need to be standardized, but they refused to do their job and standardize, and guess what, the industry got together and made another standardization board which was mentioned in the OP. The W3C can't hardline anything... they just format the direction we're going... they don't choose it, the industry does that.

Go ahead, think I'm wrong, think the W3C should just stick it to all those web developers and browser companies that have spent years working around the group that is supposed to make their lives easier. The W3C is a paper tiger... they are completely at the mercy of everyone else. They can't hardline anything, much less something which was being standardized without them anyway.

hmm.

are they going to enforce all the current browsers to support it fully and correctly as well?

or will some browsers go their own way with "extensions" and "implementations" specific to their own system like last time.

date tag?

I have suggested this before and always got shouted down for it... but as a web developer, I really wish they had simply implemented tags like 'date', which the browser would automatically know about as a date field and have its own built-in popup calendar for browsing dates, rather than having to either rely on plain text, lame dropdown menus, or else implementing yet another date popup javascript library (or including yet another javascript library which slows down the user experience even more).

There are so many things that could be included in the html language if it weren't for the purists - dates, columns, real collapsable tree controls, counters, AJAXified controls that work without all the crap you have to do today to detect browsers... but no, the purists say "you can do it in this (incredible convoluted) css" or "you can implement this in javascript" (cue long convoluted "obvious" solution).

Geeks are notorious for generalising and making everything nice and orthogonal, but they often forget that sometimes it's worth having something that makes life easier 90% of the time, even if it's technically possible to reduce it to a set of other constructs that already exist.

Remember lisp, nobody uses it for real-world programming even though it's incredibly powerful. No, we use other languages that have lots of useless and redundant and inflexible syntax that makes the act of everyday programming easier and more straightforward most of the time. Are these inferior languages as powerful, expressive and all-encompassing as lisp? No. Are they easier for 99% of mere mortals to comprehend and use? Yes. If we had tags for controls that reflected the more dynamic nature of the Web today, even if many of those tags could be implemented in javascript, it would make pages smaller and faster 90% of the time (you could still implement it yourself if you really needed additional functionality).

But, as usual, the purists are in control. We're not supposed to use tables for arranging pages; no, we have to use CSS to do that. So now we have a bunch of pages that don't render properly. But do they admit that it was a bad idea? No, it's the browsers' faults for crappy implementations. I don't get it, this religious mindset that says "You must do it one way, our way is the only way". "The TABLE tag is for tabular data only, don't use it for arranging the page". What crap. The table tag is amazingly useful, it works in all browsers, and no I don't mind in the least typing TR and TD everywhere. It's simple and it works. Yes, it's more verbose perhaps than the CSS version but at least it works in all browsers and doesn't end up with overlapping crappy text all over the place.

The Author is Not Completely Wrong

There was an interesting discussion about this in the xml-dev mailing list [xml.org]. Rick Jelliffe had this to say:

XML was developed as a subset of SGML. Most of the ISO working group which looked after SGML were also involved with the creation of XML (Clark, Kimber, Bosak, also Goldfarb, Peterson, me, and others). The correction for SGML came out before XML was finally put as a recommendation (AFAIR) so there never was a time when XML was not a true subset of SGML. Where there were differences, ISO8879 was corrected specifically to make sure that XML was indeed a subset. In fact, Charles Goldfarb even said at one stage "XML *is* the revision of SGML" (debate on the revision of ISO 8879 had started years before: XML was the embodyment of that).

XML can be argued as both the revision to and a subset of SGML. Hence my disappointment in anything new that seems to shy away from this path, like HTML 5 instead of XHTML.

Re:The Author is Not Completely Wrong

HTML 5 is also 'XHTML 5'. You can use well-formed XHTML style syntax, and deliver it with an application/xml or application/xhtml+xml mimetype, *or* you can format it HTML style and deliver it with a standard HTML mimetype.

http://blog.whatwg.org/html-vs-xhtml [whatwg.org]

Re:Cry for relevency

After years and years, a critical mass of people are finally learning a, b, u, i, big, super, img, and other standard tags, most of which just don't work the same or at all under XHTML.

Um, what? Seriously, the b, u, i and big tags are _exactly the same_ in XHTML. There was never a super element in HTML 4, it's just sup, and it's unchanged. The a tag does everything from HTML 4 the same way in XHTML. The only difference in it is that it's allowed extra attributes.

Out of all of those things, the only one that's changed at all is the img tag, and that's only in two places - first, in XHTML you are required to provide an alt= attribute (instead of just strongly recommended like in HTML 4), and second, you have to close the tag properly, with a /> at the end.

Frames are also still part of the XHTML spec.

The font tag however, is gone and won't be missed any more than the blink tag was, by anyone other than frontpage (which absolutely loves adding thirty or so font tags in a row setting and unsetting the color 'white' from the text.