- From: Sylvain Galineau <galineau@adobe.com>
- Date: Mon, 29 Apr 2013 16:29:36 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-style list <www-style@w3.org>
On 4/29/13 3:43 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: >On Mon, Apr 29, 2013 at 2:51 PM, Sylvain Galineau <galineau@adobe.com> >wrote: >> Though now I'm wondering if saying gCS() returns the computed value in >>this >> case is really true. Fwiw css3-box described it thus: >> >> "The used values of the above properties, except for any values that >> are ‘auto’, are calculated from the computed values, evaluating >> percentages. >> Then apply one of the following cases: […now follows the constraint >>fix-up >> steps that do not show up in getComputedStyle()...]" >> >> In other words, one could describe what's going on as: >>getComputedStyle() >> does return the used value *before any box model constraint adjustments >> have >> been made*. >> >> Not sure that clarifies things - it implies an extra stage of >>computation >> for these properties - but it also describes the runtime behavior >> reasonably >> well. > >Yeah, that value stage is called "not the used value". ^_^ >Introducing it, specifically to fix an interop issue in t/r/b/l, seems >like a ton of overkill. overflow: overkill; Agree. For CSS2.1 the change that makes most sense to me is to eliminate the bit about values being ignored and make sure the width prose aligns with the height prose i.e. it consistently states that the specified steps define the used value. Then CSSOM's job is to define the interop behavior of gCS(); here this means defining the set of properties for which it'll only resolve relative lengths and percentages and leave specified absolute lengths alone. Does that make sense?
Received on Monday, 29 April 2013 23:30:01 UTC