Repository navigation
[cssom] getComputedStyle and shorthands. #2529
Description
Currently https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle says:
declarations: All longhand properties that are supported CSS properties, in lexicographical order, with the value being the resolved value computed for obj using the style rules associated with doc.
Which means that getComputedStyle(document.documentElement).font shouldn't be present, since it's a shorthand.
This is inconsistent with https://drafts.csswg.org/cssom/#dom-cssstyledeclaration-getpropertyvalue, though which handles shorthands.
Should ComputedStyle.getPropertyValue handle shorthands? If so, should they be exposed as a property in the declaration object?
Right now answers from browsers to "does getPropertyValue handle shorthands?", and "are shorthands exposed as a property?" are:
- Firefox: no, no
- WebKit / Blink: yes, yes
- Edge: no, no
What should happen here?
Note that both FF and Edge have a special-case for overflow, which used to be a longhand.
Activity
emilio commentedon Apr 11, 2018
cc @ericwilligers, which was filing bugs related to this.
emilio commentedon Apr 11, 2018
This is very related to #1033.
FremyCompany commentedon Apr 11, 2018
cc @FremyCompany
FremyCompany commentedon Apr 11, 2018
I think "yes" looked like a not-great idea when css started.
But now that shorthands can have values that you cannot expose in the longhands (like
font:var(--heading-font)) the behavior of webkit/blink probably makes more sense.upsuper commentedon Apr 24, 2018
Variables cannot appear in result from getComputedStyle, so that's not an issue.
For Firefox, we do have a special case that system font on
fontis kept in computed style, but that's not something new anyway.tabatkins commentedon Apr 24, 2018
"Shorthands aren't present" was always a design mistake - it meant that the shape of the gCS result changes when we break a longhand apart into further sub-properties, "upgrading" it into a shorthand, so userland code depending on that property would break. Shorthands should always have been present in gCS, and we should update the spec to say so; the fact that we already have an impl doing this is a nice plus.
(The fact that the non-exposing browsers have an exception for one of the "upgraded" shorthands shows the problem with not exposing them from the get-go.)
upsuper commentedon May 3, 2018
I have an impression that not having shorthands in gCS result was also intended for forward compatibility. There might be a discussion with @dbaron three years ago, but I don't recall the reasoning exactly.
I would guess the reason is something like, when a new longhand property is added to a shorthand, and the new property contains some value which is not expressible in the shorthand, the shorthand may fail to serialize. If there is code relying on serialization of shorthand, they may fail unexpectedly in browsers with the new property, leading to webcompat issue and making it harder to ship some new properties. Obvious past examples may include
borderandfont.This argument may also apply to specified value as well, but my understanding is that computed value is usually more useful to interpret for scripts (since that's a step closer to the value engine actually uses), while specified value is often just used for setting. That means keeping serialization forward and backward compatible is probably more important for gCS than for specified value.
tabatkins commentedon May 3, 2018
While that's a reasonable concern, it's much less important for forward-compat than the one I gave. "Don't serialize shorthands at all" means you'll automatically break code that depends on the serialization of that property as soon as you ship the change turning a longhand into a shorthand. "Serialize shorthands" breaks zero code when you ship the new feature; it only breaks stuff if the page is further updated to take advantage of the new, unserializable, feature. At that point the maintainer can just fix that code as well (or otherwise work around it), since they're already there altering the page.
upsuper commentedon May 3, 2018
I agree that "don't serialize shorthands at all" is definitely not something we want. We at least need to serialize shorthands which were longhands.
tabatkins commentedon May 4, 2018
Right, but "dont' serialize this seemingly-random set of properties with no clear grouping" isn't nearly as convincing. ^_^
emilio commentedon Jun 28, 2018
I'd like to discuss this at the F2F, given everyone would be around.
css-meeting-bot commentedon Jul 4, 2018
The Working Group just discussed
getComputedStyles and shorthands, and agreed to the following:RESOLVED: all shorthands must show up in getComputedStylesThe full IRC log of that discussion
<florian> topic: getComputedStyles and shorthands<florian> github: https://github.com//issues/2529
<florian> emilio: FF and Edge only support getComputedStyle on shorthands that used to be longhands, Blink supports more
<florian> emilio: shorthands in the computed style object are exposed as properties
<florian> emilio: I want to know what people want. Fine with changing, but it's work
<florian> ericwilligers: if it was a longhand, it would serialize
<florian> TabAtkins: it needs to
<florian> emilio: there are bugs on the grid shorthands
<florian> emilio: People have argued various ways.
<florian> TabAtkins: this is an obvious forward compat mistake
<florian> TabAtkins: all properties from now on should support it
<florian> TabAtkins: and if we can, all the legacy shorthands should as well, when a value can be constructed if it's not a a webcompat problem
<florian> TabAtkins: which doesn't seem to be the case
<florian> dbaron: if it's not possible to represent, then we have to go for empty string
<florian> TabAtkins: that's fine
<TabAtkins> It's still forward-compatible; adding a new property to the shorthand will never make it, by *default*, stop serializing
<florian> emilio: there's also the question of computed values vs resolved values
<florian> heycam: it would be very weird if the longhands resolved but the shorthands didn't, so we should match
<florian> heycam: Edge is the only other browser not doing it. So Edge?
<florian> emilio: Edge, are you OK with doing it? the only ones you have on top of used-to-be-longhands are grid properties.
<florian> Rossen: I don't believe I've seen compat issues. I am reluctant to write a bunch of code for something that's not needed.
<florian> TabAtkins: going forward, we need
<florian> s/we need/we need to./
<florian> TabAtkins: for legacy props, it wouldn't be the end of the world if we didn't do it, but it would be inconsistant and unfortunate.
<florian> emilio: It can be done quite easily for lots of properties
<florian> Florian: can we resolve to do on all, even if priorities means it might take a while
<florian> Rossen: we need consistency, so let's have it everywhere.
<florian> RESOLVED: all shorthands must show up in getComputedStyles
<florian> xidorn: I wonder if you should see the shorthands in the iterator
<florian> xidorn: I think there's a usecase for copying computed values from one element to another, and they just iterate through
<florian> myles: This should be a separate issue.
<florian> [mumble mumble]
2 remaining items
Several fixes to manual fullscreen tests (#13102)
Bug 1492746 [wpt PR 13102] - Several fixes to manual fullscreen tests…
Bug 1492746 [wpt PR 13102] - Several fixes to manual fullscreen tests…
Bug 1492746 [wpt PR 13102] - Several fixes to manual fullscreen tests…
Bug 1492746 [wpt PR 13102] - Several fixes to manual fullscreen tests…
Bug 1492746 [wpt PR 13102] - Several fixes to manual fullscreen tests…
christian-bromann commentedon Nov 26, 2020
This inconsistency also affects WebDriver tests where users try to get the shorthand CSS property of an element resulting in different responses, see webdriverio/webdriverio#6161.
foolip commentedon Sep 10, 2021
I'm closing web-platform-tests/wpt#13238 as it's blocked on this issue, but when this is resolved it could be a starting point for tests.
emilio commentedon Sep 10, 2021
@foolip there's a resolution above (edits still needed), or what am I missing?
gsnedders commentedon Dec 14, 2021
This doesn't actually follow from the current spec;
fontis a supported CSS property and therefore we generate:It does, however, mean that
fontdoesn't appear as an indexed property.Support the "animation" shorthand property in the computed style
Support the "animation" shorthand property in the computed style
gsnedders commentedon Mar 17, 2022
@emilio per my prior comment, what edit do you believe is actually needed?
emilio commentedon May 20, 2022
I think given that the spec (and browsers it seems) are correct