W3C Publishes First Public Working Draft of HTML 5 310
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."
First thoughts (Score:3, Interesting)
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:Not again (Score:4, Interesting)
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:Of course, it won't matter. (Score:4, Interesting)
Re:Still sloppy (Score:5, Interesting)
I agree that it's not ideal, but I couldn't really see a way around it.
No more style attribute?!?!?! (Score:4, Interesting)
*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.
Re:HTML5 is the wrong path (Score:5, Interesting)
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 (Score:1, Interesting)
If browsers support both specs, why not follow the superior one?
Re:HTML5 is the wrong path (Score:2, Interesting)
The standards are just not very good (Score:3, Interesting)
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:
Re:Still sloppy (Score:4, Interesting)
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).