Archive for January, 2011
Monday, January 31st, 2011
Another week, another WHATWG Weekly. While the change of name continues to excite the wider world — be sure to read HTML5 vs. HTML by Jeffrey Zeldman for some perspective — standards development marches on.
Media Type Sniffing
At the start of the week Adam Barth gave “whatwgians” a heads up on an update to the Media Type Sniffing specification, published by the IETF Web Security (websec) WG. It now includes rules for handling WebP, Ogg, WAVE, and WebM resources that lack a media type. This work was originally part of the HTML specification and as it progressed found a home at the IETF. The reason sniffing is being documented is that browsers are required to do it if they want to handle legacy content. On top of that, if their sniffing algorithms differ it is bad for security, as explained by the Secure Content Sniffing For Web Browsers paper.
As fonts are being uniformly sniffed by browsers as well due to the lack of registered media types for them I asked for the font sniffing rules to be included in Media Type Sniffing.
Real-Time Web
Patrik Persson with Ericsson Research reported they have been exploring peer-to-peer conversational video based on several APIs from the HTML specification. This is where the web platform is still lacking compared to plugins, but it is starting to look like that will change. Sorting out the details however will likely take time as browsers do not have camera integration so far and have no UDP or peer-to-peer network stack.
The network part is also still an unknown. There is no agreed upon standard protocol yet for this type of functionality. The RTC-Web effort plans to change that though.
hgroup
Various people are unsatisfied with the design of the hgroup element and wish for it to be changed. Some want it to be removed until more research is done. And they may be right. There is some anecdotal evidence that the element is difficult for people to grasp — Bruce Lawson discussed it with developers and Lars Gunther experimented on students. There are a few bugs opened on it and Steve Faulkner is trying to get the HTML WG to do a poll.
Change Proposals
The W3C HTML WG currently has three issues open on the processing details of meta elements with their http-equiv attribute set to "content-type" (125, 126, and 148). Change proposals were written for all of these last week.
Kenny Lu, assisted by Henri Sivonen, is trying to get the u element conforming by writing a Change Proposal for issue 144. Furthermore he believes u as well as b and i should be marked presentational. On the HTML WG mailing list Ian Hickson argued that if we return b and i to be presentational elements in HTML and introduce u as a presentational element, we should bring all presentational elements back. Preferring consistency over design-by-committee.
Shorts
Posted in Weekly Review | 6 Comments »
Monday, January 24th, 2011
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.
canvas and <!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.uk working.)
- 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:
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:
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.
Posted in Weekly Review | 6 Comments »
Saturday, January 22nd, 2011
As support for WebM is ramping up, Web authors can start using it. However, since not everyone has a WebM-enabled browser, yet, using WebM on your site poses the problem of having to explain to the visitors of your site how they can view WebM. It is inefficient for everyone to have to do this from scratch on their sites. Also, chances are that per-site help text will be incomplete and out of date soon.
To address this problem, with hosting and domain name help from Anne van Kesteren, I have made webm.html5.org as a place to pool the effort. When you publish WebM content, instead of explaining which browsers support WebM, you can simply link to webm.html5.org and it will detect if the user’s browser supports WebM. If the browser doesn’t support WebM, the page will suggest upgrading the browser to a new version that supports WebM, installing a WebM decoder if the browser supports 3rd-party decoders and one is available, switching to another browser or using another operating system (as applicable and in that order).
The dull visual appearance of the page is a known problem. Visual design isn’t my strong point. I have also avoided using logos without permission. If you’d like to contribute nicer CSS or a nicer-looking (but still short and on-topic) test clip, please find hsivonen on the #whatwg IRC channel on Freenode. Also, if you can contribute accurate advice for platforms that aren’t already covered (e.g. FreeBSD, AIX or OS/2), please drop a line on IRC or in the comments here. (You can view source on webm.html5.org to see what is already covered.)
Posted in WHATWG | 16 Comments »
Wednesday, January 19th, 2011
In 2009 we announced that the HTML5 specification at the WHATWG was progressing to Last Call. The plan at the time was to finish the specification this year and publish a snapshot of "HTML5" in 2012. However, shortly after that we realised that the demand for new features in HTML remained high, and so we would have to continue maintaining HTML and adding features to it before we could call "HTML5" complete, and as a result we moved to a new development model, where the technology is not versioned and instead we just have a living document that defines the technology as it evolves.
As there is still interest in publishing a snapshot of HTML5, the W3C is still working on that (in conjunction with the WHATWG).
Because the specification is now a living document, we are today announcing two changes:
- The HTML specification will henceforth just be known as "HTML", with the URL
http://whatwg.org/html. (We will also continue to maintain the Web Applications 1.0 specification that contains HTML and a number of related APIs like Web Storage, Web Workers, and Server-Sent Events.)
- The WHATWG HTML spec can now be considered a "living standard". It's more mature than any version of the HTML specification to date, so it made no sense for us to keep referring to it as merely a draft. We will no longer be following the "snapshot" model of spec development, with the occasional "call for comments", "call for implementations", and so forth.
In practice, the WHATWG has basically been operating like this for years, and indeed we were going to change the name last year but ended up deciding to wait a bit since people still used the term "HTML5" a lot. However, the term is now basically being used to mean anything Web-standards-related, so it's time to move on!
If you have any questions please don't hesitate to ask them in the comments or on IRC. We'll update the FAQ with the most commonly asked questions.
Posted in WHATWG | 152 Comments »
Sunday, January 16th, 2011
Inspired by my friend Peter who writes summaries about the ongoing progress with WebKit I thought I should try writing such a summary about the WHATWG. If this works out you might see another one. Obviously a lot has been happening thus far so to not make this ridiculously hard I will restrict myself to everything that happened fairly recently.
Aryeh Gregor took it upon himself to write a specification for window.btoa and window.atob. These methods originate with Gecko and have been adopted by other browsers since, but have never been formally specified. This also explains why implementations are different. If you want to help out standardizing something take a look at companion specifications on the WHATWG Wiki.
The device element (see What’s Next in HTML, episode 1) continues to be discussed on the mailing list (subscribe). Though from sharing a video/audio stream the focus in the discussion has shifted towards allowing applications to interact with non-typical hardware and the implications to security thereof. Consider attaching certain sensors to your computer or maybe your model train set and wanting to interact with it directly from a web application without having to install plugins of any kind.
Web Workers and the DOM was discussed to quite some extent on the mailing list. Evidently developers want more out of Web Workers and are running into limitations. Web Workers do not have access to a DOM, because existing DOM implementations are not thread-safe. Various threads on the mailing list are about overcoming this hindrance.
Silvia Pfeiffer who apparently has been contracting for Google recently (congrats!) wrote a lengthy email: Google Feedback on the HTML5 media a11y specifications. I.e. feedback on WebVTT — the WHATWG way of doing captions — and the new track element. Mark Watson with Netflix wonders how captioning will work in an adaptive streaming context.
It does not stop here. Really:
Have a good week!
Posted in Weekly Review | 2 Comments »