Slashdot Mirror

But I have yet to find a decent how-to for it, nor a decent list of tags, etc. available.

Every single tag is listed in the table of contents under section 4. TBH the only way you could miss that is if you'd made no attempt whatsoever to actually find a list.

As for a how-to: pick any "decent how-to" for HTML 4 and use that plus some common sense.

http://wiki.whatwg.org/wiki/FAQ#When_will_HTML5_be_finished.3F

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That's actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 still, more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

How, exactly, does it vary?

See this and this.

It seems way more consistent than CSS has been

Are you talking about CSS 2 or CSS 3 here?

How, exactly, does it vary? It seems way more consistent than CSS has been -- again, outside of IE.

It's also not far off. According to their FAQ:

It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012.

If you believe the W3C's official line, it'll be later this year.

So not flamebait, maybe, but definitely FUD.

First of all, in the US, decoding MPEG-1 is not yet patent free, since some of the MPEG-1 layer 3 audio (MP3) patents are still around. I suppose you might be able to challenge them based on prior art.

I did propose that a MPEG-1 subset without MP3 could be used for the common base format for HTML5 but it basically did not go anywhere because 1. If a subset is used, then enough people will probably start using a full version of MPEG-1 (with MP3 audio) that free and legal software cannot support, and 2. Ogg Theora and Vorbis have better quality.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-May/019991.html

I figure MPEG-1 support is useful once full MPEG-1 can be supported (Dec 2012 maybe?) if there still is no base format (or at least no base format better than Motion JPEG).

When HTML 5 is out there will be no "Teach yourself HTML 5 in 24 hours".

I have been reading the HTML 5 discussion docs at WHATWG

Here is one DOM of one element:

interface HTMLDataListElement : HTMLElement {
readonly attribute HTMLCollection options;
};

"Teach yourself a half dozen HTML5 Elements in 24 hours - Part 1 of 50/Series 1 of 200)"

I agree with you, but the fact that it's IE is annoying from a developer's perspective. I'm getting less annoyed with IE with every release, but it still does weird things sometimes, and it would be nice if they moved faster on HTML5 (I know it's not "done" yet, but WHATWG suggests that some parts are done, like the canvas tag).

I can play every board game that I've paid for and Apple's approved.

Just to pick nits, for something as simple as a board game, you probably don't really need to use native APIs anyway. Just write it as a web app. At least on iPhone, you can save a web app to the home screen as a standalone app. I'm assuming that the iPad will probably have similar functionality.

With an iPhone offline web app, when you launch it, it takes over the whole screen (minus the menu bar, IIRC). The HTML, CSS, JavaScript, etc. is cached locally on the device, so the app works even when you don't have access to a Wi-Fi or cellular network. It can even store data locally on the device (SQL storage, HTML5 local storage, cookies, etc.) and upload it later if/when a network connection becomes available. And you can use multi-touch events to interact much like you can with a native app.

Of course, it's harder for the developer to make money with web apps, but not impossible. Web programming is certainly not sufficient for some types of apps, but for board games? Sure.

Worth pointing out that HTML5 isn't a standard yet. It's still in draft for the next couple years.

Canvas is at last call at the WHATWG. Look at the little tags at the side: "Last call for comments". This means that the WHATWG (a standards organization) believes that part of the spec is stable and is asking for implementations.

Canvas is also a de facto standard. Gecko, WebKit, and Presto have all implemented it more or less interoperably for an awful long time now: Firefox since 2005, for instance.

You are correct to say that HTML5 is not yet a W3C standard, unless you call Working Drafts "standards". But the W3C is not the only standards body out there.

Then neither are you. Perhaps you should read the HTML5 specs.

Have you actually done that? Because it's well over 600 pages in PDF format. No, I thought not, or else you'd realize that there are key things that HTML5 is still missing. Support for microphone/webcam input, for instance, is a glaringly obvious feature that has yet to be specced, let alone implemented.

