W3C home > Mailing lists > Public > www-style@w3.org > April 2013

Re: [css21] What's the used value of left/right when overconstrained in relpos?

From: Sylvain Galineau <galineau@adobe.com>
Date: Mon, 29 Apr 2013 14:51:38 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Message-ID: <CDA429DF.3284%galineau@adobe.com>

On 4/29/13 1:32 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Mon, Apr 29, 2013 at 1:22 PM, Sylvain Galineau <galineau@adobe.com>
>> On 4/29/13 1:14 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>>On Mon, Apr 29, 2013 at 11:38 AM, Sylvain Galineau <galineau@adobe.com>
>>>> Fwiw the old box model module is rather clear about the constraint
>>>>  applying to the used value in the inline dimensions [1]. As you note,
>>>> interop confirms this. I don't think CSS21 or CSSOM ever clearly
>>>> what getComputedStyle() should return here though.
>>>I think you misunderstood my comment about interop.  I was saying the
>>>exact opposite - at least three browsers today do *not* apply the
>>>constraint fix-up to the used values (or at least, to what
>>>getComputedStyle() returns, which is supposed to be the used value).
>> No I got you right, it's just that I don't quite think of
>> getComputedStyle()
>> as returning the used value because of the situations where it does
>> the computed value, such as this one. Doesn't really change my point:
>> returning the computed value is the interop behavior in this case. Not
>> this would be a safe change.
>Ah, I gotcha.  So you're saying that getComputedStyle should be
>returning the computed value.
>Here's the problem: Chrome currently does that, but Firefox definitely
>resolves percentages (based on layout values) when returning a value
>for t/r/b/l in getComputedStyle.  I don't know IE's behavior, since
>I'm currently on my Linux box.

IE does the same. 

>So our choices are either:
>1. Change CSSOM to remove top/left/bottom/right from the used-value
>list, so it joins the rest of CSS in returning computed values
>(forcing at least Firefox, and maybe IE, to change behavior for
>2. Clarify 2.1 that the "ignore" thing has *no effect* on used values;
>it just means that the given property has no effect when doing layout.
> t/r/b/l remain as used-values in gCS().  (Requiring Chrome to change
>so that it resolves percentages, but we already have an in-flight
>patch to do this.)

I'd rather get rid of the 'ignore' bit entirely, if possible, since the
other bits you reference are pretty clear.

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
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
been made*. 

Not sure that clarifies things - it implies an extra stage of computation
for these properties - but it also describes the runtime behavior


Received on Monday, 29 April 2013 21:53:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:29 UTC