Slashdot Mirror
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."
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".
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
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".
THL phish sticks
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.
I wank in the shower.
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 .
So we have
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
Is that such a difficult concept?
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
"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.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Good to see they're binning frames.
But - why has there never been an include mechanism in HTML?
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.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
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, better lists, and meters.
Though audio and video I can live without. I'll be the first to get rid of it in my user CSS.
Oh, and I hope they know what they're doing by removing CENTER. Currently, there's no way to replicate its behaviour from CSS (CSS2). (And no, text-align: center ain't the same.)
I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.
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 :)
http://it.slashdot.org/article.pl?sid=08/01/21/0652248
Absurdity: A statement or belief manifestly inconsistent with one's own opinion. -- Ambrose Bierce
Oh! I found the problem. You're looking for the article about PDFs. If you'll just follow me...
Dewey, what part of this looks like authorities should be involved?
use CSS classes (for example ), define the look on a separate CSS file, and let the browser do its work and cache the CSS, you will reduce bandwith this way
Several of the features (e.g. Canvas) are already supported by all major browsers save for IE.
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. (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.
Javascript + Nintendo DSi = DSiCade
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".
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 difficult parts of the recommendation, if W3C explicitely reserves the right to change the spec under them any time before you're done?
If your using the style attribute for everything, your missing the point of CSS...
<style type="text/css">
table.align_left td{
text-align:left;
}
</style>
<table class="align_left">
<tr>
<td>Look a left aligned cell</td>
<td>Look a left aligned cell</td>
</tr>
<tr>
<td>Look a left aligned cell</td>
<td>Look a left aligned cell</td>
</tr>
</table>
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.
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 contradictory or that don't really work in the real world for one reason or another, and the browser vendors thus would rather implement something else. The requirement for waiting until we have 2 complete implementations is so that we know, when we say the spec is done, that it really can be implemented and that such implementations really can be interoperable.
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.
Ed R.Zahurak
You know, oblivion keeps looking better every day.
I didn't see anything new for uploading files. It would be great if improved support for uploads could be considered. Currently uploading 10 files requires 10 file widgets and performing the browse/select process for each one. It would be nice if the kind of interface found on sites like facebook for uploading multiple images/files could be achieved without the need for Flash or Java.
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/
http://www.webstandards.org/action/acid3
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
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.
"We now have AAC/MPEG-4 part 3 for audio and H.264/MPEG-4 part 10 for video"... both of which are patent-encumbered.
Actually most specs at the W3C don't use this model, which is what explains a lot. :-)
But yeah, like with software development, you have to fix bugs when you find them, and you rarely find the bugs before actually trying to use the software (or in this case, the spec).
(BTW, all of the above should work even when Javascript is disabled, so you NoScript users get security _AND_ functionality)
http://www.mhall119.com
(I'm the HTML5 spec's editor.)
What you describe seems more like a stylistic thing than a semantic thing (e.g. it wouldn't really make much sense in a speech browser, as far as I can tell). I recommend suggesting it to the CSS working group.
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.)
Ed R.Zahurak
You know, oblivion keeps looking better every day.
The alternative to trial and error when creating a spec is just error.
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:
The HTML5 spec includes an XHTML variant, just like it includes a text/html variant. The spec itself is agnostic about which you should use, you can use whichever one you want.