[cssom] getComputedStyle and shorthands. #2529

emilio · 2018-04-11T10:05:14Z

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.

The text was updated successfully, but these errors were encountered:

emilio · 2018-04-11T10:06:28Z

cc @ericwilligers, which was filing bugs related to this.

emilio · 2018-04-11T10:10:08Z

This is very related to #1033.

FremyCompany · 2018-04-11T11:09:10Z

cc @FremyCompany

FremyCompany · 2018-04-11T11:11:00Z

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 · 2018-04-24T01:40:42Z

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 font is kept in computed style, but that's not something new anyway.

tabatkins · 2018-04-24T18:18:37Z

"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 · 2018-05-03T06:46:01Z

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 border and font.

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 · 2018-05-03T18:19:18Z

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 · 2018-05-03T22:49:20Z

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 · 2018-05-04T00:38:45Z

Right, but "dont' serialize this seemingly-random set of properties with no clear grouping" isn't nearly as convincing. ^_^

emilio · 2018-06-28T09:53:25Z

I'd like to discuss this at the F2F, given everyone would be around.

css-meeting-bot · 2018-07-04T07:18:17Z

The Working Group just discussed getComputedStyles and shorthands, and agreed to the following:

RESOLVED: all shorthands must show up in getComputedStyles

The 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]

This discrepency was discovered in a Fullscreen test: #13102 The spec issue for resolving this is: w3c/csswg-drafts#2529

foolip · 2018-09-27T10:38:25Z

I depended on this difference in behavior accidentally in a Fullscreen test, which @upsuper fixed in web-platform-tests/wpt#13102. I've created web-platform-tests/wpt#13238 as a test for that issue specifically. When this issue is resolved, please be sure to also merge that or a similar test. Filing bugs on the browsers that fail it would be great too.

These tests are made to start after onload so that iframe content doesn't change anymore: * fullscreen/api/element-ready-check-containing-iframe-manual.html * fullscreen/api/element-ready-check-not-allowed-manual.html * fullscreen/api/element-request-fullscreen-and-exit-iframe-manual.html * fullscreen/model/move-to-fullscreen-iframe-manual.html fullscreen/rendering/ua-style-iframe-manual.html is updated to check each subproperties individually rather than shorthand properties. fullscreen/api/element-request-fullscreen-timing-manual.html is changed so that the second test starts after an animation frame to work around Gecko throttling rAF before the first paint. Related bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1493878 w3c/csswg-drafts#2529

…, a=testonly Automatic update from web-platform-testsSeveral fixes to manual fullscreen tests (#13102) These tests are made to start after onload so that iframe content doesn't change anymore: * fullscreen/api/element-ready-check-containing-iframe-manual.html * fullscreen/api/element-ready-check-not-allowed-manual.html * fullscreen/api/element-request-fullscreen-and-exit-iframe-manual.html * fullscreen/model/move-to-fullscreen-iframe-manual.html fullscreen/rendering/ua-style-iframe-manual.html is updated to check each subproperties individually rather than shorthand properties. fullscreen/api/element-request-fullscreen-timing-manual.html is changed so that the second test starts after an animation frame to work around Gecko throttling rAF before the first paint. Related bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1493878 w3c/csswg-drafts#2529 -- wpt-commits: b3c7bf4261939cd1aba9b3264152a718b634ffa7 wpt-pr: 13102

…, a=testonly Automatic update from web-platform-testsSeveral fixes to manual fullscreen tests (#13102) These tests are made to start after onload so that iframe content doesn't change anymore: * fullscreen/api/element-ready-check-containing-iframe-manual.html * fullscreen/api/element-ready-check-not-allowed-manual.html * fullscreen/api/element-request-fullscreen-and-exit-iframe-manual.html * fullscreen/model/move-to-fullscreen-iframe-manual.html fullscreen/rendering/ua-style-iframe-manual.html is updated to check each subproperties individually rather than shorthand properties. fullscreen/api/element-request-fullscreen-timing-manual.html is changed so that the second test starts after an animation frame to work around Gecko throttling rAF before the first paint. Related bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1493878 w3c/csswg-drafts#2529 -- wpt-commits: b3c7bf4261939cd1aba9b3264152a718b634ffa7 wpt-pr: 13102 UltraBlame original commit: 4c97e39c26a7f0ea4a0714fc8a7c77e21734ed0e

christian-bromann · 2020-11-26T07:51:34Z

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 · 2021-09-10T07:44:02Z

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 · 2021-09-10T13:04:47Z

@foolip there's a resolution above (edits still needed), or what am I missing?

gsnedders · 2021-12-14T17:04:35Z

Which means that getComputedStyle(document.documentElement).font shouldn't be present, since it's a shorthand.

This doesn't actually follow from the current spec; font is a supported CSS property and therefore we generate:

partial interface CSSStyleDeclaration {
  [CEReactions] attribute [LegacyNullToEmptyString] CSSOMString font;
};

It does, however, mean that font doesn't appear as an indexed property.

The object’s supported property indices are the numbers in the range zero to one less than the number of CSS declarations in the declarations.

https://bugs.webkit.org/show_bug.cgi?id=234785 Reviewed by Sam Weinig. LayoutTests/imported/w3c: Mark WPT progressions. * web-platform-tests/css/css-animations/computed-style-animation-parsing-expected.txt: * web-platform-tests/css/css-animations/parsing/animation-computed-expected.txt: * web-platform-tests/css/css-pseudo/parsing/marker-supported-properties-expected.txt: Source/WebCore: There is an existing WPT for the "animation" shorthand in the computed style which we used to fail because we would simply not do any work to return the longhands compiled into a list. It seems that the CSS WG, per w3c/csswg-drafts#2529, is moving in the direction of specifying what happens with shorthands in computed style, so we're adding support for the "animation" shorthand. * css/CSSComputedStyleDeclaration.cpp: (WebCore::animationShorthandValue): (WebCore::ComputedStyleExtractor::valueForPropertyInStyle): Canonical link: https://commits.webkit.org/245670@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@287535 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=234785 Reviewed by Sam Weinig. LayoutTests/imported/w3c: Mark WPT progressions. * web-platform-tests/css/css-animations/computed-style-animation-parsing-expected.txt: * web-platform-tests/css/css-animations/parsing/animation-computed-expected.txt: * web-platform-tests/css/css-pseudo/parsing/marker-supported-properties-expected.txt: Source/WebCore: There is an existing WPT for the "animation" shorthand in the computed style which we used to fail because we would simply not do any work to return the longhands compiled into a list. It seems that the CSS WG, per w3c/csswg-drafts#2529, is moving in the direction of specifying what happens with shorthands in computed style, so we're adding support for the "animation" shorthand. * css/CSSComputedStyleDeclaration.cpp: (WebCore::animationShorthandValue): (WebCore::ComputedStyleExtractor::valueForPropertyInStyle): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@287535 268f45cc-cd09-0410-ab3c-d52691b4dbfc

gsnedders · 2022-03-17T22:13:42Z

@emilio per my prior comment, what edit do you believe is actually needed?

emilio · 2022-05-20T15:25:44Z

I think given that the spec (and browsers it seems) are correct

emilio added the cssom-1 Current Work label Apr 11, 2018

emilio added the Agenda+ F2F label Jun 28, 2018

astearns removed the Agenda+ F2F label Jul 4, 2018

upsuper mentioned this issue Jul 4, 2018

[cssom] Should shorthands in object from getComputedStyle be enumerable? #2877

Open

svgeesus mentioned this issue Aug 22, 2018

[css-fonts-4] Computed value for shorthand font: should describe serialization for font-variant-css21 and font-stretch-css3 #1671

Closed

upsuper mentioned this issue Sep 21, 2018

Several fixes to manual fullscreen tests web-platform-tests/wpt#13102

Merged

foolip added a commit to web-platform-tests/wpt that referenced this issue Sep 27, 2018

[cssom] Add a test for border shorthand property

dd48105

This discrepency was discovered in a Fullscreen test: #13102 The spec issue for resolving this is: w3c/csswg-drafts#2529

foolip mentioned this issue Sep 27, 2018

[cssom] Add a test for border shorthand property web-platform-tests/wpt#13238

Closed

birtles mentioned this issue Dec 14, 2018

Serialize animation in the right order web-platform-tests/wpt#14480

Merged

jdm mentioned this issue Feb 6, 2019

Shorthand properties of computed CSSStyleDeclaration don't return correct values servo/servo#22838

Closed

christian-bromann mentioned this issue Nov 26, 2020

element.getCSSProperty(property) returns null for Firefox webdriverio/webdriverio#6161

Closed

emilio closed this as completed May 20, 2022

Loirooriol mentioned this issue Feb 27, 2023

[cssom] How safe is it really to shorthandify properties? #8398

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[cssom] getComputedStyle and shorthands. #2529

[cssom] getComputedStyle and shorthands. #2529

emilio commented Apr 11, 2018

emilio commented Apr 11, 2018

emilio commented Apr 11, 2018

FremyCompany commented Apr 11, 2018

FremyCompany commented Apr 11, 2018 •

edited

Loading

upsuper commented Apr 24, 2018

tabatkins commented Apr 24, 2018

upsuper commented May 3, 2018 •

edited

Loading

tabatkins commented May 3, 2018

upsuper commented May 3, 2018

tabatkins commented May 4, 2018

emilio commented Jun 28, 2018

css-meeting-bot commented Jul 4, 2018

foolip commented Sep 27, 2018

christian-bromann commented Nov 26, 2020

foolip commented Sep 10, 2021

emilio commented Sep 10, 2021

gsnedders commented Dec 14, 2021

gsnedders commented Mar 17, 2022

emilio commented May 20, 2022

[cssom] getComputedStyle and shorthands. #2529

[cssom] getComputedStyle and shorthands. #2529

Comments

emilio commented Apr 11, 2018

emilio commented Apr 11, 2018

emilio commented Apr 11, 2018

FremyCompany commented Apr 11, 2018

FremyCompany commented Apr 11, 2018 • edited Loading

upsuper commented Apr 24, 2018

tabatkins commented Apr 24, 2018

upsuper commented May 3, 2018 • edited Loading

tabatkins commented May 3, 2018

upsuper commented May 3, 2018

tabatkins commented May 4, 2018

emilio commented Jun 28, 2018

css-meeting-bot commented Jul 4, 2018

foolip commented Sep 27, 2018

christian-bromann commented Nov 26, 2020

foolip commented Sep 10, 2021

emilio commented Sep 10, 2021

gsnedders commented Dec 14, 2021

gsnedders commented Mar 17, 2022

emilio commented May 20, 2022

FremyCompany commented Apr 11, 2018 •

edited

Loading

upsuper commented May 3, 2018 •

edited

Loading