Flash and Silverlight won't see the inside of this box because they are both proprietary and HTML 5 can do everything flash or silverlight can do in a standards based way (just ask google voice).

Um, not quite. HTML5 is awesome, yes, but it's not up to Flash's feature levels yet. Not even in the spec, let alone implementations. For example, audio input (along with webcam, etc.) is in the spec labeled as "Idea: yet to be specified". Let alone things that are a little more obscure or less obviously useful. Google Voice ain't going to work in pure HTML5 just yet.

But Apple is big enough to get major sites to make an iPhone app so they work anyway. So, minimal harm to them, lots of harm to Flash, which is great for the web.

In the US the last MPEG-LA patents listed for H.264 expire in 2028, not 2017.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020737.html

Its worse. You would have to wait until 2028 for the US MPEG-LA H.264 patents to expire.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020737.html

The editors of HTML5 are Ian Hickson (Google, Inc.) and David Hyatt (Apple, Inc.)

Don't believe everything you read. Ian is the only editor; David Hyatt doesn't edit the spec at all. Don't take my word for it. Take a look at the mailing list archives for last month: 22 posts by Ian Hickson, zero by Dave Hyatt. Actually, I couldn't find any posts on public-html by David Hyatt in the last year, and that's the list where all W3C spec discussion is done (there's no private HTMLWG group). Also notice that the WHATWG spec only lists Ian as editor.

More directly, just look at the Subversion log for the spec. You'll find that every single commit ever is by ianh, none by David Hyatt. I don't know why he's listed on the W3C version of the spec, but it's not because he does any actual editing.

Ian Hickson, as it happens, is violently against anything even slightly non-standard, and you can bet he would love to see H.264 die. But his overriding goal is for the spec to reflect reality. He's not going to mandate Theora support when he knows that not all browsers will support it. Likewise, he removed Web Databases from the spec (moving them to a separate spec) when Mozilla said they didn't want to implement them.

The editors of HTML5 are Ian Hickson (Google, Inc.) and David Hyatt (Apple, Inc.)

Don't believe everything you read. Ian is the only editor; David Hyatt doesn't edit the spec at all. Don't take my word for it. Take a look at the mailing list archives for last month: 22 posts by Ian Hickson, zero by Dave Hyatt. Actually, I couldn't find any posts on public-html by David Hyatt in the last year, and that's the list where all W3C spec discussion is done (there's no private HTMLWG group). Also notice that the WHATWG spec only lists Ian as editor.

More directly, just look at the Subversion log for the spec. You'll find that every single commit ever is by ianh, none by David Hyatt. I don't know why he's listed on the W3C version of the spec, but it's not because he does any actual editing.

Ian Hickson, as it happens, is violently against anything even slightly non-standard, and you can bet he would love to see H.264 die. But his overriding goal is for the spec to reflect reality. He's not going to mandate Theora support when he knows that not all browsers will support it. Likewise, he removed Web Databases from the spec (moving them to a separate spec) when Mozilla said they didn't want to implement them.

HTML5 allows multiple video or audio codecs to be provided. Therefore, Youtube and Vimeo can provide both H.264 and Ogg Theora/Vorbis support. If their concern is bandwidth, then they can just provide a slightly lower quality Ogg version with the same bandwidth usage.

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-source-element

" In fact there are Theora hardware decoders in the market already [xiph.org]."

That link you provided doesn't show that. It says there are players out there which support Theora; however, "there is a hardware decoder implementation being developed." That means there isn't currently a hardware decoder.

Meanwhile, there are numerous h.264 decoders available in hardware from multiple vendors. See Macej Stachowiak from Apple's post here, and search "h.264 asic" on your favorite search engine for more.

HTML5 includes XHTML5, so although it is true that XHTML2 is dead, it is also irrelevant.

http://www.whatwg.org/specs/web-apps/current-work/#the-xhtml-syntax

that's why we invented WebWorkers: http://www.whatwg.org/specs/web-workers/current-work/

