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

Re: [css3-2d-transforms][css3-images] <position> grammar is duplicated or points to the wrong spec

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 24 Jan 2012 07:44:40 -0800
Message-ID: <CAAWBYDDX60Un-naO48H5WNLZr8aDWNMXTkEgKuL6owS0Q_ni_Q@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
On Mon, Jan 23, 2012 at 11:33 PM, fantasai
<fantasai.lists@inkedblade.net> wrote:
> On 01/23/2012 11:17 AM, Tab Atkins Jr. wrote:
>> On Mon, Jan 23, 2012 at 9:20 AM, L. David Baron<dbaron@dbaron.org>  wrote:
>>> What's not obtainable using calc()?  Gecko's implementation of
>>> calc(10% + 5px) for background-position positions the 10% point of
>>> the image 5px to the left of the 10% point in the container.
>> Note that this is non-conforming with the current calc() spec, as
>> calc() will simply return a<length>, which is then interpreted as a
>> simple offset from the side.
> How is it non-conforming? Where does calc() say it computes to a <length>?

"A math expression has a resolved type, which is one of ‘<length>’,
‘<frequency>’, ‘<angle>’, ‘<time>’, or ‘<number>’. [...] If
percentages are accepted in the context in which the expression is
placed, a PERCENTAGE token has the type of the value that percentages
are relative to; otherwise, a math expression containing percentages
is invalid."

>> Gecko's behavior is the *right* one, of course.  We just need to spec
>> that using calc() in a<position>  has special behavior.  I've been
>> nitpicking other new properties to ensure that they don't run into
>> similar problems.
> We should put this in as an example, to make sure nobody else gets it
> wrong.

I've also created a wiki page for it at

Received on Tuesday, 24 January 2012 15:45:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:54 UTC