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
--
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.
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?
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?
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!
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.
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?
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?
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?
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.
> 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/CAMO7KM_1Jvc4gcZd%3DueaFswRZXQ657SMX5tWRQKmefAPXb3nVw%40mail.gmail.com.
--
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/CALPJ472JZV2O49x_1xXnA%2Bb5Cd2iNon1XJhq20C3nbC%2B%3DzVGvQ%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
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/
—Florian
--
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/4BFB849A-6F0C-4D8F-93BB-6EC0F4F27B63%40rivoal.net.
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?
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.
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:
- When you need to manipulate complex CSS values like transforms. The cost of parsing transforms in JavaScript outweighs Typed OM overhead.
- 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.
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.
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.
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:
- When you need to manipulate complex CSS values like transforms. The cost of parsing transforms in JavaScript outweighs Typed OM overhead.
- 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 :)
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:
- When you need to manipulate complex CSS values like transforms. The cost of parsing transforms in JavaScript outweighs Typed OM overhead.
- 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 :)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.
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:
- When you need to manipulate complex CSS values like transforms. The cost of parsing transforms in JavaScript outweighs Typed OM overhead.
- 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.
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-r7KwDKd14zKoXxKxXOjXYSRR_bqaM4pahxyYDs%3DpABQ%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/CAARdPYfQVYvf_CiYU2CmEoJ28DqNFUbB8-jvT8cvu%3Dc2O7aEcg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO7KM_3OeaXRw3hx0XOr%2Bv3WJf1W20E6%2ByZ9-ynC4hetm09Ow%40mail.gmail.com.
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.
--
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/CAOMQ%2Bw-r7KwDKd14zKoXxKxXOjXYSRR_bqaM4pahxyYDs%3DpABQ%40mail.gmail.com.
--
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/CAMO7KM_3OeaXRw3hx0XOr%2Bv3WJf1W20E6%2ByZ9-ynC4hetm09Ow%40mail.gmail.com.
--
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/CAGW2wGF_YPO_-aD9wXjwpGCR-GVe1HrKLfRXfARowtP9bN8%3DRA%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
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/CAARdPYfQVYvf_CiYU2CmEoJ28DqNFUbB8-jvT8cvu%3Dc2O7aEcg%40mail.gmail.com.
--
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/CAOMQ%2Bw-r7KwDKd14zKoXxKxXOjXYSRR_bqaM4pahxyYDs%3DpABQ%40mail.gmail.com.
--
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_3OeaXRw3hx0XOr%2Bv3WJf1W20E6%2ByZ9-ynC4hetm09Ow%40mail.gmail.com.
--
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.
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
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.