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 »
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 »
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 »
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 »
After over a year without proper releases, there is now a new release of the Validator.nu HTML Parser. There have been numerous changes to the HTML5 spec and, consequently, to the parser since the previous release. All users of the parser should update to the latest release in order to run a version that corresponds to the current spec.
Posted in Syntax | Comments Off on Version 1.3 of the Validator.nu HTML Parser Released