The WHATWG Blog

Please leave your sense of logic at the door, thanks!

WHATWG Weekly: the rubber hits the road

by Shelley Powers in Weekly Review

The HTML WG is heading towards Last Call, and the activity is increasing, both in the W3C and in the WHATWG email lists.

Opera is working on its implementation of the new HTML5 <details> and had several implementation questions. The issue is that the implementors need to provide a way for users to style the element, and whatever is used should be consistent among the implementors.

In the discussion, the concept of XBL shadow trees arose. If you're not familiar with XBL, it is, or was, the XML Binding Language—a Mozilla creation using XML to describe the behavior and styling of XUL widgets and XML elements. There is an effort to standardize the concept in the W3C with XBL2. Currently, the spec is in Candidate Recommendation status, with the most recent activity being a discussion about moving the spec forward that happened in March.

The issue of what happens with the DOM range when a page mutates spawned a lively discussion between Aryeh Gregor (Google) and Boris Zbarsky (Mozilla). The discussion looks to continue from a response posted by Ryosuke Miya (WebKit).

In an email that revives a dormant discussion related to media elements statistics, Silvia Pfeiffer points to a wiki page on Video Metrics. These wiki pages that pull all the disparate pieces together—not only from different implementors but discussed in different email lists and groups—are essential for ensuring cooperation, cohesion, and transparency. If anyone has another page that should be featured in a Weekly, drop a note in comments, send me an email, or tweet me at @shelleypowers, and I'll find a way to incorporate a reference to the page.

In the meantime, Chris Pearce has added support for Mozilla-specific decoding/painting statistics in the Firefox trunk for expected release with Firefox 5.

The discussion on @longdesc continues. In a comment to a weblog post, Bruce Lawson questioned whether the <details> element can't be used in place of longdesc. He continued the discussion with a question on the feasibility of this substitute to the WHATWG email list.

Speaking of @longdesc, I wanted to take this opportunity to point out the extensive collection of @longdesc use cases that Laura Carlson has been heroically gathering. There was also a wiki page gathering together all of the discussions on longdesc, but I believe it was locked down due to contentious activity. If there's a new wiki page somewhere, make a note in comments or send me the link and I'll update this page.

Alexandre Morgaut initiated a fascinating discussion on a browser implementation detail that many JavaScript developers may not be aware of.

All the major browsers add any HTML element that has an @id attribute to the global namespace. Chrome, Opera, IE, and Safari do so automatically, and Firefox does so in quirks mode. What this means is that if you have an element with an @id of "testing", you can access that element by the @id value name directly in code—without having to use getElementById first to get the element reference.

This behavior isn't part of HTML4, but it is part of HTML5, as noted in a bug filed on this behavior.

I linked to this discussion to a), make you aware of the functionality and the ongoing discussion and bug, and b) to strongly suggest that you never make use of this functionality in your applications. Read the WHATWG email thread for more on why this browser behavior is potentially harmful.

On the W3C side, I'll defer details of actions to the inestimable Karl Dubost, and his excellent Open Web Platform Weekly reports, but I did want to point out some decisions and email discussions of interest.

The co-chairs made a decision on Issue 120 related to RDFa prefixes. They decided in favor of continued support for prefixes, with recommendations to clarify their use and ensure people are aware they are optional.

The co-chairs also made a decision about Issue 122, choosing the change proposal that recommended removing the section describing alt text for decorative images out of HTML5 in favor of a link to the WCAG 2.0 guidelines.

In regards to Issue 142 on Poster Alt, the co-chairs decided in favor of the no Poster Alt change proposal.

Later in the week, the co-chairs declared that Issue 145 on codecs-vs-octet, was closed by amicable resolution. Amicable resolution...we should all take a moment to pause and savor this rare resolution state.

OK, moment's over.

The co-chairs continued with the rollout of decisions with one for Issue 129 on ARIA mapping, and whether @role can override rather than define element semantics. The chairs decided in favor of the change proposal to allow @role to change some role mappings, with some specific exceptions outlined in the decision.

I believe this is a first: the chairs also re-opened Issue 30 as a Last Call Issue. In case you're unfamiliar with Issue 30, it is about @longdesc.

Two decisions led to formal objections: Issue 120 on RDFa prefixes, and Issue 142 on Poster Alt. All formal objections are recorded and maintained in one specific page.

The Canvas API accessibility folks have asked for feedback on improved hit testing for canvas accessibility. The request is focused specifically to the canvas development community. I believe you can respond to the public-canvas-api email list even if you aren't a member. If not, you could probably post emails directly to Richard Schwerdtfeger.

An announcement was made on the new Task Force for Home Networking inside the Web and TV IG.

There's also be considerable discussion on incorporating support for PUT and DELETE in forms, including a re-opened bug on the issue.

The discussion still continues on the license for HTML5.

Whew! I'm exhausted just writing all of this stuff. The activity should continue to be high as the W3C HTML WG moves towards Last Call, and as the rubber hits the road with HTML5.

2 Responses to “WHATWG Weekly: the rubber hits the road”

  1. The spec-related things I’m working on now are funded by Google, so that would be the correct affiliation to list for me, not MediaWiki.