Last week I was in Sydney for the first face to face meeting of “CSS
Houdini”, a new joint task force of W3C’s CSS Working Group and
Technical Architecture Group.
The goal is to “explain the magic” of CSS, make it extensible by
providing low-level primitives that can be built upon to add new
higher-level features to the platform without baking them into browsers.
Participants were from Microsoft, Google, Mozilla, HP, W3C, Disruptive
Innovations, Apple, Vivliostyle, Adobe, and jQuery Foundation.
I have heard concerns that Google or Apple would just expose whatever
Blink/WebKit’s internals currently are, and the rest of us implementers
would be stuck with that. Since this work is happening at W3C and
participants include people working on competing engines, I am confident
this won’t happen. I will also be watching for design decisions that
could be incompatible with Servo’s goals (e.g. parallel layout, layout
concurrent with script, etc.)
About the task force:
Mailing list: https://lists.w3.org/Archives/Public/public-houdini/
IRC: #houdini @ irc.w3.org
Wiki: https://wiki.css-houdini.org/
Draft specifications: http://dev.w3.org/houdini/
Source repository: https://hg.css-houdini.org/drafts
Read/write mirror repository (pull requests work):
https://github.com/w3c/css-houdini-drafts
Formatted minutes of these discussions should be published soon. In the
meantime, the raw IRC logs are at:
http://log.csswg.org/irc.w3.org/houdini/2015-02-06/
http://log.csswg.org/irc.w3.org/houdini/2015-02-07/
The group agreed on its own scope, and on starting new 8 specifications.
I described them below based on my the minutes and my own recollection
of the discussions. If you want to discussed the proposals themselves
(as opposed to their implications for Servo), please do so on the
public-houd...@w3.org mailing list. (Subscription info is at the URL above.)
* Fragment Tree
Expose read-only information to script about the fragment tree, which is
roughly what implementations call the render tree, frame tree, or flow
tree. This includes "anonymous" fragments, that are not generated
directly by any DOM element. This was previously discussed as a "Box
Tree", but was renamed since boxes (as defined in CSS specs) don’t have
geometry, only fragments (again per spec, after fragmentation across
lines, columns, regions or pages) do.
* CSS Parser API
Expose various pieces of the CSS parser: selectors, rules, complete
stylesheets, colors, gradients, unknown properties, etc. Web authors are
often doing this ad-hoc with regular expressions, which is painful and
hard to get right. The shape and API of returned objects (representing
tokens or an AST or higher-level values) is yet to be determined.
* CSS Properties and Values Extensions
Currently, CSS implementations throw away (per spec) rules or
declarations they don’t understand. The error recovery and fallback
allow for some forward-compatibility, but this is somewhat limited. We
now also have CSS Custom Properties, but they’re namespaced with the --
prefix. This proposes adding APIs enabling script to register new
at-rules and properties with a details about their behavior and
callbacks for parsing, as well as new values for existing "types" (e.g
color, length, image, …), thus enabling polyfills.
* Font Metrics Extensions
Some desired features like drop caps a.k.a. initial letters require
various measurements from fonts such as position of the baseline, height
of ascenders and descenders, etc. This proposes APIs to determine which
font is actually used for a given piece of text in the document (since
the `font-family` property accepts a list of family names) and query
such measurements.
* Custom Paint
This proposes adding callbacks into script during painting, to enable
various graphical effects. One example given was an animated procedural
background image of ripples, as if on a fluid surface, that propagate
from a disturbance point and bounce against the borders of the element.
* CSS Custom Layout
This propose adding the ability to define new layout modes (like Flexbox
is a layout mode) in script, with callbacks for the various phases of
layout. These modes would probably be opted into through new values of
the 'display' property.
* CSS Scroll Extensions
This proposes adding hooks to control scrolling (e.g. for snap points),
and what scrolling should block on (e.g. slow scroll event handlers).
* CSS Async Style
As far as I understand, this proposes adding control on what phases of
rendering of what parts of the document can be deferred or (de)prioritized.
--
Simon Sapin
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
