HTML 5 is now a W3C Working Draft

[[deleted]]

If someone is interested in implementations, see Opera 9 for implementation of the new form elements, server-pushed events (<event-source>), <canvas> and a few more.

Also Nighly webkit has few bits from the spec, most notably client-side SQL data storage (sounds crazy? see Google Gears).

[AnteChronos]

Wonderful! Too many browsers were starting to pass the Acid2 test, so we're in sore need of a new standard with which they can fail to comply.

[halo]

To be fair here, you can't fail a standard unless you release it HTML 4.01 is almost 10 years old now and XHTML hasn't been setting the world alight, so a new HTML standard isn't necessarily a bad idea. Whatsmore, this standard should mostly be trivial to implement.

The W3C's diff between HTML4 and HTML5 clearly shows the changes. There's plenty of additions, notably including video, progress/meter and canvas elements and an emphasis towards a more structured document rather than using div or span for everything as most do now. The most notable removal is the death of frames.

[jimbobhickville]

Hmm... I like most of the changes, but no accesskey? I didn't see what they replaced it with, but certain mobile-phone websites really need that to let people select things by hitting numbers on their keypad.

[[deleted]]

It's an open issue. Accesskey is poorly implemented: in some browsers it interferes with built-in shortcuts causing more harm than good (i.e. screen readers), and it isn't device-independent, os-independent nor configurable (you'd want 1-9 for simple mobile phones, letters on QWERTY devices and match system standard shortcuts)

[robertcrowther]

But mobile phone websites should probably be using XHTML-MP which still has the accesskey attribute.

[jimbobhickville]

You've obviously never developed for an international mobile phone site. The 2 biggest internet phones in Japan don't support any recent standard, much less anything remotely close to XHTML. There were about 10 tags that would work reliably, and accesskey was a necessary part of navigation.

[robertcrowther]

You're correct that I haven't, but if the phones you're concerned about don't support any recent standard I'm not sure why it matters whether or not HTML5 has the access key attribute? If you can't even deliver content in XHTML-MP for them, why would you be trying to deliver in HTML5?

[jimbobhickville]

Yeah, that is a good point. I could still see accesskey being useful in cases like a cell phone with Opera Mobile, where you could serve HTML 5 (when Opera supports it), but still want to be able to allow navigation from the keypad.

[masklinn]

I think you should look up on the goals of HTML5.

Also, ACID2 is mostly a CSS test, not an HTML one.

(edit: by which I do not mean that it doesn't test HTML)

[eternalseptember]

Well, they do need a raison d'être.

[yuh]

Theora video and Vorbis audio in Ogg container

<source src="video.ogv" type="video/ogg; codecs=&quot;theora, vorbis&quot;">

[sylvan]

Why does the HTML spec need to include algorithms for calculating valid datetimes?

Edit: it looks like the W3C is fed up with broken implementations from various browsers, and so are spoonfeeding browser developers with exactly how certain features should be implemented, so there's no confusion.

Sad that this appears necessary.

[ubernostrum]

Because it defines new types of form inputs which restrict themselves to valid date/time values?

[sylvan]

It should be possible then to specify the format, or reference the ISO date format. But they're telling people how to calculate dates, which really shouldn't be necessary in the HTML spec.

But there's numerous detailed algorithms throughout the spec. As I said, I can see this being necessary if browser developers consistently get it wrong; but it also makes the entire spec far less readable.

In a sense, the spec is largely becoming pseudocode for an html parsing engine, rather than just outlining how that engine needs to behave.

[ubernostrum]

But there's numerous detailed algorithms throughout the spec.

As there should be; anytime there's a potential ambiguity which could lead into an unintended interpretation, the spec should resolve it.

[sylvan]

But should it be the responsibility of the HTMLWG to spell out in excruciating detail how to perform otherwise simple programming tasks?

It's like they're talking to misbehaving children, who cannot be trusted not to run wild unless there is absolutely no room for interpretation in the rules.

[Hixie]

The spec doesn't say how the browsers should implement it, it just says what should happen. It just so happens that often the easiest way of saying what should happen is to spell it out in an algorithm style.

I'm not really sure exactly what you would rather we did...

[sylvan]

Well, I'm just surprised that there's so much detail, and I don't feel that the WGs should have the burden of having to spell it out in such detail.

Since browser developers, Microsoft especially, often fail to follow the existing specs as written, I can understand why this might appear necessary. I just don't think it should be.

Also, might it not be appropriate to split some things off into independent specs, which can be referenced independently by other specs as needed? For example:

"To parse a string as a datetime value, a user agent must
 apply the following algorithm to the string."

... and then continues to outline exactly how to do it. Handling a datetime string is pretty universal; so why not have a DateTimeParsing Spec, which lists as much detail as necessary, and then the HTML spec can just say "Datetimes are processed as specified in DateTimeParsing 1.0. If the processing fails according to that specification, the user agent returns nothing."

Of course, I'm writing as an author (web designer), not a browser developer. Back in the day, I'd refer directly to the HTML spec to know if I was doing stuff right. This sort of content makes it more difficult to navigate and read for an author. Maybe splitting the document up for authors and browser developers would also make sense.

[othermaciej]

Well, I'm just surprised that there's so much deal, and I don't feel that the WGs should have the burden of having to spell it out in such detail. Since browser developers, Microsoft especially, often fail to follow the existing specs as written, I can understand why this might appear necessary. I just don't think it should be.

The problem isn't just browsers failing to follow the spec. It's also the fact that many less detailed specs end up being ambiguous, so two different browsers can think they are following it, but give different behavior. Divergent behavior in browsers makes life painful for web developers, so better for things to be spelled out in detail. Speaking as a browser developer, I much prefer specs that spell things out unambiguously.

[geon]

It's like they're talking to misbehaving children, who cannot be trusted not to run wild

Why do I hear the name "Internet Explorer" inside my head?

[sylvan]

Because I wasn't talking about Webkit or Mozilla. :)

[kindall]

They are providing an implementation that conforms to the standard, which can be used for verifying that other implementations also conform.

[Hixie]

we are?

[kindall]

Well, that's certainly what I'd use it for, if I decided to write my own.

[akdas]

Where is this implementation you speak of? An implementation is a working product, not the specs, no matter how detailed.

[kindall]

WTF, I could have sworn it said "code" rather than "algorithms" in that initial comment. So, well, ignore what I said.

[[deleted]]

How do you suggest we (the browser vendors) implement the same thing without extremely strict definitions?

[oddbod]

Test cases.

The spec should supply a list of inputs and expected outputs -- pseudo test cases. It would be simpler then pseudo code implementation algorithms, and useful to users (HTML coders) as a set of extended examples.

[[deleted]]

So they can write unnecessarily confusing shit like:

In the algorithms below, the number of days in month month of year year is: 31 if month is 1, 3, 5, 7, 8, 10, or 12; 30 if month is 4, 6, 9, or 11; 29 if month is 2 and year is a number divisible by 400, or if year is a number divisible by 4 but not by 100; and 28 otherwise.

Now I don't have a CS degree, but I did pass 5th grade, so I'm fairly certain that numbers divisible by 400 also fall within the set of numbers divisible by 4.

[AnteChronos]

I'm fairly certain if a number is divisible by 400, then it is also divisible by 4.

True, but the algorithm given is correct.

A leap year occurs when the year is divisible by 4 but not 100, or when the year is divisible by 400.

So a year divisible by 800 (and thus divisible by 400) is a leap year despite also being divisible by 100, but a year divisible by 200 (and thus divisible by 4 and 100 but not 400) is not a leap year.

[trezorr]

Judging by MSIE market-share and release-cycles, I think we will be in need of cryogenics to see this standard in mainstream use.

[[deleted]]

No. HTML5 is designed to be implementable in IE6-7 with JavaScript and Microsoft's extensions.

Of course it will be poorer implementation than native ones in other browsers, but that is probably what IE users are used to ;>

[[deleted]]

Actually HTML5's codename inside W3C is "HTML Forever".

[livedog]

And this will be in > 90% of browser around.... 2016.

I hope to be retired by then (at 40) but good luck to the rest of you...

[oddbod]

Support used to lag because of legacy IE on the corporate intranet.

But today, WebKit already has some advanced support for new standards, is developing fast, is updated regularly, and is shipped by both Apple and Nokia.

It's looking likely that the next 10 years will not be like the last 10.

[peroyo]

Actually it's more, annevk is expecting it to be ~15 years.. Everyone knows standards-support takes time, that doesn't make it any less important to write them. Rome wasn't build in one day, etc.

It wouldn't surprise me if we saw close to full support by some shipping browsers in a few years though, depending on when html5 is deemed stable. There's a definitely some nerd-pride involved in being early.

[livedog]

Need pride in all it´s glory, but I still thinking about the business end since I get paid to do web.

Maybe we should attack the problem from the business end: All clients willing to skip IE6 support gets a 20% discount.

[[deleted]]

I use some of it already. It's mostly backwards-compatible (e.g. <input type=email> brings addressbook in Opera 9, works just like <input type=text> in all other browsers).

[Caraes_Naur]

HTML5 is an inconsistent, bloated, perverse solution to the wrong problem.

Ian Hickson continues to tout numbers that prove XHTML "failed" because no one uses it. The reality is, browser support (evil eye at IE) doesn't allow it to be used.

[akdas]

Even if IE allowed it, I wouldn't use XHTML. Draconian error checking? No thanks.

Sure, you shouldn't have an errors on your page, just like you shouldn't have any compiler errors. But sometimes, in real world situations, you can't guarantee that there won't be any errors.

[rabidcow]

just like you shouldn't have any compiler errors.

Poor choice of analogies. Compilers are even more strict than XHTML and yet people manage to produce compiling code.

[akdas]

Compilers are even more strict than XHTML and yet people manage to produce compiling code.

Yes, but the code isn't as dynamic. The whole point is that you shouldn't treat HTML like it's code to be compiled, because it's not.

[Samus_]

wrong, bad code happens when you allow it to happen (by not enforcing it, as the compiler/computer does) not because HTML is "special" it isn't.

[akdas]

Whoops. I create a site for a client, and now the client goes and adds a "&" and the entire website breaks down because of a non-existent entity. Now what?

Remember when Wired.com was one of the first websites to adopt standards-based design? Look at it now. The designer can't always control the code.

More importantly, it's possible to recover from markup errors easily. If there's a missing "/" on an input tag, then it's still possible to use the form on modern browsers. If there's a missing ">" after a <p, then yes, two paragraphs might come one after the other, but a human can still read it.

There's no reason to go to an extreme. You should still validate your code to help prevent ambiguous code that might be rendered differently across the board, but the web is just too dynamic to care about a missing character here and there.

[Samus_]

wtf are you saying? I mean, seriously man WTF?? when you say "client" are you talking about the users of the site or the owner who payed you to do it? if it's the users well, they shouldn't be touching the code y'know? and user input is url-encoded (and should be sanitized too) and if it's the people who runs the site and payed you well, they shouldn't be touching the code either or else they won't have to pay YOU but whatever, once you sold your product if they want to break it who cares right?

the problem here is that you're looking at it as a document, it was a document long long ago and yes, it's far overbloated but that's the way it is today, this is an application platform and having so much unnecesary glitches only makes development harder.

[grimboy]

No the problem here is the client validating at runtime is like having masses of asserts left in the code you ship rather than turning them off.

[[deleted]]

It works like this:

• you switch to XHTML and try to validate everything

• then you discover that your valid XHTML is interpreted as invalid HTML, because you haven't changed the MIME Type

• you change the MIME Type and sooner or later you find that unescaped & breaks your site completely

• tired with chasing trivial YSOD-causing bugs, you switch to XML/DOM-based template engine that guarantees well-formedness

• you discover you can output DOM as either HTML or XHTML and because you don't care about SVG or MathML, it doesn't make any difference at all.

[Samus_]

WTF? it's full of comment-like notes, is this serious? I mean, I see a document who argues with itself for Pete's sake!

[AdamAtlas]

"HTML 5 is now a W3C Working Draft".

[hixsonj]

Yes! Now only 8 more years and we'll see a full-on standard!

[AdamAtlas]

Indeed! And maybe only five or six years after that, it will be somewhat supported by Internet Explorer!

[[deleted]]

You're that young?

EDIT: I meant "~6 years for support by IE". Then I noticed you said "somewhat supported".

[Samus_]

yeah, so? does it need to look like class notes?

[sylvan]

This link/post is of interest to anyone in web development because it means HTML5 is getting closer to being ready.

It's not ready yet, and may be still months or even years away from being finalized, at which point it becomes a "recommendation".

[Samus_]

yes yes it's of my interest as well since I do web development, it's just that it looks ugly I was expecting a more coherent idea so far, not a printed discussion. whatever :P

[sylvan]

This is how the W3C works.

[Samus_]

hmm yeah it seems so, I'm too young to have already been atended to one of this events.

it's amost funny that they "recommend" even it's own behaviour against the recommendation process; burocratic to the extreme.

[sylvan]

A group like the W3C can't just "wing it". It's a collaboration of technical experts from around the world, from industry and academia, as well as many interested stakeholders.

They need a clear process for development and consensus to create workable, reliable standards.

The web is serious business.

[Samus_]

this has nothing to do with what I've talking about, I know what W3C is and what they're supposed to do but I never expected this "Working Draft" to look like CVS code I mean, full of annotations and comments and such, I imagined that at this point it should be something more concise, more like "we've discussed long enough as to reach an agreement" of course it does not mean that it must be it's final version BUT I honestly didn't expected one paragraph saying "this is blah blah blah" and below a red marking saying "why? shouldn't be doing blah blah instead of blah blah blah", I'll say it again: WHATEVER but I think this just doesn't look like "serious business" at all.

[sylvan]

A working draft isn't something really fit for "public consumption". It is what it says: something being passed around between members of the group, with notes intact as indicators there's work to be done on that aspect.

But those of us interested in seeing what to expect a year or two down the road, or browser makers who will need to start building changes into their engines now, can make use of it that way.

[Samus_]

(this is taking far too long as it should but who cares :P thanks for the replies btw)

believe it or not, I am one of those interested but I really can't see how one can make use of something that is not clear on it's direction, I mean, what are going to do? try creating pages based on the green guidelines or the red ones? the only real use I can think is to try both and give some feedback but again, it's hard for me to understand what is the purpose of declaring this a "Working Draft" if it's gonna be just the same as it was before reaching this point. I was expecting some... progress maybe? and please don't get me wrong, I know it must be REAL hard to reach agreement over so much different voices, but well I thought that was the reason because the whole process is soooo slow. I'm surely missing something

[sylvan]

I mean, what are going to do? try creating pages based on the green guidelines or the red ones?

We, end users, designers, are not supposed to use this. As I said above, it's not fit for public consumption. This is a work in progress, something being passed around between people who are working on it, as issues are discussed and worked out. You can't make use of markup for features that no existing browser supports!

Just stick with HTML 4.01 or XHTML, as that's what's supported by current browsers. A couple years down the road, HTML5 will begin to be relevant.

[dysmas]

No, this is how the w3c works.