- From: Florian Rivoal <florianr@opera.com>
- Date: Mon, 25 Jun 2012 15:48:06 +0200
- To: www-style@w3.org
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? That should be possible, but I find it quite ugly. > 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, but they don't change what values are valid to specify, or how valid values get dispatched to longhands. - Florian
Received on Monday, 25 June 2012 13:48:36 UTC