Intent to ship: CSS Properties and Values API Level 1

[Anders Ruud]

Contact emails

and...@chromium.org

Spec

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

TAG review: not sure if this is done. Should it be? (Not familiar with process).

Summary

CSS Properties and Values API Level 1 defines a registerProperty() function, which allows authors to specify type, initial value, and inheritability for custom CSS properties. The two most important implications of this, is that custom properties can be animated, and that CSS Typed OM APIs can return typed CSSStyleValue objects (rather than just CSSUnparsedValue).

The intent is to ship a subset of the syntax types:

Shipping:

• <angle>
  
• <color>
  
• <custom-ident>
  
• <integer>
  
• <length-percentage>
  
• <length>
  
• <number>
  
• <percentage>
  
• <resolution>
  
• <time>
  
• <url>
  
• ident
  
• Lists, e.g. <length>+ or <length>#.
  
• Compound syntax, e.g. <url> | none
  
• * (any token stream)
  

Not shipping (at this time):

• <image>
  
• <transform-function>
  
• <transform-list>

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/b6UBgAZt1kQ

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

Yes.

Demo link

https://css-houdini.rocks/animating-gradient/

Debuggability

The registered custom properties behave as unregistered custom properties in DevTools.

Interoperability and Compatibility

Edge: No signals
Firefox: In development (possibly stalled)
Safari: In development
Web developers: Positive, animating custom properties is frequently requested.

Ergonomics
Q: Are there any other platform APIs this feature will frequently be used in tandem with?

A: CSS Typed OM, CSS Paint API, CSS Layout API (in the future) as well as animation APIs.

Q: Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

A: I don't think there are issues with the severity level of "must run on a certain thread". Naturally using the feature isn't entirely free, e.g. registrations must persist somewhere in memory, and the token stream of registered properties need to be rewritten for substitution (unlike regular custom properties), but those are hardly architecture-level issues.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes, but see weak point below.

• https://wpt.fyi/results/css/css-properties-values-api?label=experimental
  
• https://wpt.fyi/results/css/css-paint-api?label=experimental
  
• Weak point: there are some basic interpolation tests in the css-paint-api suite, but the thorough ones are not in WPT. (Issue 900581).
  

Entry on the feature dashboard

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

[Boris Zbarsky]

On 11/1/18 3:53 AM, Anders Ruud wrote:
> Firefox: In development
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1370344>(possibly stalled)

There was an intern working on this as an experiment last year. No one
is actively working on it now, nor am I aware of specific plans to ship
this in Firefox.

It doesn't help that there are years-old spec issues filed by Mozilla
engineers that are still unaddressed. Some, like
<https://github.com/w3c/css-houdini-drafts/issues/112> (filed 2.5 years
ago!) would pretty clearly block anything resembling shipping this, on
the Firefox side.

> Is this feature fully tested by web-platform-tests

Clearly not, since the spec is not even fully defined, per above issue. ;)

-Boris

[Daniel Bratell]

Yes, there should be (have been a while back) a tag review of https://drafts.css-houdini.org/css-properties-values-api/ before it goes on to shipping. I can't find one on https://github.com/w3ctag/design-reviews so you should request one now. The tag design review is to ensure that the spec is stable enough, fits with related standards and has wide spread general approval.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUpgvdJAnQrjmApmvfWfAerS3eNeiKLM_LfcTofpi7c8RQ%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Anders Ruud]

On Thu, Nov 1, 2018 at 1:26 PM Daniel Bratell <bra...@opera.com> wrote:

Yes, there should be (have been a while back) a tag review of https://drafts.css-houdini.org/css-properties-values-api/ before it goes on to shipping. I can't find one on https://github.com/w3ctag/design-reviews so you should request one now. The tag design review is to ensure that the spec is stable enough, fits with related standards and has wide spread general approval.

/Daniel

OK, thanks, done.

https://github.com/w3ctag/design-reviews/issues/318

[Philip Jägenstedt]

On Thu, Nov 1, 2018 at 2:02 PM Anders Ruud <and...@chromium.org> wrote:

On Thu, Nov 1, 2018 at 1:26 PM Daniel Bratell <bra...@opera.com> wrote:

