W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2018

Re: [csswg-drafts] [cssom] getComputedStyle and shorthands.

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 04 Jul 2018 07:18:18 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-402386896-1530688697-sysbot+gh@w3.org>
The Working Group just discussed `getComputedStyles and shorthands`, and agreed to the following:

* `RESOLVED: all shorthands must show up in getComputedStyles`

<details><summary>The full IRC log of that discussion</summary>
&lt;florian> topic: getComputedStyles and shorthands<br>
&lt;florian> github: https://github.com/w3c/csswg-drafts/issues/2529<br>
&lt;florian> emilio: FF and Edge only support getComputedStyle on shorthands that used to be longhands, Blink supports more<br>
&lt;florian> emilio: shorthands in the computed style object are exposed as properties<br>
&lt;florian> emilio: I want to know what people want. Fine with changing, but it's work<br>
&lt;florian> ericwilligers: if it was a longhand, it would serialize<br>
&lt;florian> TabAtkins: it needs to<br>
&lt;florian> emilio: there are bugs on the grid shorthands<br>
&lt;florian> emilio: People have argued various ways.<br>
&lt;florian> TabAtkins: this is an obvious forward compat mistake<br>
&lt;florian> TabAtkins: all properties from now on should support it<br>
&lt;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<br>
&lt;florian> TabAtkins: which doesn't seem to be the case<br>
&lt;florian> dbaron: if it's not possible to represent, then we have to go for empty string<br>
&lt;florian> TabAtkins: that's fine<br>
&lt;TabAtkins> It's still forward-compatible; adding a new property to the shorthand will never make it, by *default*, stop serializing<br>
&lt;florian> emilio: there's also the question of computed values vs resolved values<br>
&lt;florian> heycam: it would be very weird if the longhands resolved but the shorthands didn't, so we should match<br>
&lt;florian> heycam: Edge is the only other browser not doing it. So Edge?<br>
&lt;florian> emilio: Edge, are you OK with doing it? the only ones you have on top of used-to-be-longhands are grid properties.<br>
&lt;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.<br>
&lt;florian> TabAtkins: going forward, we need<br>
&lt;florian> s/we need/we need to./<br>
&lt;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.<br>
&lt;florian> emilio: It can be done quite easily for lots of properties<br>
&lt;florian> Florian: can we resolve to do on all, even if priorities means it might take a while<br>
&lt;florian> Rossen: we need consistency, so let's have it everywhere.<br>
&lt;florian> RESOLVED: all shorthands must show up in getComputedStyles<br>
&lt;florian> xidorn: I wonder if you should see the shorthands in the iterator<br>
&lt;florian> xidorn: I think there's a usecase for copying computed values from one element to another, and they just iterate through<br>
&lt;florian> myles: This should be a separate issue.<br>
&lt;florian> [mumble mumble]<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2529#issuecomment-402386896 using your GitHub account
Received on Wednesday, 4 July 2018 07:18:22 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 19 September 2019 01:18:59 UTC