Intent to Ship: CSS Typed OM

829 views
Skip to first unread message

Naina Raisinghani

unread,
Jan 24, 2018, 12:07:17 AM1/24/18
to blink-dev, Darren Shen

Contact emails

sh...@chromium.org | nai...@chromium.org


Explainer

Coming Soon™


Relevant links

Specification: https://drafts.css-houdini.org/css-typed-om-1/

Tag Review (hasn't been done yet): https://github.com/w3ctag/design-reviews/issues/223

Link to Intent to Implement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/KpCcUTv1UQ8


Summary

Converting CSSOM value strings into meaningfully typed JavaScript representations and back can incur a significant performance overhead. This specification exposes CSS values as typed JavaScript objects to facilitate their performant manipulation.


Debuggability

Most of the debugging features should work out of the box. Doesn’t need any added support.


Risks

Interoperability and Compatibility

  • Much like other Houdini APIs, the primary risk is that other browsers don’t implement this feature and it doesn’t become part of the wider web platform.

  • Firefox had started implementation work on CSS Type OM, but paused this work. There is a risk that our implementations will diverge due to changes in spec. However, their implementation is behind a flag and hence not considered feature complete.

  • There is a possibility of change in the spec text, which would then require a change in the implementation.


Edge: No signals

Firefox: Implementation progress here - https://bugzilla.mozilla.org/show_bug.cgi?id=1278697

Safari: No official signals (has shown verbal interest though)


Ergonomics

This API will be used in conjunction with the CSS Paint API.


Activation

We expect that this feature won’t have broad adoption initially. This is similar to other new CSS features which typically only have broad adoption after most of the evergreen browsers support it.


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

Yes.


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

Yes. All tests are upstreamed as tentative for now to allow for any possible changes in the spec and hence in the tests.

Link to wpt.fyi: https://wpt.fyi/css/css-typed-om


Link to entry on the feature dashboard

https://www.chromestatus.com/features/5682491075592192


Requesting approval to ship?

Yes


Philip Jägenstedt

unread,
Jan 24, 2018, 9:05:08 AM1/24/18
to Naina Raisinghani, blink-dev, Darren Shen
I'm thrilled to see so much of the tests shared before we've even shipped! (I hope that before long, we'll be able to see the results before shipping too, but not today.)

There are a fair number of open spec issues labeled as css-typed-om-1, mostly filed by you and Darren. Stringification behavior seems like a case where we must do something already and it would be good for the spec and tests to reflect that at shipping time. Does that make sense, and/or are there other issues like that?

Looks like there's been some activity from Microsoft, enough so that we'd know if they had serious concerns at least?

--
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/c53f1c72-4f4f-4fb3-b649-eb88ec621ed6%40chromium.org.

Naina Raisinghani

unread,
Jan 24, 2018, 11:18:31 PM1/24/18
to Philip Jägenstedt, blink-dev, Darren Shen
Hi Philip, 

On Thu, Jan 25, 2018 at 1:05 AM Philip Jägenstedt <foo...@google.com> wrote:
I'm thrilled to see so much of the tests shared before we've even shipped! (I hope that before long, we'll be able to see the results before shipping too, but not today.)

Yup, kudos to Darren for keeping the wpt suite updated. :)
 
There are a fair number of open spec issues labeled as css-typed-om-1, mostly filed by you and Darren. Stringification behavior seems like a case where we must do something already and it would be good for the spec and tests to reflect that at shipping time. Does that make sense, and/or are there other issues like that?

Currently we have 31 open issues against the Typed OM 1 spec. 15 of these issues already have PRs out. We hope to get them committed by end of next week. Re: the remaining 16 issues - those are marked as NeedsEdits - we need to write up spec text but resolutions by the WG have been made. We don't expect major changes to the spec other than the following 3 issues: 
Once we get these changes in by end of next week, we can republish the spec and then transition to CR. This will also help surface any concerns that other implementors might have.

Looks like there's been some activity from Microsoft, enough so that we'd know if they had serious concerns at least?

Yup, Microsoft has been a vocal participant in the conversation re: all Houdini specs. Typed OM is no different. There is however, no signal on the official feature dashboard as of yet.

Let us know if you have any more concerns,

Emilio Cobos Álvarez

unread,
Jan 25, 2018, 10:28:02 AM1/25/18
to blin...@chromium.org
On 01/24/2018 06:07 AM, Naina Raisinghani wrote:
> Firefox:Implementation progress here -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1278697

FWIW, I don't think nothing ever landed. There were also two attempts to
implement typed custom properties with a bit more progress[1][2] which
were also intern projects, but there's nobody working on getting those
rebased and landed right now as far as I know.

> Safari:No official signals (has shown verbal interest though)

I think there's a thread in webkit-dev@ where some Apple people did show
interest publicly:

https://lists.webkit.org/pipermail/webkit-dev/2017-August/029445.html

> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> Yes. All tests are upstreamed as tentative for now to allow for any
> possible changes in the spec and hence in the tests.

Thank you so much for this btw, it's great to be able to have tests
ready for these APIs, and being able to ensure we're interoperable with
Blink's implementation.

-- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1273706
[2]: https://github.com/servo/servo/pull/18167

Philip Jägenstedt

unread,
Jan 26, 2018, 12:45:05 AM1/26/18
to Emilio Cobos Álvarez, blin...@chromium.org
Thanks Emilio, it's great to hear confirmation that upstreamed tests are appreciated and useful. I hope that this will lead us to better interop faster, relying less on web developers to get bitten by the issues before we notice.

Philip Jägenstedt

unread,
Jan 26, 2018, 1:09:04 AM1/26/18
to Naina Raisinghani, blink-dev, Darren Shen
Thanks Naina,

My remaining concern is about having the spec and tests match what we ship, so that a second implementer can lean on those to easily achieve interop with Blink. But we ship things with small discrepancies all the time that get fixed afterwards, so just looking for anything where shipping amounts to a decision that others might be unhappy with or we regret.

Sorry I assumed a stringifier already existed, that's not always the case of course.

For the remaining three issues, I can't see any implementers disagreeing, only https://github.com/w3c/css-houdini-drafts/issues/159 has some discussion. I tried to find what's been implemented there but failed to find it.

Looks like CSSStyleValue.parse('background-color', 'red') returns a CSSKeywordValue with value "red", a string. Is the idea that this would be replaced with CSSColorValue?

If it's just not implemented yet then it's actually not that important if the spec for it is done, but I wonder how we'd go about "upgrading" from CSSKeywordValue to CSSColorValue. As soon as web content is using CSS Typed OM, this door can be closed.

If that's a concern, are there other bits that have been punted to Level 2 that might become harder to ship because we have something else sitting in its place?

fantasai

unread,
Jan 26, 2018, 9:58:14 PM1/26/18
to blink-dev
Naina wrote:
> Relevant links
>
> Specification: https://drafts.css-houdini.org/css-typed-om-1/
>
> Tag Review (hasn't been done yet): https://github.com/w3ctag/design-reviews/issues/223
>
> Link to Intent to Implement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/KpCcUTv1UQ8
> ...
> Interoperability and Compatibility
>
> Much like other Houdini APIs, the primary risk is that other browsers don’t implement this feature and it doesn’t become part of the wider web platform.
>
> Firefox had started implementation work on CSS Type OM, but paused this work. There is a risk that our implementations will diverge due to changes in spec. However, their implementation is behind a flag and hence not considered feature complete
> ... > Edge: No signals
> Firefox: Implementation progress here - https://bugzilla.mozilla.org/show_bug.cgi?id=1278697
> Safari: No official signals (has shown verbal interest though)

The specification was last published in August; if it is
up-to-date, that's great; but if not it should be republished
so that the specification and your implementation match. (You
are the editor of the spec, so there should be no reason for
it to lag behind your intent to ship.)

Also, if the technology is ready for shipping, then the editors
(that is, you and Tab and Shane, who are all on the Blink team)
should post a last call for review on the spec and request a CR
transition: to encourage any lagging reviewers, to sweep up any
remaining feedback on the thing you are about to ship, and to
indicate to the other implementers that design work is done and
no major changes are expected.

Not every team has the resources to re-implement a rapidly
churning spec the way Google does, and so the teams whose
signals you're trying to read are likely to be waiting for the
spec to stabilize before committing resources to implementation.
You will get better information about their implementation intent
if you request a CR transition and get either their approval or
their pushback.

> There is a possibility of change in the spec text,
> which would then require a change in the implementation.

Given that there are still open issues marked in the spec,
there seems to be a certainty that there will be changes
in the spec text. Whether they require a change in your
implementation depends on how those issues are resolved,
of course. Regardless, however, I deplore this wishy-washy
approach to describing the situation. (Did you copy that
from a template? How useful is it really if it's not
describing anything unique about this Intent?)

If you want to say something *useful* about it, you can
do a quick triage of the open spec issues and see how
significant they are: are they likely to result in major
changes or not?

~fantasai

Darren Shen

unread,
Jan 28, 2018, 11:42:36 PM1/28/18
to Philip Jägenstedt, Naina Raisinghani, blink-dev
On Fri, Jan 26, 2018 at 5:09 PM Philip Jägenstedt <foo...@google.com> wrote:
Thanks Naina,

My remaining concern is about having the spec and tests match what we ship, so that a second implementer can lean on those to easily achieve interop with Blink. But we ship things with small discrepancies all the time that get fixed afterwards, so just looking for anything where shipping amounts to a decision that others might be unhappy with or we regret.

Sorry I assumed a stringifier already existed, that's not always the case of course.

For the remaining three issues, I can't see any implementers disagreeing, only https://github.com/w3c/css-houdini-drafts/issues/159 has some discussion. I tried to find what's been implemented there but failed to find it.

Yep, that's because we currently don't have an implementation for CSSColorValue yet. Hopefully we can spec and implement something by the end of this week. 
 
Looks like CSSStyleValue.parse('background-color', 'red') returns a CSSKeywordValue with value "red", a string. Is the idea that this would be replaced with CSSColorValue?

Not quite; 'red' will still be a CSSKeywordValue. If you want a CSSColorValue, then you would get the computed value which would be an rgba(...) value, which is represented by a CSSColorValue. Alternatively, you could also call CSSColorValue.parse('red'). 

If it's just not implemented yet then it's actually not that important if the spec for it is done, but I wonder how we'd go about "upgrading" from CSSKeywordValue to CSSColorValue. As soon as web content is using CSS Typed OM, this door can be closed.

If that's a concern, are there other bits that have been punted to Level 2 that might become harder to ship because we have something else sitting in its place?

Currently, any property that we can't cater for with existing subclasses of CSSStyleValue are represented as just CSSStyleValues. The idea is that you can still use these values in style property maps, but you can't manipulate them as typed objects. As we add new subclasses of CSSStyleValues in the future (e.g. CSSFontFaceValue), existing code should not break (we just get new capabilities), so interop risk should be low.

Hope that answers your concerns!

Philip Jägenstedt

unread,
Jan 30, 2018, 6:36:42 AM1/30/18
to Darren Shen, Naina Raisinghani, blink-dev
On Mon, Jan 29, 2018 at 11:42 AM Darren Shen <sh...@chromium.org> wrote:
On Fri, Jan 26, 2018 at 5:09 PM Philip Jägenstedt <foo...@google.com> wrote:
Thanks Naina,

My remaining concern is about having the spec and tests match what we ship, so that a second implementer can lean on those to easily achieve interop with Blink. But we ship things with small discrepancies all the time that get fixed afterwards, so just looking for anything where shipping amounts to a decision that others might be unhappy with or we regret.

Sorry I assumed a stringifier already existed, that's not always the case of course.

For the remaining three issues, I can't see any implementers disagreeing, only https://github.com/w3c/css-houdini-drafts/issues/159 has some discussion. I tried to find what's been implemented there but failed to find it.

Yep, that's because we currently don't have an implementation for CSSColorValue yet. Hopefully we can spec and implement something by the end of this week.

Ah, well if the plan is to ship that initially, then any concerns about how it'll be upgraded are moot.
 
Looks like CSSStyleValue.parse('background-color', 'red') returns a CSSKeywordValue with value "red", a string. Is the idea that this would be replaced with CSSColorValue?

Not quite; 'red' will still be a CSSKeywordValue. If you want a CSSColorValue, then you would get the computed value which would be an rgba(...) value, which is represented by a CSSColorValue. Alternatively, you could also call CSSColorValue.parse('red'). 

I see my mistake. 'red' is a CSSKeywordValue simply because it's a keyword, but CSSStyleValue.parse('background-color', '#ff0000') return a CSSStyleValue, and perhaps other types are possible too. It's not the case that CSSColorValue will always be used to represent all colors, then. An explainer for newbs would be nice :)

If it's just not implemented yet then it's actually not that important if the spec for it is done, but I wonder how we'd go about "upgrading" from CSSKeywordValue to CSSColorValue. As soon as web content is using CSS Typed OM, this door can be closed.

If that's a concern, are there other bits that have been punted to Level 2 that might become harder to ship because we have something else sitting in its place?

Currently, any property that we can't cater for with existing subclasses of CSSStyleValue are represented as just CSSStyleValues. The idea is that you can still use these values in style property maps, but you can't manipulate them as typed objects. As we add new subclasses of CSSStyleValues in the future (e.g. CSSFontFaceValue), existing code should not break (we just get new capabilities), so interop risk should be low.

Right, as long as CSSStyleValues is the base class and every other type is derived from it, there's no problem. I thought we might have an HTMLUnknownElement kind of setup, which is pretty odd and worth not repeating.

Hope that answers your concerns!

It does, sounds like there's no special future compat concern here, thank you!

I see that there's been some action on https://github.com/w3ctag/design-reviews/issues/223 now with some new issues from dbaron, although most of them resolved already.

Would it make sense to keep working through the known issues where other implementers couldn't match Blink by starting from the spec and tests, update the implementation, and then ping this thread?

Philip Jägenstedt

unread,
Jan 30, 2018, 8:34:05 AM1/30/18
to fantasai, blink-dev
W3C maturity levels aren't part of the Blink launch process, and the template even steers people away from it by saying: 'Links to “living standard” versions (eg. w3c.github.io / whatwg.org) are generally preferred over specific snapshots (eg. w3.org/TR), but be sure to indicate which specific parts of the specification you are shipping now.'

I think that's the right advice in general, because at best it's up to date, and from what I've heard from other implementers they also avoid looking at /TR/. (Aside: I personally don't think the situation can be salvaged with anything short of auto-publishing from git master to /TR/ for all specs.)

However, ignoring /TR/ isn't strictly speaking incompatible with publishing to /TR/. Shane, Tab, Naina, do you think requesting a CR transition here, or in general, would be useful?

Daniel Bratell

unread,
Jan 30, 2018, 10:59:16 AM1/30/18
to blink-dev, Naina Raisinghani, Darren Shen
On Wed, 24 Jan 2018 06:07:17 +0100, Naina Raisinghani <nai...@chromium.org> wrote:

Summary

Converting CSSOM value strings into meaningfully typed JavaScript representations and back can incur a significant performance overhead. This specification exposes CSS values as typed JavaScript objects to facilitate their performant manipulation.


I couldn't see anything that describes whether this goal has been achieved. Parsing strings is not instant, but creating (allocating) and manipulating objects and later freeing them in some garbage collection is also not instant so it is not obvious to me what will end up being most performant.

Do you have any measurements to share here?

/Daniel

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

fantasai

unread,
Jan 30, 2018, 2:03:03 PM1/30/18
to Philip Jägenstedt, blink-dev
On 01/30/2018 05:33 AM, Philip Jägenstedt wrote:
> W3C maturity levels <https://w3c.github.io/w3process/#maturity-levels> aren't part of the Blink launch process

Sure, but the processes triggered by requesting a CR transition
will improve the odds of you having useful information for this
section of your template and of having better a better interop
story in general. (For the reasons mentioned above; see above.)

~fantasai

Naina Raisinghani

unread,
Jan 30, 2018, 8:49:45 PM1/30/18
to Daniel Bratell, blink-dev, Darren Shen
On Wed, Jan 31, 2018 at 2:59 AM Daniel Bratell <bra...@opera.com> wrote:
On Wed, 24 Jan 2018 06:07:17 +0100, Naina Raisinghani <nai...@chromium.org> wrote:

Summary

Converting CSSOM value strings into meaningfully typed JavaScript representations and back can incur a significant performance overhead. This specification exposes CSS values as typed JavaScript objects to facilitate their performant manipulation.


I couldn't see anything that describes whether this goal has been achieved. Parsing strings is not instant, but creating (allocating) and manipulating objects and later freeing them in some garbage collection is also not instant so it is not obvious to me what will end up being most performant.

Since Typed OM objects are mutable, you don't have to keep creating new objects to manipulate them which avoids the perf cost you mentioned.
 

Do you have any measurements to share here?

meade@ did some initial benchmarking here: https://github.com/wilddamon/typedom-demos 

Naina Raisinghani

unread,
Jan 31, 2018, 1:05:24 AM1/31/18
to Philip Jägenstedt, Darren Shen, blink-dev
On Tue, Jan 30, 2018 at 10:36 PM Philip Jägenstedt <foo...@google.com> wrote:
On Mon, Jan 29, 2018 at 11:42 AM Darren Shen <sh...@chromium.org> wrote:
On Fri, Jan 26, 2018 at 5:09 PM Philip Jägenstedt <foo...@google.com> wrote:
Thanks Naina,

My remaining concern is about having the spec and tests match what we ship, so that a second implementer can lean on those to easily achieve interop with Blink. But we ship things with small discrepancies all the time that get fixed afterwards, so just looking for anything where shipping amounts to a decision that others might be unhappy with or we regret.

Sorry I assumed a stringifier already existed, that's not always the case of course.

For the remaining three issues, I can't see any implementers disagreeing, only https://github.com/w3c/css-houdini-drafts/issues/159 has some discussion. I tried to find what's been implemented there but failed to find it.

Yep, that's because we currently don't have an implementation for CSSColorValue yet. Hopefully we can spec and implement something by the end of this week.

Ah, well if the plan is to ship that initially, then any concerns about how it'll be upgraded are moot.
 
Looks like CSSStyleValue.parse('background-color', 'red') returns a CSSKeywordValue with value "red", a string. Is the idea that this would be replaced with CSSColorValue?

Not quite; 'red' will still be a CSSKeywordValue. If you want a CSSColorValue, then you would get the computed value which would be an rgba(...) value, which is represented by a CSSColorValue. Alternatively, you could also call CSSColorValue.parse('red'). 

I see my mistake. 'red' is a CSSKeywordValue simply because it's a keyword, but CSSStyleValue.parse('background-color', '#ff0000') return a CSSStyleValue, and perhaps other types are possible too. It's not the case that CSSColorValue will always be used to represent all colors, then. An explainer for newbs would be nice :)

We are working on an explainer. Will try to get you a link to it by the end of next week. 
 
If it's just not implemented yet then it's actually not that important if the spec for it is done, but I wonder how we'd go about "upgrading" from CSSKeywordValue to CSSColorValue. As soon as web content is using CSS Typed OM, this door can be closed.

If that's a concern, are there other bits that have been punted to Level 2 that might become harder to ship because we have something else sitting in its place?

Currently, any property that we can't cater for with existing subclasses of CSSStyleValue are represented as just CSSStyleValues. The idea is that you can still use these values in style property maps, but you can't manipulate them as typed objects. As we add new subclasses of CSSStyleValues in the future (e.g. CSSFontFaceValue), existing code should not break (we just get new capabilities), so interop risk should be low.

Right, as long as CSSStyleValues is the base class and every other type is derived from it, there's no problem. I thought we might have an HTMLUnknownElement kind of setup, which is pretty odd and worth not repeating.

Hope that answers your concerns!

It does, sounds like there's no special future compat concern here, thank you!

I see that there's been some action on https://github.com/w3ctag/design-reviews/issues/223 now with some new issues from dbaron, although most of them resolved already.

Yup, we have been burning through all the Typed OM issues this week. We are planning to resolve all known issues this week while Tab is in Sydney. *fingers crossed*
 
Would it make sense to keep working through the known issues where other implementers couldn't match Blink by starting from the spec and tests, update the implementation, and then ping this thread?

I think for the while, since we have 11 open issues, let's hold off on the need for LGTMs. At the end of the week, if we feel like we have resolved all the issues, we will ping this thread saying so and the OWNERS can evaluate accordingly? 

Philip Jägenstedt

unread,
Jan 31, 2018, 2:09:25 AM1/31/18
to Naina Raisinghani, Darren Shen, blink-dev
On Wed, Jan 31, 2018 at 1:05 PM Naina Raisinghani <nai...@chromium.org> wrote:
On Tue, Jan 30, 2018 at 10:36 PM Philip Jägenstedt <foo...@google.com> wrote:
On Mon, Jan 29, 2018 at 11:42 AM Darren Shen <sh...@chromium.org> wrote:
On Fri, Jan 26, 2018 at 5:09 PM Philip Jägenstedt <foo...@google.com> wrote:
Thanks Naina,

My remaining concern is about having the spec and tests match what we ship, so that a second implementer can lean on those to easily achieve interop with Blink. But we ship things with small discrepancies all the time that get fixed afterwards, so just looking for anything where shipping amounts to a decision that others might be unhappy with or we regret.

Sorry I assumed a stringifier already existed, that's not always the case of course.

For the remaining three issues, I can't see any implementers disagreeing, only https://github.com/w3c/css-houdini-drafts/issues/159 has some discussion. I tried to find what's been implemented there but failed to find it.

Yep, that's because we currently don't have an implementation for CSSColorValue yet. Hopefully we can spec and implement something by the end of this week.

Ah, well if the plan is to ship that initially, then any concerns about how it'll be upgraded are moot.
 
Looks like CSSStyleValue.parse('background-color', 'red') returns a CSSKeywordValue with value "red", a string. Is the idea that this would be replaced with CSSColorValue?

Not quite; 'red' will still be a CSSKeywordValue. If you want a CSSColorValue, then you would get the computed value which would be an rgba(...) value, which is represented by a CSSColorValue. Alternatively, you could also call CSSColorValue.parse('red'). 

I see my mistake. 'red' is a CSSKeywordValue simply because it's a keyword, but CSSStyleValue.parse('background-color', '#ff0000') return a CSSStyleValue, and perhaps other types are possible too. It's not the case that CSSColorValue will always be used to represent all colors, then. An explainer for newbs would be nice :)

We are working on an explainer. Will try to get you a link to it by the end of next week. 
 
If it's just not implemented yet then it's actually not that important if the spec for it is done, but I wonder how we'd go about "upgrading" from CSSKeywordValue to CSSColorValue. As soon as web content is using CSS Typed OM, this door can be closed.

If that's a concern, are there other bits that have been punted to Level 2 that might become harder to ship because we have something else sitting in its place?

Currently, any property that we can't cater for with existing subclasses of CSSStyleValue are represented as just CSSStyleValues. The idea is that you can still use these values in style property maps, but you can't manipulate them as typed objects. As we add new subclasses of CSSStyleValues in the future (e.g. CSSFontFaceValue), existing code should not break (we just get new capabilities), so interop risk should be low.
Right, as long as CSSStyleValues is the base class and every other type is derived from it, there's no problem. I thought we might have an HTMLUnknownElement kind of setup, which is pretty odd and worth not repeating.

Hope that answers your concerns!

It does, sounds like there's no special future compat concern here, thank you!

I see that there's been some action on https://github.com/w3ctag/design-reviews/issues/223 now with some new issues from dbaron, although most of them resolved already.
Yup, we have been burning through all the Typed OM issues this week. We are planning to resolve all known issues this week while Tab is in Sydney. *fingers crossed*
 
Would it make sense to keep working through the known issues where other implementers couldn't match Blink by starting from the spec and tests, update the implementation, and then ping this thread?

I think for the while, since we have 11 open issues, let's hold off on the need for LGTMs. At the end of the week, if we feel like we have resolved all the issues, we will ping this thread saying so and the OWNERS can evaluate accordingly? 

That SGTM, thanks! I expect the final outcome would be pretty much the same regardless of the order here, but might as well give it that extra week given that we're pretty far from the next branch point.

Anne van Kesteren

unread,
Jan 31, 2018, 2:50:24 AM1/31/18
to Naina Raisinghani, Daniel Bratell, blink-dev, Darren Shen
On Wed, Jan 31, 2018 at 2:49 AM, 'Naina Raisinghani' via blink-dev
<blin...@chromium.org> wrote:
> On Wed, Jan 31, 2018 at 2:59 AM Daniel Bratell <bra...@opera.com> wrote:
>> Converting CSSOM value strings into meaningfully typed JavaScript
>> representations and back can incur a significant performance overhead. This
>> specification exposes CSS values as typed JavaScript objects to facilitate
>> their performant manipulation.
>>
>> I couldn't see anything that describes whether this goal has been
>> achieved. Parsing strings is not instant, but creating (allocating) and
>> manipulating objects and later freeing them in some garbage collection is
>> also not instant so it is not obvious to me what will end up being most
>> performant.
>
> Since Typed OM objects are mutable, you don't have to keep creating new
> objects to manipulate them which avoids the perf cost you mentioned.

And yet the demo below cites GC occurring every 5 frames and doesn't
really make Typed OM out to be a clear winner (assuming I'm
interpreting the numbers correctly; in particular the performance is
not nearly as consistent and slower in naive setups).


>> Do you have any measurements to share here?
>
> meade@ did some initial benchmarking here:
> https://github.com/wilddamon/typedom-demos


--
https://annevankesteren.nl/

Daniel Bratell

unread,
Jan 31, 2018, 8:45:50 AM1/31/18
to Naina Raisinghani, blink-dev, Darren Shen
If I read the results correctly, this will be slower unless you use the technique mentioned above, and I'm not sure if the tests include the GC time so it might be significantly slower. If, on the other hand, you manage to reuse the same objects 100k times, it will end up using half the time than strings.

What do you think, is this a fair description, and are there any untapped optimizations in either parser or the CSS Typed OM model that might change these numbers?

Darren Shen

unread,
Jan 31, 2018, 6:37:01 PM1/31/18
to Daniel Bratell, Naina Raisinghani, blink-dev
Hi Daniel and Anne,

I think your concerns about performance are valid. As Daniel said, ultimately it's a tradeoff between string parsing vs. allocation/GC: the more objects you reuse, the better. So it's not a simple case of "switch to Typed OM and performance will improve"; you still need to take care in writing performant code, like the precalc version of the demo code.

I admit we haven't invested a lot of time optimising, mainly because we think it's more useful to optimize for real world use cases. Nevertheless, we believe that there are still a lot of optimization opportunities left, especially in reducing the GC overhead. On the other hand, the Blink CSS parser is heavily optimised already, so I think it's unlikely we'll see major improvements there.

Personally, I think as long as Typed OM has competitive performance with the existing CSSOM, it's already a huge win in terms of the convenience, generality and extensibility of a typed API.

P.S. The demo is a bit outdated now, so I'm planning to do some updated perf benchmarks next week.

kai zhu

unread,
Feb 1, 2018, 12:48:23 AM2/1/18
to Darren Shen, Naina Raisinghani, Daniel Bratell, blink-dev

where does this logic that typed-systems are inherently better than string/regexp manipulation come from?  from a user-perspective, this looks like making something thats relatively easy-to-use into something more complicated (get/set human-readable-strings vs get/set who-knows-what with no obvious performance benefit).

-kai

> --
> 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/CAMO7KM_1Jvc4gcZd%3DueaFswRZXQ657SMX5tWRQKmefAPXb3nVw%40mail.gmail.com.

PhistucK

unread,
Feb 1, 2018, 3:42:27 PM2/1/18
to kai zhu, Darren Shen, Naina Raisinghani, Daniel Bratell, blink-dev
Whenever I had to parse or create complex CSS values in JavaScript, for example, for transforms and similar, it would have been much more convenient to use a typed model rather than strings.
(I do not know how accommodative the CSS Typed OM is for this transforms, so it might still be inconvenient ;) But I imagine it is much better)


PhistucK

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

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALPJ472JZV2O49x_1xXnA%2Bb5Cd2iNon1XJhq20C3nbC%2B%3DzVGvQ%40mail.gmail.com.

Naina Raisinghani

unread,
Feb 4, 2018, 9:05:46 PM2/4/18
to Philip Jägenstedt, Darren Shen, blink-dev
Hi Philip, 

Just updating the issue status here:
There are now 14 issues filed on Typed OM. Most of them require editorial changes and were filed over the weekend or today. We closed > 45 issues last week while Tab was visiting Sydney. \o/

Also since a lot of people were asking about performance I have filed an issue on the spec regarding that, so we have one place to track that conversation.

Let us know if there are any other concerns that we should address?

Naina Raisinghani

unread,
Feb 4, 2018, 10:46:04 PM2/4/18
to Philip Jägenstedt, Darren Shen, blink-dev
Also forgot to mention 2 issues are also going to be discussed at a telecon this week: https://github.com/w3c/css-houdini-drafts/issues/610 and https://github.com/w3c/css-houdini-drafts/issues/574 

Florian Rivoal

unread,
Feb 5, 2018, 9:45:58 PM2/5/18
to Naina Raisinghani, Philip Jägenstedt, Darren Shen, blink-dev


On Feb 5, 2018, at 11:05, 'Naina Raisinghani' via blink-dev <blin...@chromium.org> wrote:

We closed > 45 issues last week while Tab was visiting Sydney. \o/

That both sounds like fantastic progress (congrats!) and like a good indication that the spec is not particularly stable yet, and that shipping may be premature.

It is very much possible that you got everything right or close enough to being right, and that the spec will not change much going forward. But with such a high rate of change, it's should to be a little while before all interested parties have a change to digest this. Unless all interested parties were in the same room as Tab and you last week, but then I'd question whether this has a sufficiently broad audience to get the wide review it needs.

—Florian

Rick Byers

unread,
Feb 6, 2018, 1:00:38 PM2/6/18
to Florian Rivoal, Naina Raisinghani, Philip Jägenstedt, Darren Shen, blink-dev
I share your concern that this spec isn't quite ready to ship yet.  But note that it's blink policy not to block shipping on an absence of review.  There's a significant amount of time from when we approve an intent to when it's possibly too late to disable due to new interop/compat risks being raised (a minimum of 8 weeks from feature freeze to stable cut date), and we've found that most significant problems tend to be easily addressible post-ship within the first year of a new feature anyway (low compat risk due to limited adoption).  So we don't currently see a compelling need to add additional delay to ensure there's been adequate review of the design of a new feature.


—Florian

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

Naina Raisinghani

unread,
Feb 6, 2018, 7:58:25 PM2/6/18
to Rick Byers, Florian Rivoal, Philip Jägenstedt, Darren Shen, blink-dev
To add to what to Rick said and reiterate, nearly all of the issues we have closed have been either:
  • Marked as resolved in a WG meeting, just not had spec written
  • Non-substantial edits - either clarify a term or link to other spec texts
  • Had PRs out for a long time, Tab being here was an impetus for him to review the PRs (Thanks Tab! :P)
We have always pushed the substantial issues to WG discussion (that is the best place to get consensus by far.) :) 

