HTML 5 gets forked up Splitters! That's the cry which may well be echoing out across the web in coming days, as the World Wide Web Consortium (W3C) and Web Hypertext Application Technology Working Group (WHATWG) have decided to pursue their common agenda of a marvellous new standard for the web by doing things differently. The split seems amicable …
Forking under certain controlled circumstances works as long as the fork and and the trunk keep in touch. IIRC that's how the ext4 filesystem was eventually developed: as a fork of ext3 so as to keep ext3 stable while working on new filesystem ideas. The new ideas worked, so they were made into the new trunk as ext4.
It is very scary. Why? Because people with put the new-and-unstable into production just to get the new-shiney and then moan like all hell when it doesn't work perfectly.
It would be like someone putting ext4 on to their production servers before it was fully-baked, and then blaming ext4 when it goes on its arse.
The big problem we have with this is it won't be techies driving things (BTRFS, good as it is, is not production ready so no one uses it outside of dev/test) but happy-clapping meeja-type and designers who have no clue (and do not care) about the technical risks. They'll get is working on iOS Safari, and then blame the world when it doesn't work everywhere else.
crap developers have always done that, so the current events won't change anything, they can barely keep a page running across multiple versions of a browser without it breaking, I used to have a guy working with me who suffered the same problem until I took him aside and educated him better.
".....They'll get is working on iOS Safari...." Sorry, but if they do get it truly working on Safari (and not the usual Apple standards fudge) that should give the rest of the World time to get HTML5 working on everything else, have a cuppa, and get most of the work done on HTML6 (or whatever follows).
I think this is the worst possible outcome.
On the one hand, we have one standards body running glacially slowly. On the other hand, we have a standards body producing a "living" standard that is a total pain for developers as it's a moving target.
The W3C's standard is going to be obsolete by the time it gets ratified, and the WHATWG are going to cause developers immense pain as we'll never be certain as to what the standard really is.
I wasn't a fan of some parts of HTML 5 (optional closing tags. Hmmmm....) but this is just making things worse.
Can someone please take these two bodies into a darkened room and "explain" to them what a whole world of pain they are opening up ?
It's actually just business as usual. People not familiar with what's going on are generally spooked by the fact that the process specification isn't due to finish for several years. This scares customers from adopting the perfectly reasonable approach of adopting what has been finalised: the DTD and the new tags.
WHATWG can go back to being the developers group of trying to work out what works and trying to work out how to get the bits that don't work to work. The current hottest potato is how to deal the apparent need to serve up different versions of the same image.
The W3C can go back to being the bloated body that adds a veneer of respectability to the whole thing. If it means that we get an "HTML 5 transitional" then I guess we'll have to live with it.
Tinkering with the standards is not good for everyone else. Sure, someone goes home all pleased because their standard is now 'more consistent', 'logical' and 'elegant', but they're not the poor souls who've got to update browsers and websites as a result.
"The specification does not change arbitrarily: we are extremely careful! As parts of the specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). "
Yeah right. If you change the spec, everyone out there will still be interpreting it the old way, not the new way. That's especially problematic for an awful lot of mobile devices (i.e. Android), with their generally less-than-regular-if-ever software update cycles.
its largely a pearls to swine exercise.
I still feel there are people involved in many aspects of HTML5 who are there purely to ensure it doesn’t succeed so perhaps by dividing we may sneak useful features through one route or the other.
It is nice to see people proposing things that were possible before IE arrived.
Does this meal that the WHATWG will be creating a kind of bleeding edge specification which will make it into the browsers? Once it's implemented and matured a little, W3C will then be adding it to their own version of the standard?
If that's true, surely that's a good way to work as it means that web developers can choose to use the WHATWG features on the understanding that they are not mature features. However, if you code up your HTML to the W3C standard, you will know that your code is written on a mature base and should work pretty much everywhere.
That just leaves one question.... with the two standards work like that, or are the likely to go in completely different directions? If that's the case, it probably would mean the death of the W3C, eventually.
Basically, yes. W3C stuff is what the suits like to hear. Unfortunately, for most of the last decade Microsoft abused the standardisation procedure to block progress on HTML and cement its position. This is why WHATWG was set up by developers in the first place.
HTML isn't code, it's markup; and while that might sound pedantic it is important. The rules have always told browsers that they cannot ignore anything they don't understand which means developers can get on trying things out without worrying too much. The main advantage of HTML 5 is that it specifies how to handle errors, something that was sorely missing from HTML < 5. The main deficit, in my view at least, is an equivalent for the browser-prefixes in CSS. But as even they are being largely ignored but the crowd of ignoramuses that, myself included, web developers, that point is probably moot. What I would like to see is users being given the control in browsers to decide whether they want to support experimental features rather than the current lottery. Oh, and I like <time> to survive the whole process.
The W3C will survive if only to rubberstamp what WHATWG comes up with. This is much same as other international bodies such as the IEEE which generally approves stuff that the industry is already pushing on consumers.
"Does this meal that the WHATWG will be creating a kind of bleeding edge specification which will make it into the browsers?"
Yes - and no. It means that browser vendor X will add new, shiny, fancy feature Y, the WHATWG will document it, and the other vendors will (likely) follow suit. After a while the W3C will add it to their spec, and it'll be formalised.
In the meantime vendors of, say, assistive technologies will run like mad to keep up, releasing new, costly versions.
Developers rejoice. Users? Not so much. Imagine it like this: you start building a gross of houses on a huge plain. The LAST house won't use the same power adapters as the FIRST house, but sooner or later ONE or the other of those plugs will get formally standardized.
I propose we create a 3rd umbrella organisation, that covers both WHATWG and W3C, then we create a committee for the naming of that 3rd organisation with a tedious voting system spanning several years giving anybody the option to veto any decision at any point and return to square one.
I'd be more worried that at the end of this when we get our new standard, but for it to be ill defined and ambiguous in nature. Having 1 out of a 100 web browser developers having to work it out for themselves, all with different personal agendas is how things end up with the web burning.
Many W3C members have a nasty habit of being extremely evangelical about their own limited points of view and detest anything that is not exactly what they have penned. Even improving on what they might propose is often seen as a personal attack. As a result, I've spotted countless good things discarded, many bad things implemented (e.g. as mentioned above, a new and utterly daft approach to closing tags that undoes all of the progress in making the structure more controlled and therefore reliably parsable by a browser).
Some of the biggest new features of HTML5 are barely usable at the moment due to the fragmentation or optional implementation status of major components - i.e. video and canvas elements, resulting in being forced to use large JS libraries to produce dynamic code and to handle the browser by browser (and version by version) specifics.
The situation is made harder as a lot of the new features have little or no backwards capability either without adding stupid code for no reason - for example the very useful "header", "article" and even "footer" tags... Ideal places for styles to be attached but ignored by older browsers and even some "html5 browsers" and therefore you have to insert additional div and span elements just to put in the styling - at which point why bother with the "header" and "article" tags? It's just becoming tag soup.
"As parts of the specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). "
The 'spec' has already broken backwards compatibility several times. More BS from a true master at the trade.
It's funny how folks can get all scared of evolving standards and lack of a final, end-of-line destination, not knowing how much of their own lives run on open-source technologies. The whole point is that it's open for new development and new perspectives, so anyone can take it and add something new or refine what's there. Otherwise how do you get that new feature the boss is complaining "seems obvious, why doesn't it work that way already"? Technology keeps evolving and progressing, so things that run on technology or dictate the standards of technology have to evolve with that same pace. Just like legal systems have to evolve to keep pace with the changes - otherwise all our traffic laws would be based off of what's appropriate for horsecarts and wagons.
Feels like some still are these days, at that.
Wonder if any of the leaders of both groups actually work "at the coal face" so to speak?
I would hope they do.
The reality is, for the most part, developers have to work behind the bleeding edge for real world applications - at least for desktop websites.
Having said that, used carefully, progressive enhancement and various javascript libraries (such as respond.js and moderniser) allow us to put into practice some of the better aspects of css3 and html5.
So long as the client is educated and informed as to what different browsers will display, I think cause for alarm right now is ill-advised.
The trickle down has always been glacial and the standards have to appease many different interests - that's just human nature - it's *not* an easy job to corral all the camps and get agreement.
What we *don't* want is a return to the mess we had in the late nineties and early noughties. We're in a massively better place now than we were then, thanks in part to those who set the standards, but mainly to those who implement them and find workarounds - developers!
There will always be a bleeding edge - we just need to ensure it's possible to achieve that edge in production within a reasonable time frame as the edge moves forward.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
