Re: [css4-background] background-position-x and background-position-y or logical directions

Am 21.06.2012 16:55 schrieb Florian Rivoal:
> Hi,
>
> IE and Webkit support background-position-x and background-position-y, and
> it is being used in the wild (primarily for sprites), so I was considering
> specifying so that we could have a solid basis to implementing it.
>
> However, if we do introduce this, it prevents us from introducing
> writing-mode sensitive logical position keywords.
>
> With physical directions, there is no problem
> background-position: bottom right;
> ->
> background-position-x: right;
> background-position-y: bottom;
>
> But this can't work:
> background-position: start head;
> ->
> background-position-x: ??;
> background-position-y: ??;
>
> The only solution I can think of is pretty ugly:
> background-position: bottom right;
> ->
> background-position-x: right;
> background-position-y: bottom;
> background-position-inline: auto;
> background-position-cross: auto;
>
> background-position: start head;
> ->
> background-position-x: auto;
> background-position-y: auto;
> background-position-inline: start;
> background-position-cross: head;
>
> This would need a precedence rule to deal with all the longhands being
> manually set to non auto values.
>
> If we don't care for this (ugly) workaround, I am afraid we have to
> decide between logical keywords and *-x / *-y.
>
> There are arguments in both directions.
>
> In favor of -x and -y:
> * they are already supported by 2 out of the 4 main engines, and have
> been for many years, so maybe we should pave the cow path and boost
> interoperability with existing content.
>
> Against -x and -y:
> * they are blocking another useful extension of background-position
> unless we resort to ugly workarounds
> * They can be simulated with variables, so we can live without them:
>
> For instance, here is a typical example of how they are used:
> .icon { background: url(sprite.png) 0 0 no-repeat; }
> #a { background-position-y: 0; }
> #b { background-position-y: -30px; }
> #c { background-position-y: -60px; }
> .icon:hover { background-position-x: -30px; }
> .icon:active { background-position-x: -60px; }
>
> This can be rewritten with variables:
> .icon { background: url(sprite.png) var(bg-x, 0) var(bg-y, 0) no-repeat;}
> #a { var-bg-y: 0; }
> #b { var-bg-y: -30px; }
> #c { var-bg-y: -60px; }
> .icon:hover { var-bg-x: -30px; }
> .icon:active { var-bg-x: -60px; }

IMHO the main issue about background-position is the fact that it does 
not allow to set values relative to the right and bottom edges of a box. 
Now, if introducing new keywords is a possibility, wouldn't it also be 
possible to introduce new property names instead? Such as:
background-position-top
background-position-right
background-position-bottom
background-position-left

If that introduces problems with the order of the shorthand property, it 
would maybe even be worth to think about leaving background-position 
unchanged (or even deprecate it), and introduce another property name, 
such as background-placement.

I am not sure, but would writing-mode sensitive keywords still be 
necessary if we had background-position-top, -right, -bottom, and -left? 
I assume that authors who write pages with varying writing modes (and 
directions) write separate stylesheets for them anyway, as they want to 
adjust borders, margins etc.

I am aware of the fact that this kind of stuff has been discussed 
before, but I can't really understand if background-position is extended 
without addressing the main flaw of it.

-- 
Markus

Received on Tuesday, 26 June 2012 12:20:43 UTC