This Week in HTML 5 – Episode 27
Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group. In this episode, I'd like to highlight some of the discussions that I've missed in previous episodes.
- Greg Millam writes, "I'm one of the main engineers responsible for captioning support on YouTube, and I've joined the Chrome team at Google to attempt to help drive video captions and subtitling forward." Henri Sivonen replies, "I agree it makes sense to start with something simple. The markupless flavor of SRT would be such a format. However, supporting the formatting tags in later flavors of SRT is a can of worms." [full thread: Captions, Subtitles, and the Video Element]
- Robert O'Rourke writes, "Are there any plans to bring list headers from HTML3 into HTML5?" Ian Hickson replies, "You can do this in HTML5, using <figure> and <legend>." The thread continues in a number of directions. Marcus Ernst writes, "Anyway I would consider it even more appropriate to allow the list inside a paragraph," to which Ian replies, "We had this in the spec originally, but we dropped it due to a variety of issues (it made life harder for editors, it didn't work in text/html even when it looked like it did, people got confused...)." [full thread: List Headers]
- Drew Wilson writes, "There's currently no way to set or get cookies from workers, which makes various types of cookie-based operations problematic." Jonas Sicking replies, "Allowing cookie to be set would unfortunately create a synchronous communication channel between the worker and the main window." The discussion continues, focusing on issues of multi-threaded updates to
document.cookie. Drew Wilson again: "Following up on this. I created two pages, one that tests cookies in a loop, and one that sets cookies in a loop, and ran them in separate windows in Firefox 3, IE7, and Chrome. Chrome and IE7 currently allow concurrent modification of document.cookies (i.e. the test loop throws up an alert). Firefox does not." [full thread: Accessing cookies from workers]
- There have been a number of overlapping discussions on whether and how to allow authors to embed RDFa in HTML 5 documents. See 1, 2, 3, and followups. Besides the technical arguments about how it would work, much of the discussion centers around the concept of distributed extensibility, which I've touched on before. For example, here is Chris Wilson (of the Microsoft IE development team): "We have had (in the past as well, imo, in the future) a requirement for decentralized extensibility - that is, that document/content authors can extend the set of elements with their own semantic or behavioral elements. I continue to think there is a requirement for that. (One might well ask why we didn't implement full XML in that case; I'll politely not answer from a historical context, but will point out that the draconian error handling and poor fallback story make delivering content in XML in the browser a poor solution in the ecosystem today.)"
- Steven Faulkner writes, "I have ... taken a stab at a RFC 2119 compatible definition for table summaries: http://esw.w3.org/topic/HTML/SummaryForTABLE/SummarySpecification." [full thread: Draft text for summary attribute definition, continued in March archives]
There has also been a vigorous debate about the license of the specification itself.
- Sam Ruby writes, "In my discussions with Ian and at Mozilla, I gathered that it was a shared understanding that by October that the license for the W3C license would be somehow open source friendly, and specifically that a Creative Commons Attribution license was something that was of common and general interest." The "open source friendly" clause is a reference to the fact that the spec does actually contain some code (in the form of WebIDL declarations), and vendors of open source browsers would like to include this code (or derive code from it) into their products.
- After much discussion, Philippe Le Hegaret (of the W3C) writes, "In response to requests from developers to make it easier to include portions of W3C specifications in software documentation, bug reports, code, and test cases, W3C have drafted a new Excerpt & Citation License. ... Uses like forking of a specification would remain prohibited to protect the due process and the consensus found in a chartered Working Group."
- Ian Hickson immediately replies, "Increasing license proliferation is a really bad idea here. I would be opposed to introducing yet another license. ... [The forking] use case is the main one that I'm concerned about, FWIW."
- Jonas Sicking explains his reasoning about allowing forking: "I think it would gain W3C a tremendous amount of trust if it were to allow [forking]. To many people, me included, having the gurentee that W3C can't go off 'into the weeds' means that I have don't have to worry about my time being wasted when I contribute. I think many people feel the same when they contribute to the forkable software I represent."
- Philippe notes that the W3C "isn't used to the concept of allowing a fork" of their specifications, which is one of the requirements of any "open source friendly" license.
- I believe Maciej Stachowiak (WebKit developer at Apple) best summarized the group's objections: "1) Preventing specification forks is not achievable through license terms; a sufficiently motivated party can create a new spec from scratch. 2) Preventing specification forks is probably not necessary; the one time it happened, the outcome was good and the effort merged back into a realigned W3C. 3) Due to 1 and 2, we should give more consideration to LGPL/GPL compatibility than prevention of forks via licensing terms."
- Ian Hickson agrees: "I do agree that the original use cases are (intentionally and explicitly) not all met by the proposal that was put forward, and I do think the original use cases were an accurate portrayal of the use cases that this working group has consensus on. Compatibility with open source (including GPL and LGPL projects), clear license terms (ideally reusing an existing license), and the ability to fork are all issues that working group members discussed and considered important previously."
Tune in next week for another exciting episode of "This Week in HTML 5."