Open Bug 137688 Opened 19 years ago Updated 26 days ago

getPropertyValue on computed style (getComputedStyle) does not do shorthand properties

Categories

(Core :: DOM: CSS Object Model, defect, P3)

defect

Tracking

()

People

(Reporter: bzbarsky, Assigned: boris)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [wpt-triaged])

Attachments

(1 file)

nsComputedDOMStyle should handle getPropertyValue asking for shorthands
Priority: -- → P5
Target Milestone: --- → Future
Blocks: 200499
Blocks: 201830
No plans to work on this any time in the foreseeable future, so to default owner.
Assignee: bz-vacation → general
Priority: P5 → --
Target Milestone: Future → ---
Duplicate of this bug: 395823
Duplicate of this bug: 479698
Assignee: general → nobody
QA Contact: ian → general
QA Contact: general → style-system
Duplicate of this bug: 962072
Attached file test.html
10 years later... Still no plan on fixing the bug?
Not until there's a spec for the behavior, at least, no, because until then there's no way to implement this: the behavior is not define.  The spec is being worked on.
Where is the spec being worked on, and is it possible to see the progress?
And note that there are computed values of some shorthands that cannot actually be represented as a value for the shorthand.  Not an issue for "padding", but definitely an issue for "border".
Duplicate of this bug: 1005447
Note that getPropertyCSSValue is supposed to return null for shorthands -- which is what we do for the shorthands that have always been shorthands -- but not the ones that were originally longhands.

There are plenty of non-representable values of shorthands -- that happens for specified style too -- and I believe the spec says to handle it the same way, by serializing to the empty string:
https://drafts.csswg.org/cssom/#dom-cssstyledeclaration-getpropertyvalue refers to
https://drafts.csswg.org/cssom/#serialize-a-css-value which says:
"If shorthand cannot represent the values of list in its grammar, return the empty string and terminate these steps."
(and that wording covers both computed and specified style).


That said:  what do other browsers do here?  Will we hit compatibility problems if we start supporting shorthands?
Duplicate of this bug: 889091
Duplicate of this bug: 58638
It looks like Chrome and Safari supports shorthands currently. I'm able to get appropriate serialized value on them. I think we should do the same too.
Duplicate of this bug: 1381646
Duplicate of this bug: 1448646
Duplicate of this bug: 1448656
This is sort-of easily-implementable without duplicating a lot of code by using the "uncomputing" machinery we already have for animations, and constructing a temporary declaration block to try serializing the shorthand with all the relevant declarations, I guess.
Duplicate of this bug: 1450301
Priority: -- → P3
As per [1] the CSSWG has resolved: "all shorthands must show up in getComputedStyles". The spec has yet to be updated to reflect the resolution, however.

[1] https://github.com/w3c/csswg-drafts/issues/2529#issuecomment-402386896
Duplicate of this bug: 1541483
Duplicate of this bug: 1574222
See Also: → 1574222

I may take a look at this once I finish Bug 1574222.

Whiteboard: [wpt-triaged]

[tweaking title to mention "getComputedStyle", for bugzilla-search-discoverability purposes]

Summary: getPropertyValue on computed style does not do shorthand properties → getPropertyValue on computed style (getComputedStyle) does not do shorthand properties
QA Contact: boris.chiou
Assignee: nobody → boris.chiou
QA Contact: boris.chiou

I'm thinking about what should we do for this bug. Perhaps we should drop SHORTHAND_IN_GETCS from ServoCSSPropList.mako.py, which makes "shorthand in gCS" be a default behavior.

There are various different cases. The current shorthand-in-getcs code doesn't work for all properties. In particular, this code won't do the right thing for:

  • Properties that depend on layout (like padding and margin).
  • Properties that are logical / non-animatable.

I haven't thought all this through, but for the first, I think ideally we'd fix ToResolvedValue for the relevant bits so that we can also remove all the C++-side implementations and CSSValue and so on. That may be a bit of work though, and depending on how many shorthands of the layout-affecting properties are there, we may want to punt on it and just implement them on C++. However it seems like there's a fair amount of them.

For the second we just need more generated code to go from resolved to specified value. Right now that code is reusing AnimatedValue::from_computed_value() and then AnimatedValue::uncompute. This makes assumptions that don't hold for all properties:

  • That resolved and computed values are the same.
  • That all properties are animatable.

All those assumptions don't hold for all shorthands. They hold for the shorthands we support right now though.

This bug is also problematic for WebDriver tests where "Get Element CSS Value" is being called with a shorthand css property resulting in different results for Chrome and Firefox (see e.g.: https://github.com/webdriverio/webdriverio/issues/6161).

Duplicate of this bug: 1690830
You need to log in before you can comment on or make changes to this bug.