1278697 - (css-typed-om) [META] Implement CSS Houdini Typed OM Level 1 specification

Status: NEW

(Core :: CSS Parsing and Computation, enhancement, P3)

Description

[Jonathan Chan [:jyc]]

This bug would be resolved when we implement the CSS Typed OM specification, which exposes typed CSS values to JavaScript (see URL).

Comment 1

[Tantek Çelik]

Upgrading this to a metabug. 

This is a meta-bug to track our support for css-typed-om:
  https://www.w3.org/TR/css-typed-om-1/
  https://drafts.css-houdini.org/css-typed-om/ (editor's draft)

This bug will be marked as "Depends on" bugs that are needed to complete implementation of css-typed-om.  The dependency tree can be used to view a list of these dependencies.

Comment 3

[Gregory Pappas [:gregp]]

Is this still being worked on?

Comment 4

[Daniel Holbert [:dholbert]]

Not currently, no.

Comment 5

[trusktr]

Where is this in the priority list?

I really need it for https://lume.io: Custom Elements for 3D graphics (CSS and WebGL), where the CSS transforms are currently sent in via style attributes, but sending in numbers to the Typed OM will be way better.

Comment 6

[Anhtaih89]

Hello 👋🏼 — I'm Tai, an engineer at Webflow. Within this context, I'm a developer building a visual abstraction for HTML/CSS using the underlying browser APIs (like getComputedStyle). We would love to be able to leverage computedStyleMap to build some really cool stuff for our users, and are basically blocked until there is Firefox support for CSS Typed OM.

I also came here because we recently had some bugs due to changes to how getComputedStyle is apparently evolving, and was recommended by Lea Verou to use computedStyleMap for the "fix" (we had to find another way). Here is the github issue:

https://github.com/w3c/csswg-drafts/issues/8398#issuecomment-1570264185

Thank you!
Tai

Comment 8

[Jason Ho]

Has anybody tried to work on this?

I assume anybody can pick this up right?

Or is there some blocker people should know about?
like is the CSSOM specification weird or what?

Comment 9

[Sebastian Zartner [:sebo]]

I am not working for Mozilla, so take this with a grain of salt.

(In reply to Jason Ho from comment #8)

Has anybody tried to work on this?
Or is there some blocker people should know about?
like is the CSSOM specification weird or what?

At least Mozilla is positive about it, see https://mozilla.github.io/standards-positions/#css-typed-om. So there is probably only a priority/time constraint.

I assume anybody can pick this up right?

I guess so. Though the specification is also quite complex. So that's rather something for someone experienced in coding for Gecko.

Sebastian

Comment 10

[Emilio Cobos Álvarez (:emilio)]

There's no blocker (other than time and resources). Anybody can pick this up, I'd be happy to mentor / review patches / etc. We can sort out the complex bits as we get to them :)

Comment 11

[trusktr]

There's an issue here on performance:

https://github.com/w3c/csswg-drafts/issues/11567

Basically in Chrome and Safari there's no incentive to switch projects over to CSS Typed OM, when animating CSS styles of an element, because the performance is the same as modifying style attributes using style strings.

Maybe it is that Chrome and Safari browsers are incurring the cost of the number-to-style-string conversion, which is heavy. I believe that one of the main purposes of the CSS Typed OM API is performance: let us modify CSS state using numbers, for performant animation.

Theoretically a browser can optimize this if they wish (avoiding a number-to-style conversion until the user reads the style), and optimize sending numbers directly to the rendering implementation. Could the spec be updated to enforce this?