Google seems to have a policy of talking about new ways to do things, and not making changes suddenly. Afterall, YouTube is the dominant video sharing site right now, and they don't want to let an open source format make them risk their status. So, it looks like HTML5 is going to get a good kick from Google telling them "Hey, we'll use whatever you tell us... but you've got to finish the spec first!" We'll see what this does to that.

Google employs Ian Hickson, the editor of HTML5. He quite literally wrote the entire spec (>1000 pages of complete.html) single-handedly, and personally reads and acts on all feedback. He makes all decisions about the spec unless maybe he's overruled by the HTML Working Group Decision Process, which has happened a grand total of once so far, and that on a purely editorial issue (microdata being a separate spec). Google doesn't need to give anyone "a good kick" when they're the ones writing the spec. They have eight HTMLWG members, too.

(Of course, if Google didn't employ Hixie he'd probably just do the exact same thing but employed by someone else. But they still do employ him.)

I bet that there are no technical reasons why it takes 5 years or more to come up with an HTML standard. I bet that there are lots of political reasons for that. I bet that a small team of engineers could do a better job in less time than a bureaucratic committee.

HTML5 is developed by the WHATWG, which more or less is a small team of engineers rather than a bureaucratic committee. It's driven almost entirely by implementers. The reason things aren't happening immediately is because the various browser developers only have a limited amount of development resources; they can only assign some of them to implementing new markup-level features (as opposed to security features, UI, bug fixes, etc.); and HTML5 defines a huge number of new features (latest draft is 696 pages). The spec is basically done, we're only waiting on implementation now. It's coming, piece by piece.

Even IF they fully implement the video tag correctly, who exactly will reformat all their existing video collections in AVI / FLV into open source format (.OGG ?), and what benefit will it give them. Absolutely none.

And for sure, even if and when the standard *is* finalized, that won't be before all the big players have bartered with the comittee for concessions on alternative allowable formats, and we'll end up with a video tag that needs to play not just open source formats but also AVI, WMV, FLV and all the popular formats of the day.

Provided of course in the next N years, an even better video compression format comes along and despite the agreed upon video tag, we'll end up with an <ms-video> tag, an <flv-video> tag etc etc.

Please try consulting the actual spec. HTML5 does not define or require any particular format for video or audio. It's open-ended and works with any format the browser supports, just like <img> works with any image format. Currently Firefox supports only Ogg Theora, Chrome supports both Theora and H.264, and Safari uses the system codecs. You can provide the video in multiple formats, and the browser will use the first one that it supports. Not flawless, but nothing like the chaos you hypothesize.

In an ideal world a lot of things would be great ... unfortunately we live in the real world where innovators cannot wait 5 years for technology to be debated, formalized, bartered, compromised and generally muddied into yet another worthless piece of documentation that is out of date before it's ever released.

That is exactly how the HTML5 development process does not work. HTML5 is developed primarily by the WHATWG. The WHATWG has nine members who decide everything, and eight of them are employed by one of the four major non-MS browser vendors: Mozilla, Apple, Google, and Opera. The spec is completely implementer-driven, and an overriding priority is to match what actual implementations do. If a single major implementer refuses to implement a feature, it's dropped from the spec (like mandatory Theora support). Meanwhile, the actual spec text is updated constantly in response to implementation and authoring feedback. You can even follow the changes on Twitter.

In point of fact, the WHATWG is more or less a place for implementers to coordinate on what they want to implement. The limiting factor is not specification speed: Ian Hickson writes and edits enormous amounts of spec text as quickly as you might wish. The limiting factor is implementation, vendors actually writing the code to implement the spec. That cost would be about the same even if every vendor made up its own implementation for everything. Currently the spec is in Last Call and mostly static, because it's waiting for implementations to catch up before adding more features.