Yes, there should be (have been a while back) a tag review of https://drafts.css-houdini.org/css-properties-values-api/ before it goes on to shipping. I can't find one on https://github.com/w3ctag/design-reviews so you should request one now. The tag design review is to ensure that the spec is stable enough, fits with related standards and has wide spread general approval.

/Daniel

OK, thanks, done.

https://github.com/w3ctag/design-reviews/issues/318

Thanks! Could you also go through https://github.com/w3c/css-houdini-drafts/labels/css-properties-values-api-1 and see which you think ought to be resolved before shipping? As a rule of thumb, issues that would likely lead to breaking changes are ones that should be resolved. (Issues that strictly add to the API surface are generally not as important.)

[Anders Ruud]

I think only #360 is likely to lead to breaking changes. We should fix that. I proposed an edit for it.

Also, we should do #112 if it's "clearly blocking anything resembling shipping this, on the Firefox side" ;), but Tab need to chime in here. He seems to have something in mind for this, and it's not clear what it is. I liked heycam's suggestion, even if it's a bit Inception-y.

[Anders Ruud]

On Thu, Nov 8, 2018 at 10:39 AM Anders Ruud <and...@chromium.org> wrote:

On Tue, Nov 6, 2018 at 4:18 PM Philip Jägenstedt <foo...@chromium.org> wrote:

On Thu, Nov 1, 2018 at 2:02 PM Anders Ruud <and...@chromium.org> wrote:

On Thu, Nov 1, 2018 at 1:26 PM Daniel Bratell <bra...@opera.com> wrote:

Yes, there should be (have been a while back) a tag review of https://drafts.css-houdini.org/css-properties-values-api/ before it goes on to shipping. I can't find one on https://github.com/w3ctag/design-reviews so you should request one now. The tag design review is to ensure that the spec is stable enough, fits with related standards and has wide spread general approval.

/Daniel

OK, thanks, done.

https://github.com/w3ctag/design-reviews/issues/318

Thanks! Could you also go through https://github.com/w3c/css-houdini-drafts/labels/css-properties-values-api-1 and see which you think ought to be resolved before shipping? As a rule of thumb, issues that would likely lead to breaking changes are ones that should be resolved. (Issues that strictly add to the API surface are generally not as important.)

I think only #360 is likely to lead to breaking changes. We should fix that. I proposed an edit for it.

This issue is now fixed. (Spec edited, implemented in Blink, tests added to WPT).

 

Also, we should do #112 if it's "clearly blocking anything resembling shipping this, on the Firefox side" ;), but Tab need to chime in here. He seems to have something in mind for this, and it's not clear what it is. I liked heycam's suggestion, even if it's a bit Inception-y.

No response from editor on this issue. 

Re. TAG review, is there anything else I should do, or just wait?

[Philip Jägenstedt]

Ping +Tab Atkins.

 

Re. TAG review, is there anything else I should do, or just wait?

Ping +Alex Russell. Anders, we usually don't block on TAG review if it was filed a reasonable amount of time ago and there's still no response. It takes a while for a feature to reach the stable channel so in principle we can deal with serious design-altering feedback up to the next branch point, by just reverting. (I don't think that's ever happened, though.)

[Alex Russell]

Thanks for the ping on TAG review. Will make sure we at least re-visit the issue at our next call. This was filed late vs current process (TAG collaboration invoked at I2I stage, not I2S), so we'll be asking some level of forgiveness for (yet another) rushed review.

[Daniel Bratell]

I see no obvious progress on the spec review. Anders, do you know what's happening there?

/Daniel

[Anders Hartvoll Ruud]

No idea.

[Philip Jägenstedt]

I see there's been some action on https://github.com/w3ctag/design-reviews/issues/318 now. Anders, were any spec issue filed as part of that which should be resolved? And is resolving https://github.com/w3c/css-houdini-drafts/issues/112 still important to resolve before shipping this? I presume that PRs would be welcome since I happen to know +Tab Atkins is busy working on CSS Syntax now.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUrNeWfNe-mM3G8kyWGfWwDnL2h-i8HPdXtsQWQQ2-nrNQ%40mail.gmail.com.

[Anders Hartvoll Ruud]

On Tue, Feb 12, 2019 at 10:43 AM Philip Jägenstedt <foo...@chromium.org> wrote:

I see there's been some action on https://github.com/w3ctag/design-reviews/issues/318 now. Anders, were any spec issue filed as part of that which should be resolved?

