W3C home > Mailing lists > Public > www-style@w3.org > June 2012

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

From: Brad Kemper <brad.kemper@gmail.com>
Date: Sat, 23 Jun 2012 12:35:06 -0700
Message-Id: <52D49CB1-CAA4-4A12-B87D-20299A96A77B@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
To: Florian Rivoal <florianr@opera.com>

On Jun 22, 2012, at 2:02 AM, "Florian Rivoal" <florianr@opera.com> wrote:

> On Thu, 21 Jun 2012 19:49:19 +0200, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> If introducing -x and -y didn't prevent us from doing another useful
>>> thing (logical keywords), then yes, we introducing them would be best,
>>> which is why I was considering writing a spec for it. But we can't have
>>> both, and that troubles me.
>> 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. Doesn't something similar happen when non-none float values change display to block?
Received on Saturday, 23 June 2012 19:35:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC