An incremental approach Typed & Custom Properties

Hi all,

Here are some ideas on how to progressively roll out typed & custom
properties in an incremental manner, providing a lot of value at each step.

=== Firstly just a recap on what custom properties are, and why they are
useful (for Houdini). ===
Custom properties will allow us to trigger/invalidate later parts of the
pipeline, for example custom paint, layout, line layout, etc.

.a {
  --my-custom-prop: 100;
}
// THIS IS NOT A SERIOUS API PROPOSAL
registerCustomSomething('customSomething', {invalidatesOn:
['--my-custom-prop']});

Here when we change '--my-custom-prop', this will invalidate
'customSomething' recalculating paint, layout, etc, within this frame.

The full custom properties spec wants/needs a few things:
 - How to parse the value of a custom property.
 - What is the type / defining the type of the custom property.
 - Etc

This will be a relatively large spec.

=== A recap on a Typed Style OM and why it is useful: ===
One benefit that we can provide to authors is adding Typed Style OM access.
For example at the moment in main-thread javascript, if an author wants to
know the computed background-color, 'red' component of an element they have
to:
var str = getComputedStyle(element).backgroundColor;
var red = parseInt(/someregex/.match(str), 10);
The same applies to Length types, transforms, etc, etc, etc. Strings are a
clunky API.

A Typed Style OM would allow direct access to value - e.g. r/g/b channels
of a color, or per-unit values of lengths.

The Typed Style OM would provide a set of *built-in types* that can already
be parsed, etc by the browser:
 - Length
 - Number
 - Color
 - Etc.

=== What an incremental approach to Custom Properties would provide: ===
We strictly don't need the whole custom properties (level 2) spec to
invalidate later parts of the pipeline.
The current CSS Custom Properties Spec will suffice for just the
invalidation part of this at the moment. (
http://dev.w3.org/csswg/css-variables/)
Initially later steps of the pipeline would just rely on the string based
style API.

One incremental step we can take is allowing in-built types to be tied to
custom properties (before the full custom properties, level 2 come into
effect).
For example:
// THIS IS NOT A SERIOUS API PROPOSAL
registerCustomProperty('--my-custom-prop', {
  type: CSS.NumberType
});

This would mean that later steps of the pipeline (layout, line layout,
paint) could utilize the typed API for custom properties.

Doing things incrementally will provide a lot of performance & usability
benefits to authors early.

=== In summary: ===
Step 1) CSS Custom Properties Level 1.
Step 2) Typed CSS Properties.
Step 3) Add types to CSS Custom Properties (Level 1.5). (allow built-in
types to be tied to custom properties).
Step 4) CSS Custom Properties Level 2. (full parsing & type defining of
custom properties).
Step 5) Party.

Thoughts?

Thanks,
Ian