W3C Publishes First Public Working Draft of HTML 5

Lachlan Hunt writes "Today W3C announced that the HTML Working Group has published the first public working draft of HTML 5 — A vocabulary and associated APIs for HTML and XHTML. It's been over 9 months since the working group began in March 2007 and this long awaited milestone has finally been achieved. '"HTML is of course a very important standard," said Tim Berners-Lee, author of the first version of HTML and W3C Director. "I am glad to see that the community of developers, including browser vendors, is working together to create the best possible path for the Web..." Some of the most interesting new features for authors are APIs for drawing two-dimensional graphics, embedding and controlling audio and video content, maintaining persistent client-side data storage, and for enabling users to edit documents and parts of documents interactively.' An updated draft of HTML 5 differences from HTML 4 has also been published to help guide you through the changes."

Number 5 ALIVE, Stephanie!

Looks like this is what Mozilla, Apple, Microsoft, etc will need to begin supporting 5 in the future.
How long that takes, noone really knows. More importantly, how easy will this be to use and how useful will the semantic bindings be?

Finally, anyone know

Someone hire this guy!

Looks like this is what Mozilla, Apple, Microsoft, etc will need to begin supporting 5 in the future.

I think they should hire you for your keen insight.

How long that takes, noone really knows.

Another stunning peek into the future.

More importantly, how easy will this be to use and how useful will the semantic bindings be?

It'll be as easy to use as a snowboard and as useful as a hammer.

Finally, anyone know if HTML5 mandates any specific version of EMCA/Java-Script? That part seemed vague to me.

A three second scan of the linked article yields:

"Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings for DOM Specifications specification, as this specification uses that specification's terminology. [EBFD]"

Their language indicates that ECMAScript isn't a requirement. Essentially, "if you use it, you must implement it in a certain way". They don't mention requirements for implementations that don't use ECMAScript.
 

Re:

How long that takes, noone really knows.

About a month less than it will take for them to roll out HTML 6, at a guess...

Re:

Looks like this is what Mozilla, Apple, Microsoft, etc will need to begin supporting 5 in the future.
How long that takes, noone really knows. More importantly, how easy will this be to use and how useful will the semantic bindings be?

Finally, anyone know if HTML5 mandates any specific version of EMCA/Java-Script? That part seemed vague to me.

No, a user agent need not support scripting at all. If it does support an ECMAScript-based scripting language then it would likely be using the third edition or later, as the specification includes an exception system, and try catch blocks were not introd

The treadmill....

I have this theory...some of you might too....

Large for-profit software giants must constantly make product to stay in business, pay programmers, and make profit...even if there's nothing REALLY to fix. Just make upgrades...sell new versions.

Consumers and businesses are constantly put on an upgrade-treadmill as older products are purposely torpedoed...even when they worked fine and did the job they needed to do.

now replace "for-profit software giants" with "design-by-committee standards organization" and "stay in business, pay programmers, and make profit" with "stay in charge and not have to get real jobs".

Re:The treadmill....

It's not a treadmill if you actually cover ground.

Re:

But what if W3C is an airplane and you put it on the treadmill -- does it stay still or take off?

Re:The treadmill....

HTML5 is the furthest thing from committee-driven development in the W3C. Basically, I'm a dictator and every piece of feedback goes through me. (This is a point of contention with a lot of people who disagree with my approach, which has basically been to focus on use cases, pragmatic arguments, and research, and to eschew "expert opinions" as the sole guide to what the spec should say.)

Also, spec writers aren't in charge of anything. This is actually a common fallacy, which leads to people writing specs without paying attention to their users and implementers -- just look at most specs coming out of the W3C. No, spec writers are in fact at the very bottom of the food chain. We can only specify things which the implementers want to implement, otherwise they'll ignore us, and we are only able to control what users do in so far as we tell them to do things that they want to do, otherwise they'll ignore us too. Just look at browser vendors ignoring specs they disagree with. Just look at how many pages have some sort of syntax error (over 93% according to a study of several billion documents I did last year).

With HTML5 we're specifically trying to avoid torpedoing what implementers and users are doing today. A huge part of the effort is to make the spec relevant, specify what users are doing, specify things that other specs left vague, add features where users are working around holes in the spec, etc.

As to whether my job is a "real job" or not... I can't speak to that. It's a lot of work, at least. :-)

First thoughts

