# The future of style

The Future of Style aggregates posts from various blogs that talk about the development of Cascading Style Sheets (CSS) [not development with Cascading Style Sheets]. While it is hosted by the W3C CSS Working Group, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of the CSS Working Group or the W3C.

## WWW 2015, the 24th International World Wide Web Conference, …

Source: W3C's Cascading Style Sheets home page • 12 December 2014 05:31 AM

18 May 2015 WWW 2015, the 24th International World Wide Web Conference, will be held in Florence, Italy, May 18–22, 2015.

## Minutes Telecon 2014-12-10

Source: CSS WG Blog • Dael Jackson • 11 December 2014 03:49 PM

- Rossen introduced the creating of a taskforce to tackle some of the lower level layout primitives and exposing the programmability model of layout and styling to script. The group will meet in person just prior to the Sydney F2F in February to finalize details of the charter, meeting schedule, and exact scope of what the taskforce will try to achieve. Anyone interested in this work is invited to join the mailing list and follow on the wiki (available here)
- Everyone in the group was actioned to review the edits dbaron made on the Transitions spec and give feedback.
- Resolved: Keep allowing *-identifier when it’s not digits and recommend a string when it is.
- Resolved: Allow strings as argument to `:lang()`
- Everyone agreed that an errata to CSS2.1 should be created to better explain how space is distributed among columns. dbaron will write up Gecko’s behavior for the mailing list and SimonSapin will use that to create some tests and find interoperability for the errata explanation. This discussion transitioned to the difficulties in republishing a document in REC and the lack of tests for the CSS2.1 errata. There was a desire to make sure that changes like this are clear to those looking at the spec.
- Resolved: Add a new link at the top of CSS2.1 linking to the Editor’s Draft
- These CSS3-UI issues were decided:
  - Resolved: To the extent that the outline follows the border edge, it should follow the border-radius curve (issue 56)
  - Resolved: Implementors may directly manipulate width and height elements on the style attr being changed and change “resize factor” to “resize function” to address fantasai’s concern (issues 47 and 53)

Full Minutes

## Tibetan character picker v15

Source: ishida blog » css • r12a • 06 December 2014 10:39 PM

I have uploaded a new version of the Tibetan character picker.

The new version dispenses with the images for the selection table. If you don’t have a suitable font to display the new version of the picker, you can still access the previous version, which uses images.

Other changes include:

- Significant rearrangement of the default table, with many less common symbols moved into a location that you need to click on to reveal. This declutters the selection table.
- Addition of latin prompts to help locate letters (standard with v15).
- Hints (When switched on and you mouse over a character, other similar characters or characters incorporating the shape you moused over, are highlighted. Particularly useful for people who don’t know the script well, and may miss small differences, but also useful sometimes for finding a character if you first see something similar.)
- A new Wylie button that converts Tibetan text into an extended Wylie Latin transcription. There are still some uncommon characters that don’t work, but it should cover most normal needs. I used diacritics over lowercase letters rather than uppercase letters, except for the fixed form characters. I also didn’t provide conversions for many of the symbols – they will appear without change in the transcription. See the notes on the page for more information.
- The Codepoints button, which produces a list of characters in the output box, now has a new feature. If you have highlighted some text in the output box, you will only see a list of the highlighted characters. If there are no highlights, the contents of the whole output box are listed.
- Don’t forget, if you are using the picker on an iPad or mobile device, to set Autofocus to Off before tapping on characters. This stops the device keypad popping up every time you select a character. (This is also standard for v15.)

About pickers: Pickers allow you to quickly create phrases in a script by clicking on Unicode characters arranged in a way that aids their identification. Pickers are likely to be most useful if you don’t know a script well enough to use the native keyboard. The arrangement of characters also makes it much more usable than a regular character map utility. See the list of available pickers.

## Mongolian variant forms

Source: ishida blog » css • r12a • 06 December 2014 10:13 AM

There is some confusion about which shapes should be produced by fonts for Mongolian characters. Most letters have at least one isolated, initial, medial and final shape, but other shapes are produced by contextual factors, such as vowel harmony.

Unicode has a list of standardised variant shapes, dating from 27 November 2013, but that list is not complete and contains what are currently viewed by some as errors. It also doesn’t specify the expected default shapes for initial, medial and final positions.

The original list of standardised variants was based on 蒙古文编码 by Professor Quejingzhabu in 2000.

A new proposal was published on 20 January 2014, which attempts to resolve the current issues, although I think that it introduces one or two issues of its own.

The other factor in this is what the actual fonts do. Sometimes they follow the Unicode standardised variants list, other times they diverge from it. Occasionally a majority of implementations appear to diverge in the same way, suggesting that the standardised list should be adapted to reality.

To help unravel this, I put together a page called Notes on Mongolian variant forms that visually shows the changes between the various proposals, and compares the results produced by various fonts.

This is still an early draft. The information only covers the basic Mongolian range – Todo, Sibe, etc still to come. Also, I would like to add information about other fonts, if I can obtain them.

## Minutes Telecon 2014-12-03

Source: CSS WG Blog • Dael Jackson • 04 December 2014 01:52 AM

- There were a few people that felt that having a psuedo-class apply to the label if it applies to its labeled control would add useful functionality, but several people weren’t convinced that there were real-world use cases. Therefore, Florian will come up with use cases attempting to create this behavior and anyone else is welcome to also add cases.
- These CSS3-UI issues/topics were decided:
  - It was felt that implementors that don’t implement `invert` shouldn’t parse `invert`.
  - Resolved: Update the spec to make it more clear what optional means in the current spec (Issue 42)
  - Resolved: Authors must not hide outlines on focused elements unless they provide an alternate highlight mechanism for focused elements (Issue 43)
  - Resolved: UAs may support `image` in addition to `uri` and refer to image production as part of the text. (Issue 44)
  - Resolved: Clamp cursor coordinates individually when invalid. (Issue 46)
  - Resolved: Do not address this issue (Issue #49, ability to show a tooltip with full text when a line is ellipsed) in CSS3-UI

Full Minutes

## Minutes Telecon 2014-11-16

Source: CSS WG Blog • Dael Jackson • 26 November 2014 08:54 PM

- Everyone should review Transforms in order to be able to vote on publishing a new working draft next week.
- Microsoft is going to test out the changes it would like to see so fixed position creates a new stacking context. If it works well, it will be brought back to the group and likely written into the spec.
- Resolved: extend `:matches()` to pseudo-elements
- Resolved: The specificity of a `:matches()` inside a `:not()` is the specificity of the most specific
- Resolved: reuse the hook from `:active` on `:focus`
- Resolved: define a new `:focus-within` that matches on the same things as `:focus`, plus parents, including if there are Shadow DOMs
- Resolved: both `:hover` and `:active` should propagate from the labeled control to the label, in addition to the other direction.
- For `text-overflow`, the conversation about handling items where, due to other properties, the text can’t overflow ended up being too complex for the time on the telecon and will go back to the mailing list.
- Resolved: Drop the text that says: “The resize property applies to elements whose computed overflow value is something other than visible. If overflow is different in a particular axis (i.e. overflow-x vs. overflow-y), then this property applies to the dimension(s) which do not have the value visible.” from CSS3-UI
- For outline offset, everyone agreed that there needed to be constraints on how far in the negative direction values can go, but there were several different options as to how the should be written. Options included:
  - Setting 0 as the minimum.
  - Set a floor as soon as any two lines of the shape touch each other.
  - Changing the outline of the shape itself and making it shrink.
- Florian will try and write up a clear and relatively simple proposal for the mailing list.

Full Minutes

## Minutes Telecon 2014-11-19

Source: CSS WG Blog • Dael Jackson • 20 November 2014 11:03 PM

- Resolved: Accept fantasai’s proposal for `flex-basis: auto` changes (auto means `main-size` and add a keyword for automatic sizing)
- It was quickly agreed that the text for explaining `urange` (available here) could move to the Fonts spec. There was disagreement between jdaggett and TabAtkins as to if this additional normative text was necessary for the spec, however, implementers stated that they did want the text available to them. A compromise was reached where it would be in an appendix so that regular authors wouldn’t normally encounter it.
- Resolved: Move the `urange` definition to an appendix in the Fonts spec.
- Resolved: Drop pseudo classes from CSS3-UI in favor of Selectors 4
- Resolved: For clarity, all future pseudo-classes should be in a Selectors module
- Resolved: Drop XFORMS related pseudo-elements
- A tracking tool for the moved and removed pseudo-elements and pseudo-classes is available here.
- Resolved: Drop `content: icon` and the icon property from CSS-UI
- Resolved: pull `nav-index` from level 3 of CSS-UI and put it on a wiki
- Tantek requested that individuals add the URLs for discussions related to `nav-index` to the wiki here.
- There wasn’t time to discuss the `text-overflow` issue, so discussion will continue on the mailing list.
- Resolved: Create a taskforce to work on box-tree API and extensible CSS APIs

Full Minutes

## The WebApps WG and the CSS WG published a Note to indicate t…

Source: W3C's Cascading Style Sheets home page • 18 November 2014 12:00 AM

18 Nov 2014 The WebApps WG and the CSS WG published a Note to indicate that no further work is expected on Fullscreen

## Picker changes

Source: ishida blog » css • r12a • 17 November 2014 10:51 PM

If you use my Unicode character pickers, you may have noticed some changes recently. I’ve moved several pickers on to version 14. Most of the noticeable changes are in the location and styling of elements on the UI – the features remain pretty much unchanged.

Pages have acquired a header at the top (which is typically hidden), that provides links to related pages, and integrates the style into that of the rest of the site. What you don’t see is a large effort to tidy the code base and style sheets.

So far, I have changed the following: Arabic block, Armenian, Balinese, Bengali, Khmer, IPA, Lao, Mongolian, Myanmar, and Tibetan.

I will convert more as and when I get time.

However, in parallel, I have already made a start on version 15, which is a significant rewrite. Gone are the graphics, to be replaced by characters and webfonts. This makes a huge improvement to the loading time of the page. I’m also hoping to introduce more automated transcription methods, and simpler shape matching approaches.

Some of the pickers I already upgraded to version 14 have mechanisms for transcription and shape-based identification that took a huge effort to create, and will take a substantial effort to upgrade to version 15. So they may stay as they are for a while. However, easier to handle and new pickers will move to the new format.

Actually, I already made a start with Gurmukhi v15, which yanks that picker out of the stone-age and into the future. There’s also a new picker for the Uighur language that uses v15 technology. I’ll write separate blogs about those.

[By the way, if you are viewing the pickers on a mobile device such as an iPad, don't forget to turn Autofocus off (click on 'more controls' to find the switch). This will stop the onscreen keyboard popping up, annoyingly, each time you try to tap on a character.]

## Minutes Telecon 2014-11-12

Source: CSS WG Blog • Dael Jackson • 13 November 2014 01:12 AM

- The discussion about CSS3 UI focused on two different items: the previous decision of the working group to add Florian as a co-editor to CSS3 UI and how CSS3 UI should progress forward. In regards to co-editorship, it was decided that Florian should function as co-editor for CSS UI Level 4 instead of for level 3. Progress on CSS3 UI will hopefully move forward more quickly now that tantek has time to focus on it and more unstable items will be moved back to level 4. The work Florian already has done to take previous commits into bikeshed will still be handled by the two of them and they will work together to get the edits Florian found into CSS3 UI.
- Resolved: Add Florian as a CSS UI level 4 editor, not to level 3, and they will work together on publishing the pieces that Florian already prepared for level 3
- Resolved: New WD for Exclusions and Position
- The FPWD of Pseudo-Elements will happen after language is added for `::grammar-error` and `::spelling-error`, including information pertaining to the security concerns.
- There was a lot of support for the general path dauwhe is taking on Generated Content and it was agreed that as issues come up they’ll be discussed further on the list.
- Resolved: Proceed as outlined by dauwhe for Generated Content and continue conversing on the mailing list
- The `content` property should stay where it is.
- The language on the `:hover` pseudo was wrong and will be changed.
- fantasai asked for responses on the mailing list about where `::selection` should inherit from.

Full Minutes

## Living on the Edge – our next step in helping the web just work

Source: IEBlog • ieblog • 11 November 2014 05:58 PM

Today we are rolling out a new Windows 10 preview build with significant Internet Explorer interoperability updates. In line with our commitment to interoperability and compatibility, this update includes over 2000 fixes for interoperability issues, support for 20 new platform features, and our new architecture for advancing interoperability and compatibility. We’re excited to be sharing this work at such an early stage in our development process and we look forward to hearing your feedback. We're also rolling out this preview build to users of our new RemoteIE service, available for Windows, Mac OS X, and other platforms.

# Introducing the “living” Edge document mode

The cornerstone of this update to IE is the “Edge” mode platform—a new document mode designed with interoperability at its core. With this mode, we’re applying the highly successful interoperability strategy of Windows Phone 8.1 Update to Windows 10.

As we announced in August 2013, we are deprecating document modes as of IE11. With our latest platform updates, the need for legacy document modes is primarily limited to Enterprise legacy web apps. With new architectural changes, these legacy document modes will be isolated from changes in the “living” Edge mode, which will help to guarantee a much higher level of compatibility for customers who depend on those modes and help us move even faster on improvements in Edge. The next major version of IE will still honor document modes served by intranet sites, sites on the Compatibility View list, and when used with Enterprise Mode only.

Public Internet sites will be rendered with the new Edge mode platform (ignoring X-UA-Compatible). It is our goal that Edge is the "living" document mode from here out and no further document modes will be introduced going forward. We need your help in testing this new mode so we are enabling it on by default for a small percentage of the Windows Insider user base and those of you that manually select the mode (see below).

Edge mode introduces an interoperable UA string designed to get today’s modern Web content, and to avoid old IE-only content. We’ve also spent a lot of time ensuring that the IE platform behaves like modern Web content expects.

In cases where these changes necessarily differ from standards, we’re following through with standards bodies and other browsers to update specs and implementations to reflect the interoperable behavior.

## New features in preview

Also in Edge mode are early implementations of several in development features (we’ll blog more about these in depth soon):

CSS Preserve-3D – A popular developer request, this feature enables CSS transforms on multiple elements to be composed as a part of a 3D scene rather than flattened together.

Content Security Policy 1.0 – CSP is the next step forward since HTML5 Sandbox in preventing cross-site scripting. Pages provide a policy via the Content-Security-Policy header. This policy defines the origins from which resources on the page (JS, CSS, plugins, images, etc) are allowed to be loaded. This adds a defense-in-depth mechanism for preventing malicious content from being injected into the page. Resources blocked by CSP are reported through F12 tools and, optionally, as a report back to the server.

CSS Interaction Media Queries (Level 4) – A key component in responsive design is responsive input handling. We’ve talked before about adapting UX for input types, and this feature gives Web developers a new tool to do just that. Stylesheets can now use pointer and hover media queries to adapt UI based on the general precision of the user’s input (fine/coarse) and whether the device supports hover.

Gamepad API – First previewed earlier this year, Gamepad API is now in the preview for Windows 10. Plug in an Xbox One or Xbox 360 controller and check out our demo code on GitHub.

WAV Audio – This audio format uses PCM audio for lossless quality. With this release, WAV is supported in the <audio> element and will eventually be supported with Web Audio in a future release.

Selection API– We've improved our interoperability for the Selection object by implementing APIs like Selection.extend(), containsNode(),and setBaseAndExtent(). We have also helped get the W3C Selection API specification to First Public Working Draft and ensured it covers all of these interoperable APIs.

ECMAScript 6 Features – New language features from the latest ES6 “Harmony” draft specification:

Classes – syntax for declaring classes in ES6.

Promises – allows easier and cleaner asynchronous coding. Adds the Promise constructor, along with the 'all' and 'race' utility methods to the language itself.

Iterators – enables iteration over iterable objects (including arrays, array-like objects, iterators and generators), invoking a custom iteration hook with statements to be executed for the value of each distinct property.

Arrow Function – the arrow (=>) provides a shorthand for the function keyword with lexical 'this' binding.

Math, Number, Object, String Built-ins – dozens of new utility functions and properties for manipulating and inspecting data.

Object Literal Enhancements – adds computed properties, concise method definitions, and short-hand for properties whose value is initialized to a same-named variable.

Spread – the spread operator expands iterable expressions into individual arguments. For example, a.b(…array) is roughly the same as a.b.apply(a, array).

Template Strings – string literals that allow for expressions to be evaluated and concatenated with the string literal.

Symbols – allows properties to be added to existing objects without the possibility of interference with the existing properties, unintended visibility, or with other uncoordinated additions by any other code.

Proxies – enables JavaScript programmers to implement objects with new kinds of custom behavior.

Weak Set – a set of objects such that those objects will be collected if they are not referenced anywhere else.

# Experimental Features

Also in this release is the introduction of a new experimental features dashboard, accessed by browsing to about:flags. Here you’ll find new platform experiments that you can enable to try out the very bleeding edge of what we’re working on. Future experiments may include new standards we’re working on, interoperability fixes we’re trying out, new performance or security architectures, and more.

Given the sheer volume of changes in Edge mode, we’re going to progressively roll out the new mode by choosing a random set of Windows Insiders to get Edge while the rest remain in 11 document mode. Our data science and quality engineering teams will leverage user feedback and anonymous telemetry to guide the roll out while we make tweaks to the platform in future preview builds accordingly.

If you’re a developer coding against new features or testing for compatibility, you can head over to about:flags and choose Edge mode explicitly by setting “Enable Experimental Web Platform Features” to “Enabled” (“Automatic” restores you to the default roll out and “Disabled” lets you compare with 11 mode).

At any time, developers can identify the mode a page is in via F12 tools. Note that dynamically switching between Edge and other document modes from F12 isn’t yet supported (we told you these experiments may bite!). For now, use about:flags for switching when developing and testing.

# Giving Feedback

We’re sharing our changes earlier in the process than ever so we can collect your feedback to help shape the product. Last month, we introduced the IE Platform Suggestion Box on UserVoice where developers can suggest and vote on improvements to the platform. In this release, we’re adding a feedback tool right in the top-level UI. Just click the smiley face icon to “send a frown” such as reporting a problem on a site. If the page is running in Edge mode, you can also try reloading in the “compatibility mode” (IE11 behavior). As always, you can also report issues through Connect or the Windows Feedback app in the Windows 10 Tech Preview.

We’re excited to share with you an early look at what we’ve been working on. Join our engineering team on Twitter at 11am PST Friday November 14 where we'll be answering your #AskIE questions, and follow along with some of the other work we’re planning at status.modern.IE.

Jacob Rossi (@jacobrossi) - Senior Program Manager, Internet Explorer

Update 11/12/2014 : Added ES6 Proxies and WeakSet to the list of features in this preview build, removed RegExp built-ins (still in development)

## Minutes Telecon 2014-10-22

Source: CSS WG Blog • Dael Jackson • 23 October 2014 03:02 AM

- Resolved: Animation properties don’t apply inside `@keyframe` rules except the animation timing function (where we have explainer text already)
- Resolved: Keywords are invalid `@keyframes` names and will throw an error when set through the OM
- Resolved: `findRule/deleteRule` return/delete the last rule with the specified key.
- sylvaing requested input/assistance in turning the Animations resolution from Sophia regarding how the animating values are computed when they depend on the value of another property into actual prose in the spec.
- There was disagreement between the authors of Text about the purpose and effectiveness of an author poll to try and determine sentiments from Korean speakers about the spacing solution developed at the Sophia F2F. In the end, there was wide support for contacting companies to see what issues they have encountered and an e-mail will be written to poll individuals in an attempt to get more responses. If there is no significant response or no valuable data, the group will defer to their Sophia decision.
- Once the spacing issue and a few others are resolved, Text will be ready for a LC publication, so people were asked to submit any issues they may have soon so they can be addressed.
- If they haven’t already, TPAC participants were asked to add their information to the CSS wiki. Also, another call was also put out for additional topics for discussion to be added to the wiki.
- Flexbox‘s LC period will end just before TPAC, so everyone was urged to review it, especially for compat feedback on the `flex-basis: auto/main-size` issue.

Full Minutes

## Opera published an interview with Håkon Wium Lie to mark the…

Source: W3C's Cascading Style Sheets home page • 22 October 2014 12:00 AM

22 Oct 2014 Opera published an interview with Håkon Wium Lie to mark the 20th anniversary (10 Oct) of the first public message mentioning “Cascading [HTML] Style Sheets.” (For more history, see: chapter 2 of Cascading Style Sheets, designing for the Web; a list of alternative style sheet proposals; and Håkon's PhD thesis.)

## Notes on Tibetan script

Source: ishida blog » css • r12a • 18 October 2014 05:48 AM

See the Tibetan Script Notes

Last March I pulled together some notes about the Tibetan script overall, and detailed notes about Unicode characters used in Tibetan.

I am writing these pages as I explore the Tibetan script as used for the Tibetan language. They may be updated from time to time and should not be considered authoritative. Basically I am mostly simplifying, combining, streamlining and arranging the text from the sources listed at the bottom of the page.

The first half of the script notes page describes how Unicode characters are used to write Tibetan. The second half looks at text layout in Tibetan (eg. line-breaking, justification, emphasis, punctuation, etc.)

The character notes page lists all the characters in the Unicode Tibetan block, and provides specific usage notes for many of them per their use for writing the Tibetan language.

See the Tibetan Character Notes

Tibetan is an abugida, ie. consonants carry an inherent vowel sound that is overridden using vowel signs. Text runs from left to right.

There are various different Tibetan scripts, of two basic types: དབུ་ཙན་ dbu-can, pronounced /uchen/ (with a head), and དབུ་མེད་ dbu-med, pronounced /ume/ (headless). This page concentrates on the former. Pronunciations are based on the central, Lhasa dialect.

The pronunciation of Tibetan words is typically much simpler than the orthography, which involves patterns of consonants. These reduce ambiguity and can affect pronunciation and tone. In the notes I try to explain how that works, in an approachable way (though it’s still a little complicated, at first).

Traditional Tibetan text was written on pechas (དཔེ་ཆ་ dpe-cha), loose-leaf sheets. Some of the characters used and formatting approaches are different in books and pechas.

For similar notes on other scripts, see my docs list.

## Minutes Sophia-Antipolis F2F Part IV 2014-09-09: Initial Letters, Animations

Source: CSS WG Blog • Dael Jackson • 15 October 2014 11:45 PM

### Initial Letters

- Resolved: Publish FPWD of CSS-inline with `initial-letter` section intact, and 2 prior sections pointing to appropriate parts of 2.1, with note that they will be updated.
- Resolved: `initial-letter` depends on line grid spacing or (if none) line-height of containing block. Does not depend on content of the lines.
- Resolved: `initial-letter` does not have longhands
- Resolved: Order of values is size first, drop second (as decided in previous F2F)
- Resolved: Size is a `number`. Alignment point is determined by script.
- There were some unresolved concerns about the best approach to handle initial letters with combining marks.
- Discussed cases where the alignment subject should be the glyph bounds vs. the margin-box bounds.
- Ruby’s interaction with `initial-letter` was also an area of concern.

Full Minutes || Spec Referenced

### Animations

- sgalineau outlined the remaining issue about how to resolve properties that depend on a value from a different property. The options for the behavior were outlined in an e-mail from dbaron available here
  - All the options were evaluated and the group originally leaned toward option D.
  - There was a lot of testing done to determine which behavior browsers currently use and there was no clear winner.
  - Eventually it was concluded that the optimal behavior was option G (Base values are interpolated values from all animations on this element and on all elements on which its computed values depend) with the beta variant (Base values are dynamic (i.e., if the expected value at a future time changes the running animation changes to match)).
- Resolved: Use Option G Beta
- Resolved: Animations and Transitions both really do have the behavior that non-interpolable properties switch at 50% of the timing function.
- TabAtkins will write an e-mail summarizing the proposal phasing out current requirements for snapshotting some events.
- Resolved: When `animation-duration:0s`, start/end events fire with 0 `elapsedTime`
- Resolved: Iteration events only fire for iterations that are actually run e.g. those not ‘absorbed’ by a negative delay.
- Pause events were discussed and had a lot of interest, but were deferred to level 2 in order not to delay Animations level 1.

Full Minutes || Spec Referenced

## Minutes Sophia-Antipolis F2F Part III 2014-09-09: Motion Path as FXTF, Future F2F Meetings, GCPM3/GCPM4

Source: CSS WG Blog • Dael Jackson • 15 October 2014 11:42 PM

### Motion Path as FXTF

- Resolved: Joint publish CSS motion paths with SVG WG

Full Minutes || Spec Referenced

### Future F2F Meetings

- There will be a join meeting with SVG on the Thursday morning of TPAC.
- Next F2F is in Australia hosted by Google and overlapping with SVG, tentatively the first week of February.
- Resolved: Monday-Tue SVG, Weds FX, Thu-Fri CSS
- Next is 18-22 May, NYC, host Bloomberg, dates pending research on other conferences around that time
- Google will host sometime in late summer with a location somewhere in Europe (London, Paris, and Zurich were all mentioned)

Full Minutes

### GCPM3/GCPM4

- There was a wide-ranging conversation about moving GCPM3 forward, how to better spec items that are currently mostly magic, and what pieces would be better served in a different spec entirely. Proposed:
  - Named strings, leaders, target-counters, and bookmarks to CSS Generated Content Level 3.
  - Page selectors and page groups to CSS Paged Media Level 3.
  - Move complex running headers (beyond stringset) to a Regions-based solution.
  - Turn Footnotes section into a giant Issue.
- For footnotes, there was general consensus that the current model relied too much on magic and that functioning footnotes are important to achieve.
- There was some discussion of what a page is and reviving work on paginated views. Also on the impact of pagination on various APIs.
- Later, dauwhe presented some proposals for GCPM4:
  - Extensions to Regions in order to handle running heads and footers and footnotes, particularly for handling copying vs. continuation of a flow, and for extracting from the current page.
  - Using page templates to represent the footnote area and the 16 margin box slots from Paged Media
  - General agreement on the approach, though it was felt the proposals needed more revision.
- dauwhe offered to edit all relevant specs

Full Minutes || Specs Referenced: GCPM3 and GCPM4

## Minutes Sophia-Antipolis F2F Part V 2014-09-10: CSS UI, Next F2F Dates, New W3C Process, Flexbox

Source: CSS WG Blog • Dael Jackson • 15 October 2014 11:35 PM

### CSS UI

- andreyr brought up the request for a `last-visible-line-in-block` ellipsis. More discussion is needed to create a concrete understanding of all the related problems and come up with a solution.
- Resolved: The number of lines of context visible as the caret is moved towards the edge of a scrollable area is a quality of implementation issue
- No change for `:focusWithin`, can use `:has(:focus)` instead.

Full Minutes || Spec Referenced

### Positioning

- andreyr will put together a proposal to update positioning to better handle fixed & sticky positioning inside `overflow:scroll` boxes

Full Minutes

### Next F2F Dates

- Due to flight costs, proposed dates are the week of 9 February with CSS meeting Monday and Tuesday and meeting with SVG on Wednesday.

Full Minutes

### New W3C Process

- Resolved: Convert all specs to the new W3C Process at the next publication at which such a conversion is allowed.
- plh presented new tooling for publishing WDs. W3C plans to allow up to one snapshot per day, and editors will be able to publish without W3C staff intervention. There was some discussion of how much oversight the CSSWG should have on publishing, whether editorial or substantive changes could go directly to /TR, etc.

Full Minutes

### Flexbox

- Resolved: Accept current solution for issue 20 (keyword for auto flex basis), with issue for waiting on compatibility feedback, and explaining alternate solution.
- Resolved: Accept proposed resolution for issue 21
- Resolved: Ignore the potential effects of an intrinsic min/max size when resolving percentages (issue 27)
- Resolved: Accept issue 39
- Resolved: Rejected due to misunderstanding of the spec for issue 22
- Resolved: Rejected due to out of scope on issue 23
- Resolved: We like `flex-wrap: balance` idea but are deferring it (issue 25)
- Resolved: No-change on issue 35
- Resolved: Republish as LC when the edits are done

Full Minutes || Spec Referenced

## Minutes Sophia-Antipolis F2F Part VI 2014-09-10: CSS3 Text, Survey of All the Specs

Source: CSS WG Blog • Dael Jackson • 15 October 2014 11:32 PM

### CSS3 Text

- The proposed solutions to creating an algorithm for spacing of un-language-tagged content were discussed and limited to two options:
  - A. Treating Hangul as non-expandable and Han/Kana as expandable
  - B. Use fantasai’s Universal Compromise approach
  - The spec authors will put out a poll to determine which of the remaining options is most livable.
- In conjunction with Internationalization WG, the group will create a wiki or Note of best practices for language specific justification and link that in the spec. CSS Text will not be responsible for detailing justification best practices (only the limits within which implementations must behave).
- Resolved: Remove `distribute` special-case logic from `text-align-last`
- Resolved: Add `inter-character`, same meaning as `distribute`

Full Minutes || Spec Referenced

### Survey of All the Specs

- The group took some time to go over every spec both for good housekeeping and to work toward meeting the new heartbeat requirement from W3C (Details here).
- CSS3 Linebox has an outstanding resolution to publish an update
- CSS Generated and Replaced Content is getting stripped down and will pull in GCPM generated content bits before being republished by fantasai, dauwhe, and maybe TabAtkins
- CSS TV Profile 1.0 will be made into a note
- CSS Presentation Levels will be made into a note
- CSS Reader Media Type will become a rescinded note
- CSS Hyperlink Presentation Module will become a rescinded note
- CSS Basic Box Module will become be republished with an obnoxious note of instability pointing to CSS2.1 as the normative spec.
- CSS Grid Positioning is an erroneous link as it was superseded by Grid Layout
- BECSS will become a rescinded note
- CSS Marquee will become a rescinded note
- CSS Mobile Profile 2.0 will be made into a note
- CSS Multi-column Layout is still alive and well, it just needs more work and tests
- CSS Device Adaptation is on hold waiting until we hear back from others not at the meeting
- Resolved: CSS Template Module becomes actively-developed Note
- Resolved: Add TabAtkins as editor of css3-ui
- CSS Positioned Layout will wait until we hear from ArronEi
- CSS Speech is fine, but just waiting for a better test suite. People are implementing it, though.
- CSS Image Values Level 3 will be edited and republished by fantasai and TabAtkins
- Resolved: CSSWG thinks Fullscreen should move to a Note referencing the WHATWG spec
- CSS Images Level 4 will stay as a WD, no republication until something to republish
- CSS Sizing Module is being actively edited
- CSS Animations will be republished in the next three months by sylvaing
- Resolved: add dauwhe as editor to Paged Media 3
- CSS Conditional Rules is just in need of a few more tests to fill in the gaps
- CSS Overflow Module is active, just doesn’t need publishing yet
- Selectors Level 4 is active, just doesn’t need publishing yet
- Box Alignment Module L3 is active, just doesn’t need publishing yet
- CSS Exclusions is active, just doesn’t need publishing yet
- CSS Values and Units is almost ready, but needs some word-smithing
- Text Decoration 3 is active, just doesn’t need publishing yet
- DOMMATRIX will become a rescinded note
- CSS Fonts is active, just doesn’t need publishing yet
- CSS Scoping needs to incorporate outstanding edits, be republished

Full Minutes

## Opera 25 released

Source: Dev.Opera • Mathias Bynens • 14 October 2014 10:00 PM

Opera 25 (based on Chromium 38) for Mac and Windows is out! To find out what’s new for consumers, see our Desktop Team blog. Here’s what it means for web developers.

## The `<picture>` HTML element

Yes, `<picture>` is now available in Opera (and Chrome) by default! This new HTML element can be wrapped around any good ol’ `<img>` element to enable art direction, different images types, high-DPI images, changing image sizes, and more. We recommend you read Yoav Weiss’s introduction to native responsive images, or look at Andreas Bovens’s list of responsive image use cases with documented code examples.

## Screen Orientation API

The Screen Orientation API provides the ability to read the user’s screen orientation type and angle, to be informed when the screen orientation state changes, and be able to lock the screen orientation to a specific state. This functionality is available under the `window.screen.orientation` object.

## Notifications API

Opera now supports the Notifications API, available under the `window.Notification` object. Even though the Chromium project has supported this feature for a long time, we wanted to get the UX right before shipping this in Opera.

The way Chromium deals with notifications makes it seem non-native to the operating system on most platforms. We wanted to make it feel native on all our supported platforms, and we worked on it to make it happen. As a result, Opera’s web notifications look and behave like native notifications. We believe this is a much better experience for users.

Opera add-ons can make use of this functionality through the `chrome.notifications` API. Note that because of our native OS integration, only simple notifications (similar to non-rich web notifications) are supported in Opera; rich `chrome.notifications` are not.

## `File` constructor

The global `File` constructor can be used to programmatically generate file objects on the client side:

    var html = '<!DOCTYPE html><title>Test</title><h1>Hello world!</h1>';
    var file = new File([html], 'test.html', {
            'type': 'text/html'
    });

Here’s a demo that generates files on the client side and offers download links for them.

## `TextEncoder`/`TextDecoder` API

The WHATWG Encoding Living Standard defines `TextEncoder` and `TextDecoder` interfaces that make it easy to translate between raw bytes and native JavaScript strings, regardless of which of the many standard encodings you need to work with.

    // Encode a string using UTF-8:
    var encoder = new TextEncoder('utf-8');
    var encoded = utf8encoder.encode('foo𝌆bar');
    // → an ArrayBuffer containing the bytes for this string as per UTF-8
    // → [0x66, 0x6F, 0x6F, 0xF0, 0x9D, 0x8C, 0x86, 0x62, 0x61, 0x72]

    // Decode the UTF-8 bytes back into a string:
    var decoder = new TextDecoder('utf-8');
    decoder.decode(encoded);
    // → 'foo𝌆bar'

For more information on this feature, see Easier `ArrayBuffer` ↔ string conversion with the Encoding API.

## ES6 iterators and `for-of`

ECMAScript 6 introduces a new `for-of` construct, which iterates over iterable objects like arrays, array-like objects, strings, iterators, generators, maps, and sets.

    var iterable = ['a', 'b', 'c'];
    for (var item of iterable) {
            console.log(item);
    }

My favorite example of this is iterating over all characters in a string. With `for-of`, supplementary Unicode symbols are automatically treated as a single unit, just like you’d expect. In ES5 you had to write a lot of boilerplate code to make that happen.

    var string = 'foo𝌆bar';
    for (var item of string) {
            console.log(item);
    }
    // → 'f', 'o', 'o', '𝌆', 'b', 'a', 'r'

## ES6 `Map`

A `Map` object is a simple key/value map. Unlike regular objects in JavaScript, which store their keys as strings, `Map`s accept any value — both primitive values and objects — as keys and values. Here’s a simple example:

    var map = new Map();
    var person = { 'name': 'John Smith' };
    // Store a value in the Map that is tied to this `person` object.
    map.set(person, 'foo');
    // Later, we can check if the Map contains a matching value:
    map.has(person); // true
    // That value can be retrieved based on the `person` object:
    map.get(person); // 'foo'

    // Iterate over the items in the Map using `for-of`.
    for (var item of map) {
            console.log(
                    item[0], // key
                    item[1]  // value
            );
    }

## ES6 `Set`

A `Set` object is a collection of unique values. `Set`s accept values of any type — both primitive values and objects.

    var set = new Set();
    var person = { 'name': 'John Smith' };
    // Store some values in the Set.
    set.add(person);
    set.add(42);
    set.add(42); // Note: duplicates are ignored.
    // Later, we can check if the Set contains a value:
    set.has(42); // true
    set.has(person); // true

    // Iterate over the items in the Set using `for-of`.
    for (var item of set) {
            console.log(item);
    }

## ES6 `Symbol`s

A `Symbol` is a unique and immutable data type that allows properties to be added to existing objects without the possibility of interference with the existing properties, unintended visibility, or with other uncoordinated additions by any other code.

Here’s an example:

    (function() {
            var symbol = Symbol();
            var object = {};
            object[symbol] = 42;
            console.log(object[symbol]); // 42
    }());

Due to the use of Symbols, it’s impossible to extract the private value `42` from the object unless you have access to the `symbol` reference variable.

`Object.getOwnPropertySymbols` can be used to programmatically list the Symbol properties on a given object. Here’s an example that demonstrates that `Array.prototype` makes use of Symbols:

    Object.getOwnPropertySymbols(Array.prototype);
    // → [Symbol(Symbol.unscopables), Symbol(Symbol.iterator)]

## ES6 unscopables

Unscopables allow properties to be hidden from `with` statement lookup rules. This makes it possible to add new properties to existing host objects, both in JavaScript and in the DOM, without breaking backwards compatibility.

## ES6 math functions

ES6 defines lots of new mathematics-related functions, which we’re happy to support in this new release:

- `Math.acosh`
- `Math.asinh`
- `Math.atanh`
- `Math.cbrt`
- `Math.clz32`
- `Math.cosh`
- `Math.expm1`
- `Math.fround`
- `Math.hypot`
- `Math.log10`
- `Math.log1p`
- `Math.log2`
- `Math.sign`
- `Math.sinh`
- `Math.tanh`
- `Math.trunc`

## Various SVG improvements

SVG `<text>` elements got a nice performance boost.

Also, SVG `<feBlend>` elements now support the following additional blend modes (for use in `<feBlend mode="…">`):

- `color`
- `color-burn`
- `color-dodge`
- `difference`
- `exclusion`
- `hard-light`
- `hue`
- `luminosity`
- `overlay`
- `saturation`
- `soft-light`

## Removal of support for SVG web fonts

Only Presto (i.e. Opera ≤ 12) and WebKit-based browsers ever implemented support for SVG web fonts in `@font-face`. Nowadays WOFF and WOFF2 are a much better choice.

As of this release, SVG web fonts are no longer supported, except on Windows systems which use GDI-based font rendering instead of DirectWrite-based font rendering (i.e. Windows < 7). Note that although the feature still works on those systems for now, it is considered deprecated, and support will eventually be removed completely.

## 64-bit release on OS X

Opera for Mac is now a 64-bit browser. This offers many benefits for speed, stability and security.

The flip side of this change is that the 32-bit Silverlight plug-in for Mac no longer works, which obviously affects Silverlight-based applications, such as Netflix. At the moment, a 64-bit version of the Silverlight plugin is not available.

Other than Silverlight, Netflix also supports video using Encrypted Media Extensions (EME). However, given that Opera doesn’t support EME, this option unfortunately does not work either.

## What’s next?

If you’re interested in experimenting with features that are in the pipeline for future versions of Opera, we recommend following our Opera Developer stream.

## Application Foundations for the Open Web Platform

Source: W3C Blog • Jeff Jaffe • 14 October 2014 05:45 PM

Bringing HTML5 to the status of W3C Recommendation (in October 2014) is a defining moment in the development of the Open Web Platform (OWP), a set of technologies for developing distributed applications with the greatest interoperability in history. This year is also the 25th anniversary of the Web and 20th anniversary of W3C, making this an even more meaningful time to engage with the community about the Next Big Thing for the Web Platform.

My starting point for this discussion is that, now that HTML5 is done, W3C should focus on strengthening the parts of the Open Web Platform that developers most urgently need for success. I call this push for developers “Application Foundations.”

This is a new formulation, shaped in part by discussion at the September Extensible Web Summit in Berlin, as well as discussions within the W3C staff. I am planning further discussion at W3C’s TPAC 2014 meeting at the end of the month, and I welcome your feedback to this post and in the months ahead.

While this formulation is new, most of the work is not new. Rather, this represents a new way of looking at the considerable work that is already in the Web community, and placing some structure around the considerable work in front of us.

## The Focus on Developers

The OWP is widely deployed, improving in function every day, and transforming industry after industry. According to a survey earlier this year, 42% of developers are using HTML5, CSS, and JavaScript when building applications. The promise of the Open Web Platform is to lower the cost of developing powerful applications to reach the most people, on any device.

As popular as the OWP is, it is still too challenging for developers to create some types of Web applications. Lack of broad interoperability for some features complicates development. Lack of standard features in the platform drives developers to create hybrid applications, implying a larger mix of tools, libraries, and interoperability issues. There is more work to meet growing expectations around privacy, security, and accessibility.

There are many ways to focus on developers. Many W3C activities outside of standards development are geared toward enabling developers, including tools (validator), documentation (Web Platform Docs), training (W3DevCampus, W3Conf), participation (Community Groups, draft Webizen program).

The question I want to get at in this post, however, relates to our open standards agenda: are we building the platform that developers need? How can we find out?

That is where the Application Foundations come in. They give us a way to think about the Open Web Platform that will make it easier for the W3C community to converge on the top priorities for developers.

## What are Application Foundations?

Platforms mature predictably in the following way: at a given time, some capabilities are core and “applications” rely on the core. Invariably, there comes a time when certain features are so pervasively used as services by other applications, the “next generation” of the platform must subsume some of those features (via libraries, platform services, daemons, etc.).

Operating systems provide a familiar example. Typically, an operating system kernel provides the key lower layer functions that a computer needs for its programs (aka applications): program execution, memory management, support for devices, etc. In early versions of many operating systems, there are also higher layer functions (such as networking, security, GUIs, etc.). Often these functions have some manifestation in the kernel, but also some manifestation in applications. Over time, given experience with the higher layer functions, people recognize that some must mature into major subsystems (aka foundations) that are above the kernel, leveraged by many applications. Modular design of these subsystems allows experts in different areas (security, communications protocols, and so on) to deliver solutions that will best serve all the other parts of the platform.

We see this pattern with the Open Web Platform as well. There was a time that video would have been viewed as an application of the Web, but in HTML5, video has unquestionably been absorbed into the core infrastructure (e.g., via the HTML <video> element). An apt metaphor is to call the programmable Open Web Platform of today the first generation operating system of the Web. In the past couple of years, important subsystems have already started to emerge, and in this post I propose a taxonomy of eight Application Foundations to focus our discussion on the next generation:

- Security and Privacy
- Core Web Design and Development
- Device Interaction
- Application Lifecycle
- Media and Real-Time Communications
- Performance and Tuning
- Usability and Accessibility
- Services

Each Foundation represents collection of services and capabilities that should be available for all applications. For example, the Security and Privacy Foundation includes capabilities such as crypto, multi-factor authentication, and resource integrity.

We expect each Foundation to evolve independently, driven by experts in that topic. We also know that there will be interconnections, such as Security implications of Device Interactions, or Accessibility considerations of streaming Media.

Below I will begin to enumerate the capabilities we have associated with each Foundation, both long-standing and new or planned work that will substantially advance the capability of the OWP.

In our internal discussions there was quick consensus on the usefulness of an Application Foundations paradigm. There was also passionate debate about taxonomy itself. Did we come up with one that will speak to developers? Did we neglect some important piece of functionality? Should this or that second-level item be a top-level category or vice versa? To help structure the broader debate to come, I’d like to provide some background for the choices proposed here.

## Principles for Thinking about these Foundations

Bearing in mind that we are looking for a best fit to structure discussion, not a perfect dissection, here are some key principles for thinking about these Foundations:

- Although this exercise is motivated by the desire to meet developer needs, we sought labels that would be meaningful for end users as well. We looked for terms we thought would speak to those audiences about both desirable qualities of the platform and current pain points that we need to address.
- These topics were derived by looking at W3C’s current priorities and discussions about upcoming work. W3C’s agenda is in constant motion, and this taxonomy will only be useful so long as it aligns with priorities. But the river bed shapes the river and vice versa.
- Because the focus is on current developer pain points, we do not attempt to fit all of W3C’s work into the eight categories. We are committed to our entire agenda, but this particular exercise is limited in scope. For the same reason, we do not attempt to represent all completed work in this categorization. While we might want to see how broadly we could apply this taxonomy, our priority project is to enable developers today and tomorrow.
- Because the focus is on W3C’s agenda, these Foundations do not attempt to represent all things one we think of as being important to the Web, HTTP and JavaScript being two notable examples. Moreover, many key IETF standards (HTTP, URL, IPv6) might more properly be defined as part of the kernel – rather than a higher level Foundation.

## Putting the Foundations to Use

Although this framework is meant initially only as a communications vehicle —a way of describing the substantial work we have to do to enhance the OWP— we may find other uses later. Once fleshed out and road-tested, for example, the W3C Technical Architecture Group (TAG) might use this model for architectural discussions about the Open Web Platform.

Ultimately, with such a framework, it becomes easier to identify what is missing from the platform, because we will think more cohesively about its key components. And where there are similar capabilities (e.g. different functions that show up in the same Foundation), it will make it easier to identify where synergies can simplify or improve the platform.

By definition, Foundations are common subsystems useful not only for “horizontal applications”, but also for a variety of industries such as digital publishing, automotive, or entertainment. In a separate exercise we plan to work with those industries to create a view of the Foundations specific to what they need from the Open Web Platform.

So let’s get started. In each paragraph below, I outline why we think this area deserves to be a Foundation. I list some absolutely critical problems the community is currently addressing. This will help motivate why each Foundation was chosen, and the technology development required to give rise to the next generation Web.

## Application Foundations

### Security and Privacy

The Web is an indispensable infrastructure for sharing and for commerce. As we have created the OWP, we have become increasingly sensitive to making this a secure infrastructure. See, for example, our 2013 “Montevideo” statement calling for greater Internet security.

The vulnerabilities have become increasingly prominent. They vary in range and style. There are vulnerabilities that result from criminal exploitation of security holes for financial gain. There are numerous situations where information and communications that was intended to be private has found its way into unauthorized hands.

From a pure technical point of view, there is a tremendous amount of security research and there is knowledge on how to make an infrastructure secure. Many security advances are available in devices that are connected to the Web today. Nonetheless, security exposures abound: because it is too difficult for applications to leverage the security that is available; because new security techniques are not yet in place; and because users are not encouraged to rely on strong security.

We do not expect all developers to be security experts, so we must make it easier to use the security mechanisms of operating systems. The Crypto API provides access to some of those services from within JavaScript, and is already being deployed. This trend will be extended as platforms add stronger security such as multi-factor authentication, biometrics, smartcards, all discussed at our September Workshop on Authentication, Hardware Tokens and Beyond. We also need to add a more comprehensive Identity Management system which discourages weak passwords.

To strengthen this Foundation, we are working closely with a number of organizations, including the IETF, FIDO Alliance, and Smartcard Alliance.

### Core Web Design and Development

Developers use many widely deployed front end technologies for structure, style, layout, animations, graphics, interactivity, and typography of pages and apps. HTML5 brought native support for audio and video, canvas, and more. Dozens of CSS modules are used for advanced layout, transformations, transitions, filters, writing modes, and more. SVG is now widely supported for scalable graphics and animations, and WOFF is beautifying the Web and making it easier to read.

Still, the work is not complete. Much new work will be driven by the adoption of the Web on a broader set of devices, including mobile phones, tablets and e-book readers, televisions, and automobiles. The responsive design paradigm helps us think about how we need to enhance HTML, CSS, and other APIs to enable presentation across this wider set of devices.

One exciting direction for this Foundation is Web Components, which will make it easier for developers to carry out common tasks with reusable templates and code modules, all leveraging standards under the hood.

Another area of anticipated of work will be driven by a more complete integration of digital publishing into the Web. In the past, advanced styling and layout for magazines has remained an area where special purpose systems were required. In this Foundation, we will ensure that we have the primitives for advanced styling and layout so that all publishing can be done interoperably on all Web devices.

Our Test the Web Forward activity, though relevant across the Foundations, has been particularly influential for Core Web Design and Development, and we invite the community to contribute to that active testing effort.

### Device interaction

Closely related to the Core Foundation is the Device Interaction Foundation, which describes the ways that devices are used to control or provide data to applications. New Web APIs are proposed weekly to give access to all of the features offered by supporting devices. For mobile phones, APIs exist or are in development for access to camera, microphone, orientation, GPS, vibration, ambient light, pointer lock, screen orientation, battery status, touch events, bluetooth, NFC, and more.

The next generation of Web attached devices will introduce new challenges. For instance, the Automotive and Web Platform Business Group is developing APIs to access information about vehicle speed, throttle position, interior lights, horn, and other car data that could help improve driving safety and convenience. We anticipate some of that work will advance to the standards track. In general, wearables, personal medical equipment devices, home energy management devices, and the Internet of Things will drive developer demand for data in applications, and for Web abstractions to simplify what will be new complexity in underlying networks. To achieve that simplicity for developers, the TAG, Device APIs Working Group, Web Apps Working Group, and Systems Applications Working Group all have a role to play in capturing good practices for API design.

### Application Lifecycle

The proliferation of environments —both mobile and non-mobile— in which an application may run has created new challenges for developers to satisfy user expectations. People expect their apps to be useful even when there is no network (“offline”), to do the right thing when the network returns (“sync”), to take into account location-specific information (“geofencing”), to be easy to launch on their device (“manifest”), to respond to notifications (from the local device or remote server), and so on. The Application Lifecycle Foundation deals with the range of context changes that may affect an application. For example, developers have made clear that that AppCache fails to meet important offline use cases. so we must come up with a superior solution.

The emerging approach (“Workers”) for addressing many these lifecycle requirements involves spawning important tasks as asynchronous processes outside of an application. For instance, a Worker can be used to manage a cache and update it according to network availability or receive server-sent notifications, even when an application is not actively running. Enhancing these Foundations these will enable developers to create superior user experiences.

### Media and Real-Time Communications

A number of communications protocols and related APIs continue to serve developers well, from HTTP to XMLHttpRequest to Web Sockets. But to meet the growing demand for real-time communications and streaming media, we must add new capabilities, the focus of this Foundation.

The promise of WebRTC is to make every single connected device with a Web browser a potential communications end point. This turns the browser into a one-stop solution for voice, video, chat, and screen sharing. A sample use case driving interest in real-time in the browser is enabling “click-to-call” solutions for improved customer service. WebRTC has the potential to bring augmented reality to the Web and create a brand new class of user experiences – an exciting direction for this Foundation.

For audio and video, developers will have a variety of tools to manipulate media streams, edit audio input, and send output to multiple screens (“second screen”). This last capability is of particular interest to the entertainment industry. For example, in the US, a majority of people have a second device nearby while watching television, allowing for new interactive experiences such as social interactions or online commerce.

### Performance and Tuning

Open Web Platform functionality has moved steadily to the client side, which creates a variety of new challenges related to security, application lifecycle management, but especially performance. JavaScript engines have improved dramatically in the past few years. But for high-end games, media streams, and even some simple interactions like scrolling, we still have much to do so that developers can monitor application performance and code in ways that make the best use of resources. This is the focus of our Performance and Tuning Foundation.

Today we are working on APIs for performance profiling such as navigation timing and resource hints. In various discussions and Workshops, people have asked for a number of enhancements: for understanding load times, enabling automatic collection of performance data, providing hints to the server for content adaptation, improving performance diagnostics, managing memory and garbage collection, preserving frame rates, using the network efficiently, and much more.

The responsive design paradigm mentioned in the Core Web Design and Development Foundation also plays a role in the world of performance: we can make better use of the network and processing power if we can take into account screen size and other device characteristics.

### Usability and Accessibility

The richness of the Open Web Platform has raised new challenges for some users. It is great to be able to create an app that runs on every device, but is it easy to use or klunky? It’s great to offer streaming media, but do developers have the standards to include captions to make the media accessible?

Designers have pioneered a number of approaches (responsive, mobile first), that can improve accessibility and usability, and W3C’s Web Accessibility Initiative has developed some standards (such as WCAG2 and WAI-ARIA) to enable developers to build accessible applications. But we have more work to do to make it easier to design user interfaces that scale to a wide array of devices and assistive technologies. We have confidence that designers and developers will come up with creative new ways to use standards for new contexts. For example, the vibration API used by some mobile applications might offer new ways to communicate safely with drivers through the steering wheel in some automotive apps, and could also be used to create more accessible experiences for people with certain types of disabilities.

Less than one third of current Web users speak English as their native language and that proportion will continue to decrease as the Web reaches more and more communities of limited English proficiency. If the Web is to live up to the “World Wide” portion of its name, it must support the needs of world-wide users at a basic level as they engage with content in the various languages. The W3C Internationalization Activity pursues this goal in various ways, including coordination with other organizations, creation of educational materials, coordination on the work of other W3C groups, and technical work itself on various topics.

### Services

Earlier I mentioned the pattern of widely used applications migrating “closer to the core.” While this is true for all the Foundations, it is especially clear in the Services Foundation, where today we are exploring the four most likely candidates for future inclusion.

The first is Web payments. Payments have been with us for decades, and e-commerce is thriving, predicted to reach $1.471 trillion this year, an increase of nearly 20% from last year. But usability issues, security issues, and lack of open standard APIs are slowing innovation around digital wallets and other ways to benefit payments on the Web. W3C is poised to launch a group to study the current gaps in Web technology for payments. The Payments group will recommend new work to fill those gaps, some of which will have an impact on other Foundations (e.g., Usability, Security and Privacy). Because a successful integration of payments into the Web requires extensive cooperation, the group will also liaise with other organizations in the payments industry that are using Web technology to foster alignment and interoperability on a global scale.

The second is annotations. People annotate the Web in many ways, commenting on photos or videos, when reading e-books, and when supporting social media posts. But there is no standard infrastructure for annotations. Comments are siloed in someone else’s blog system, or controlled by the publisher of an e-book. Our vision is that annotations on the Web should be more Web-like: linkable, sharable, discoverable, and decentralized. We need a standard annotation services layer.

The third is the Social Web. Consumer facing social Web services, combined with “bring your own device (BYOD)” and remote work policies in enterprise, have driven businesses to turn increasingly to social applications as a way to achieve scalable information integration. Businesses are now looking for open standards for status updates (e.g., Activity Streams) and other social data. These same standards will give users greater control over their own data and thus create new opportunities in the Security and Privacy Foundation as well.

The fourth is the Web of Data. The Semantic Web and Linked Data Platform already provide enhanced capabilities for publishing and linking data. These services have been used to enhance search engines and to address industry use cases in health care and life sciences, government, and elsewhere. But we know that more is necessary for developers to make use of the troves of data currently available. One upcoming activity will be to collect ontologies of how linked data should be organized for different applications (notably for search).

## Conclusion

Web technology continues to expand by leaps and bounds. The core capability is growing, the application to industry is growing, and we continually find new devices for web technology and new use cases. To be able to focus on this expansion we need modular design, and a principle in modular design is to be able to clearly and succinctly talk about categories of function. Hopefully this post begins a healthy discussion about the framework for the Open Web Platform going forward.

As part of that discussion will continue to develop a new Application Foundations Web page and invite feedback via our public Application Foundations wiki.

## Acknowledgments

I acknowledge extensive discussions within the W3C Team, but especially with Phil Archer, Robin Berjon, Dominique Hazaël-Massieux, Ivan Herman, Ian Jacobs, Philippe Le Hégaret, Dave Raggett, Wendy Seltzer, and Mike Smith. At the Extensible Web Summit, I received great input from Axel Rauschmayer, Benoit Marchant, and Alan Stearns.

## The CSS WG changed seven drafts into Notes, to indicate that…

Source: W3C's Cascading Style Sheets home page • 14 October 2014 12:00 AM

14 Oct 2014 The CSS WG changed seven drafts into Notes, to indicate that no further work on them is expected: CSS TV Profile 1.0, CSS Presentation Levels Module, CSS Mobile Profile 2.0, CSS Marquee Module Level 3, Behavioral Extensions to CSS, CSS3 Hyperlink Presentation Module and The CSS ‘Reader’ Media Type

## This week: CSS 20th anniversary, autowebplatform progress, TimBL’s keynote, Physical Web, etc.

Source: W3C Blog • Coralie Mercier • 10 October 2014 02:31 PM

This is the 3-10 October 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

## W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first]

- (`600`) Dev.Opera: CSS: It was twenty years ago today — an interview with Håkon Wium Lie
- (`80`) Automotive: Accelerating the Adoption of Web Technologies in the Automotive Industry
- (`35`) HTML5 wearable: Hoodie season is here. Bundle up and wear your HTML5 badge proudly! @html5 @w3c @html5guy
- (`620`) Hybrid apps: HTML5 Has A New Best Friend—And It’s Apple, Not Google
- (25) Hybrid apps: HTML5 does not have a new best friend

## Open Web & net neutrality

- The New York Times | Bits: Tim Berners-Lee, Web Creator, Defends Net Neutrality – 8 October 2014
- Scott Jenson (Google): Physical Web, an open web spec to “Walk up and use anything” – 3 October 2014
- Open Web Board: KDDI Develops Creative Platform for Firefox OS Developers – 3 October 2014

## W3C in the Press (or blogs)

22 articles since the last Digest; a selection follows. You may read all articles in our Press Clippings page.

- Gizmodo (10 October), CSS Is 20 Years Old Today
- CNET (9 October), The tired GIF gets a modern-day makeover
- Motherboard (8 October), Tim Berners-Lee Wants a World Wide Web Where Our Data Works for Us
- The Guardian | Technology (8 October), Sir Tim Berners-Lee speaks out on data ownership
- Intel IoT Blog (6 October), Accelerating the Adoption of Web Technologies in the Automotive Industry

## CSS: It was twenty years ago today — an interview with Håkon Wium Lie

Source: Dev.Opera • Bruce Lawson • 09 October 2014 10:00 PM

Opera’s CTO Håkon Wium Lie

Twenty years ago today, Opera’s CTO Håkon Wium Lie published Cascading HTML style sheets – a proposal. If Paul McCartney were a web developer, and writing ‘Sergeant Pepper’s Lonely Hearts Club Band’ today, he would almost certainly write:

> It was twenty years ago today
> That Håkon wrote a doc to say
> That if the Web’s gonna last a while
> Then we need a way to define style.
> So may I introduce to you
> a way to add visual treats:
> It’s Sergeant Håkon’s Cascading Style Sheets!

However, when we went round to Paul’s house to ask him to sing this for us, he declined and set his guard dogs, `FontTag` and `Bgcolor`, on us. So, instead, to mark this occasion, Bruce sat down with Håkon to ask a few questions about the past, present and future of CSS.

CSS was conceived twenty years ago. Are you happy about how your baby, child and teenager has turned out?

Yes, I’m very happy with CSS. CSS is a cornerstone web specification and web pages are more beautiful as a result of CSS being there. The fact that HTML is still alive and well is also a testimonial to the success of CSS. As with all youngsters, however, there is room for improvement.

You’ve been quoted as saying you proposed CSS “to save HTML”. Please explain.

HTML would have been very different if CSS had not appeared. Authors who came to the web from a desktop publishing background were baffled by the lack of `<color>` and `<font>` tags. Including myself. In my first real publication on the web, I resorted to making images with text in it — you can see it in this publication from 1993. If this development had continued, the web would have become a giant fax machine where pictures of text would be passed along. This would have been terrible for blind users and search engines alike. CSS was proposed to prevent this development by giving authors a way to express their designs without adding new HTML tags.

In the first proposal, there was a percentage of influence specifier, e.g. `h1.font.size = 24pt 100%`, described as follows:

> The percentage at the end of the line indicates what degree of influence that is requested (here 100%). If this is the initial style sheet (i.e. the one under user control), this request can be fulfilled, i.e. all headline elements will be rendered using Helvetica. If the statement comes in a later style sheet, any unclaimed influence is granted.

Why was this dropped?

The mechanism you refer to was there to try combine the needs and preferences of both authors and readers. It was inspired by an idea from the MIT Media Lab: TVs in the future would not have controls for brightness and color, but for sex and violence, or left-wing and right-wing, perhaps. The CSS proposal was to have sliding scale where the author was fully in charge in one end of the scale, and the user was fully in charge in the other end of the scale. In between, the browser would try to mix requests to make everyone happy. This works well for certain properties (like `font-size`) but is hard to do for others (like `font-family`). In his first response to the CSS proposal, Bert criticized this idea:

> The idea that two designs can be averaged to come up with an intermediate style seems utterly wrong to me. What happens when my blue-on-yellow style is combined with somebody else’s yellow-on-blue? Do I get green-on-green? Or who wants to look at a page with Avant-garde titles over Helvetica paragraphs?

I responded:

> Some attributes mix better than others. A typical use of “weighted average” is to soften the author’s attempt to be distinct, e.g. the suggested font sizes – while the user still gets the message. One doesn’t have to use this feature, but while “100%” is equal to a binary “1” there is no going back from a binary syntax. In general, I think computer interfaces are much too binary.

Of course, Bert was right (he is, almost always) that the proposal created more problems than it solved, and the mixing was dropped.

Ditto the JS-style dot syntax. Why did it change?

It’s interesting you call it JS-style syntax. When I first proposed CSS, JavaScript was not around so I couldn’t borrow it from there. Rather, the syntax was inspired by X resources from the X11 Window System, another inspirational project coming out of MIT.

The reason for changing the CSS syntax from `font.size` to `font-size` was twofold. First, the hyphen makes it look more like written English, which improves human readability. Second, DSSSL and DSSSL-Lite used hyphenated property names. James Clark, who wrote the first draft of DSSSL-Lite, participated in the first W3C workshop on style sheets, and Bert and I borrowed the hyphen from DSSSL. On the downside, the hyphen represents minus in math, which sometimes confuses parsers.

How did Bert Bos get involved, and how did you work together?

Bert Bos reviewed my initial proposal. His background and focus was a bit different from mine, but when he wrote up his own proposal we quickly realized that two proposals could be combined into one. At that point, the web project was being kicked out of CERN and W3C was formed. I was starting up the European branch of W3C at INRIA and Bert was hired immediately. Most of CSS1 was hammered out on a whiteboard in Sophia-Antipolis in July 1995. Bert is still working for W3C in Sophia-Antipolis. Whenever I’m struggling with a difficult technical problem, I wish Bert and the whiteboard were there.

When listing people who made CSS possible, I must also mention Thomas Reardon and Chris Wilson of Microsoft. Thomas was the program manager for Internet Explorer (IE) who early caught onto the idea of adding style sheets to the web. Chris Wilson was the programmer who added CSS to IE3. IE3’s implementation was far from the standard, but one must remember that it was released before CSS1 was finished. Simon Daniels (also of Microsoft) wrote some impressive demos in IE3, and together they committed a major software company to support an emerging standard.

Were there any competing proposals? Why was yours better?

There were a dozen or so proposals for style sheets languages to be used. However, not all of them were suitable due to the characteristics of the web. For example, browsers use progressive rendering to display documents, and they must handle situations where style sheets are not accessible. There’s a wide range of web devices out there and you can’t write a style sheet for each one. So, style sheet languages must express designs that are scalable and responsive. It’s a fascinating area of study and I’ve written a PhD Thesis, which compares the approach taken by the various style sheet proposals.

Naturally, I’m biased in the second part of your question. But I believe CSS has several notable features which makes it especially suitable for web use: cascading, pseudo-classes and pseudo-elements, forward-compatible parsing rules, support for different media types, strong emphasis on selectors, and the amazing `em` unit.

What’s the biggest mistake you (and Bert) made?

I devote a chapter in my PhD thesis to problems in CSS. There are some, even self-inflicted ones. But the biggest problem CSS1 experienced was not in its design (which is pretty good, if you ask me), but rather in the initial implementations. Jeffrey Zeldman described the situation:

> If Netscape 3 ignored CSS rules applied to the `<body>` element and added random amounts of whitespace to every structural element on your page, and if IE4 got `<body>` right but bungled padding, what kind of CSS was safe to write? Some developers chose not to write CSS at all. Others wrote one style sheet to compensate for IE4’s flaws and a different style sheet to compensate for the blunders of Netscape 4.

Microsoft and Netscape both deserve some blame, but we — me, Bert, W3C — could have avoided many problems by producing a test suite along with the CSS1 specification. The first real CSS test appeared in October 1998 when Todd Fahrner published his Acid test. The test was creative, visual, and developers could immediately see whether they passed the test or not. In the beginning, no browsers passed. But then, with a strong push from the CSS community, things started to improve. The WaSP played a key role in assuring support for standards. The Opera browser also played a role by showing it was actually possible to implement CSS correctly. When I realized how solid Opera’s CSS implementation was — much better than Microsoft’s or Netscape’s — I joined Opera.

One of Opera’s claims to fame before I joined was that the browser would fit on a floppy disk (which is 1.44 MB). “Fits on a floppy” was a great slogan in those days. When CSS was added, a few more bytes were needed and Opera would no longer fit. “Almost fits on a floppy” doesn’t quite have the same ring to it.

The original Acid test inspired Acid2 and Acid3, which use the same formula: a visual and demanding web page which tests a wide range of features. The development of Acid2 was triggered by an open letter from Bill Gates, where he praised interoperability. Making IE7 follow the CSS standards seemed like a natural follow-up item, and Microsoft was challenged by Acid2. In fairness, other browsers also had issues, and Acid2 exposed bugs in all of them. Microsoft ignored Acid2 in IE7, but — magic sometimes happens — IE8 supported it perfectly. As do all current browsers.

Why did you decide on the box model whereby margin, padding, border are added to declared width rather than the IE5 `box-sizing: border-box` model?

There are good use cases for both models, I believe. If you want want an image to stretch out to fill the whole content box, the original CSS box model is the one to use. However, if it’s important that padding and borders do not extend outside a certain area, the IE5 model is better. Personally I think there are more use cases for the CSS box model, but some people that I respect highly think otherwise. The conflict has been gracefully resolved by the addition of the `box-sizing` property which all browsers now support.

I’ve always disliked absolute positioning. Am I wrong? How did it come about in the spec?

Your question takes me back to some heated debates in 1996. The short story is that Microsoft proposed absolute positioning in a draft called CSS Regions: Absolute Positioning and Z-Ordering (discussions took place on W3C member-only lists, I’m afraid; the closest public document is WD-positioning). Several members of the newly formed CSS Working group had reservations, and Bert and I wrote up a simplified counter-proposal. Our proposal got rid of the `position` property (`display` was used instead) and only described relative positioning (which would give us time to think through absolute positioning). Microsoft, however, had already implemented their proposal and were reluctant to remove functionality. In the end, the only material changes were to add the `right` and `bottom` properties (to balance `left` and `top`), and to add `position: fixed`. This became part of CSS2.

Like you, I have never become comfortable with absolute positioning. That being said, absolute positioning has found its place on the web and I use it from time to time to achieve things that would otherwise be hard, if not impossible, to encode.

I’ve heard people say that you shouldn’t use floats for layout, as they “weren’t intended” for that — they were just to wrap text around images. Does the intention matter, if they work?

Having text wrap around images is one of the basic layout techniques. For sure, floats should be used for layout. One area I’d like for CSS to progress into is paginated onscreen presentations. When you paginate content, floats become even more useful because you can float elements to the top and bottom of the screen.

If you could wave a magic wand, which bit of current CSS would you banish from the world, and what would you magically add and implement everywhere?

I’d banish browser-version-specific code like: `<!--[if lt IE 7 ]>`. While technically not expressed in CSS, these kinds of “comments” should not be necessary and they lower the standards of the web.

The second part of your question is even more interesting: what parts of CSS should be magically implemented everywhere? In 2006, I would have said web fonts. In 2007, I would have said the `<video>` element (straying into HTML-land for a while). Both of these are now implemented in all browsers.

In 2011, seeing that many apps used pages (and not scrollbars) to create compelling presentations, I started advocating for web pages to become real pages. The idea is that the style sheet would trigger paged mode so that content is split into pages. Users would navigate from one page to the next with gestures, or perhaps with `PageUp` and `PageDown`. I want it to be possible, even easy, to create ebook-readers in browsers. For this to happen, a bit of magic would be helpful. Could you sprinkle some fairy dust on the pillows of all browser vendors, please?

But CSS is not just for browsers. Bert and I wrote a book on CSS and in 2005, for the third edition, we wanted to use CSS itself for formatting. The browsers were not up to the job, but then Prince came along. Michael Day and his colleagues in Melbourne made a terrific product which was able to create a beautiful PDF document from HTML and CSS which we could send to the printer. In order to them to fix my favorite bugs, I joined the board of directors. Prince has since been used to format hundreds of books. We will still have some paper books in the future, I believe. And they will be made from HTML and CSS.

Why do we still not have a method of laying out pages in CSS that doesn’t require a Doctorate in Rocket Surgery? (I’m looking at you, Flexbox…)

Layout is complex, and layout on the web is even more complex due to pages being displayed on so many different devices. CSS has several mechanisms for laying out content, including absolutely positioned elements, floats, multi-column layout, and CSS tables. The interaction between them can be complex, but I don’t think any doctorate is needed. I must admit to not having used Flexbox much, though.

What’s your opinion on pre-processors like SASS and LESS? Does CSS have anything to learn from them?

Yes, pre-processors make a lot of sense. We should probably take the five or so most popular features from pre-processors and add them to CSS itself. My own favorites would be nested selectors, and single-line comments (starting with `//`). When CSS turns 50 I’ll tell you why they were not part of CSS from the beginning.

You’re one of the members of the WHATWG. How did that come about?

WHATWG was formed when it became clear that W3C would abandon work on HTML and instead focus efforts on compound documents based on XHTML, XForms, SMIL and SVG. For browser makers, HTML was much too important to abandon. Therefore, Ian Hickson, who, at the time, worked in my group at Opera, set up WHATWG to continue working on the web as we know it. Also, we were concerned about Microsoft’s XAML, which had a thin layer of XML on top of a proprietary application language. The focus of WHATWG is therefore on applications, rather than documents. Ian continues to do an amazing job as the editor of the HTML standard.

You’re the father of CSS, yet you’ve recently published some specs under the WHATWG domain rather than the CSS WG in the W3C. Why?

Indeed, CSS Figures and CSS Books are work items of WHATWG. There are some important benefits to publishing the specification in WHATWG. The “living standard” model allows quick updates with little overhead; in the past it was difficult to publish W3C Working Drafts in this area. WHATWG’s goal of keeping the specifications a little ahead of the implementations but not so far ahead that the implementations give up is one that I strongly believe in.

Finally, is CSS still up to the job? Or should we try to move to another model — for example, Grid Style Sheets?

Ethan Munson and Philip M Marden wrote in 1999 that “style sheet languages are terribly under-researched”. This remains true today, and efforts to research and improve style sheet languages must be encouraged.

GSS is an interesting example which adds the “Cassowary” constraint solver to the style sheet mechanism. In my initial CSS implementation in 1995 I used the “SkyBlue” constraint solver to resolve conflicting style sheet statements. (By the way, “SkyBlue” and “Cassowary” were both developed at the University of Washington.) Having a constraint solver allows you to express relationships between arbitrary elements and have conflicts resolved automagically. However, things can get complex when elements disappear and new ones arrive, like they do through DOM operations. Circular dependencies must also be handled gracefully. Therefore, the idea of allowing CSS to express layout constraints between any elements were dropped at an early stage.

In the past, adding support for a new specification required you to convince all browser makers to devote precious developer time. This raised the bar, perhaps uncomfortably high. These days, it’s possible to extend browsers by way of JavaScript libraries. This makes it easier to experiment and perform some of the research style sheets deserve.

Returning to your question: is CSS still up for the job? I think so. I don’t see anything on the horizon that makes me think otherwise. New ideas will come along, but they will extend CSS rather than replace it. I believe that the CSS code we write today will be readable by computers 500 years from now.

Thank you. Happy CSS Birthday!

## CSS Regions draft updated

Source: CSS WG Blog • Alan Stearns • 09 October 2014 09:13 PM

The CSS Working Group has published an updated Working Draft of CSS Regions Level 1. CSS Regions gives the ability to say, “Display this content (a named flow) over there (a region chain).”

The changes from the last public working draft are only in the introduction. You may have looked into CSS Regions in the past and thought to yourself, “Magazine-style layout isn’t relevant to me.” If you have, please take a look at the new intro which now shows much more basic examples and motivations for the feature.

Please send feedback to the (archived) public mailing list www-style@w3.org with the spec code (`[css-regions]`) and your comment topic in the subject line.

(Alternatively, you can email one of the editors and ask them to forward your comment.)

## Minutes Telecon 2014-10-08

Source: CSS WG Blog • Dael Jackson • 09 October 2014 12:20 AM

- Resolved: Unclosed URLs at the end of file should auto-close
- Resolved: Change the values and units to make invalid empty URL fail to resolve automatically
- Resolved: Remove the old text that negates the entire media query if an unrecognized media value or feature appears
- MaRakow reported that now that there’s interest in Snappoints, he’ll begin working on the open issues.
- Resolved: Accept Pseudo Elements 4 as an official ED, add TabAtkins as an editor, and remove the bits that aren’t in Selectors 3
- Everyone was reminded to register for TPAC if they haven’t.
- Fantasai requested that people look over the Flexbox spec and have any questions ready so they can move to CR either at or shortly after TPAC.

Full Minutes

## The CSS WG updated the Working Draft of CSS Regions Module L…

Source: W3C's Cascading Style Sheets home page • 09 October 2014 12:00 AM

9 Oct 2014 The CSS WG updated the Working Draft of CSS Regions Module Level 1

## The CSS WG updated the Working Draft of CSS Regions Module L…

Source: W3C's Cascading Style Sheets home page • 09 October 2014 12:00 AM

9 Oct 2014 The CSS WG updated the Working Draft of CSS Regions Module Level 1

## RealObjects released PDFreactor version 7, an XML-to-PDF for…

Source: W3C's Cascading Style Sheets home page • 09 October 2014 12:00 AM

9 Oct 2014 RealObjects released PDFreactor version 7, an XML-to-PDF formatter, with support for, among other things, CSS Transforms, CSS Regions, Web Fonts, and running elements. Other features include support for HTML5 (including the <canvas> element), MathML, SVG, XSLT, JavaScript, and accessible PDF. (Java. Free personal version)

## Decision by consensus or by informed editor; which is better?

Source: W3C Blog • Jeff Jaffe • 07 October 2014 06:11 PM

There has been discussion in the Web standards community about which is the better way to advance technical specifications: by a formal consensus process or by having all decisions made by informed editors as they informally gather a consensus. After all, the W3C has long considered consensus a core value of W3C. On the other hand, the WHATWG describes a process whereby the relevant editor makes the decisions by trying to see where the consensus is, and is explicit about eschewing formal consensus. Which approach is better?

### False dichotomy!

In my view, there are advantages to either approach. Clearly when there is an excellent spec writer who works with colleagues there is tremendous efficiency to having decisions made by informed editors. People make excellent progress with this approach both in the WHATWG and in many W3C Groups, including Community Groups (which typically have a high degree of flexibility in how they approach spec writing). In W3C Working Groups it is often the case that an informed editor is able to rapidly make progress in writing a spec and produces Working Drafts with the results. A W3C Working Draft does not necessarily represent a consensus of the Working Group, as it is not a finished product of the group.

While rapid progress can be made by informed editors, W3C will not give its imprimatur that a specification is a “Standard”, or a W3C Recommendation, however, unless it goes through the formal consensus process.

Billions of people and millions of developers rely on Web standards. Since the Web was invented by W3C Director Tim Berners-Lee 25 years ago, it has become a core infrastructure for personal communications, commerce, education, and entertainment. While implementers of standards can rapidly interact with informed editors, it is important that the entire ecosystem has the confidence of due process and is assured that they have their say. This ecosystem includes those who implement standards in browsers, web site developers, app developers, users, people with disabilities, corporate IT, procurement officers, telecommunication firms, ISPs, publishers, news outlets, marketing professionals, on-line e-commerce sites, researchers, educators, textbook authors, and de jure standards organizations such as the International Organization for Standardization (ISO). Significantly, the community is global.

To appreciate why this is important and necessary, it is worthwhile to review some of the key principles of OpenStand and explain their motivation.

### OpenStand’s five fundamental principles of standards development

- Due process. Included in this requirement is the opportunity to appeal decisions. Even the best editors make mistakes. Even when they are sincere and knowledgeable, the process needs to give assurance that there is a fair mechanism for appeal to independent arbiters. Also included in due process are processes for periodic standards review. If the entire globe relies on the standards, and the ecosystem of people that are affected is diverse, it is essential that there be underlying due process.
- Broad consensus. Included is that there are processes to allow all views to be considered across a range of interests. Again, it is the diverse range of interests that requires a consensus process. While much of the ecosystem might choose not to provide comments, they need to be assured that there are opportunities for the fair consideration of every issue.
- Transparency. Included are public comment periods before approval and adoption. It is understood that experts in spec writing are able to iterate rather rapidly at a pace that the general public could not possibly appreciate. Hence it is essential that when a major level of progress has been made in some technical area that a Working Group declares that it is timely to adopt this major level of progress as a new standard – and provides comment periods of appropriate length for the ecosystem to weigh in.
- Balance. Standards are not dominated by any particular person, company, or interest group. Hypothetically, a company, or small number of related companies might have the resources to invest in standards definition and (potentially) market power to enforce their decisions. The web, being an infrastructure dedicated for the benefit of all people needs to be assured that it remains open of undue influence by interest groups. Again, although it is certainly possible for informed editors to shield web standards from such influence, it is critical that a process guarantees that there is openness to consensus by all.
- Openness. The requirement that processes be open to all interested and informed parties appears to be one that can be achieved both by consensus processes as well as informed editor processes.

### The consensus process has much to learn from Decisions by informed editors

As described in OpenStand, the consensus process has the right properties for developing standards as critical and pervasive as web standards. However, there are tradeoffs, prominent among them that introducing review and accountability to those review comments typically has an impact on speed and agility. We have much to learn from other processes such as “decisions by informed editors”. We are currently looking at a prime example of that, HTML4 was standardized in 1999, and it is taking us 15 years to get to HTML5 – due to be standardized later this year. Three years ago we began revamping our processes in W3C to achieve much of the agility that the industry needs, without sacrificing OpenStand principles. Here are some of the key recent process innovations that W3C has taken to get the best of both worlds.

- Community Groups. Three years ago we introduced Community Groups for topics not yet ready for standardization. Today over 4400 people work in 179 Community Groups in a far more agile fashion. We still withhold the imprimatur of standard, however, unless the work transitions to the formal Working Group process.
- Process Revision. We have revised the W3C Process, eliminating unnecessary process steps, and giving WGs more latitude how they achieve the key requirements of wide review.
- Modularity. We recognize that large monolithic specs are difficult to advance. CSS2.1 took 13 years to complete after CSS2, so for further enhancements we have modularized the CSS spec. Several CSS Level 3 specs are already at the stable “Candidate Recommendation” level; some are already Recommendations.
- Improving W3C’s plans for spec iteration. When the HTML group decided to build a plan to get HTML5 to recommendation, they simultaneously planned for a HTML5.1 in 2016. There is also discussion to modularize HTML to allow parts to proceed more rapidly.
- Errata management. Implementations evolve continuously, and we discover bugs in our Recommendations. We need to improve our processes to more rapidly reflect fixes to our Recommendations among implementers. This is done well in the WHATWG, less well in W3C and we need to improve. Based on community input, I recently raised an issue to work on improving this.

### So in the end, which is better?

There are advantages to having decisions made by informed editors. But W3C must keep its commitment to the OpenStand consensus principles. For good reasons as described above. At the same time, we must improve our processes to foster agility and learning from other approaches.

## This week: W3C turned 20, Typography, Mozilla/Ford Open Web Fellowship, etc.

Source: W3C Blog • Coralie Mercier • 03 October 2014 03:35 PM

This is the 26 September – 3 October 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

## W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first]

- (`1305`) Milestone: 1-Oct – W3C 20th anniversary [tweet, news]
- (`50`) I18N: Improving typography on the Web and in eBooks
- (`Also`) Adobe: Drop Caps Are Beautiful, Sylvain Galineau [+ Demos]
- (`20`) a11y: Carousel Concepts • Carousels • WAI Web Accessibility Tutorials

## Open Web & net neutrality

- Mozilla (30 September), The Ford Foundation and Mozilla partner to launch Open Web Fellowship in efforts to protect the Web
- The New York Times (28 September), With Perspective From Both Sides of His Desk, F.C.C. Chairman Ponders Net Neutrality

## W3C in the Press (or blogs)

9 articles since the last Digest; a selection follows. You may read all articles in our Press Clippings page.

- telecompaper (2 October), Ericsson Research releases Bowser, OpenWebRTC as open source
- Gigaom (2 October), Some pros and cons of Google’s plan to give every “thing” a URL
- Heise online (1 October), 20 Jahre World Wide Web Consortium (20 years World Wide Web Consortium)
- The Guardian | Technology (28 September), Tim Berners-Lee calls for internet bill of rights to ensure greater privacy
- London Evening Standard Online (26 September), Tim Berners-Lee: People will always try to control the internet. We have to keep fighting for it
- Semanticweb.com (23 September), The Semantic Web’s Rocking, And There Ain’t No Stopping It Now

## Feeds

The Future of Style features:

- CSS WG Blog
- CSS3 . Info
- Dev.Opera
- IEBlog
- W3C Blog
- W3C i18n and css
- W3C's Cascading Style Sheets home page
- Web Directions Blog
- ishida blog » css

If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to this aggregator, please get in touch with fantasai.

## Site navigation

- CSS home
- Learn & use
- Software
- Participate / drafts