Yes, there was a tentative reply on the TAG review. No issues were filed yet, but I think it's clear that the CSS(Typed)OM behavior needs to be added to the spec. I will create some PRs for this in the next few days.

 

And is resolving https://github.com/w3c/css-houdini-drafts/issues/112 still important to resolve before shipping this?

The question is whether leaving #112 unfixed will create a compat issue. It doesn't seem terribly likely to me to be honest, but I'm still leaning towards fixing it, just in case.

 

I presume that PRs would be welcome since I happen to know +Tab Atkins is busy working on CSS Syntax now.

Indeed, but the situation is still that I'm not entirely sure how to spec this.

[Philip Jägenstedt]

On Tue, Feb 12, 2019 at 2:01 PM Anders Hartvoll Ruud <and...@chromium.org> wrote:

On Tue, Feb 12, 2019 at 10:43 AM Philip Jägenstedt <foo...@chromium.org> wrote:

I see there's been some action on https://github.com/w3ctag/design-reviews/issues/318 now. Anders, were any spec issue filed as part of that which should be resolved?

Yes, there was a tentative reply on the TAG review. No issues were filed yet, but I think it's clear that the CSS(Typed)OM behavior needs to be added to the spec. I will create some PRs for this in the next few days.

 

And is resolving https://github.com/w3c/css-houdini-drafts/issues/112 still important to resolve before shipping this?

The question is whether leaving #112 unfixed will create a compat issue. It doesn't seem terribly likely to me to be honest, but I'm still leaning towards fixing it, just in case.

SG, but if your judgement is that it's not important to fix #112, then that would be OK too.

 

I presume that PRs would be welcome since I happen to know +Tab Atkins is busy working on CSS Syntax now.

Indeed, but the situation is still that I'm not entirely sure how to spec this.

I'm not too familiar with CSS specs, but is this because some infrastructure is missing from the spec? Wherever you added the code in the implementation, is there no analogous part of the spec? How direct is the mapping from spec to implementation here?

[Anders Hartvoll Ruud]

On Tue, Feb 12, 2019 at 2:26 PM Philip Jägenstedt <foo...@chromium.org> wrote:

On Tue, Feb 12, 2019 at 2:01 PM Anders Hartvoll Ruud <and...@chromium.org> wrote:

On Tue, Feb 12, 2019 at 10:43 AM Philip Jägenstedt <foo...@chromium.org> wrote:

I see there's been some action on https://github.com/w3ctag/design-reviews/issues/318 now. Anders, were any spec issue filed as part of that which should be resolved?

Yes, there was a tentative reply on the TAG review. No issues were filed yet, but I think it's clear that the CSS(Typed)OM behavior needs to be added to the spec. I will create some PRs for this in the next few days.

 

And is resolving https://github.com/w3c/css-houdini-drafts/issues/112 still important to resolve before shipping this?

The question is whether leaving #112 unfixed will create a compat issue. It doesn't seem terribly likely to me to be honest, but I'm still leaning towards fixing it, just in case.

SG, but if your judgement is that it's not important to fix #112, then that would be OK too.

 

I presume that PRs would be welcome since I happen to know +Tab Atkins is busy working on CSS Syntax now.

Indeed, but the situation is still that I'm not entirely sure how to spec this.

I'm not too familiar with CSS specs, but is this because some infrastructure is missing from the spec?

Heh 🙂. I can describe how it works somehow, but I'm not entirely sure how to best put this into CSS spec language while leaning on the appropriate existing concepts from the CSS spec multiverse, if that makes sense.

But tell you what, I'll try to get intimately familiar with the language/style/description/thinking in css-syntax, and then I'll draft a PR for #112 inspired by that.

 

Wherever you added the code in the implementation, is there no analogous part of the spec?

Not for all parts of it, actually. For example the spec does not mention how whitespace is handled.

Sidenote: This part was actually implemented by my predecessor (probably timloh@).

[Philip Jägenstedt]

Thanks for jumping in to tackle the spec issues, Anders! It sounds like maybe there's a bit of scaffolding needed, and there will be a question about how far you should go to sort it out. Hopefully it'll become clear naturally, but the rule of thumb I'd use is "can others implement CSS Properties and Values interoperably?" Some layers not fleshed out in the spec might not matter to that question, and others might.