Anyway, in the end, HTML5 brings one thing to the table that Flash can never hope to by itself: competition. You may think Flash works pretty well, but it will never be able to stand up to the feature set you get from five companies ruthlessly competing with each other for market share over years. Or even if it does, it will only because it's forced to innovate or die – because of HTML5. Even the greatest fan of Flash should welcome HTML5 as a strong incentive for Adobe to make it even better.

Even IF they fully implement the video tag correctly, who exactly will reformat all their existing video collections in AVI / FLV into open source format (.OGG ?), and what benefit will it give them. Absolutely none.

And for sure, even if and when the standard *is* finalized, that won't be before all the big players have bartered with the comittee for concessions on alternative allowable formats, and we'll end up with a video tag that needs to play not just open source formats but also AVI, WMV, FLV and all the popular formats of the day.

Provided of course in the next N years, an even better video compression format comes along and despite the agreed upon video tag, we'll end up with an <ms-video> tag, an <flv-video> tag etc etc.

Please try consulting the actual spec. HTML5 does not define or require any particular format for video or audio. It's open-ended and works with any format the browser supports, just like <img> works with any image format. Currently Firefox supports only Ogg Theora, Chrome supports both Theora and H.264, and Safari uses the system codecs. You can provide the video in multiple formats, and the browser will use the first one that it supports. Not flawless, but nothing like the chaos you hypothesize.

In an ideal world a lot of things would be great ... unfortunately we live in the real world where innovators cannot wait 5 years for technology to be debated, formalized, bartered, compromised and generally muddied into yet another worthless piece of documentation that is out of date before it's ever released.

That is exactly how the HTML5 development process does not work. HTML5 is developed primarily by the WHATWG. The WHATWG has nine members who decide everything, and eight of them are employed by one of the four major non-MS browser vendors: Mozilla, Apple, Google, and Opera. The spec is completely implementer-driven, and an overriding priority is to match what actual implementations do. If a single major implementer refuses to implement a feature, it's dropped from the spec (like mandatory Theora support). Meanwhile, the actual spec text is updated constantly in response to implementation and authoring feedback. You can even follow the changes on Twitter.

In point of fact, the WHATWG is more or less a place for implementers to coordinate on what they want to implement. The limiting factor is not specification speed: Ian Hickson writes and edits enormous amounts of spec text as quickly as you might wish. The limiting factor is implementation, vendors actually writing the code to implement the spec. That cost would be about the same even if every vendor made up its own implementation for everything. Currently the spec is in Last Call and mostly static, because it's waiting for implementations to catch up before adding more features.

Anyway, in the end, HTML5 brings one thing to the table that Flash can never hope to by itself: competition. You may think Flash works pretty well, but it will never be able to stand up to the feature set you get from five companies ruthlessly competing with each other for market share over years. Or even if it does, it will only because it's forced to innovate or die – because of HTML5. Even the greatest fan of Flash should welcome HTML5 as a strong incentive for Adobe to make it even better.

There was a draft standard of HTML5 released January 2008.

The first drafts of HTML5 were published by the WHATWG in 2004. 2008 was only when the W3C got involved. The W3C's endorsement has made little to no practical difference to the development or implementation of HTML5 so far – Mozilla, Apple, Google, and Opera were all implementing based on the WHATWG spec to begin with, and the W3C editor is the same as the WHATWG editor. The W3C was brought in to the picture as a political measure, and its involvement shouldn't be viewed as a milestone from a spec perspective.

Well as far as i know (from reading over some of the HTML5 functionality), HTML5 should be capable of running Gmail Offline.

There was a section i can remember reading that highlighted how you can create a file that will tell the browser to download a list of files, 3 different types of files were talked about as well.

Ah, found some stuff on it
Offline Applications

I'm no web designer so perhaps I'm misunderstanding TFA, but is offline script caching one of the features of HTML5?

Yes.
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline

Offline caching is a feature of HTML5.

http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline

Threads are not the only solution to concurrency. JS works will event loops.

And Promises make event loops even nicer.

