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

On Mon, Jan 23, 2012 at 11:00 AM, L. David Baron <dbaron@dbaron.org> wrote:
> On Monday 2012-01-23 12:32 -0500, Aryeh Gregor wrote:
>> Everything is obtainable using calc() -- that's my point.  And I think
>> it's clearer using calc() anyway.  Why should we allow
>> "transform-origin: left 10px bottom 10px" when "transform-origin: 10px
>> calc(100% - 10px)" works?  If the problem is that "bottom" is more
>> readable than "100%", we should solve that by allowing "calc(bottom -
>> 10px)".
>
> I'm not crazy about the new background-position syntax; I'd be fine
> with just using calc() for this.

I'm not.  The fact that you can go from "left top" to "left 10px top
10px" is nice; having to go from "bottom right" to "left calc(100% -10
px) top calc(100% - 10px)" would be pretty bad. It also provides a
nice analogue to the existing 'bottom' and 'right' properties for
abspos.


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.

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.

Fantasai - this makes me think more strongly that we should go ahead
and spec <position> in Values 3.  Thoughts?

~TJ

Received on Monday, 23 January 2012 19:18:45 UTC