L. David Baron

unread,
Feb 6, 2018, 8:42:54 PM2/6/18
to Naina Raisinghani, Rick Byers, Florian Rivoal, Philip Jägenstedt, Darren Shen, blink-dev
I think a number of the issues are about cases where the spec isn't
yet complete enough or formal enough to lead to interoperable
implementations. (There are also some open issues in the spec text
itself of the same form, that don't have corresponding github
issues.)

Not resolving these issues before a second implementor implements
the spec would probably lead either to (1) lack of interoperability
or (2) to that implementor having to reverse-engineer Chrome's
behavior in a number of cases in order to get interoperability.

-David

On Wednesday 2018-02-07 00:58 +0000, 'Naina Raisinghani' via blink-dev wrote:
> To add to what to Rick said and reiterate, nearly all of the issues we have
> closed have been either:
>
> - Marked as resolved in a WG meeting, just not had spec written
> - Non-substantial edits - either clarify a term or link to other spec
> texts
> - Had PRs out for a long time, Tab being here was an impetus for him to
> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4BFB849A-6F0C-4D8F-93BB-6EC0F4F27B63%40rivoal.net?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.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOnwxys9KWpW1_gVZ1F9BXKuCjev9-XspPu%2B5XffriyneAdwSA%40mail.gmail.com.

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)
signature.asc

Philip Jägenstedt

unread,
Feb 7, 2018, 1:40:47 PM2/7/18
to Naina Raisinghani, Darren Shen, blink-dev
Hi Naina, sorry for the delay,

On the performance issue, I suppose it's a little bit concerning that "a common use case" is a bit slower with CSS Typed OM. I commented briefly on the object reuse option. What's possible can only be determined by trying so I won't speculate, but do you think anything changes if we find that CSS Typed OM really is slightly slower in common scenarios? What kind of advice would we want to give to web developers, a rule of thumb more helpful than always trying both and benchmarking?

Based on the list of closed issues it looks like good progress on the spec. Do those changes have corresponding tests, or perhaps some tentative tests that are now no longer tentative?

Are there still remaining issues where an interoperable second implementation would be difficult, or is the number of such issues now small and decreasing?

Philip Jägenstedt

unread,
Feb 7, 2018, 2:13:15 PM2/7/18
to L. David Baron, Naina Raisinghani, Rick Byers, Florian Rivoal, Darren Shen, blink-dev
Thanks for continuing to file issues, David!

Looking at the inline issues, there's just two, and "Define precisely which properties are list-valued and which aren’t, probably in an appendix" sounds like an important thing. Naina, Darren, can you give that a GitHub issue if it is something that needs spec'ing to match what your implementation does? (The other is about maybe adding API surface, which isn't a problem until it's implemented anywhere.)