But don't forget about Web Workers which gives us feeble javascript programmers true shared-nothing concurrency.

No, it is not ridiculous. It is a recognition that to avoid another HTML 3 fiasco, all parties, including vendors, have to be brought to the table. And forced to stay at the table through various market pressures, if need be.

Check out the Web Hypertext Application Technology Working Group. This is an extensive web site and will probably have an answer to all reasonable questions.

Is this a comment about HTML5 support? The standard isn't even established yet so it seems irresponsible for web designers to use that format for their entire framework, and premature to consider it a must-have for web browsers. IE9 will support it, I believe, though MS balked at supporting a non-final language.

No, that's not right. Parent post is rife with disinformation.

The HTML5 standard will be in development for years and will be influenced by real world feedback. This is a change in strategy that is leading to a more robust standard. Quoting from the WHATWG FAQ

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That's actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 still, more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

Many browsers, including MSIEv8, are incorporating at least some of the stable HTML5 features. HTML5 is also being designed so that features that are not available on a particular browser can be emulated with JavaScript. Common JavaScript libraries (JQuery,etc) are incorporating HTML5 emulations.

Microsoft, and other browser makers, are not going to wait until 2022 for a completed standard before beginning to implement HTML5 features. This is already well under way. And since the HTML5 approach deliberately eases the work of emulating its features in browsers that do not offer native support, we can expect to see more third party libraries, plug-ins, and so on that provide missing features to various browser versions.

Modern flash is pretty much a rich graphics API wrapped around a cleaned up Javascript. It's a pretty nice language and environment, actually; but just inappropriately overused in many websites. I'm skeptical that html video extensions will replace it, because I don't think the html encoding will have nearly the versatility of a general purpose programming language. Will it be able to, for instance, stream recommended alternative videos or advertisements while the video is paused, for instance? It's not that I want that, but a lot of site owners do.

Of course, using JavaScript. Events are fired whenever anything interesting happens to the video (like pausing or resuming). You can create <video> elements in JavaScript just like any HTML elements. JavaScript can be used to pause, resume, seek, or anything else you might like. You can look through the whole API in the HTML5 spec. You can overlay things on top of <video> using regular old CSS, unlike plugins. Etc., etc.

<video> lets you use the full power of a general programming language, namely JavaScript. Unlike Flash videos, however, you can interact with HTML5 videos using JavaScript and CSS – the same technologies you need to know anyway to create the whole rest of your page. Not having to learn Flash is a big long-term advantage as long as authors need to know CSS and JS anyway.

To anyone who thinks that sites will inevitably use Flash instead of <video> for obfuscation, tell me: why does almost no one use Flash instead of <img> for obfuscation today? You could do it – but you could also do obfuscation using straight HTML+CSS+JS, and that's a lot easier than bothering to load up Flash.

Chris DiBona of Slashdot fame now of Google fame had some choice words regarding Theora.

... the video functionality that, while officially removed from the HTML5 standard, will be implemented by everyone anyway...

I really don't know where this urban legend started and why people believe it, since it's trivial to verify that <video> has never been removed from HTML5.

What has been (hopefully temporary) removed is the mention of Ogg Theora as baseline format since Apple and Microsoft haven't yet accepted to implement it (Safari supports it anyway with the XiphQT component installed). OTOH, Mozilla, Google and Opera all support Ogg Theora (and Vorbis for audio) in their browsers (current of future versions), so apparently Theora is still the strongest candidate, altough Google may change this if they buy On2 and free the VP8 codec.

P.S.: sorry fanboys, H.264 is not an option: starting from 2011 websites with H.264 videos will have to pay an unspecified amount of money to the MPEG LA.

"Several sources are reporting that while native audio/video support has been dropped from the HTML 5 spec" is hard to reconcile with http://www.whatwg.org/specs/web-apps/current-work/#video (and the same document is available at the W3C, O doubters). It seems (gasp) that several sources can be...wrong!

