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: Mon, 30 Jan 2012 13:42:34 -0800
Message-ID: <CAAWBYDBkZiwMGAHFNDGAHTNTcdUDSLLuKQE1Sqb4D2TC0E3pyg@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, Brian Manthos <brianman@microsoft.com>, "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>, fantasai <fantasai@inkedblade.net>
On Thu, Jan 26, 2012 at 8:08 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Jan 24, 2012, at 1:08 PM, Sylvain Galineau <sylvaing@microsoft.com> wrote:
>> In that respect, I support
>> being consistent though I'm worried about changing calc() to make background-position
>> consistent having side-effects elsewhere calc() can be used. Might be an unwarranted
>> fear but I'd rather not change it again.
> Another option would be to force calc() to resolve to either a percentage or a length based on which unit is mentioned first in the expression. So for instance, if the background is 200px square, and you have this:
> background-position: calc(50% + 2px);
> then it would resolve to:
> background-position: 51%; /* which is 102px */
> But if you had this:
> background-position: calc(2px + 50%);
> then it would resolve to this:
> background-position: 102px;
> Hmm. Same end result, but different computed value? How'd that happen? It seems fairly easy to understand this way, even of I don't claim anything about intuitiveness.

Those aren't the same end-result.  Code up the situation you mention
(200px element, with bg-position being either 51% or 102px), and
you'll see.

Making calc()'s result be order-dependent for what should always be a
commutative operation (addition) sounds really bad.  Plus, it requires
annoying contortions to work with subtraction, where you'd have to
switch to addition of a negative number if you wanted to swap the

Received on Monday, 30 January 2012 21:43:29 UTC

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