- From: François REMY via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Feb 2017 17:33:04 +0000
- To: public-css-archive@w3.org
My comment on the call was that we had chosen ```display: contents``` to behave like ```display: inline``` instead of ```display: none``` because that was how Firefox layouted the controls (it also seemed to have the preference of most authors in the room). I didn't check what the getComputedStyle function returned, but to be fair -- in Edge at least -- this function could return you any value independently of what we actually store in our formats, I don't think that is particularly relevant. If Gecko desires to store formats in one way that is not what a spec says the computed value is, it should be perfectly fine as long as there is some code in getComputedStyle that takes care of returning the expected value to authors, and they have function in their codebase like ```shouldComputedXyzabcBeAuto(style, boxSource)``` to adhere to existing spec text that conditions on if the computed value of Xyxabc is Auto. In Edge, getting a value through getComputedStyle will regularly trigger some new cascade pass for the asked property if the value stored in the formats isn't enough to synthetize the value to return. This is desirable also to prevent :visited styles from leaking out for properties that might be affected by that. In short, I am not entirely sure why there is so much push from gecko to "dumbify" the computed value of properties to the point they end up being the specified value in almost all the cases. The computed value is a concept, and is not tied to your implementation of formatting in any strong way. -- GitHub Notification of comment by FremyCompany Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/540#issuecomment-282062764 using your GitHub account
Received on Thursday, 23 February 2017 17:33:12 UTC