Chrome 3 will include a Theora decoder ... a known broken and crappy one from an old FFmpeg build that can't cope with Thusnelda-encoded files, i.e. the close-to-H.264-quality encoder that Xiph and Mozilla have been working on.

They know about the bug ... but can't be bothered fixing it.

So sites with lots of Theora video will have to browser-sniff and suggest Firefox 3.5 to those with Chrome.

How to snatch defeat from the jaws of cluefulness ...

(note also that Chris DiBona mysteriously vanished from the WHATWG list after his FUD was refuted. It would be interesting to hear why.)

The "no suitable codec" blurb is a quote from Hixie. I (the submitter) left out the part that qualified this statement with "no suitable codec that all browser vendors are willing to ship," which is more or less what you mentioned. I probably should have mentioned that to make the meaning of "suitable" more clear.

I thought the whole point of HTML5 video was to have it work in every standards-compliant browser...

It was. It was specified that browsers playing HTML 5 video should support Ogg Theora, the codec that Firefox 3.5 among others uses. But it was removed after pressure from Apple and Nokia.

On the bright side Ogg Theora is supported by Firefox 3.5, Opera say they will support it, Google Chrome is on board, Safari can be made to support it by installing Theora codecs for QiuctTime and there are ways to make other browsers support it as well. So the problem is solved on the publisher side: publish in Ogg Theora. Hopefully this will put enough content coded in Ogg Theora out there to make it a de facto standard that solves the problem on the viewer side as well by pressuring webpages like Youtube to offer it and Safari and IE to implement it.

I thought the whole point of HTML5 video was to have it work in every standards-compliant browser...

It was. It was specified that browsers playing HTML 5 video should support Ogg Theora, the codec that Firefox 3.5 among others uses. But it was removed after pressure from Apple and Nokia.

On the bright side Ogg Theora is supported by Firefox 3.5, Opera say they will support it, Google Chrome is on board, Safari can be made to support it by installing Theora codecs for QiuctTime and there are ways to make other browsers support it as well. So the problem is solved on the publisher side: publish in Ogg Theora. Hopefully this will put enough content coded in Ogg Theora out there to make it a de facto standard that solves the problem on the viewer side as well by pressuring webpages like Youtube to offer it and Safari and IE to implement it.

You joke, but between the Canvas and Web Socket standards, I don't see any reason why they couldn't.

Granted, WebSockets have yet to be implemented in browsers, but I hear Google owns a fairly popular one...

You can write a program that runs in a web browser but does not store its data in the cloud. Use HTML + JavaScript + Google Gears (or HTML5 offline storage), and you essentially have a Desktop app.

Yes, JavaScript is slower, because it is interpreted, not compiled. But the race among web browsers for faster JavaScript has closed the gap. Witness, Chrome Expriments for some fun demos of the surprising things a browser can do.

Yes, JavaScript has been known to be hard to deal with. But that is almost completely because of different implementations by different browsers. Actually, the fault is almost entirely Internet Explorer. The difference between writing JavaScript for Chrome and Safari and Firefox is tiny compared to the difference between them and Internet Explorer. Even IE 7 and 8 continue to botch things that others have down.

But the jQuery library (and others) have smoothed a lot of those inconsistencies and given JavaScript programmers a more uniform API (thank you, those who have worked on these!).

JavaScript as a programming language is actually quite nice and elegant --- the way you write objects and arrays and the dot notation for calling methods and how everything is an object --- it looks a lot like Python.

"Microsoft has not commented on their intent to support <video> at all."

Because the browser vendors are the W3C and WHATWG.