David, of the open GitHub issues, are there any that seem extra important?

Naina, Darren, Tab, as the list of issues is burned down, the obvious question is when the interop risk is low enough, when could a second interoperable implementation be produced without much struggle? I couldn't start to spell this out in objective terms, and I think we should lean on your judgement of when we've past that point. Is that helpful? Not helpful?

Darren Shen

unread,
Feb 7, 2018, 9:04:13 PM2/7/18
to Philip Jägenstedt, Naina Raisinghani, blink-dev
Hi Philip,

Thanks for the questions. Replied inline:

On Thu, Feb 8, 2018 at 5:40 AM Philip Jägenstedt <foo...@google.com> wrote:
Hi Naina, sorry for the delay,

On the performance issue, I suppose it's a little bit concerning that "a common use case" is a bit slower with CSS Typed OM. I commented briefly on the object reuse option. What's possible can only be determined by trying so I won't speculate, but do you think anything changes if we find that CSS Typed OM really is slightly slower in common scenarios? What kind of advice would we want to give to web developers, a rule of thumb more helpful than always trying both and benchmarking?

Yeah, I think those are all good questions. So far, I can think of two use cases where Typed OM excels:
  1. When you need to manipulate complex CSS values like transforms. The cost of parsing transforms in JavaScript outweighs Typed OM overhead.
  2. When you create a Typed OM object once and repeatedly set it in a styleMap (e.g. in a rAF() callback).