Still no client side include (no, object doesn't cut it...).
People are talking about browser support, it seems to be written in such a way as they should already be able to support it if they support either HTML 4 or XHTML.
It removes lots of sylistic tags, CSS way to go.

New section tag is good.

Overall, looks interesting, cleaning up HTML a bit more, forcing it to be more of a structure rather then presentation language.

Anyway, I'll start using it, when and if, it becomes useful for my work. Otherwise, XHTML and HTML 4 are it.

Re:

I can see advantages for most things they're proposing ... except for dropping the target attribute in anchor tags. I don't get that one. That's really useful for making external links open in new windows/tabs. Unless there's an alternative I've missed I t

Re:

I would imagine they would simply advocate JavaScript for this sort of thing (not that I agree, necessarily). I could also see CSS to some degree controlling this; it's not necessarily presentational, but I could see different stylesheets making use of dif

Re:

it's because the end-user is supposed to decide whether or not to open a link in a new window/tab, not the site.

Read the diff

And I must say, I like where this is going so far. It feels like a very natural progression from HTML4's ideology, while respecting authors' collective recent interests, such as media embedding, and <canvas>.

Still sloppy

"The DOCTYPE declaration is <!DOCTYPE html> and is case-insensitive in the HTML syntax."

So we have

<!DOCTYPE html><html>

At the start of every HTML document served with an text/html mime type? That's real rational. Let's get this tidied up once and for all and start html documents with

<HTML version='xxxx'>

Is that such a difficult concept?

TWW

Re:

Is that such a difficult concept?

I'll make you a deal: you talk to the W3C and get them to drop this completely and utterly bass-ackward broken idea of creating new non-XML flavors of HTML, and I'll talk to the XML folks about dropping the DOCTYPE requirement.

Re:Still sloppy

Actually originally we wanted to remove the DOCTYPE altogether, and since the <html> start tag is optional that would have made the boilerplate "" (the empty string), or "<html>" if you want to include the <html> start tag. Unfortunately, in non-HTML5 browsers, if there's no DOCTYPE, you'll get quirks mode, which we wanted to avoid. That's why we went with the shortest string we could find that triggered standards mode, namely "<!DOCTYPE HTML>".

I agree that it's not ideal, but I couldn't really see a way around it.

Re:Still sloppy

Versioning is basically meaningless on the Web. Browser vendors (other than Microsoft, at least) have repeatedly said that they don't want to have multiple code paths for features, which means that they want each version of HTML to work the same as each previous version. Same for CSS, same for the DOM APIs.

If every version of HTML is going to be identical from the browser's point of view, why bother including any versioning information in there at all?

As far as validators go: the point of validators is to report errors. When HTML6 comes out, if there are things in HTML6 that are errors that aren't errors in HTML5, that presumably means we found bugs in the HTML5 spec, and so it is more helpful to authors if we report them than if we don't. Therefore validators should always validate against the latest spec (unless manually configured otherwise, of course), and the validators don't need a version number in the format.

Having version numbers in formats makes people do stupid things, like make behaviour depend on the version flag. Not having a version number in the format makes people notice that kind of mistake more (since then explicit flags have to be invented to make the mistake, instead of just using the version number in the format).

Includes?

Good to see they're binning frames.

But - why has there never been an include mechanism in HTML?

Re:

But - why has there never been an include mechanism in HTML?

I don't know the answer, but I suspect two things:

• Not that much demand from developers... this is simple to solve server-side.
• Potential for abuse/mistakes. You'd have to protect browsers against nested includes/circular references which could get tricky

From the differences page

Absent Elements
font, although it is allowed when inserted by a WYSIWYG editor due to limitations in the state of the art in user interface for these editors.

I know this is for ease of use, but seriously: if the people at W3C really want a "standard", doing stuff like this does nothing but make it ok to ignore the standard. So which is it, CSS or font? Pick one!

no default ogg, sadly...

title says it all really. basically they are not going for a default of ogg for audio and video by the looks of it...

Finally

XML's syntax sucks. It's annoyingly verbose, and annoyingly lowercase (lowercase tags suck because they are harder to tell from normal text). I'm glad they're supporting HTML syntax.

On top of that, we get decent application controls such as grids, trees, b

Re:

You want to center a block? Set it's width, and set left and right margins to 'auto'. That's CSS for 'center block relative to enclosing block.' (And yes, that behaviour is in the spec.)

Otherwise, what are you looking to do that you can't?

Re:

XML's syntax sucks. It's annoyingly verbose, and annoyingly lowercase (lowercase tags suck because they are harder to tell from normal text). I'm glad they're supporting HTML syntax.

I'd say that XHTML (which is what we should be talking about) is actually

Re:

With HTML5 we are doing a few things to address the fact that authors write invalid content. One is that we are relaxing a lot of the content model requirements. Another is that we are allowing the "/>" style on elements that have no end tag (like <i

Still no value on select tags?

If anyone involved in the spec reads this, for the love of god PLEASE include a 'value' on the "select" tag.

'as an alternative to flagging an option tag with selected="selected", a select tag may have a 'value' attribute. A renderer should select the first child option with a matching value attribute.'

Please, my servers are getting fed up with rendering an entire country list just to flag one with selected="selected".

HTML5 is the wrong path

To (hopefully) anyone who understands and advocates XHTML and CSS, HTML5 is a tragic mistake. I can't believe TBL is supporting this garbage. It brings back some (but not all: <i> and <b>, but not <u>) presentational tags and gives them worthless definitions. It's full of concessions to lazy/unskilled developers. It makes XML compliance optional. It's full of niche tags which are so narrowly focused (aside, dialog) that they're almost certainly doomed to lousy browser support. It doesn't address the current inadequacies of forms. It has tons of design flaws and inconsistencies.

Until there are consequences for not following the standards, it doesn't matter what the W3C does: People will continue to make pages and sites that are "just good enough", and browsers will continue to render what they want how they want. In the past, now, and for the foreseeable future, there's no incentive for anyone to do things right other than ego.

I don't get it. The people designing this stuff are supposed to be experts in the field, yet they seem hell bent on force feeding everyone this drivel. If their true goal is the hurl the web into chaos, then they will certainly succeed.

Re:

XHTML failed: hardly anyone uses it. According to studies I did at Google, using a sample of several billion pages, about 0.0044% of pages use XHTML with the XML MIME type, and about 15% of people try to use XHTML, by giving the XHTML namespace, but actual

Re:

No version of IE supports XHTML's correct mime type. XHTML "failed" not because people didn't want to use it, or didn't understand it, but because the majority browser didn't support it. So XHTML is served with the mime type IE does understand, and this

Re:

HTML5 has a defined parsing model and is not actually any harder or slower to parse than XML. In fact, I have heard implementors from several browser vendors say that HTML5's parser spec is easier to implement than XML, and that there should be no performa

Re:HTML5 is the wrong path

Indeed.

HTML 5 is probably the worst thing that can happen to the web right now, slowly but surely XHTML compliance was bringing together browsers and sites, you only have to look at the magnificent jump in compatibility of sites from IE6 and Firefox 1 to IE7 and Firefox 2, whilst far from ideal still, developing Standards compliant code for the latest generation of browsers is much less of a headache than it's ever been.

HTML 5 increases ambiguity, it's a language seemingly designed for the MySpace generation - people who just want to hack together quick and dirty sites without any care or thought for scalability and accessibility. The simplification of XHTML over HTML whereby ambiguity is decreased by fixed rules, and less presentation tags was absolutely fantastic for developing sites that work on a variety of user agents as much more is left for the user agent to figure out so that small handheld devices could finally display compliant sites in a way that best fit the screen. Accessibility software such as screen readers have a much easier time as they could largely ignore CSS and stick to reading out the actual content without worry that some random presentation tags with a non-strict syntax was going to bugger up the parsing.

The most important concept with XHTML was separation of presentation from content coupled with a strict syntax and HTML 5 goes against these two extremely important points for ensuring we have a clean, standardised, accessible web. It's also quite a problem that HTML 5 says "Oh you don't have to use this or that, you can do it was you want", a standard needs to make up it's fucking mind not sit on the fence because otherwise it's not much of a standard as you get people doing things in many different ways, some of which are undoubtedly going to break in some user agent or another.

Essentially what's happened with HTML 5 is we've got a language that caters for those incapable of working with a well structured language, on one hand this is great because more people can publish to the web, on the other it's awful as it basically fucks up the web further. Instead of dumbing down the underlying language and breaking the web as a result, we should be producing better tools for working with the existing language keeping the web clean without leaving it difficult to publish to.

Do we really want to prolong the old situation of sites that only work or look differently with some browsers and that are inaccesible to people with special accessibility requirements? Not to mention that aren't scalable as content and presentation get mangled into one and hence really aren't maintainable either?

Re:HTML5 is the wrong path

Essentially what's happened with HTML 5 is we've got a language that caters for those incapable of working with a well structured language, on one hand this is great because more people can publish to the web, on the other it's awful as it basically fucks up the web further.

As far as I understand, HTML 5 specifies exactly how a user agent should deal with formally incorrect code. I have never understood some people's obsession with XHTML, where a compliant browser is supposed to display an error message. With Opera, I encounter "XHTML" pages every now and then that do not display at all because they were dynamically generated from a database and there is a single illegal character in there or a forgotten close tag in a string coming from a database. How is that supposed to help anyone that every scripted page needs to be tested against every possible input condition? It could have been made optional in the user-agent to display a warning for web developers, but no, the spec requires that the browser justs bails out.

And xhtml also sucks for hand-coded pages since it is full of redundant closing tags, for things like <br>, <tr>, <td>, <li, and so on. It's only more typing and more obfuscating syntactic sugar. There are millions of people who create web content, and only a handful browsers. To me it is obvious that it is a waste of manpower to require of millions of people to learn the exact strict xhtml rules rather than make the browsers more flexible with non-conformant input, in a well-defined cross-browser portable manner. HTML 5 will add new useful features. XHTML adds nothing that wasn't already possible in HTML 4.01-strict (the version without font/frameset/bgcolor/etc. stuff).

[with xhtml] small handheld devices could finally display compliant sites in a way that best fit the screen.

I think you are talking about spacer GIFs and table markup. As far as I know, you can still abuse tables for page layout in XHTML. Moreover, to make a page that is really portable between 1024 pixel monitors and devices with a 150 pixel-wide screen requires much more than just xhtml/css; both the CSS and the page structure need to be carefully designed to be portable, in a way that is not enforced by the xhtml spec.

Re:

How is the allowance of tables amongst other things an "extreme length" when it comes to separation of semantics and style?

No more style attribute?!?!?!

No more style attributes on any element.

*blink*

Idiocy. Abso-fucking-lute idiocy.

This by itself nearly renders in-browser dhtml applications (ajax or no) non-complaint and broken.

Somebody really needs to wrench the HTML spec out of the hands of the W3C and place it into the hands of somebody who spends a little time on other side of the ivory towers.

Fix : text, sizing, rendering

Having used <canvas> a bit, I say fix it now!

1. They have still left text out of the <canvas> tag. This is near insanity. The web is littered with people working around this to get labels onto graphs, current solutions are:
   • overlay a transparent div and absolute position some text elements. Works, but no rotating and is fiddly to get the sizing correct.
   • Take a truetype font, render an image of all the glyphs into a grid and know the coordinates of each ones bounding box then paste them in ransom note style to make your text. Most people are used to subpixel rendering and this won't do it. Looks a little bad for small text, ok for large. Big downloads.
   • Be a plotter. Use the Hershey fonts from NIST back in the good old days of pen plotters. (google://hershey&canvas&element). Small, fast, only one font face, antialiasing looks a little blurrier than modern typography at small sizes.

   Hey working group! Use CSS to pick a font. Give a method to get the various metrics of a layed out string and one to draw it. That will cover most uses.

2. Lack of dynamic resizing: The width and height is specified in the HTML. It would be nice for this to be dynamic so you could use a canvas for DIV backgrounds, like the gradients behind the slashdot article titles. (Yes, obviously those gradients take fewer bytes as images, but you could do something other than repeat a tiny graphic. Use your imagination.)
3. Address rendering: The canvas uses coordinate transformations to nicely separate the display coordinates from the drawing coordinates. This is good, but if the browser antialiases then you get radically different results for lines that fall on the pixels and ones that fall in the cracks. There should be language in the spec that leads implementors to all make the same decisions about antialiasing so that authors don't have to try to guess which way a client is going to render.

The standards are just not very good

Every discussion around HTML and related W3C standards always seems to end up in a blamefest. Microsoft is to blame for their poor standards compliance, lazy web developers are to blame for sloppy code, Al Gore is to blame for inventing the Internet.

All of that is true. But I have come to believe that perhaps the blame lies primarily with the standards themselves. They are just not very good.

I know this is not a popular opinion. Let me qualify it and try to explain briefly what I mean. There is of course a lot of theoretical and historical background to consider, but frankly it is a waste of time to drag all that into a Slashdot comment.

The first problem is with HTML. HTML abstracts at the wrong level. It should be a presentation language, not a structural markup language. There is no need for HTML as a structural markup language and frankly I am baffled by the religious zeal with which some people defend this notion. As a structural markup language, HTML is very poor. Structural markup is most useful for well-defined, domain-specific applications. That is not what HTML is used for and this causes numerous problems: ill-defined rendering behavior, poor querying and indexing abilities, poor feature set, relatively slow performance, not to mention poor reusability.

The second problem is with CSS. Although at its core a good idea, it is poorly implemented, with a pointlessly weird, C-inspired syntax. It is too feeble to express presentational structure and lacks a method to express generalized context-dependent relationships. The selector language is so baroque that it is poorly understood by authors and implementors alike. Most importantly, CSS simply does not solve many common layout and styling problems, except at the most trivial level. Efforts to address this have mostly just made CSS more complicated rather than more powerful.

The third problem is with Javascript. The language itself is not bad, but it exists in an environment that is so primitive and crude, that often the easiest way to accomplish anything is still to just stuff precalculated strings into a node's innerHTML. The web is littered with the corpses of Javascript libraries to provide simple services like data binding, templating, input validation and widget sets. None of which build on eachother, because there are no tools to enable this kind of workflow, and most of which fail on either correctness, performance or standards-compliance.

Why are there so many problems with these standards? Is it normal for standards to be so problematic? It is certainly true that numerous standards failed. But on the other hand, many other standards succeeded. PostScript and PDF are very successful standards that have been implemented dozens of times with minimal interoperability issues. The same goes for countless file format standards, such as GIF, PNG, JPG and ZIP, or standards such as ASCII or Unicode.

Of course the comparison between HTML (and all related tech) and, say, GIF, is not valid. In the case of HTML there are many reasons, some socio-economic, which have brought us to the point where we are today. But despite that, I believe it is possible to identify 2 key issues with the W3C family of tech:

1. The wrong abstraction level. The W3C people have been chasing a nebulous vision of a "semantic web" which is accessible for everyone on any kind of device. This has resulted in intentionally vague, abstract specifications. But people who have not done a lot of work building GUIs for production systems do not really understand how to abstract layout and presentation. This was a key failing in the original Java GUI toolkit called AWT (Abstract Window Toolkit).
2. The wrong people. The HTML/CSS/Javascript/XSL standards have been developed by people who are primarily interested in information technology and theory. They have little understanding of and less experience with graphic design and application front-end development. They really do not understand what distinguishes good from bad in this area

Re:Not again

Yes, let's roll out another new standard for no reason at all when most of the web still hasn't caught up to the last one.

I can't be the only one who thinks the W3C is annoying as hell...

So you're advocating holding back progress because a lot of sites authors don't bother to make their HTML compliant? With the new APIs, this hardly qualifies as "no reason at all".
 

Re:Not again

I don't really keep up with the politics, but I think that HTML 5 is the W3C caving to exactly the sentiment that you are expressing. People weren't happy with the W3C and their pushing of standards that people weren't following (or at least not uniformly). They responded to outside pressure and HTML5 was born. So cut them some slack - they have seen the light and are attempting to be accommodating.

Anyway, the situation that you describe won't really be the case in a few years. Safari, Opera, Mozilla, and IE are all fairly standards-compliant these days. When IE6 decreases to 10% or so, the last of the really non-compliant browsers will be history.

Getting your site pixel-perfect on all of them is not and never will be trivial, because HTML is not supposed to do that. Certain sites do demand that, and for those sites we have things like Flash.

Re:

When IE6 decreases to 10% or so, the last of the really non-compliant browsers will be history.

Which shouldn't be a terribly long time:

http://it.slashdot.org/article.pl?sid=08/01/21/0652248 [slashdot.org]

Re:

What progress?

If you RTFA you would have seen that there are a lot of interesting changes in HTML5 that integrate with what people are doing NOW and providing a seamless set of markup and APIs. The audio, video, and canvas tags are particularly interest

Re:

Browsers still render compliant pages differently

Oh! I found the problem. You're looking for the article about PDFs. If you'll just follow me...

Re:Not again

Most of HTML5 was actually done outside of the W3C.

However, to address your earlier point, one of the big things we're doing with HTML5 is we're going and specifying the bits that all the other specs avoided, like 'window', like 'setTimeout', like how to parse HTML in the face of errors, and so on, and saying exactly how they should work, based on how browsers do them now, so that we can get the browsers to converge on one interoperable set of behaviours.

I'm also working on the Acid tests, e.g. Acid2 and Acid3, to foster interoperability on the older specs. It's working pretty well so far.

http://ln.hixie.ch/ [hixie.ch]
http://www.webstandards.org/action/acid3 [webstandards.org]

So... HTML5 should actually help bring the browsers closer on the bits that weren't specified before, and the Acid tests are directly intended to do that with the bits that _were_ specified before. If you want to help out, please do -- see the links above for how to help with Acid3, and the links below for how to help with HTML5:

http://blog.whatwg.org/w3c-restarts-html-effort [whatwg.org]

Re:Not again

Yes, let's roll out another new standard for no reason at all when most of the web still hasn't caught up to the last one.

I read the spec, and most of the additions are to incorporate what we've all been doing, with CSS/Javascript hacks and plugins, into the spec itself.

• Menu tag: An actual menu element provided by the render engine, no more CSS/Javascript menu libraries
• Combo-box input: An actual combo-box form input field, no more CSS/Javascript hacks
• Datetime input: No more javascript libraries to popup a date chooser, it comes with the browser
• Number input: No more javascript intervention to stop you from typing "bob" into a field expecting a number.
• Email input: Not only can it validate email format, but it could let you pull from your email client's addressbook
• URL input: Again, not only validation, but could let you pull from your browser's favorites, history, etc
• Input validation: No more onSubmit javascript checks to make sure your required fields have data in them.
• All Inputs have min/max and pattern (presumably regex) restraints

(BTW, all of the above should work even when Javascript is disabled, so you NoScript users get security _AND_ functionality)

• Datagrid: An actual data grid widget, no more hacking Tables to provide the same functionality
• Audio/Video tags: Just like <img/> tags, only for other media, what a concept!

Re:

Seems like it might also help machinereaders.

Standardizing the name of the navigation element, for example, allows a screenreader to find it usefully (on demand instead of in-line with the page). Same with the rest of the elements.

It also helps to standard

Re:Of course, it won't matter.

Something I found interesting is that they will not consider the spec complete until there are two fully working implementations (FTFA). Sounds good to me... the spec can be trimmed if no one is going to implement the full thing (so at least there will be a smaller spec to refer to instead of a complete spec that no one uses). Another good effect is that if MS drags their feet, they will look even more stupid :)

Re:

Something I found interesting is that they will not consider the spec complete until there are two fully working implementations (FTFA).

Which sounds rather self-defeating to me; why would a group or company put in a lot of effort implementing the most

Re:

The browser vendors are part of the working group, so they would be part of any discussions as to what to change. In practice, it's actually the browser vendors who request the changes -- typically, it's because the spec requires things that are contradict

Re:Of course, it won't matter.

The alternative to trial and error when creating a spec is just error.

Re:Of course, it won't matter.

Of course, it won't matter. At least until some major browsers support it.

Several of the features (e.g. Canvas) are already supported by all major browsers save for IE.

And it really won't matter until IE supports it.

One of the interesting aims of the HTML 5 standard was to spec the new functionality in such a way as to make it possible to emulate the new APIs in old browser. e.g. Canvas working in IE. [dnsalias.com] (Make sure you click outside the block area to start. I haven't implemented the key passing yet.)

The Storage APIs would be similarly easy to emulate through Cookies, Flash, or Google Gears. (Take your pick.) Server Side Events are more difficult, but I think it might be possible to emulate with XMLHttpRequest. If I'm wrong, there's always a Flash or Java shunt possible. DOM 2 Events is still not supported by IE, but that's easy enough to patch for by wrapping IE's attachEvent scheme.

Basically, we can force Microsoft's hand on this. A simple runtime patch and BAM, we're coding to HTML 5 standards. If enough people do it, Microsoft will realize they've lost that front and move on.

Re:

Uh, no you won't get people doing that, because they're removing the style= attribute. (See a previous reply of mine to learn exactly how stupid I think that particular move is.)