Work on HTML5 started when Apple, Mozilla and Opera founded the WHATWG (after becoming concerned about the W3C's focus on XHTML). The W3C subsequently adopted HTML5 again and is now dropping XHTML2.

The W3C is a consortium formed by member organizations with an interest in the creation of web standards. E.g. browser vendors.

So, we should still be ensuring that all tags have matching close tags?

Well, duh, obviously if your document is XML according to its mime type. If it's HTML then it can have matching close tags; from WHATWG's HTML vs. XHTML, "If you attempt to send XHTML as text/html, you are actually just using HTML, possibly with syntax errors."

What will the document header be?

There's a web site that answers such questions.

I have been told that making page uses XML compatible HTML makes for a more predictable browsing experience and also lowers memory requirements.

The first claim is turning off quirks mode and using strict mode in various browsers, a complicated subject. I believe a document authored conforming to HTML5 is always and only strict mode; HTML5 also tries to make browser handling of "tag soup" more predictable. The second claim... {{citation needed}}?

Now if they implement HTML5 right, and we get the same cleanness that XHTML 1.1 had (Strict only. No transitional shit.), and they add cross-language abilities too (trough SGML), then I'm all for it!

1. There is an XML mode for HTML5, see HTML vs. XHTML. HTML5 even uses the same xmlns="http://www.w3.org/1999/xhtml/" namespace.
2. HTML5 tries to defines exactly how a browser should handle the billions of unclean documents out there. This will help browser interoperability in the real worldwide web of garbled HTML, and has huge benefits for script parsing HTML because the DOM contents after reading in HTML should be somewhat similar in different browsers.
3. Despite this, HTML5 specifies very clearly how authors should write HTML. It separates conformance for authors (write stuff correctly!!) from conformance for browsers (there are billions of crappy HTML documents out there, deal with it). Read Why does HTML5 legitimise tag soup?: "Just because browsers are required to handle erroneous content, it does not make such markup conforming. "

Have some faith, the HTML5 spec and its writers are wayyyyy smarter than /. commenters!

Now if they implement HTML5 right, and we get the same cleanness that XHTML 1.1 had (Strict only. No transitional shit.), and they add cross-language abilities too (trough SGML), then I'm all for it!

1. There is an XML mode for HTML5, see HTML vs. XHTML. HTML5 even uses the same xmlns="http://www.w3.org/1999/xhtml/" namespace.
2. HTML5 tries to defines exactly how a browser should handle the billions of unclean documents out there. This will help browser interoperability in the real worldwide web of garbled HTML, and has huge benefits for script parsing HTML because the DOM contents after reading in HTML should be somewhat similar in different browsers.
3. Despite this, HTML5 specifies very clearly how authors should write HTML. It separates conformance for authors (write stuff correctly!!) from conformance for browsers (there are billions of crappy HTML documents out there, deal with it). Read Why does HTML5 legitimise tag soup?: "Just because browsers are required to handle erroneous content, it does not make such markup conforming. "

Have some faith, the HTML5 spec and its writers are wayyyyy smarter than /. commenters!

At least with XML you have a simple, well-defined way to convert the XML text to a tree. With HTML 5, there's only "well-defined error handling". Read the sort-of specification for this.

Here's what's supposed to happen for just one of the hard cases. (There are dozens of other cases, some at least as ugly.) Parsing is in "body" mode (normal content) and an end tag whose tag name is one of: "a", "b", "big", "code", "em", "font", "i", "nobr", "s", "small", "strike", "strong", "tt", "u" has been encountered.

Follow these steps:

1. Let the formatting element be the last element in the list of active formatting elements that:
   • is between the end of the list and the last scope marker in the list, if any, or the start of the list otherwise, and
   • has the same tag name as the token.

   If there is no such node, or, if that node is also in the stack of open elements but the element is not in scope, then this is a parse error; ignore the token, and abort these steps.
   Otherwise, if there is such a node, but that node is not in the stack of open elements, then this is a parse error; remove the element from the list, and abort these steps.
   Otherwise, there is a formatting element and that element is in the stack and is in scope. If the element is not the current node, this is a parse error. In any case, proceed with the algorithm as written in the following steps.

2. Let the furthest block be the topmost node in the stack of open elements that is lower in the stack than the formatting element, and is not an element in the phrasing or formatting categories. There might not be one.
3. If there is no furthest block, then the UA must skip the subsequent steps and instead just pop all the nodes from the bottom of the stack of open elements, from the current node up to and including the formatting element, and remove the formatting element from the list of active formatting elements.
4. Let the common ancestor be the element immediately above the formatting element in the stack of open elements.
5. Let a bookmark note the position of the formatting element in the list of active formatting elements relative to the elements on either side of it in the list.
6. Let node and last node be the furthest block. Follow these steps:
   1. Let node be the element immediately above node in the stack of open elements.
   2. If node is not in the list of active formatting elements, then remove node from the stack of open elements and then go back to step 1.
   3. Otherwise, if node is the formatting element, then go to the next step in the overall algorithm.
   4. Otherwise, if last node is the furthest block, then move the aforementioned bookmark to be immediately after the node in the list of active formatting elements.
   5. Create an element for the token for which the element node was created, replace the entry for node in the list of active formatting elements with an entry for the new element, replace the entry for node in the stack of open elements with an entry for the new element, and let node be the new element.
   6. Insert last node into node, first removing it from its previous parent node if any.
   7. Let last node be node.
   8. Return to step 1 of this inner set of steps.
7. If the common ancestor node is a table, tbody, tfoot, thead, or tr element, then, foster parent whatever last node ended up being in the previous step, first removing it from its previous parent node if any.
   Otherwise, append whatever last node ended up being in the previous step to the common ancestor node, first removing it from its previous parent node if any.
8. Create an element for the token for which the formatting element was created.
9. Take all of the child nodes of the furthest block and append them to the element created in the last st

To be fair, Google is also refusing to switch YouTube to Ogg because of its lower quality per bitrate than h.264.

No, it is not. There has been no official statement from the YouTube team saying that. There's been one off-the-cuff statement to that effect by Chris DiBona, who is the open-source program manager at Google and does not work with YouTube (AFAICT). Subsequent requests for clarification failed to elicit any official statement. Peter Kasting of the Chrome team stated:

I don't believe Chris was speaking in any official capacity for YT or Google any more than I am. I think it is inappropriate to conflate his opinion of the matter with Google's. I have not seen _any_ official statement from Google regarding codec quality.

This is a quote from an actual Google employee, who incidentally happens to work on their browser and quite possibly knows their exact reasons for supporting both Theora and H.264.

Could people please stop spreading the misinformation that Google/YouTube believes that they can't use Theora because of its bitrate? It's completely unsubstantiated. Period.

what they did, is just one brain fart out of this quote from:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020620.html

"I considered requiring Ogg Theora support in the spec, since we do have
  three implementations that are willing to implement it, but it wouldn't
  help get us true interoperabiliy, since the people who are willing to
  implement it are willing to do so regardless of the spec, and the people
  who aren't are not going to be swayed by what the spec says."

There's no word about "cutting theora" just considerations that some companies won't comply with the spec.
But I guess this is somehow normal with new specs...

b and i, at least, are in the working version of html5:

http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html

and 'strong' usually results in bold text (but I guess it might not if the CSS for a page goes all over the place).

Google have published articles stating that they could not use ogg for YouTube because it would double their bandwidth costs to maintain the quality they get from h264.

Chris DiBona said that on the whatwg list, but he's the open-source program manager at Google, not (AFAIK) part of YouTube specifically. As far as I know, it's not clear if he was giving official estimates from the YouTube team or speaking off the cuff. (It very much sounded like he was speaking off the cuff.) I'm not aware of any articles that Google has published about how much bandwidth Theora would use — could you provide links?

They want the standard to include h264 video.

Could you provide any source for that? Because various Google employees explained on the whatwg list why Chrome supported H.264, I've never heard of any of them advocating that the HTML 5 standard require it.

(Yeah, I know, this is Slashdot. I should replace "could you provide links?" with "you're making stuff up"/"that's BS"/etc., but I can't be bothered.)