[Anders Hartvoll Ruud]

Update:

PR for #112 created: https://github.com/w3c/css-houdini-drafts/pull/860

Also further WPTs are needed, and Blinks implementation will probably need to be tweaked a little, but I'll hold off on that until the PR is accepted. Meanwhile there are gaping CSSOM holes raised by TAG that need to be spec'd too. (Next week).

[Anders Hartvoll Ruud]

Everything we wanted to fix is now fixed.

•  The syntax string parsing behavior is now specified. (Boris' objection). § 3. Syntax strings
•  TAG seems (sufficiently) happy.
•  TAG had many questions re. CSS[Typed]OM behavior, which is quite understandable, as it was completely missing from the spec. Now described by § 5. CSSOM.
•  How values substitute also wasn't specified. This never came up as an issue here, but it was important to get that down in any case. § 4.5. Substitution

I should mention that the behavior of registered custom properties with em units in @keyframes can't (currently) be implemented in Blink in a manner consistent with the behavior of the standard property equivalent (Keyframe Animation Inconsistency), for the reasons explained in StyleResolver Cascade. This is slightly annoying, but I propose that we ship anyway, because:

•  The correct behavior for em/font-size/@keyframes is not specified in general. (Issue 3751).
•  Browser behavior is already all over the place. (See above issue).
•  There is an ongoing project which eventually will make consistency possible. (StyleResolver Cascade).

So I think it's time to evaluate this I2S again.

[Philip Jägenstedt]

LGTM1

Thanks for getting all of that fixed, Anders!

Looking at https://github.com/w3c/css-houdini-drafts/labels/css-properties-values-api-1 and https://drafts.css-houdini.org/css-properties-values-api/#issues-index, is that remaining issue around animations one that needs to be resolved? The phrasing "We should ensure that this is standard across implementations to avoid interop issues" suggests it's important, but I'm not sure about the details.

On the script-driven extensibility, we have custom HTML elements but no ability to extend the core HTML parser behavior and CSS custom properties but so far no ability to extend the core CSS parser. Is the some equivalent "separate but powerful enough" mechanism for CSS value syntax that could be envisioned here, or is custom properties already that mechanism? (Extending the syntax of a built-in CSS property without changing the behavior seems odd?)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUpy8%2Bn_RcfxGyCUzX5ViZ7z-wfv8HmAwYNHwXZozcbj9A%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYe0tCn%3DKqFTHKB6XW3NC3AxE9yi_LA7t3TqwdX6W9PBnw%40mail.gmail.com.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8UmK_r3vwHrCGLUbG6svecXAbNVE5XwizpXo1Q0%3Dd2Gw%40mail.gmail.com.

[Anders Hartvoll Ruud]

On Thu, May 2, 2019 at 2:22 PM Philip Jägenstedt <foo...@chromium.org> wrote:

LGTM1

🙌

 

Thanks for getting all of that fixed, Anders!

Looking at https://github.com/w3c/css-houdini-drafts/labels/css-properties-values-api-1 and https://drafts.css-houdini.org/css-properties-values-api/#issues-index, is that remaining issue around animations one that needs to be resolved? The phrasing "We should ensure that this is standard across implementations to avoid interop issues" suggests it's important, but I'm not sure about the details.

That animation issue is a special case of the general problem "how do registered custom properties substitute?", which is now described by § 4.5. Substitution. I forgot that it was there; I'll remove it as soon as I'm less OOO.

 

On the script-driven extensibility, we have custom HTML elements but no ability to extend the core HTML parser behavior and CSS custom properties but so far no ability to extend the core CSS parser. Is the some equivalent "separate but powerful enough" mechanism for CSS value syntax that could be envisioned here, or is custom properties already that mechanism?

(Registered) custom properties can be that mechanism to some extent, if we extend it to support more of the CSS value syntax. Currently, only a limited subset is supported.

 

(Extending the syntax of a built-in CSS property without changing the behavior seems odd?)

I don't think that's what Alex meant. Instead of a fixed list of supported value types like "<length>" and "<color>", he wants do define his own, e.g. "<fibonacci>" with accompanying parsing behavior that only accepts Fibonacci numbers (just to pick the most useless example).

[Philip Jägenstedt]

On Thu, May 2, 2019 at 9:40 PM Anders Hartvoll Ruud <and...@chromium.org> wrote:

On Thu, May 2, 2019 at 2:22 PM Philip Jägenstedt <foo...@chromium.org> wrote:

LGTM1

🙌

 

Thanks for getting all of that fixed, Anders!

Looking at https://github.com/w3c/css-houdini-drafts/labels/css-properties-values-api-1 and https://drafts.css-houdini.org/css-properties-values-api/#issues-index, is that remaining issue around animations one that needs to be resolved? The phrasing "We should ensure that this is standard across implementations to avoid interop issues" suggests it's important, but I'm not sure about the details.

That animation issue is a special case of the general problem "how do registered custom properties substitute?", which is now described by § 4.5. Substitution. I forgot that it was there; I'll remove it as soon as I'm less OOO.

 

On the script-driven extensibility, we have custom HTML elements but no ability to extend the core HTML parser behavior and CSS custom properties but so far no ability to extend the core CSS parser. Is the some equivalent "separate but powerful enough" mechanism for CSS value syntax that could be envisioned here, or is custom properties already that mechanism?

(Registered) custom properties can be that mechanism to some extent, if we extend it to support more of the CSS value syntax. Currently, only a limited subset is supported.

I see, I saw <declaration-value> in https://drafts.csswg.org/css-variables/#defining-variables and thought that sounded very generic, but I guess <any-value> is the most generic it could be made?

(Extending the syntax of a built-in CSS property without changing the behavior seems odd?)

I don't think that's what Alex meant. Instead of a fixed list of supported value types like "<length>" and "<color>", he wants do define his own, e.g. "<fibonacci>" with accompanying parsing behavior that only accepts Fibonacci numbers (just to pick the most useless example).

Ah, so subsetting the syntax/value space is something that could work with built-in CSS properties.

[Emilio Cobos Álvarez]

On 02/05/2019 14:21, Philip Jägenstedt wrote:
> LGTM1
>
> Thanks for getting all of that fixed, Anders!
>
> Looking
> at https://github.com/w3c/css-houdini-drafts/labels/css-properties-values-api-1 and https://drafts.css-houdini.org/css-properties-values-api/#issues-index,
> is that remaining issue around animations one that needs to be resolved?
> The phrasing "We should ensure that this is standard across
> implementations to avoid interop issues" suggests it's important, but
> I'm not sure about the details.

FWIW, I did file a couple other issues on the spec a bit ago, but I
cannot add labels to that repo:

* https://github.com/w3c/css-houdini-drafts/issues/879
* https://github.com/w3c/css-houdini-drafts/issues/880

I don't think the first-one is particularly problematic, and the second
one is not terribly major, but I'm still not fully convinced that the
current Blink behavior is consistent or desirable.

-- Emilio

>
> On the script-driven extensibility
> <https://github.com/w3ctag/design-reviews/issues/318#issuecomment-486948932>,

> we have custom HTML elements but no ability to extend the core HTML
> parser behavior and CSS custom properties but so far no ability to
> extend the core CSS parser. Is the some equivalent "separate but
> powerful enough" mechanism for CSS value syntax that could be envisioned
> here, or is custom properties already that mechanism? (Extending the
> syntax of a built-in CSS property without changing the behavior seems odd?)
>
> On Fri, Apr 26, 2019 at 9:58 AM Anders Hartvoll Ruud
> <and...@chromium.org <mailto:and...@chromium.org>> wrote:
>
> Everything we wanted to fix is now fixed.
>

> *  The syntax string parsing behavior is now specified. (Boris'
> objection). § 3. Syntax strings
> <https://drafts.css-houdini.org/css-properties-values-api-1/#syntax-strings>
> *  TAG seems (sufficiently) happy
> <https://github.com/w3ctag/design-reviews/issues/318>.
> *  TAG had many questions re. CSS[Typed]OM behavior, which is

> quite understandable, as it was completely missing from the
> spec. Now described by § 5. CSSOM

> <https://drafts.css-houdini.org/css-properties-values-api-1/#cssom>.
> *  How values substitute also wasn't specified. This never came up

> as an issue here, but it was important to get that down in any
> case. § 4.5. Substitution

> <https://drafts.css-houdini.org/css-properties-values-api-1/#substitution>

>
> I should mention that the behavior of registered custom properties
> with em units in @keyframes can't (currently) be implemented in
> Blink in a manner consistent with the behavior of the standard
> property equivalent (Keyframe Animation Inconsistency

> <https://docs.google.com/document/d/1HrmPmcQBTUMouqQQG3Kww43I5aFW9-Q9tr-DEKZk09I/edit#bookmark=id.hdfrcdmbvld4>),

> for the reasons explained in StyleResolver Cascade

> <https://docs.google.com/document/d/1HrmPmcQBTUMouqQQG3Kww43I5aFW9-Q9tr-DEKZk09I>.

> This is slightly annoying, but I propose that we ship anyway, because:
>

> *  The correct behavior for em/font-size/@keyframes is not

> specified in general. (Issue 3751

> <https://github.com/w3c/csswg-drafts/issues/3751>).
> *  Browser behavior is already all over the place. (See above issue).
> *  There is an ongoing project which eventually will make

> <and...@chromium.org <mailto:and...@chromium.org>>

> wrote:
>
> On Tue, Feb 12, 2019 at 10:43 AM Philip
> Jägenstedt <foo...@chromium.org

> <mailto:foo...@chromium.org>> wrote:
>
> I see there's been some action
> on https://github.com/w3ctag/design-reviews/issues/318
> now. Anders, were any spec issue filed as
> part of that which should be resolved?
>
>
> Yes, there was a tentative reply on the TAG
> review. No issues were filed yet, but I think
> it's clear that the CSS(Typed)OM behavior needs
> to be added to the spec. I will create some PRs
> for this in the next few days.
>  
>
> And is
> resolving https://github.com/w3c/css-houdini-drafts/issues/112
> still important to resolve before shipping this?
>
>
> The question is whether leaving #112 unfixed
> will create a compat issue. It doesn't seem
> terribly likely to me to be honest, but I'm
> still leaning towards fixing it, just in case.
>
>
> SG, but if your judgement is that it's not important
> to fix #112, then that would be OK too.
>  
>
> I presume that PRs would be welcome since I
> happen to know +Tab Atkins

> <mailto:taba...@google.com> is busy

> working on CSS Syntax now.
>
>
> Indeed, but the situation is still that I'm not
> entirely sure how to spec this.
>
>
> I'm not too familiar with CSS specs, but is this
> because some infrastructure is missing from the spec?
>
>

> Heh 🙂. I /can/ describe how it works /somehow/, but I'm

> not entirely sure how to best put this into CSS spec
> language while leaning on the appropriate existing
> concepts from the CSS spec multiverse, if that makes sense.
>
> But tell you what, I'll try to get intimately familiar
> with the language/style/description/thinking in
> css-syntax, and then I'll draft a PR for #112 inspired
> by that.
>  
>
> Wherever you added the code in the implementation,
> is there no analogous part of the spec?
>
>
> Not for all parts of it, actually. For example the spec
> does not mention how whitespace is handled.
>
> Sidenote: This part was actually implemented by my
> predecessor (probably timloh@).
>  
>
> How direct is the mapping from spec to
> implementation here? 
>
>
> On Sat, Dec 15, 2018 at 11:32 AM Anders
> Hartvoll Ruud <and...@chromium.org

> <mailto:and...@chromium.org>> wrote:
>
> No idea.
>
> On Fri, Dec 14, 2018 at 2:36 PM Daniel
> Bratell <bra...@opera.com

> <mailto:bra...@opera.com>> wrote:
>
> __

> I see no obvious progress on the
> spec review. Anders, do you know
> what's happening there?
>
> /Daniel
>
> On Thu, 29 Nov 2018 19:09:41 +0100,
> Alex Russell <sligh...@google.com

> <https://www.google.com/url?q=https%3A%2F%2Fdrafts.css-houdini.org%2Fcss-properties-values-api%2F&sa=D&sntz=1&usg=AFQjCNE6rRdfAeXTJRvzXXTejCyPSC4ntw>

> <https://github.com/w3c/css-houdini-drafts/issues/360>

> is likely to lead to
> breaking changes. We
> should fix that. I
> proposed an edit

> <https://github.com/w3c/css-houdini-drafts/pull/833>

> for it.
>
>
> This issue is now fixed.
> (Spec edited,
> implemented in Blink,
> tests added to WPT).
>  
>
> Also, we should do
> #112

> <https://github.com/w3c/css-houdini-drafts/issues/112>

> if it's "clearly
> blocking anything
> resembling shipping
> this, on the Firefox
> side" ;), but Tab
> need to chime in
> here. He seems to
> have something in
> mind for this, and
> it's not clear what
> it is. I liked
> heycam's suggestion,
> even if it's a bit
> Inception-y.
>
>
> No response from editor
> on this issue. 
>
>
> Ping +Tab Atkins.
>  
>
> Re. TAG review

> <https://github.com/w3ctag/design-reviews/issues/318>,

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUrNeWfNe-mM3G8kyWGfWwDnL2h-i8HPdXtsQWQQ2-nrNQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUpy8%2Bn_RcfxGyCUzX5ViZ7z-wfv8HmAwYNHwXZozcbj9A%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUpy8%2Bn_RcfxGyCUzX5ViZ7z-wfv8HmAwYNHwXZozcbj9A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYe0tCn%3DKqFTHKB6XW3NC3AxE9yi_LA7t3TqwdX6W9PBnw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYe0tCn%3DKqFTHKB6XW3NC3AxE9yi_LA7t3TqwdX6W9PBnw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Anders Hartvoll Ruud]

On Sat, May 4, 2019 at 1:54 PM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

On 02/05/2019 14:21, Philip Jägenstedt wrote:
> LGTM1
>
> Thanks for getting all of that fixed, Anders!
>
> Looking
> at https://github.com/w3c/css-houdini-drafts/labels/css-properties-values-api-1 and https://drafts.css-houdini.org/css-properties-values-api/#issues-index,
> is that remaining issue around animations one that needs to be resolved?
> The phrasing "We should ensure that this is standard across
> implementations to avoid interop issues" suggests it's important, but
> I'm not sure about the details.

FWIW, I did file a couple other issues on the spec a bit ago, but I
cannot add labels to that repo:

 * https://github.com/w3c/css-houdini-drafts/issues/879
 * https://github.com/w3c/css-houdini-drafts/issues/880

I don't think the first-one is particularly problematic, and the second
one is not terribly major, but I'm still not fully convinced that the
current Blink behavior is consistent or desirable.

 -- Emilio

( Where was this objection when I filed the same issue a year ago? No, it's much better to object immediately before shipping. Thanks, Emili-bro. ;P )

Seriously though, it's probably better to hold off on shipping until we have something resembling a conclusion on #880. We could e.g. end up changing the behavior of CSS.supports, which is definitely terrible after shipping.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/62744e9f-8c10-7c89-24d5-c14fac0bffb9%40mozilla.com.

[Anders Hartvoll Ruud]

Update:

tl;dr: This is shipping in M78.

This was about to ship in M76, but was then disabled on the beta branch because of spec issue #902, which led a revisit of #880. Those issues are now resolved (again, with a much less "shaky" result this time), and Blink+WPT have been updated accordingly. As soon as M77 has branched, I will enable the feature on master.

[Chris Harrelson]

Thanks Anders, Tab and Emilio for doing the extra work to fix these issues! I think it was definitely worth the time to pause and make sure it's right before shipping.

For those who are listening in and might be curious about what the root issue was: I am one of you, and went and read through the linked spec issues. :) I learned a lot from them.

The root issue is that HTML, DOM and CSS have an inversion-of-control/late-binding architecture (*). This means that you can put what you want in your CSS, HTML attributes, or DOM, even if it doesn't necessarily make a lot of sense - e.g. given the style sheets present, a particular custom property set via script may not be valid because it's the wrong type. However, only once the rendering pipeline has run can the browser know that fact, because those types might have been set by a style sheet added elsewhere that is not yet parsed, or has a pending invalidation. The original spec tried to give developer feedback right away via errors when script modified custom properties, and this was removed in the latest update.

(*) And this architecture is an important attribute of the web rendering model. It allows us to over time improve performance, pipelining, and threading on all web content; and supports mixing declarative and imperative implementations of features, which in turn helps SSR, progressive rendering, etc.

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUo12K0r6Vz8-g4kJnNDrYP4XnMWH2O0J%2BSuEOZE3AKiXw%40mail.gmail.com.