Intent to Implement: Houdini - CSS Properties and Values API Level 1

78 views

Skip to first unread message

Timothy Loh

unread,

Aug 29, 2016, 4:12:16 AM8/29/16

to blin...@chromium.org

Contact emails

tim...@chromium.org

Spec

https://drafts.css-houdini.org/css-properties-values-api/

Summary

The CSS Properties and Values API spec defines an registerProperty() function which can be called from JavaScript to register typed and animatable custom CSS properties, expanding on the functionality defined in css-variables.

Motivation

This Houdini API expands the existing CSS custom properties to improve usability of other Houdini APIs. Being able to animate these and customise inheritance and initial values makes it more useful for custom layout/paint, and having types associated with these allows the typed OM to work more effectively with custom properties.

Interoperability and Compatibility Risk

Not requesting permission to ship, so no risk. Firefox is working on implementing this

https://groups.google.com/d/msg/mozilla.dev.platform/CNmJeMkUv88/oLmZacPECAAJ.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug

https://crbug.com/641877

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5640265926705152

Requesting approval to ship?

No, implementation will be behind experimental flag.

Simon Pieters

unread,

Aug 29, 2016, 11:12:47 AM8/29/16

to blin...@chromium.org, Timothy Loh

On Mon, 29 Aug 2016 10:11:47 +0200, Timothy Loh <tim...@chromium.org>
wrote:

> Contact emails
>
> tim...@chromium.org
>
> Spec
>
> https://drafts.css-houdini.org/css-properties-values-api/
>
> Summary
>
> The CSS Properties and Values API spec defines an registerProperty()
> function which can be called from JavaScript to register typed and
> animatable custom CSS properties, expanding on the functionality defined
> in

> css-variables <https://dev.w3.org/csswg/css-variables/>.

>
> Motivation
>
> This Houdini API expands the existing CSS custom properties to improve
> usability of other Houdini APIs. Being able to animate these and
> customise
> inheritance and initial values makes it more useful for custom
> layout/paint, and having types associated with these allows the typed OM
> to
> work more effectively with custom properties.
>
> Interoperability and Compatibility Risk
>
> Not requesting permission to ship, so no risk.

I think it is useful to explore what the risk will be when it does ship,
since presumably that is a goal?

For example, briefly looking for "interop" and "compat" in the minutes of
previous Houdini meetings, I find (maybe high-level for Houdini APIs as a
whole, but still):

https://lists.w3.org/Archives/Public/public-houdini/2015Oct/0011.html :

dbaron: With the value API, we only have getters and not setters.
If you want to do this, and we need to push this into CSS
spec, every property needs to specify how it maps to
values so that we can interoperably implement getting and
setting.

https://lists.w3.org/Archives/Public/public-houdini/2015Oct/0018.html :

zcorpan: If we start exposing the internal model of the browser it
makes it harder for us to get interoperability on the
internal model because changing it means breaking sites
or having to maintain your legacy that you exposed to
scripts when changing your internal model.

https://lists.w3.org/Archives/Public/public-houdini/2015Mar/0004.html :

SimonSapin: So I'm here to make sure we don't accidentally lock
things into the details of one browser, so Servo, and
more generally parallel layout, can be compatible with
this.

dbaron: The main thing I wanna see the task force work on is
figuring out how to expose primitives so that developers
can *do* a lot of the things that today have to happen in
browser engines.
dbaron: So essentially polyfilling.
dbaron: And do them both correctly and efficiently.
dbaron: I think that when we do this it's worth thinking about
tradeoffs.
dbaron: There are a bunch of things related to user control and
future compat, where there are something benefits to not
exposing things, and we have to figure out where those
tradeoffs are.
dbaron: Another area I wanna be careful with is that it's easy to
define a set of low-level primitives and build something
else on top of those primitives, but it doesn't mean those
*were* the primitives that existed before.
dbaron: I worry about defining a set of primitives that matches
what one browser engine does and not another, and thus
forces one engine to rewrite a lot of things.
dbaron: And also the other way - I worry about defining the set of
primitives browsers do right now, and locking us out of
changing in the future.

> Firefox is working on
> implementing this
>
> https://groups.google.com/d/msg/mozilla.dev.platform/CNmJeMkUv88/oLmZacPECAAJ.

It looks like in this thread there is some work on implementing this in
Servo also, and discussion about shared tests, which sounds encouraging.

> Ongoing technical constraints
>
> None.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
> OWP launch tracking bug
>
> https://crbug.com/641877
>
> Link to entry on the feature dashboard <https://www.chromestatus.com/>
>
> https://www.chromestatus.com/feature/5640265926705152
>
> Requesting approval to ship?
> No, implementation will be behind experimental flag.
>