I’ve started work on improving the performance of styleMap.get, which should make Typed OM the winner in that “common case” benchmark. I also have other ideas but they require more work. I think the design of the Typed OM API is already as performant as it could be given the circumstances, so I’m optimistic that investing time in optimising the implementation would yield many more use cases.

The best rule rule of thumb I can think of is probably: don’t create new Typed OM objects when you don’t need to (although I’m working on reducing this cost).

Based on the list of closed issues it looks like good progress on the spec. Do those changes have corresponding tests, or perhaps some tentative tests that are now no longer tentative?

So far we’ve been tracking spec changes with corresponding implementation/WPT changes. Hopefully in the future, we’ll accompany spec changes with test changes directly. Currently, most of the WPT should not be marked as tentative (due to bulk upstream). I’ve been working on cleaning this up and “untentativising” them.
 
Are there still remaining issues where an interoperable second implementation would be difficult, or is the number of such issues now small and decreasing?

I think the number is small and decreasing, but I’ll let Naina give the details.

Thanks,
Darren

Naina Raisinghani

unread,
Feb 7, 2018, 9:10:04 PM2/7/18
to Philip Jägenstedt, L. David Baron, Rick Byers, Florian Rivoal, Darren Shen, blink-dev
Hi Philip, 

On Thu, Feb 8, 2018 at 6:13 AM Philip Jägenstedt <foo...@google.com> wrote:
Thanks for continuing to file issues, David!

Looking at the inline issues, there's just two, and "Define precisely which properties are list-valued and which aren’t, probably in an appendix" sounds like an important thing. Naina, Darren, can you give that a GitHub issue if it is something that needs spec'ing to match what your implementation does? (The other is about maybe adding API surface, which isn't a problem until it's implemented anywhere.)

Filed this as issue 644, thanks for bringing that up! Filed an issue for updateAll() as well.


David, of the open GitHub issues, are there any that seem extra important?

Naina, Darren, Tab, as the list of issues is burned down, the obvious question is when the interop risk is low enough, when could a second interoperable implementation be produced without much struggle? I couldn't start to spell this out in objective terms, and I think we should lean on your judgement of when we've past that point. Is that helpful? Not helpful?

That's a good question, ideally a second interoperable implementation needs the following:

  • An unambiguous specification

  • A detailed suite of web platform tests that can be used as a basis for further implementation.


While Darren is keeping the test suite updated with spec/implementation, we have a few issues that need spec text (these IMO are the last issues that can lead to an ambiguous spec). These are namely:

  • 645,

  • 644,

  • 643,

  • 610 - Resolved in the WG today,

  • 574 - Resolved in the WG today,

  • 556.

  • Please note: I am not counting issues that have PRs out already.


The number of issues is small currently (18 open issues, 8 with PRs out) and we are working as fast as we can to bring them to 0.

Philip Jägenstedt

unread,
Feb 8, 2018, 10:22:35 AM2/8/18
to Darren Shen, Naina Raisinghani, blink-dev
On Thu, Feb 8, 2018 at 10:04 AM Darren Shen <sh...@chromium.org> wrote:
Hi Philip,

Thanks for the questions. Replied inline:

On Thu, Feb 8, 2018 at 5:40 AM Philip Jägenstedt <foo...@google.com> wrote:
Hi Naina, sorry for the delay,

On the performance issue, I suppose it's a little bit concerning that "a common use case" is a bit slower with CSS Typed OM. I commented briefly on the object reuse option. What's possible can only be determined by trying so I won't speculate, but do you think anything changes if we find that CSS Typed OM really is slightly slower in common scenarios? What kind of advice would we want to give to web developers, a rule of thumb more helpful than always trying both and benchmarking?

Yeah, I think those are all good questions. So far, I can think of two use cases where Typed OM excels:
  1. When you need to manipulate complex CSS values like transforms. The cost of parsing transforms in JavaScript outweighs Typed OM overhead.
  2. When you create a Typed OM object once and repeatedly set it in a styleMap (e.g. in a rAF() callback).
I’ve started work on improving the performance of styleMap.get, which should make Typed OM the winner in that “common case” benchmark. I also have other ideas but they require more work. I think the design of the Typed OM API is already as performant as it could be given the circumstances, so I’m optimistic that investing time in optimising the implementation would yield many more use cases.

The best rule rule of thumb I can think of is probably: don’t create new Typed OM objects when you don’t need to (although I’m working on reducing this cost).

Cool, and I see this landed now. I guess new results from Canary yesterday, perhaps? Or can you already say that it now wins in the common get+set case?
 
Based on the list of closed issues it looks like good progress on the spec. Do those changes have corresponding tests, or perhaps some tentative tests that are now no longer tentative?

So far we’ve been tracking spec changes with corresponding implementation/WPT changes. Hopefully in the future, we’ll accompany spec changes with test changes directly. Currently, most of the WPT should not be marked as tentative (due to bulk upstream). I’ve been working on cleaning this up and “untentativising” them.

Cool! Hope that tentative tests are working well enough in practice, please complain to me if the whole setup isn't great and we should make something great instead :)

Philip Jägenstedt

unread,
Feb 8, 2018, 10:37:23 AM2/8/18
to Naina Raisinghani, L. David Baron, Rick Byers, Florian Rivoal, Darren Shen, blink-dev
On Thu, Feb 8, 2018 at 10:10 AM Naina Raisinghani <nai...@google.com> wrote:
Hi Philip, 

On Thu, Feb 8, 2018 at 6:13 AM Philip Jägenstedt <foo...@google.com> wrote:
Thanks for continuing to file issues, David!

Looking at the inline issues, there's just two, and "Define precisely which properties are list-valued and which aren’t, probably in an appendix" sounds like an important thing. Naina, Darren, can you give that a GitHub issue if it is something that needs spec'ing to match what your implementation does? (The other is about maybe adding API surface, which isn't a problem until it's implemented anywhere.)

Filed this as issue 644, thanks for bringing that up! Filed an issue for updateAll() as well.


David, of the open GitHub issues, are there any that seem extra important?

Naina, Darren, Tab, as the list of issues is burned down, the obvious question is when the interop risk is low enough, when could a second interoperable implementation be produced without much struggle? I couldn't start to spell this out in objective terms, and I think we should lean on your judgement of when we've past that point. Is that helpful? Not helpful?

That's a good question, ideally a second interoperable implementation needs the following:

  • An unambiguous specification

  • A detailed suite of web platform tests that can be used as a basis for further implementation.


I think that's exactly right. Only caveat is that it's hard to say exactly how unambiguous and how detailed is enough.

While Darren is keeping the test suite updated with spec/implementation, we have a few issues that need spec text (these IMO are the last issues that can lead to an ambiguous spec). These are namely:

  • 645,

  • 644,

  • 643,

  • 610 - Resolved in the WG today,

  • 574 - Resolved in the WG today,

  • 556.

  • Please note: I am not counting issues that have PRs out already.


The number of issues is small currently (18 open issues, 8 with PRs out) and we are working as fast as we can to bring them to 0.


Looks like a pretty small and manageable list! Does burning it down require weekly WG telecons? I think that as soon as we can comfortably say that the existing known issues will be resolved before or shortly after the feature reaches the stable channel, then we're good.

Naina Raisinghani

unread,
Feb 8, 2018, 4:45:21 PM2/8/18
to Philip Jägenstedt, L. David Baron, Rick Byers, Florian Rivoal, Darren Shen, blink-dev
On Fri, Feb 9, 2018 at 2:37 AM Philip Jägenstedt <foo...@google.com> wrote:
On Thu, Feb 8, 2018 at 10:10 AM Naina Raisinghani <nai...@google.com> wrote:
Hi Philip, 

On Thu, Feb 8, 2018 at 6:13 AM Philip Jägenstedt <foo...@google.com> wrote:
Thanks for continuing to file issues, David!

