W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: [CSS3] background-position computed value.

From: Alexis Menard <alexis.menard@intel.com>
Date: Wed, 28 Nov 2012 18:58:26 -0300
Message-ID: <CAOaK9A=8RYZSuLXCSptZx4qiYD47bjG6q0SuPU0pHtU0A5za8g@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
On Nov 28, 2012 6:05 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:
>
> On 11/28/2012 12:16 PM, Menard, Alexis wrote:
>>
>> Hi,
>>
>> I’m a bit puzzled on the CSS3 computed style value for
background-position.
>>
>> In CSS 2.1 the computed value is defined as “ for <length> the absolute
value, otherwise a percentage”. It will always return
>> two values, so for example “left” will return 0% 50%, “30px 40px” will
return 30px, 40px. FF, Opera, and WebKit behaves like
>> this, always two values are returned, no keywords.
>>
>> Now let’s take the definition as in CSS3. “A list, each item consisting
of: two keywords representing the origin and two
>> offsets from that origin, each given as an absolute length (if given a
<length>), otherwise as a percentage”.
>>
>> So of course something like left 20px top 40px should return “left 20px
top 40px”.
>>
>> Now my question is what about the old behavior, let say
background-position was set like this : 30px 40px. Should it return
>> “30px 40px” as before or should it return “left 30px top 40px” to match
the definition but then break the backward
>> compatibility? I believe backward compatibility should be preserved and
then the specification wording is not accurate as you
>> may not get two keywords and two offsets every time.
>>
>> As it is today Opera returns the old computed values, a list of two
values and in the case of the new <position> type, the
>> computed value as described by the CSS3 spec.
>>
>> Any thoughts?
>
>
> It's a common point of confusion, but getComputedStyle() does not
> return the computed style. It returns something else. And the thing
> that it returns is generally serialized into its shortest form.
>
> ~fantasai

Ok sorry about misusing the vocabulary. I believe you guys understood what
I meant. So the shortest form for "left 30px top 40px" is 30px 40px and we
should return it rather than "left 30px top 40px"? "left 30px center"
should return 30px 50% rather than "left 30px top 50%"? If so I believe
(I'm home so I don't have the test cases under hands) but it goes against
what Opera already ship. From what I saw up to two values offsets they use
the old behavior (same as WebKit and FF) and three or four values are
constructed to match the new definition.

Thanks.

>

On Nov 28, 2012 6:05 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:
>
> On 11/28/2012 12:16 PM, Menard, Alexis wrote:
>>
>> Hi,
>>
>> I’m a bit puzzled on the CSS3 computed style value for
background-position.
>>
>> In CSS 2.1 the computed value is defined as “ for <length> the absolute
value, otherwise a percentage”. It will always return
>> two values, so for example “left” will return 0% 50%, “30px 40px” will
return 30px, 40px. FF, Opera, and WebKit behaves like
>> this, always two values are returned, no keywords.
>>
>> Now let’s take the definition as in CSS3. “A list, each item consisting
of: two keywords representing the origin and two
>> offsets from that origin, each given as an absolute length (if given a
<length>), otherwise as a percentage”.
>>
>> So of course something like left 20px top 40px should return “left 20px
top 40px”.
>>
>> Now my question is what about the old behavior, let say
background-position was set like this : 30px 40px. Should it return
>> “30px 40px” as before or should it return “left 30px top 40px” to match
the definition but then break the backward
>> compatibility? I believe backward compatibility should be preserved and
then the specification wording is not accurate as you
>> may not get two keywords and two offsets every time.
>>
>> As it is today Opera returns the old computed values, a list of two
values and in the case of the new <position> type, the
>> computed value as described by the CSS3 spec.
>>
>> Any thoughts?
>
>
> It's a common point of confusion, but getComputedStyle() does not
> return the computed style. It returns something else. And the thing
> that it returns is generally serialized into its shortest form.
>
> ~fantasai
>
Received on Wednesday, 28 November 2012 21:58:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:03 GMT