Postcards From TPAC

Every year, the top Standardistas of the world jet off to TPAC: a glamorous foreign location where they drink Daquiris, dance the rhumba til dawn, build sand castles and talk about standards. It's like being James Bond, but with a License to Spec rather than kill.

Various Opera staffers email reports of their trip to an internal mailing list. As an experiment, we're reproducing them here. These are the impressions of each named reporter, at the time of writing. Their opinions might change subsequently, and their opinions are not necessarily shared by other reporters or Opera as a company. These are emphatically not official minutes (those will be published by the W3C), nor commitments by Opera to support any specific technology. With those caveats in mind, enjoy these Postcards from TPAC.

Geolocation Working Group

Opera's Lars Erik Bolstad chairs the Geolocation Working Group.

The Geolocation Working Group had a two day meeting last week. Here's a summary. (Raw meeting minutes here.)

In addition to the regular crowd of implementors we were happy to have a representative of the Microsoft IE team attending our meeting this time. Meeting participants this time included Google, Microsoft, IBM, LG, China Unicom, Telecom Italia, and NEC in addition to Opera.

The current Geolocation API specification is currently in Candidate Rec and a few formalities remain before we can request the transition to Proposed Recommendation.

We're planning to produce an implementation report by which will document that the API itself can indeed be implemented, and that there are at least two real-world web sites that comply with the normative privacy requirements for recipients of location data. As for existing implementations of the API we have quite a few by now: Desktop: Opera, Chrome, Firefox, Safari. Mobile: Opera, Chrome, Safari, Fennec.

We're (soon to be) chartered to work on the next version of the Geolocation API ("Level 2"), as well as the Device Orientation Event specification.

The Level 2 API spec will add the ability to get the location as an Address, and we've already spent quite some time discussing various proposals for an address format. The IETF crowd would like us to directly adapt the Geopriv "civic address" format specified in RFCs 4119 and 5139, but there's strong pushback from implementors who feel this is overkill. The current proposal is to have a simpler format, but to specify a mapping from the Geopriv format to the Geolocation address format, and to include the raw, unparsed Geopriv address in one of the fields.

The Device Orientation Event specification introduces new DOM events for detecting the physical orientation and movement of a device, based on combining input from an accelerometer, a magnetometer (compass) and possibly also a gyroscope. The current proposal is pretty much based on the Android APIs.

Web Applications Working Group

Anne van Kesteren represented Opera on the Web Applications Working Group. WebApps is the group that took over a lot from HTML5 and already had a lot to begin with. Arthur Barstow (Nokia) and Charles McCathieNevile (Opera) are Co-Chairs.

Web Workers

Ian Hickson does not have bandwidth to deal with the comments needed to get to Candidate Recommendation status. I said I would look into getting our test suite published.

Clipboard

Drag and drop will be left to HTML5, as well as the actual ClipboardData interface. WebApps might do copy and paste when Hallvord [from Opera] contributes his specification.

WebSQL

Will be republished as WG Note.

Indexed DB

Pretty detailed discussion on the details of this new storage proposal. Indexed DB is more low-level than WebSQL and apart from Microsoft the implementations so far are on top of SQLite.

DOM Events

Keyboard events will get an inputLocale attribute that identifies the type of keyboard in use. This allows editing applications to implement smart quotes and bidirectional switching using heuristics that are hopefully mostly correct. Removing mutation events was discussed, but it seems that Microsoft will add support for some mutation events in Internet Explorer 9.

File API

Apart from renaming of the URL methods, nothing changes.

XMLHttpRequest + Widgets

Discussed the origin problem Widgets have. One idea was that the origin could be computed from the resource package. Would require servers to keep a list of supported Widgets as they can be updated over time.

WebIDL

The former editor got hired by Mozilla and can now work on it again. Coordination with TC39 (in charge of ECMAScript) is also starting again.

WebSockets

Brief discussion of how the IETF is taking ages [standardising the WebSockets protocol] and how it would be cool to reuse Web Sockets for P2P and have it on top of UDP. Nothing concrete.

Programmable Cache

Programmable Cache was dropped.

Selectors API

Awaits WebIDL clarifications.

XBL2

Awaits implementor interest.

