« W3C Host in China | Main | IndieUI: Events expands user interface interactions for mobile and more »

Open Web Platform Weekly Summary - 2013-01-13 - 2013-01-20

The last Openweb Platform Weekly Summary was too long ago. Let's restart. Your feedback is important. If you would like to see different type of information, or topics explained in more depth, just ask me in the comments. And if you think, I have forgotten about something essential, add it in the comments.

<main> element in HTML5.1

There has been long discussions last year on adding a new element <main> to HTML for defining the area of a document which contains the main information outside of menus, footers, etc. Steve Faulkner worked hard on defining, testing, implementing, receiving the feedback of implementers. It is now pulled inside the specification edited by Robin Berjon.

Streams API

The Web is asynchronous. A client makes a request. The server sends a response. The state of the data exchanged is usually not modified during that transaction. There are many circumstances when exchanging data between a client and a server may require a stream of data being built, created over time. The Streams API is an attempt at answering such use case on top of File API, XMLHttpRequest, postMessage, and Web Workers.

Web Intents Addendum - Local Services

Web Intents is a mechanism for service discovery and gives the possibility for Web applications to communicate in between them. It becomes possible for someone adding a photo in a Web email to change the colors through the actions of another photo editing Web app. It then becomes essential to be able to discover what are the local services available, for example using UPnP. Imagine being able to shut off the sound of the IP radio station on your local network when you receive a voice over IP phone call. Web Intents Addendum - Local Services defines how to handle these communications.

CSS Cascade

The cascade in CSS is the mechanism by which an element in the DOM inherits CSS properties. With the evolution of CSS, it is becoming quite complex. With multiple stylesheets it is common to have conflicts which need to be solved. The CSS Cascade specification defines how values are propagated for all properties on all elements.

Vendor Prefixes and shims

There was an interesting discussion on the conflict between vendor prefixes and shims. A shim is a way to create a piece of JavaScript to cope for the inconsistencies between different implementations of the same feature. Florian Bösch was addressing specifically the issue with pointerLock. Boris Zbarsky gave information about the new policy at Mozilla on vendor prefixes.

For what it's worth, the current trend inside Mozilla is exactly what you say: avoiding vendor prefixes by either turning things off before shipping or shipping them unprefixed if they're stable enough. At least as a general policy; specific cases might merit exceptions.

Canvas API with even-odd winding rule fills

James Ascroft-Leigh noted that the canvas API was missing an essential feature:

I recently discovered that a common and well understood 2D graphics operation is not supported by the 2D canvas API even though it is supported by almost every other modern 2D graphics API. This missing feature is called even-odd fill and controls how the fill region is calculated for self-intersecting paths or enclosed subpaths.

It has been added


Anne van Kesteren is working hard on defining how the URL should be implemented in user agents.


The W3C Technical Architecture Group helps coordinate cross-technology architecture developments inside and outside W3C. A part of the Web community was not very happy with the work of the TAG. To change things by action, they proposed candidates who got elected. Welcome to Marcos Caceres (Unaffiliated), Yehuda Katz (jQuery Foundation), Alex Russell (Google), and Anne van Kesteren (Unaffiliated). You can follow and participate to the discussions of the TAG.

This column is written by Karl Dubost.

Filed by Karl Dubost on January 21, 2013 10:05 PM in Open Web
| | Comments (4) | TrackBacks (0)


H.E.A.T. # 2013-01-22

What is the current "vision" of the W3C. At one point, the vision was centered around XML and its supporting dialects. I saw it as a highly professional and efficient language model and I drank the koolade.

Since that vision appears to have been abandoned in favor of HTML5, which I feel is nothing more than HTML 4.01+ (due to its open tag"ness" and reluctance to give up presentational tags), has the W3C published an updated vision statement?

What is the status of the Role attribute and WAI-ARIA? I know some browsers have implemented some of the parts, but, until the specifications become Recommendations (full), I am reluctant to employ them due to last minute patchwork by the W3C. I feel these two specifications are critical to enhancing structural semantics in markup.

A lot of the specifications issued or being worked on by the W3C seems to be all over the place. I mean, which ones are actively implemented by browsers and how would they support the needs of the average web developer?

Karl Dubost Author Profile Page # 2013-01-22

Note in case, it is not clear, I'm not part of W3C staff. I do this column on my own personal time.

For following the status of implementations, caniuse gives a general status. Not something in the details. The vision of W3C is available on the W3C site. In HTML5, you have to be really precise about what you are talking about:

  • what consumers (browsers) have to support which is different from…
  • what producers (authoring tools) have to output.

Role and ARIA are being implemented. For what it's worth, anything which is not widely deployed is always at risk being a recommendation or not. That's a part of the reality of the Web. If you do not feel yet comfortable using them in your business case, then don't. If you think it will answer some of your needs, just do it.

steve faulkner # 2013-01-22

The WAI-ARIA role attribute and aria-* attributes are supported in all modern browsers (that have accessibility support implemented)and Screen Readers

Henrique Alves # 2013-01-22

Hi Karl,

Good follow up and glad that the weekly summary is back.

I know the RICG is working hard and would be nice see in future posts about the state of the <picture> element.


Leave a comment

Note: this blog is intended to foster polite on-topic discussions. Comments failing these requirements and spam will not get published. Please, enter your real name and email address. Every individual comment is reviewed by the W3C staff. This may take some time, thank you for your patience.

You can use the following HTML markup (a href, b, i, br/, p, strong, em, ul, ol, li, blockquote, pre) and/or Markdown syntax.

Your comment

About you

This blog is written by W3C staff and working group participants,
 and maintained by Coralie Mercier.
Authorized parties may log in to create a new entry.
Powered by Movable Type, magpierss and a lot of Web Technology