Re: [css-background] Add the *-x/y longhands to appropriate properties?

> On Apr 19, 2014, at 7:07 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
> 
>> On Sat, Apr 19, 2014 at 2:24 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> On Apr 18, 2014, at 3:31 PM, Tab Atkins Jr. wrote:
>>> Yes, the use-case is when, for whatever reason (watermarking?) you
>>> want the image to show up at the top of the element, but also at the
>>> "start" of the text, whichever that is.  So you'd do
>>> "background-position: top start;".
>> 
>> That still isn't a "whatever axis is vertical" situation. That's just bi-di if the vertical is also the block direction, since 'top' (being a vertical value) means the 'start' must refer to the horizontal, not necessarily the inline direction. Your example was:
>> 
>>> Where "start" means "in the start direction of whatever axis is vertical".
>> 
>> 
>> So, sometimes start could be vertical, and sometimes horizontal. But as near as I can tell, you would never not care which axis 'start' was assigned to.
> 
> I think you're misunderstanding me, 

I don't think so. 

> because this is the opposite of
> what I said.  

I quoted what you said. 

> It's the start direction in the vertical axis - by
> "whatever axis is vertical" I meant "whatever logical axis is vertical
> - block or inline".  It's relying on the convenient fact (cited as a
> pro when we finally made the decision on logical-axis names) that we
> can say "start" as a shorthand for "block-start and/or inline-start"

Right; I got that already.

> in cases where the axis is irrelevant or unambiguous.

I'm saying that whether an axis is "block-start and/or inline-start" is never irrelevant to a designer. At least, no cases come to mind, which is why I asked if you had a case. But I still haven't heard one. As near as I can tell, if I didn't care which logical axis is vertical - block or inline - it would be because I didn't care that much about how the background related to the text: above the text or to the left of it in Western text. That's pretty unlikely, but if true I might as well use physical properties, except to deal with bidi. 

>> On the other hand, maybe that's not a problem. Even though an author would never need to write 'bg-pos: left start' (aside from dealing with bi-di vertical text, I guess, if such a thing exists), perhaps there is no harm in letting it decompose into 'bg-pos-x: left; bg-pos-y: start;'.
> 
> No, there's at least some reason to do it, and it's nothing to do with
> bidi vertical text.

Like what?

>  (Such a thing does exist, btw.)

Vertical text can start on either the bottom or the top? OK, I'm not familiar with that, but I'll take your word for it. 

>> Except, that would also mean 'bg-pos-inline: left; bg-pos-block: start;' then. Does that mean in vertical text that 'bg-pos-inline: left', and therefore 'bg-pos-x: left;' is invalid?
> 
> No, the *-inline/block properties would only take logical keywords.
> The physical keywords don't have that convenient axis-agnostic form,
> and anyway, you only *need* one of the two property pairs to support
> mixtures.  (That is, since the physical properties allow mixing
> physical and logical keywords, we don't need to allow the logical
> properties to do the same, as it doesn't add anything.)

OK, so I guess 'bg-pos-y:start' would get mapped to 'bg-pos-y:top' and to 'bg-pos-block:start' once you knew the mode was horizontal-tb. Right?

>> Or are 'bg-pos-inline' and 'bg-pos-y' not quite aliases of each other? Do you maintain them as separate properties, so that 'bg-pos-inline: left' is invalid but 'bg-pos-x: left;' is still valid?
> 
> The physical and logical properties are aliases of each other, but
> *which* ones alias what is dependent on 'direction' and
> 'writing-mode'.
>  In practice, this means that you first run cascade
> for the wm-determining properties, then run cascade for everything
> else.  (We already do something equivalent to this in WK/Blink.  FF
> does something different, but which has identical effects I think.)

Yeah, I think that's the part that was missing. The resolving of the aliases is conditional upon resolving the mode first with a separate pass. 

>> Is this described anywhere?
> 
> In this thread right now, because we're proposing this behavior.

Well, it's been a fruitful discussion then.

Received on Monday, 21 April 2014 00:47:41 UTC