Open Web Platform Weekly Summary - 2013-01-28 - 2013-02-03

Ok, it seems I keep up with the pace these days. Here your weekly Openweb Platform Summary covering from January 28 to February 4, 2013. In case, you missed last week. Next week, I will be in New-York City for the W3C ebook Workshop, but I will still try to deliver the summary in time.

A C library for HTML5 Microdata

Hitoshi Uchida has announced that he created a C library for HTML5 Microdata.

launchURI proposed by Microsoft

Adrian Bateman proposed the launchURI:

Many platforms support applications registering as custom protocol scheme handlers. For example, mailto: is a scheme for mail but often application platforms encourage app-specific schemes for deep-linking within applications.

The IE10 Team implemented launchURI with a vendor prefix to achieve this. The interface would look like:

partial interface Navigator {
    void launchUri(
        DOMString uri, 
        optional LaunchURICallback successCallback,
        optional LaunchURICallback noHandlerCallback);
}
callback void LaunchURICallback();

Programmable state-machines in CSS proposal

When styling elements some developers would like to have the style change in one element reflected in another one. There is no linked behavior in CSS. Andrew Fedoniouk pointed to two approaches to solve this issue. And François Remy noted that all the bricks were already here, Web Components specification has a decorator feature. There was just a need for coordination and browser implementations.

keyCode, charCode and so on for Web applications with different keyboard layouts

Keyboards have different layouts. Mine which I'm writing with currently is Japanese. It has for example specific keys for switching in between writing English and Japanese. Masayuki Nakano sent a very long email detailing exactly how Firefox is handling keys in different contexts. He demonstrates how legacy keyCode and charCode are not very useful for Web applications having to deal with different keyboard layouts. In a second email, he is explaining how they should be defined.

Keyboard events for accessible RIAs and Games

Florian Bösch has written a blog post on why Keyboard events in Javascript are broken and he followed-up on the DOM mailing-list. The discussion took an interesting turn on User privacy. Each time, we create a feature that gives technical information about a cultural artifact of the tools, we give an opportunity for fingerprinting. Reaching the right balance is a difficult game.

CSS Parsing and entry points

Tab Atkins has started to work on a CSS syntax module, aka parsing a CSS. Simon Sapin is in the process of identifying the entry points.

1. Parsing a whole stylesheet
2. Parsing a style attribute
3. Parsing a single declaration (part of a @support condition)
4. Parsing any stand-alone "unit" that does not have error recovery: selectors (for selector APIs), media queries (media attribute), conditions or property values (for CSS.supports()), etc.

Proposal for obtaining robust style information via Javascript - getStyle()

Currently to know what is the style applied to an element, the Web developer relies on getComputedStyle(). It gives information about the state of the element, so basically the CSS values once they have been applied and processed by the browser. But there is no way to know what was the original value set in the CSS. Mike Sherov would like to have a window.getStyle(valueType, element[, pseudoElement]); François Rémy noted that the interesting value was the cascaded one. Mike completed that a broader set of states might be interesting such as: "used", "computed", "specified", "resolved", "actual", "initial", "default". He is giving the following examples (careful not actual working code at the time of this writing):

elem.getStyle( prop, type[, pseudoElem] )

<div style="width:100px;"><div id="aDiv"
style="margin:auto;width:50%;"></div></div>

document.getElementById("aDiv").getStyle("marginLeft", "used"); //25px
document.getElementById("aDiv").getStyle("marginLeft", "computed"); //auto
document.getElementById("aDiv").getStyle("width", "used"); //50px
document.getElementById("aDiv").getStyle("width", "computed"); //50%
document.getElementById("aDiv").getStyle("display", "specified"); //""
document.getElementById("aDiv").getStyle("display", "computed"); //block
document.getElementById("aDiv").getStyle("display", "default"); //block

David Baron would prefer separate methods:

element.specifiedStyle.color
element.computedStyle.color
element.usedStyle.color
element.pseudoStyle("::before").specifiedStyle.color

Read the full thread.

HTTP/2.0 It's a king of magic

How a software will certainly know that it is HTTP/2.0 speaking and how the HTTP/1.1 will fail (or not) with regards to this magic.

Moving Webapps tests to GitHub

There is a proposal about moving webapps tests to GitHub, which obviously triggered a long discussion. Special note for Robin Berjon litterary style ;)

Centered or balanced with CSS

When centering text with CSS, lines try to use the maximum space and then are centered. It looks like a bibemdun dude with nasty effects sometimes for the last word. There is a new proposal on the table to give balance in between lines. The algorithm is described in more details.

HTTP Host: header, will it survive in HTTP/2.0

Do we really need the Host: header in HTTP/2.0 and if axed what would be the consequences? It's not obvious. It might create issues for intermediairies such as HTTP proxies. Then there's always the question on what do we save exactly and how do we impact performances?