Open Bug 1299478 Opened 8 years ago Updated 2 years ago

Don't store computed CSSTransforms as specified (CSSValues)

Categories

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

defect

Tracking

()

People

(Reporter: manishearth, Unassigned)

References

Details

We currently store computed `transform`s as a nsCSSValueSharedList, i.e. exactly as specified.

https://dxr.mozilla.org/mozilla-central/source/layout/style/nsStyleStruct.h#2876

This is in contrast with most properties, which are stored in a more structured way, with <length>s being converted to nsStyleCoords, liberal usage of tagged unions, etc.

For transforms, all this conversion is done much later during layout.

Besides being an anomaly, this means that the transform property representation isn't self-documenting. It makes it harder to work with via stylo, too.


I'm not sure if it's really worth it to do this refactoring, though. Thoughts?
At the time the mSpecifiedTransform member was added in bug 531344, the CSS Transforms spec said that the computed value for transform is the same as the specified value.  Now it says that lengths in the transform items should be computed down to absolute values, as you would expect, so it might make more sense to come up with a distinct computed value representation for transform lists.

Also, it looks nsComputedDOMStyle returns a matrix() rather than the "specified value with lengths computed down" that the spec requires.  I'm not sure why that is.

David, is there any other particular reason to keep using the specified value here?
Flags: needinfo?(dbaron)
We could store it as a list, but it would have to be pretty much the same structure except for the leaves, since we need all of the function information for animation.  And writing all of the necessary types for that didn't seem to be worth the work.

I suspect other browsers return matrix() for getComputedStyle as well, but I'm not sure.  That also matches the way we stored the computed value before we supported transform animation -- or perhaps it was before we supported 3-D transforms.

(Do we have bugs if somebody does 'transform: inherit; font-size: 2em' when the parent has 'transform: translateX(3em)'?  Not that anybody would ever want that...)
Flags: needinfo?(dbaron)
Blocks: 1300006
Summary: Don't store computed CSSTransforms as specified (CSSValues) → stylo: Don't store computed CSSTransforms as specified (CSSValues)
This isn't a stylo bug, it's a gecko refactoring. Unsure if it's still worth it since the glue work (which this could have simplified) is done anyway.
Summary: stylo: Don't store computed CSSTransforms as specified (CSSValues) → Don't store computed CSSTransforms as specified (CSSValues)
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.