Looking at the inline issues, there's just two, and "Define precisely which properties are list-valued and which aren’t, probably in an appendix" sounds like an important thing. Naina, Darren, can you give that a GitHub issue if it is something that needs spec'ing to match what your implementation does? (The other is about maybe adding API surface, which isn't a problem until it's implemented anywhere.)

Filed this as issue 644, thanks for bringing that up! Filed an issue for updateAll() as well.


David, of the open GitHub issues, are there any that seem extra important?

Naina, Darren, Tab, as the list of issues is burned down, the obvious question is when the interop risk is low enough, when could a second interoperable implementation be produced without much struggle? I couldn't start to spell this out in objective terms, and I think we should lean on your judgement of when we've past that point. Is that helpful? Not helpful?

That's a good question, ideally a second interoperable implementation needs the following:

  • An unambiguous specification

  • A detailed suite of web platform tests that can be used as a basis for further implementation.


I think that's exactly right. Only caveat is that it's hard to say exactly how unambiguous and how detailed is enough.

I completely agree, we can only get as close a state to unambiguous as possible and hope that developer feedback catches the rest of the issues. 

While Darren is keeping the test suite updated with spec/implementation, we have a few issues that need spec text (these IMO are the last issues that can lead to an ambiguous spec). These are namely:

  • 645,

  • 644,

  • 643,

  • 610 - Resolved in the WG today,

  • 574 - Resolved in the WG today,

  • 556.

  • Please note: I am not counting issues that have PRs out already.


The number of issues is small currently (18 open issues, 8 with PRs out) and we are working as fast as we can to bring them to 0.


Looks like a pretty small and manageable list! Does burning it down require weekly WG telecons? I think that as soon as we can comfortably say that the existing known issues will be resolved before or shortly after the feature reaches the stable channel, then we're good.

We just discussed the issues that needed WG input in a telecon today, so now the only blocker is us getting PRs landed. We are trying out very best to get these sorted out before the M66 branch point. 

Darren Shen

unread,
Feb 8, 2018, 4:49:26 PM2/8/18
to Philip Jägenstedt, Naina Raisinghani, blink-dev
On Fri, Feb 9, 2018 at 2:22 AM Philip Jägenstedt <foo...@google.com> wrote:
On Thu, Feb 8, 2018 at 10:04 AM Darren Shen <sh...@chromium.org> wrote:
Hi Philip,

Thanks for the questions. Replied inline:

On Thu, Feb 8, 2018 at 5:40 AM Philip Jägenstedt <foo...@google.com> wrote:
Hi Naina, sorry for the delay,

On the performance issue, I suppose it's a little bit concerning that "a common use case" is a bit slower with CSS Typed OM. I commented briefly on the object reuse option. What's possible can only be determined by trying so I won't speculate, but do you think anything changes if we find that CSS Typed OM really is slightly slower in common scenarios? What kind of advice would we want to give to web developers, a rule of thumb more helpful than always trying both and benchmarking?

Yeah, I think those are all good questions. So far, I can think of two use cases where Typed OM excels:
  1. When you need to manipulate complex CSS values like transforms. The cost of parsing transforms in JavaScript outweighs Typed OM overhead.
  2. When you create a Typed OM object once and repeatedly set it in a styleMap (e.g. in a rAF() callback).
I’ve started work on improving the performance of styleMap.get, which should make Typed OM the winner in that “common case” benchmark. I also have other ideas but they require more work. I think the design of the Typed OM API is already as performant as it could be given the circumstances, so I’m optimistic that investing time in optimising the implementation would yield many more use cases.

The best rule rule of thumb I can think of is probably: don’t create new Typed OM objects when you don’t need to (although I’m working on reducing this cost).

Cool, and I see this landed now. I guess new results from Canary yesterday, perhaps? Or can you already say that it now wins in the common get+set case? 

My change hasn't made it into Canary yet, but testing on ToT seems promising (although it's with a different computer). I'll update the performance GitHub issue when I can rerun the benchmark with the same setup.

Based on the list of closed issues it looks like good progress on the spec. Do those changes have corresponding tests, or perhaps some tentative tests that are now no longer tentative?

So far we’ve been tracking spec changes with corresponding implementation/WPT changes. Hopefully in the future, we’ll accompany spec changes with test changes directly. Currently, most of the WPT should not be marked as tentative (due to bulk upstream). I’ve been working on cleaning this up and “untentativising” them.

Cool! Hope that tentative tests are working well enough in practice, please complain to me if the whole setup isn't great and we should make something great instead :)

It's working great so far :) 

Naina Raisinghani

unread,
Feb 12, 2018, 11:20:12 PM2/12/18
to Darren Shen, Philip Jägenstedt, blink-dev
On Fri, Feb 9, 2018 at 8:49 AM Darren Shen <sh...@chromium.org> wrote:
On Fri, Feb 9, 2018 at 2:22 AM Philip Jägenstedt <foo...@google.com> wrote:
On Thu, Feb 8, 2018 at 10:04 AM Darren Shen <sh...@chromium.org> wrote:
Hi Philip,

Thanks for the questions. Replied inline:

On Thu, Feb 8, 2018 at 5:40 AM Philip Jägenstedt <foo...@google.com> wrote:
Hi Naina, sorry for the delay,

On the performance issue, I suppose it's a little bit concerning that "a common use case" is a bit slower with CSS Typed OM. I commented briefly on the object reuse option. What's possible can only be determined by trying so I won't speculate, but do you think anything changes if we find that CSS Typed OM really is slightly slower in common scenarios? What kind of advice would we want to give to web developers, a rule of thumb more helpful than always trying both and benchmarking?

Yeah, I think those are all good questions. So far, I can think of two use cases where Typed OM excels:
  1. When you need to manipulate complex CSS values like transforms. The cost of parsing transforms in JavaScript outweighs Typed OM overhead.
  2. When you create a Typed OM object once and repeatedly set it in a styleMap (e.g. in a rAF() callback).
I’ve started work on improving the performance of styleMap.get, which should make Typed OM the winner in that “common case” benchmark. I also have other ideas but they require more work. I think the design of the Typed OM API is already as performant as it could be given the circumstances, so I’m optimistic that investing time in optimising the implementation would yield many more use cases.

The best rule rule of thumb I can think of is probably: don’t create new Typed OM objects when you don’t need to (although I’m working on reducing this cost).

Cool, and I see this landed now. I guess new results from Canary yesterday, perhaps? Or can you already say that it now wins in the common get+set case? 

My change hasn't made it into Canary yet, but testing on ToT seems promising (although it's with a different computer). I'll update the performance GitHub issue when I can rerun the benchmark with the same setup.

Based on the updates on the performance GitHub issue, it looks like Typed OM is now on par / faster than CSSOM in the roundtrip example.
 

Based on the list of closed issues it looks like good progress on the spec. Do those changes have corresponding tests, or perhaps some tentative tests that are now no longer tentative?

So far we’ve been tracking spec changes with corresponding implementation/WPT changes. Hopefully in the future, we’ll accompany spec changes with test changes directly. Currently, most of the WPT should not be marked as tentative (due to bulk upstream). I’ve been working on cleaning this up and “untentativising” them.

Cool! Hope that tentative tests are working well enough in practice, please complain to me if the whole setup isn't great and we should make something great instead :)

It's working great so far :) 
 
Are there still remaining issues where an interoperable second implementation would be difficult, or is the number of such issues now small and decreasing?

I think the number is small and decreasing, but I’ll let Naina give the details.

All of the issues are on track to be closed by branch point. (We might leave the one regarding adding an updateAll() function  to a future release.) However, that doesn't block shipping. 

--
Darren and Naina

Philip Jägenstedt

unread,
Feb 13, 2018, 1:25:52 AM2/13/18
to Naina Raisinghani, Darren Shen, blink-dev
On Tue, Feb 13, 2018 at 11:20 AM Naina Raisinghani <nai...@google.com> wrote:
On Fri, Feb 9, 2018 at 8:49 AM Darren Shen <sh...@chromium.org> wrote:
On Fri, Feb 9, 2018 at 2:22 AM Philip Jägenstedt <foo...@google.com> wrote:
On Thu, Feb 8, 2018 at 10:04 AM Darren Shen <sh...@chromium.org> wrote:
Hi Philip,

Thanks for the questions. Replied inline:

On Thu, Feb 8, 2018 at 5:40 AM Philip Jägenstedt <foo...@google.com> wrote:
Hi Naina, sorry for the delay,

On the performance issue, I suppose it's a little bit concerning that "a common use case" is a bit slower with CSS Typed OM. I commented briefly on the object reuse option. What's possible can only be determined by trying so I won't speculate, but do you think anything changes if we find that CSS Typed OM really is slightly slower in common scenarios? What kind of advice would we want to give to web developers, a rule of thumb more helpful than always trying both and benchmarking?