CORS and UMP

We are going to try to move CORS to Last Call and see what happens.

TAG

Short discussion with the TAG about architecture of web applications. The TAG will try to sort it out.

Console API

The idea was aired to work on window.console as web pages rely on that now. Nothing was decided.

XMLHttpRequest

Basically awaiting implementations to align with the test suite and each other. Also discussed the test suite and how it can be moved to w3.org.

Web DOM Core

Also awaits implementations to act in removing certain features. Also discussed scope. Maybe the basic event interfaces will move here.

CSS Working Group

Håkon Wium Lie spent four days at W3C's TPAC in Lyon: two at the CSS WG, one at the plenary, one at the WebFonts WG.

The CSS WG is trying to finalize CSS 2.1. Remaining issues in the specification are few, and the focus is on tests and implementation reports. In principle, this leaves more time to work on CSS3 specifications.

One of them is CSS3 Multi-column. Opera currently has the most complete implementation; we support all properties [in internal builds at time of writing], I believe, including column-span.

The WG clarified several minor points in the specification; the most radical change was column-span: 1 to column-span: none.

Layout modules

One area that is emerging is template/grid/flexbox layout. Ale Mogilevsky from Microsoft presented his "CSS Grid Alignment Level 3 proposal. The functionality offered is similar to the Template Layout Module.

