Contact emails
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:
Not shipping (at this time):
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/
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes, but see weak point below.
Entry on the feature dashboard
--
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.
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
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./DanielOK, thanks, done.
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./DanielOK, thanks, done.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.)
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.
--
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.
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.
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.
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?
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.
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.
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.
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?)
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).
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
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.
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.