Yeah, I think those are all good questions. So far, I can think of two use cases where Typed OM excels:
  1. When you need to manipulate complex CSS values like transforms. The cost of parsing transforms in JavaScript outweighs Typed OM overhead.
  2. When you create a Typed OM object once and repeatedly set it in a styleMap (e.g. in a rAF() callback).
I’ve started work on improving the performance of styleMap.get, which should make Typed OM the winner in that “common case” benchmark. I also have other ideas but they require more work. I think the design of the Typed OM API is already as performant as it could be given the circumstances, so I’m optimistic that investing time in optimising the implementation would yield many more use cases.

The best rule rule of thumb I can think of is probably: don’t create new Typed OM objects when you don’t need to (although I’m working on reducing this cost).

Cool, and I see this landed now. I guess new results from Canary yesterday, perhaps? Or can you already say that it now wins in the common get+set case? 

My change hasn't made it into Canary yet, but testing on ToT seems promising (although it's with a different computer). I'll update the performance GitHub issue when I can rerun the benchmark with the same setup.

Based on the updates on the performance GitHub issue, it looks like Typed OM is now on par / faster than CSSOM in the roundtrip example.

That's great!

Based on the list of closed issues it looks like good progress on the spec. Do those changes have corresponding tests, or perhaps some tentative tests that are now no longer tentative?

So far we’ve been tracking spec changes with corresponding implementation/WPT changes. Hopefully in the future, we’ll accompany spec changes with test changes directly. Currently, most of the WPT should not be marked as tentative (due to bulk upstream). I’ve been working on cleaning this up and “untentativising” them.

Cool! Hope that tentative tests are working well enough in practice, please complain to me if the whole setup isn't great and we should make something great instead :)

It's working great so far :) 
 
Are there still remaining issues where an interoperable second implementation would be difficult, or is the number of such issues now small and decreasing?

I think the number is small and decreasing, but I’ll let Naina give the details.

All of the issues are on track to be closed by branch point. (We might leave the one regarding adding an updateAll() function  to a future release.) However, that doesn't block shipping.

Thanks Naina and Darren, if you don't foresee any difficulties in resolving the issues, then I don't think there's anything to be gained by delaying further, especially as the relevant issues were discussed in the WG already. Your efforts to get spec, tests and implementation well aligned are exactly what we need to have features more interoperable out of the gate, and I hope we'll be proven right on that point when a second implementer comes along.

LGTM1

Chris Harrelson

unread,
Feb 13, 2018, 11:33:24 PM2/13/18
to Philip Jägenstedt, Naina Raisinghani, Darren Shen, blink-dev
LGTM2

Thank you for great work on shipping a high-quality implementation and accompanying spec/tests. All of it really make a difference!

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfQVYvf_CiYU2CmEoJ28DqNFUbB8-jvT8cvu%3Dc2O7aEcg%40mail.gmail.com.

Rick Byers

unread,
Feb 14, 2018, 8:59:44 AM2/14/18
to Chris Harrelson, Philip Jägenstedt, Naina Raisinghani, Darren Shen, blink-dev
LGTM3

Obviously this is a pretty big new feature, and so we should expect some amount of tweaking / improvements post-ship.  As long as we remain engaged with the other potential implementors and open to breaking changes (subject to known web compat constraints of course), then I think the benefits of shipping in 66 (eg. unblocking other Houdini features depending on it) outweigh the risks despite the ongoing spec discussions.


Naina Raisinghani

unread,
Feb 15, 2018, 12:19:57 AM2/15/18
to Rick Byers, Chris Harrelson, Philip Jägenstedt, Darren Shen, blink-dev
Hi folks, 

Thank you for the LGTMs and the appreciation of the effort going on here!
We definitely intend to keep on top of issues (both in the implementation and spec) filed by other implementors and people testing out Typed OM. 

Will update this thread with more news as we have it. 

Thank you again!


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

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

Boris Zbarsky

unread,
Feb 15, 2018, 1:23:47 PM2/15/18
to blink-dev
On 2/8/18 10:37 AM, 'Philip Jägenstedt' via blink-dev wrote:
> I think that's exactly right. Only caveat is that it's hard to say
> exactly how unambiguous and how detailed is enough.

Dear all,

I've just started my review of CSS Typed OM, but it's already clear that
it contains a number of intentional contradictions with the Web IDL
specification. The IDL currently in the draft cannot be parsed by a
parser conforming to Web IDL, and it's redefining some Web IDL
constructs in incompatible (and severely underdefined) ways.

So far the most critical issues I've run into are:

https://github.com/w3c/css-houdini-drafts/issues/649
https://github.com/w3c/css-houdini-drafts/issues/650
https://github.com/w3c/css-houdini-drafts/issues/651
https://github.com/w3c/css-houdini-drafts/issues/652

My understanding last I checked was that Blink's implementation of
maplikes didn't match the IDL spec very well, which might explain why
this wasn't caught earlier.

I'll continue with my review, but the specification as currently written
is not implementable without either major changes to it, or to Web IDL,
or likely to both, and a lot of clarification work.

-Boris

Boris Zbarsky

unread,
Feb 15, 2018, 1:28:02 PM2/15/18
to blink-dev
On 2/15/18 1:23 PM, Boris Zbarsky wrote:
> I'll continue with my review, but the specification as currently written
> is not implementable without either major changes to it, or to Web IDL,
> or likely to both, and a lot of clarification work.

To be clear, this is just referring to the StylePropertyMap parts; I
haven't gotten past those parts yet. ;)

-Boris

Boris Zbarsky

unread,
Feb 15, 2018, 2:58:17 PM2/15/18
to blink-dev
On 2/15/18 1:23 PM, Boris Zbarsky wrote:
> The IDL currently in the draft cannot be parsed by a
> parser conforming to Web IDL

Note that at least in some cases (e.g.
<https://github.com/w3c/css-houdini-drafts/issues/658>) this wasn't
caught because Blink's IDL did not match the spec's IDL...

-Boris

Naina Raisinghani

unread,
Feb 15, 2018, 10:17:08 PM2/15/18
to Boris Zbarsky, blink-dev
Hi Boris, 

Thanks for taking the time to take a look at the spec and filing such detailed issues. We appreciate the cross browser effort to make sure we ship an interoperable implementation! 

On Fri, Feb 16, 2018 at 5:23 AM Boris Zbarsky <bzba...@mit.edu> wrote:
On 2/8/18 10:37 AM, 'Philip Jägenstedt' via blink-dev wrote:
> I think that's exactly right. Only caveat is that it's hard to say
> exactly how unambiguous and how detailed is enough.

Dear all,

I've just started my review of CSS Typed OM, but it's already clear that
it contains a number of intentional contradictions with the Web IDL
specification.  The IDL currently in the draft cannot be parsed by a
parser conforming to Web IDL, and it's redefining some Web IDL
constructs in incompatible (and severely underdefined) ways.

Tab had made a recent switch to maplike behaviour, which we hadn't switched in our native implementation, which is why the WebIDL specified in the spec and the Blink implementation didn't match. (Side note: thanks for making that catch!) 
Hopefully, these issues should have been dealt with by Tab reverting back to the iterable behaviour for StylePropertyMap. 

I understand that you are still reviewing the spec, and we are triaging your issues and addressing the easier fixes as we do so. Hopefully, we should address all of your issues ASAP.
 
My understanding last I checked was that Blink's implementation of
maplikes didn't match the IDL spec very well, which might explain why
this wasn't caught earlier.

I'll continue with my review, but the specification as currently written
is not implementable without either major changes to it, or to Web IDL,
or likely to both, and a lot of clarification work.

Again, thank you for the review! :) As an update, there are currently 24 open issues on TypedOM, the issues are broken down as follows:

  • 10 PRs out for relevant spec changes

  • 7 of them require only spec change (no implementation change required in Blink).

  • 7 of them require implementation change to Blink - these have corresponding issues filed on Blink already

  • 4 of them are feature requests that don't block shipping



-Boris

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/6ai8np0DSOA/unsubscribe.
To unsubscribe from this group and all its topics, 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/c85942fe-ef34-84a2-030d-cf593399f89d%40mit.edu.

Boris Zbarsky

unread,
Feb 16, 2018, 11:30:02 AM2/16/18
to Naina Raisinghani, blink-dev
On 2/15/18 10:16 PM, 'Naina Raisinghani' via blink-dev wrote:
> Hopefully, these issues should have been dealt with by Tab reverting
> back to the iterable behaviour for StylePropertyMap.

Naina,

That seems likely. I'll circle back to look at those bits once I get
through the rest of the spec... Probably not until end of next week,
given other commitments.

