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: Aryeh Gregor <ayg@aryeh.name>
Date: Mon, 23 Jan 2012 11:04:31 -0500
Message-ID: <CAKA+Ax=n6toRu_vTEWNvPi-62VS8rTV2STF1gQdyVg-VGUkbSQ@mail.gmail.com>
To: Lea Verou <leaverou@gmail.com>, "L. David Baron" <dbaron@dbaron.org>
Cc: www-style list <www-style@w3.org>
On Sat, Jan 21, 2012 at 8:33 AM, Lea Verou <leaverou@gmail.com> wrote:
> It seems the grammar for <position> is duplicated in the definition of the `transform-origin` property [1], rather than being deferred to the one that can be found in css3-background [2]
> On the other hand, css3-images do try to point to its definition elsewhere, but they point to css3-values, which doesn't define it [3]
> [1]: http://dev.w3.org/csswg/css3-2d-transforms/#transform-origin
> [2]: http://dev.w3.org/csswg/css3-background/#the-background-position
> [3]: http://dev.w3.org/csswg/css3-images/#radial-gradients

The transform-origin syntax specified in the 2D transforms draft is
not actually implemented by browsers, AFAICT, which instead implement
the conflicting syntax for transform-origin specified in the 3D
transforms draft:


See especially:


On Sat, Jan 21, 2012 at 11:01 AM, L. David Baron <dbaron@dbaron.org> wrote:
> In 3-D transforms, on the other hand, the syntax is actually
> different since it allows a 3-D point (a value in x, y, and z).
> It's not necessarily clear to me how this should interact with the
> new background-position syntax -- it's perhaps a bad result of the
> suggestion I made to use the same syntax for both (when I was
> thinking only about 2-D).
> That said, I'm not sure transform-origin really needs to allow a 3-D
> point, given that transform-origin doesn't actually add
> functionality -- it just makes it easier to think about transforms
> in different ways -- the same effects can always be done using
> translate.

This might have been a reasonable argument at one point -- although
all the functionality of the enhanced 2D transform-origin can be
obtained with calc(), right?  But Gecko and WebKit both implement the
transform-origin from the 3D draft, so the ship has sailed.  The 2D
draft should drop the three- and four-argument versions.

(Also, the background-position syntax doesn't make sense to me.  It
allows "left 10% bottom 10%", which is the same as "10% 90%"; but
doesn't allow "10% 5px 10% 5px", which is an effect that's not
obtainable without using calc().  Nor does it allow things like "10%
bottom 5px" to mean "10% calc(100% - 5px)".  "[ left | right |
<percentage> ] [ <length> ]?" would make more sense to me than "[ left
| right ] [ <percentage> | <length> ]?".  But that's a side point.)
Received on Monday, 23 January 2012 16:05:33 UTC

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