I suggested that the working group work out some use cases to compare the various proposals. Flexboxes (http://dev.w3.org/csswg/css3-flexbox/ and http://www.w3.org/TR/css3-flexbox/) are also relevant for this; ideally the more advanced layout models should build on terminology from flexboxes.

Generated Content and Printed Media

A new hyphen property was added to GCPM: hyphenate-last-line-avoid.

The hyphenate-* properties have so far only been implemented in batch processors. However, I believe browsers also will benefit from supporting hyphenation. One problem in doing so is that hyphenation is language-specific. The TeX community has developed word patterns that one should be able to reuse, though.

CSS Fonts

There were discussions on CSS3 Fonts and how to interface the descriptor syntax with OpenType Features. Mozilla demo'd support for OpenType Features at the plenary day. Very useful for serious typographers.

Writing modes

Writing modes was the most controversial discussion.

The editor's draft outlines a strategy for adding ~30 new properties and many new values to support style sheets that specify values based on the writing mode of an element. This is a big deal -- never has 30 properties been added in one go, and it touches upon many areas: i18n, data structures for CSS properties, CSS authoring, ebooks etc.

I believe these to be true:

  • LTR or RTL writing is a fundamental feature of a document. As such, it should be specified in the document and not in the style sheet. (However, valued can be propagated through CSS properties, which are handy for such purposes.)
  • horizontal or vertical writing is mostly a matter of presentation. A book in Japanese or (traditional) Chinese can be presented horizontally or vertically. As such, this belongs in the style sheet.
  • some argue that it would be convenient for padding/margin/border properties to automatically switch direction based on the writing mode of the element. Potentially, style sheets can be shortened if this is added, but there is an implementation/education cost/specification maintenance cost.
  • others think that the mapping to top/right/bottom/left (which exist in all cultures) can be handled with existing constructs, e.g., the lang attribute:
    :lang(ja) { ... }
    :lang(en) { ... }
    Or, if we accept adding functionality, we could extend selectors on the left side. E.g.:
     p:rtl { margin-left: 1em }
  • writing-direction-dependent switching is only one of several types of indirection. Another one is the inside/outside of a printed page. For example, you may want to float a figure to the outside of a page, or set a border on the outside.

The ebook community, which needs to present books both horizontally and vertically, have found a solution in alternative style sheets which describe horizontal/vertical presentations.

Also, there's a proposal for allowing "logical" values to the added to the margin and padding shorthands.

For now, the css3-writing-modes draft will move forward without the physical/logical parts.

WebFonts

The WebFonts group has a simple purpose in life: to get the WOFF container to REC. The only controversial issue I can see is whether the WOFF format should imply a Same-Origin-Restriction. This is currently in the draft. I know there are different opinions inside Opera on this. Personally, I think it's a useful restriction as will stop people from leeching bandwidth from unsuspecting web sites. And CORS can be used to relax the requirement.

SVG

Erik Dahlstrom represented Opera at TPAC.

We met with parts of the CSS WG one afternoon to discuss transforms and animations and other CSS/SVG issues.

The overall picture is that Microsoft is pushing for an aggressive release schedule.

They want stable specs by June 2011 for:

  • transforms 2d/3d
  • filters
  • animations
  • svg integration
  • simplified svg DOM
  • gradients (alower priority)

More details: one animation model for the web (possibly some common middle ground between SMIL animations and CSS animations). The issue of how CSS transitions, animations and SMIL interacts needs some attention.

One specific use-case mentioned was ads: declarative animations that work on both SVG and HTML.

There will have to be a DOM API for the model too: for getting animation model state, for controlling animations (e.g pause/start/stop) and for creating and applying an animation to an element.

WG RESOLUTION: To have a proposal to have the same shared data model and functionality across SVG Animation and CSS Animation

The SVG/CSS FX taskforce spec for 2d transforms in CSS

Differences from current css2d transform draft make transform apply as a property in svg, aligns transform syntax with svg (and the DOM API methods, not yet committed though).

Work in progress: http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html.

Filters, masks and clip-path in CSS / HTML

The group wants to move the filter spec into the SVG/CSS FX taskforce, and make filters/mask/clip-path usable outside of svg too.

SVG Integration

http://dev.w3.org/SVG/modules/integration/SVGIntegration.html This is to patch up some of the holes between CSS/SVG/HTML. The expectation is that this will allow the WG to make many tests for e.g different methods of inclusion of svg in html and css.

Gradients

Work only starting up so far, sharing gradients between svg and css, possibly adding more advanced gradients to svg (mesh gradients, diffusion curves).

Problem with mesh gradients is mostly about ease of animating/authoring (more or less requires a tool for editing). Already used e.g by PDF/PS.

Simplified SVG DOM (for SVG2)

Some of the proposals and discussions -

We had a report from Adrian Bateman (MS) on the new testing framework (test.w3.org). The tests for the 2d transforms spec will attempt to use this framework. We will explore crowdsourcing the review/submission of testcases in general. Long term plan is to move to using the new framework.

SVG 1.1 Second Edition

Work progressing, ~10 LC comments left to address. Needs to be done before the end of the year.

The WG aims to recharter in January

HTML Working Group

Anne van Kesteren attended on Opera's behalf.

Accessibility

The a11y Task Force made a list of user requirements (about 100). During the meeting Frank Olivier from Microsoft went through the requirements with the HTML WG and we organized them. It turns out about 10 of them are applicable to the HTML5 specification and are not addressed yet. The HTML WG Co-Chairs as well as the W3C Interaction Domain Lead put their foot down with respect to accessibility potentially delaying the HTML5 Last Call. It was made clear that HTML5 is time driven, not feature driven. So if the work on these requirements is not complete by May next year, it will not happen.

Media accessibility

Microsoft is in principle okay with WebSRT, if it meets the accessibility requirements. Great news! The W3C indicated WebSRT would not be within charter and would require a new Working Group. I have made the Co-Chairs take an action to sort out how WebSRT can be done at the W3C.

Testing

It seems everyone is okay with using the JavaScript harness James Graham made. test.w3.org might become testw3.org or some such out of XSS concerns. Nobody really liked the automated test runner and in general it seems that instructions for writing tests are needed.

IETF

Discussion on how the IETF/IANA registries are out-of-date and hard to use. (E.g. for HTTP headers and URL schemes.) Either needs improvement or be replaced with a more useful registry on e.g. w3.org. Discussion on how restrictions on text/* media types make no sense for HTTP usage. (E.g. CRLF for line breaks, no UTF-16, defaults to US-ASCII.) And discussed the path forward with processing URLs - I think it will be https://tools.ietf.org/html/draft-abarth-url

Semantics

Short discussion over whether retrofitting<i>, <b>, <small>, etc. as being semantic elements rather than presentational was worth it and made sense. No real conclusion reached.

The full minutes can be found at http://www.w3.org/2010/11/04-html-wg-minutes.html and http://www.w3.org/2010/11/04-html-wg2-minutes.html. (Agenda.)