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

On Jun 25, 2012, at 6:48 AM, "Florian Rivoal" <florianr@opera.com> wrote:

> On Sat, 23 Jun 2012 21:35:06 +0200, Brad Kemper <brad.kemper@gmail.com> wrote:
> 
>>>> Why not leave background-position-x and background-position-y physical, but let the values they accept depend on writing mode? Thus, if writing mode is vertical, then background-position-x can be head or foot, and if writing mode is horizontal, then background-position-x can be start or stop.
>>> 
>>> When you want to determine if background-position-x can accept head, or when
>>> you want to see if background-position:head should send its value to
>>> background-position-x or background-position-y, you're still only
>>> at the parsing stage.
>>> 
>>> To know the writing mode on an element, you need to have finished
>>> the parsing stage, and applied the cascade and looked up the computed
>>> value of the direction property on the relevant element.
>>> 
>>> This happens strictly after the parsing stage, to late to be used to
>>> influence the parsing of other properties.
>> 
>> I hadn't thought of that. But what if you did parsing and cascading, accepting all the logical values for both x and y indiscriminately, and then after the cascade determining if they made sense or not, and reverting them to initial if they didn't? You'd just need to cascade writing mode before background.
> 
> 
> Maybe we could do something like this:
> 
> background-position: head 10px start 20px;
> ->
> background-position-x: head 10px / start 20px;
> background-position-y: head 10px / start 20px;
> 
> Where at computed value time, we'd drop the irrelevant half based on the
> writing mode?

Yes, that's more or less what I had in mind. But if the author writes background-position-x, he could leave off the head value and slash, since it would ultimately be ignored anyway. When irrelevant bits are left off, then the parser expands it to something like this:

background-position-x: initial / start 20px;
background-position-y: head 10px / initial;

Which would then get expanded to (the parser dropping the irrelevant 'initial' part during expansion):

background-position: head 10px start 20px;


> That should be possible, but I find it quite ugly.

Well, authors wouldn't see it that ugly most of the time. If they used the shorthand, it would just make sense the way everyone would expect and understand. And when writing the longhand x and y, you would only write the part that mattered (which would what would end up as computed value anyway). The only ones to care about the intermediate value as you wrote it would be the implementors and the spec writers.

It would allow us to have our cake and eat it too.

>> Doesn't something similar happen when non-none float values change display to block?
> 
> I am not sure I understand the question, but if I do, no, it is
> different (unless we do the ugly thing I suggest above). The
> values of the float property change the effect and the computed
> value of display,

Thats the part I meant.

> but they don't change what values are valid
> to specify, or how valid values get dispatched to longhands.

Received on Monday, 25 June 2012 16:29:19 UTC