Change of name, video bandwidth, Change Proposals, and XSS
I think my summary last week worked out so here is the next. We changed the names of one of the standards we are working on and per Parkinson’s Law of Triviality this generated enormous amounts of feedback. Everything from “Love it!” to “Terrible.” Try to keep in mind that:
- Developers want features from browsers, not the next version of some standard.
canvasand<!doctype html>are used today. - Browsers implement features, not whole standards. And when they implement a feature they want to implement whatever is latest. (They are not going to implement a specific release of a standard when a later draft version contains known fixes to make e.g.
bbc.co.ukworking.) - Validators (these days) want to support roughly what the union of browsers implement so authors get the most useful feedback.
The FAQ has been updated with questions raised after the announcement and you are always welcome on IRC to discuss matters. Not to worry, most time zones are covered.
In WHATWG-land
On the mailing list a long thread started on implementations using a lot of bandwidth in their implementations of video. The basic problem is that when the user pauses the video the implementation continuous to retrieve data. This is a tricky problem as this is very helpful to the user — when not paying for bandwidth — but not necessarily for the application developer who is always paying for bandwidth.
Jeremy Orlow forwarded an email from the Chromium project about streaming Blob objects. A use case would be sending continuous data from the server and feeding it into an audio element as well as storing that data locally.
Quite a few more items were discussed:
- Tab Atkins replied to the questions on Microdata.
- Anton Kovalyov with Disqus asked what kind of statistics people would like to see of a large amount of HTML data he is accumulating.
- Alexey Proskuryakov pointed out that
window.print()needs some more work as WebKit had to change their implementation to match other browsers. Ola Kleiven confirmed Opera has a related issue. - Philip Jägenstedt (implements video in Opera) commented on Google’s feedback from last week.
- Henri Sivonen launched Get WebM! — an initiative to get WebM-enabled browsers to the masses.
- Charles Pritchard continued lobbying for adding descent measurement to
TextMetrics.
At the W3C
As you might know various W3C Working Groups work together with the WHATWG on specifications. That lots of people are part of both organizations makes this quite easy. The W3C still uses a snapshot model and as a result the HTML WG is working towards Last Call. A deadline was set and since end last year all new issues will automatically become Last Call comments. Older issues are being settled with Change Proposals. A Change Proposal Status overview is available and quite a few were created just last week:
- In No
<video>Content-TypePhilip Jägenstedt argues browsers should start sniffing for video just like they do for images. Julian Reschke has a more conservative proposal. - No Poster Alt written by Philip Jägenstedt and David Singer (Apple’s standards guru).
<video muted>is yet another Change Proposal by Philip Jägenstedt where he suggests a different syntax for muting media.
There are no boundaries to what can be considered an issue unfortunately and therefore sometimes petty editorial matters end up taking a lot of time. E.g. what links the Status section can contain and what exactly can be said in the Acknowledgments section. It makes people rant, but to no avail so far.
Any changes made as a result of an accepted Change Proposal are also reflected in the WHATWG standard by the way as the source document for the specifications is identical.
Fighting XSS
Over in [email protected] Adam Barth has a proposal for XSS mitigation in browsers. Basically trying to find a simple measure that could help authors fight cross-site scripting vulnerabilities.
Anne, I invite you to do an analysis of where the working group is actually spending “a lot of time”. I think the results may surprise you.
The path forward is with concrete proposals, and I think you have demonstrated that such do not require much in the way of length.
I also think that you missed something significant: hgroup.
Thanks Sam! I have added
hgroupto my list of things to cover next week. And you do have a point that mailing list bickering is not helping much. Will try to tread a little more careful.I realize I’m adding to the “arguing about trivial things” pile… but :-)…
Have you considered versioning the different components of HTML? I.e., Canvas 2d v1.0, WebGL v1.0, tag v1.0, etc. Then, you can take a snapshot and say, for example, that HTML5 consists of Canvas 2d v1.3, WebGL v1.8, etc…
Versioning is important for explaining functionality to clients. All browsers support HTML. What do I put on my resume? I code HTML? Yeah, the same thing people who picked up a book in 1996 will claim. Web 2.0? Web 3.0? HTML5 is a nice buzzword that non-technical people can understand and look for.
How do I explain that they need to upgrade their browsers? Non-technical clients understand version numbers. “This app uses HTML5. IE8 doesn’t support HTML5, so you need to upgrade to IE9 or Firefox 4”, etc.
Version numbers serve a lot of different purposes outside of telling browsers what to implement…
I’m sure you’re sick of hearing this by now.
“This app uses HTML5.” is not a useful message for your users, IMO. It would be more useful to say “This app uses the canvas element” or something like that. After all, “This app uses HTML5.” could refer to the command element, which is not implemented by any browser, or to wbr, which is implemented everywhere.
Sean:
We do have internal version numbers for parts of the spec, e.g. the media stuff is in v3, IIRC, and the canvas stuff at v4, IIRC. But even between major changes to the APIs the APIs still get continuous fixes and updates, so it’s not clear that it does more than just help with internal planning.
What do people put on their resume for C++, or Perl, or Java?
HTML5 is a buzzword, as you say. You can use the buzzword without the spec having that as its name.
IE8 doesn’t support HTML5 but IE9 does? How do you determine that? Sure, IE9 will support a few more things from the W3C HTML5 spec than IE8, but both support stuff in that spec, and both are missing stuff from that spec, and both support stuff in the spec but do it incorrectly according to the spec. It’s not clear to me that the _spec’s_ version number has any bearing on this. Just tell people that they need IE9 and that IE8 isn’t good enough to view your site, you don’t have to mention the spec to do this.
I think spec version numbers make people _think_ that they serve lots of purposes, but in practice they’re just a comfort item. They don’t actually serve the purposes described. They didn’t serve them back in the day of near-annual versions, and they certainly don’t serve them today where versions take a decade or more to develop. Just think back the last ten years. The Web has evolved plenty during that time, both in terms of what browsers do and in terms of what Web developers do, yet we haven’t had version numbers to help us. The world survived fine.
AFRIK, HTML will continue to have version numbers at the W3C side. Only the WHATWG side has changed. I think the HTML working group will take snapshots of the WHATWG spec as it evolves and assign them version numbers.