I appreciate the fast responses on the issues I filed!

-Boris

Darren Shen

unread,
Feb 28, 2018, 7:49:31 PM2/28/18
to Naina Raisinghani, Rick Byers, Chris Harrelson, Philip Jägenstedt, blink-dev
Hi folks,

Just updating the thread with the implementation status. As a first pass, we're shipping Typed OM for a subset of ~50 properties used on more than 50% of page loads. Hopefully this will be enough for developers to play with and get feedback.

We still have some open implementation bugs, but most of these should not cause backwards-compat/interop issues when we fix them in M67. Supporting the remaining properties might take longer as we need to spec and test them, but we can roll them out iteratively.

Thanks!

Eric Bidelman

unread,
Feb 28, 2018, 8:06:39 PM2/28/18
to sh...@chromium.org, Naina Raisinghani, Rick Byers, Chris Harrelson, Philip Jägenstedt, blink-dev
On Wed, Feb 28, 2018 at 4:49 PM Darren Shen <sh...@chromium.org> wrote:
Hi folks,

Just updating the thread with the implementation status. As a first pass, we're shipping Typed OM for a subset of ~50 properties used on more than 50% of page loads. Hopefully this will be enough for developers to play with and get feedback.

Are the 50 properties documented somewhere? If not, can we document it :)
 

PhistucK

unread,
Mar 1, 2018, 12:21:46 PM3/1/18
to Eric Bidelman, Darren Shen, Naina Raisinghani, Rick Byers, Chris Harrelson, Philip Jägenstedt, blink-dev
Idea - do not ship (or implement, unless it is too late ;)) Typed OM for any prefixed CSS property.


PhistucK

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

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

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGW2wGF_YPO_-aD9wXjwpGCR-GVe1HrKLfRXfARowtP9bN8%3DRA%40mail.gmail.com.

Darren Shen

unread,
Mar 2, 2018, 12:56:35 AM3/2/18
to PhistucK, Eric Bidelman, Naina Raisinghani, Rick Byers, Chris Harrelson, Philip Jägenstedt, blink-dev
Hi Eric, good idea. I've added a README containing a list of properties that we support.

Hi PhistucK, noted! We're not shipping Typed OM on any prefixed properties (it would be hard to write web platform tests for them).

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

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

--
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.

--
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.

Boris Zbarsky

unread,
Mar 2, 2018, 11:39:07 AM3/2/18
to blink-dev
On 2/16/18 11:29 AM, Boris Zbarsky wrote:
> That seems likely.  I'll circle back to look at those bits once I get
> through the rest of the spec...  Probably not until end of next week,
> given other commitments.

This clearly hasn't happened yet, but I am still working on making time
for more review on this spec. That said, I am fairly concerned at this
point about fundamental issues with the spec's actual goals and
structure which might make further review of the current state a
low-value activity. Specifically:

1) The behavior of how CSS Typed OM interacts with styling, or indeed
how any of the setters work, is fundamentally undefined. I just filed a
few issues [1] on simple examples of this, but it's pretty pervasive.

2) The basic premise of the spec is "The API exposed by this
specification is designed for performance rather than ergonomics" but as
far as I can tell for sets this spec involves serializing the data
structures created, then reparsing the string. Or something; it's hard
to tell, since the actual behavior is not defined (see point 1). But
that's my understanding of the goal per discussion in
<https://github.com/w3c/css-houdini-drafts/issues/718>. That doesn't
obviously see like a performance win over the script just pasting
together a string and parsing it via existing CSSOM APIs.

At this point I would really like to understand what use cases the spec
is aiming to address and why the spec's approach is the
performance-priotizing way to address them. Because that's not at all
obvious to me.

I know the intent to ship has already been approved, by the way. But
I'm not at all sure that the general API shape being used here actually
accomplishes the goals as I understood them. Which means maybe I
misunderstood the goals?

-Boris

[1] https://github.com/w3c/css-houdini-drafts/issues/719
https://github.com/w3c/css-houdini-drafts/issues/720
https://github.com/w3c/css-houdini-drafts/issues/722
https://github.com/w3c/css-houdini-drafts/issues/723

sh...@chromium.org

unread,
Mar 4, 2018, 8:42:51 PM3/4/18
to blink-dev
Hi Boris,

Thanks for filing those issues, they should be resolved now. As discussed in #718, Typed OM shouldn't need any parsing or serialization unless you directly give it a string or ask for a string.

Rune Lillesveen

unread,
Mar 8, 2018, 11:01:27 AM3/8/18
to Naina Raisinghani, blink-dev, Darren Shen
Sorry for entering late, but I have a couple of notes:

* The intent doesn't say, but looking at the implementation and crbug issues, you intend to ship support for a subset of properties. That is, "unsupported" properties are reified as CSSStyleValue. Is the intention to ship the APIs first and incrementally add reification for supported properties after that? How would that be interoperably used when browsers support different subsets of properties?

Can you say something about which subset you intend to support and why?

* The specification of reification for known properties seems unfinished in the spec. An example is that opacity is said to be reified as a CSSStyleValue, while the implementation (understandably) returns a CSSNumericValue. Another examples are counter-* properties which are specified to reify as a CSSKeywordValue, but that would leave the optional counter value out. It would be good to at least be confident we have specified the shipped properties as intended.

On Wed, Jan 24, 2018 at 6:07 AM Naina Raisinghani <nai...@chromium.org> wrote:

Contact emails

sh...@chromium.org | nai...@chromium.org


Explainer

Coming Soon™


Relevant links

Specification: https://drafts.css-houdini.org/css-typed-om-1/

Tag Review (hasn't been done yet): https://github.com/w3ctag/design-reviews/issues/223

Link to Intent to Implement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/KpCcUTv1UQ8


Summary

Converting CSSOM value strings into meaningfully typed JavaScript representations and back can incur a significant performance overhead. This specification exposes CSS values as typed JavaScript objects to facilitate their performant manipulation.


Debuggability

Most of the debugging features should work out of the box. Doesn’t need any added support.


Risks

Interoperability and Compatibility

  • Much like other Houdini APIs, the primary risk is that other browsers don’t implement this feature and it doesn’t become part of the wider web platform.

  • Firefox had started implementation work on CSS Type OM, but paused this work. There is a risk that our implementations will diverge due to changes in spec. However, their implementation is behind a flag and hence not considered feature complete.

  • There is a possibility of change in the spec text, which would then require a change in the implementation.


Edge: No signals

Firefox: Implementation progress here - https://bugzilla.mozilla.org/show_bug.cgi?id=1278697

Safari: No official signals (has shown verbal interest though)


Ergonomics

This API will be used in conjunction with the CSS Paint API.


Activation

We expect that this feature won’t have broad adoption initially. This is similar to other new CSS features which typically only have broad adoption after most of the evergreen browsers support it.


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

Yes.


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

Yes. All tests are upstreamed as tentative for now to allow for any possible changes in the spec and hence in the tests.

Link to wpt.fyi: https://wpt.fyi/css/css-typed-om


Link to entry on the feature dashboard

https://www.chromestatus.com/features/5682491075592192


Requesting approval to ship?

Yes

 
--
Rune Lillesveen

Darren Shen

unread,
Mar 13, 2018, 8:09:32 PM3/13/18
to Rune Lillesveen, Naina Raisinghani, blink-dev
On Fri, Mar 9, 2018 at 1:01 AM Rune Lillesveen <fut...@chromium.org> wrote:
Sorry for entering late, but I have a couple of notes:

* The intent doesn't say, but looking at the implementation and crbug issues, you intend to ship support for a subset of properties. That is, "unsupported" properties are reified as CSSStyleValue. Is the intention to ship the APIs first and incrementally add reification for supported properties after that? How would that be interoperably used when browsers support different subsets of properties?

Yeah that's the idea for the short term. We're planning to ship the remaining properties in M67 to avoid any interop problems. If any browser is intending on implementing Typed OM, please let us know so we can prioritise full L1 support.

I've also filed a GitHub issue being more explicit about the upgrade story.
 
Can you say something about which subset you intend to support and why?

A list of supported properties in M66 can be found hereWe picked them because they were used in > 50% of page loads or because they were trivial to support
 
* The specification of reification for known properties seems unfinished in the spec. An example is that opacity is said to be reified as a CSSStyleValue, while the implementation (understandably) returns a CSSNumericValue. Another examples are counter-* properties which are specified to reify as a CSSKeywordValue, but that would leave the optional counter value out. It would be good to at least be confident we have specified the shipped properties as intended.

Yep, I'm working through those right now. I've got a pull request for this here (there are still a few left). The counter-* properties haven't been spec'd yet.
Reply all
Reply to author
Forward
0 new messages