[css-align] Should 'left' and 'right' really both fall back to 'start?

[dbaron]

The definition of left and of right alignment currently both say:

If the property’s axis is not parallel with the inline axis, this value behaves as start.

It seems less than ideal for both of them to fall back to start, since there may be an expectation that they end up on opposite sides.

I think one of them should probably fall back to end. I'm inclined to say it should be right, given that line-left is equivalent to (see mappings) inline-start whenever direction is ltr. This is for two reasons:

• I believe direction: ltr is more widely used (on the Web, and as a share of world population)
• I suspect the main use case for such fallback might be flipping the writing-mode of CJK content between vertical and horizontal, where I suspect direction: rtl to be particularly rarely used.

[fantasai]

I'm somewhat disinclined to do this, because there is no clearly correct mapping from left/right to block-start/block-end, and I'd like to avoid privileging LTR if there isn't a clear reason to do so.
Also, since Align (and Flexbox and Grid) are heavily biased towards flow-relative keywords, it's reasonably likely that an author will use a start/end pairing anyway--even more so if the author is accustomed to working with writing-modes.

That said, I would not object if the WG decided otherwise, so adding Agenda+.

[asmusf]

As a generic argument, the case of having two opposite values mapped to the same thing does appear counterintuitive and should therefore be avoided. I don't see where the special condition ("if the property's axis is not parallel") makes this case special enough to override the expectation that these are opposites. (However, I'm prepared to find out that I'm wrong on that after all).

The principle of not favoring one class of writing system over another only goes so far: absent any definite information you have to pick one; I'm not sure why this case is different.

If there's a particularly common scenario where the axes are not parallel, then the fallback should be selected based on what conditions are most common for that scenario. I don't know if @dbaron is correct in his second reason, but if that can be borne out, would be the stronger of the two in my view.

[fantasai]

Okay, so, we definitely have a better answer for some of these: we can use either the physical directions or the line-relative directions in order to get an answer that is perfectly reasonable and non-arbitrary in the majority of cases. We should fix the spec to do that (to use the physical mappings where they exist). However, there still remain some cases that can't be solved with either mapping.

The table below summarizes all the cases. L represents line-relative mapping, P represents physical mapping. ? represents cases that can't be mapped with either.

	`align-self`	`justify-self`	`align-content`	`justify-content`
Horizontal Parent Horizontal Self	↕ ??	↔ P=L	↕ ??	↔ P=L
Horizontal Parent Vertical Self	↕ ?	↔ P=L	↔ P	↕ L
Vertical Parent Horizontal Self	↔ P	↕ L	↕ ?	↔ P
Vertical Parent Vertical Self	↔ P	↕ L	↔ P	↕ L

The remaining cases are:

• align-self and align-content in a 100% horizontal writing mode environment. There is no non-arbitrary answer for mapping left/right along the vertical axis here. (?? in the table below)
• align-self in the case of a horizontal parent and vertical self. align-self maps against the parent’s writing mode normally, but we could map against the self in this case to get an answer.
• align-content in the case of a vertical parent and horizontal self. align-content maps against the self writing mode normally, but we could map against the self in this case to get an answer.
  That said, I'm currently of the opinion that we should treat the second two cases according to the logic of the first, though, to avoid crossing contexts.

So we can reduce the number of cases affected, but horizontal writing modes will still need an arbitrary mapping for left and right in the vertical axis.

[murata2makoto]

Fantasai wrote:

I'm somewhat disinclined to do this, because there is no clearly correct mapping from left/right to block-start/block-end, and I'd like to avoid privileging LTR if there isn't a clear reason to do so.

If different reasonable guys have different expectations, I would like to have no mapping. Ignoring properties is fine. Just my two cents.

[dbaron]

Contextually ignoring values in CSS isn't an option in CSS, though, since ignoring in CSS needs to happen at parse time, which is separated from value computation time.

[css-meeting-bot]

The CSS Working Group just discussed Should 'left' and 'right' really both fall back to 'start?, and agreed to the following resolutions:

• RESOLVED: leave the left and right values to fallback to start
• RESOLVED: Remove left and right from align-self and align-content in align L3

The full IRC log of that discussion

<dael> Topic: Should 'left' and 'right' really both fall back to 'start?
<dael> Github: https://github.com//issues/1403
<dael> fantasai: dbaron pointed out that left and right fallback to start if inline axis is not in the axis we're alining in. THe spec could have been smarter on this, we have physical and line-relative left and right. Betweent he 2 there's an answer to what's left and what's right. THere is a case of a completely hoz doc and align-self or align-content says left or right we don't have a way of saying if top or bottom is left or right. Spec says do start.
<dael> fantasai: dbaron says left for top and right for bottom. I'm of the opinion this is error and both should fall back to start. It's fairly arbitrary.
<dael> fantasai: ?? commented that they would like to have no mapping. That's more or less eq to start. THere's some differences.
<fantasai> e.g. whether or not to form a BFC
<dael> Rossen_: Proposal is fall back to start. fantasai explained why she believes this should be the case. Other opinions?
<dael> dbaron: My general concrn was it seems strange to have things calle dleft and right that can end up on the same side.
<dael> dbaron: It seemed like the case where you're likely to hit this is cjk where you author for vert or hoz and then decide to change it.
<dael> Rossen_: For floats left and right do we have similar?
<dael> fantasai: No because we use the line-relative left and right.
<dael> TabAtkins: I'll add that although you can come up with uses for left and right they were impl for being able to do legacy things. So it's okay for me if they're not great in some corner cases.
<AmeliaBR> To be clear, we'd never have left falling back to right and vice-versa. It is about left and right both falling back to "top", correct?
<dael> Rossen_: True. Although all existing content is legacy
<fantasai> yes
<dael> TabAtkins: No, I mean the legacy keyword.
<dael> Rossen_: Got you
<dael> fantasai: It's more. There are occations wher eyou want hte physeical direction
<dael> TabAtkins: We added it to support legacy keywrods. You can use it other ways, but that was the original reason. We wouldn't have had left and right if we weren't trying to do legacy
<dael> Rossen_: dbaron would you be okay if we resolved to fall back to start?
<dael> fantasai: We also could remove the keywords from align-self and align-content
<dael> dbaron: I'm okay with it.
<dael> Rossen_: What I hear is that we have generally seemed to be okay with falling back to start which doesn't mean it's great because you could have left and right map to the same thing. fantasai points out we make be hable to revisit having these values.
<dael> fantasai: We needed them for justify-content and -self. They were added...there were some cases where they would have meaning in align, but they're not critical.
<dael> Rossen_: I also think there are impl that are exposing those. Those are being used...removing left and right would be harder then fallack to start
<dael> fantasai: I don't htink so. Majority of people aren't using left and right in a veritical axis. Unless you're using veritical writing modes there is no left and right on align-self and align-content becuase there is no left and right
<dael> Rossen_: Perhaps.
<dael> Rossen_: What if we try to resolve on the fallback and then seperately decide on keeping them. I'm not just trying to kick that down the road, but I want to see usage
<dael> Rossen_: objections to: leave the left and right values to fallback to start
<dael> RESOLVED: leave the left and right values to fallback to start
<tantek> I thought dbaron
<tantek> 's point was an obj
<tantek> no?
<dbaron> I'm not objecting... I just thought it should be the other way.
<dael> fantasai: WOuld it make sense to resolve to drop them? We can add them later.
<tantek> fantasai: has a good point
<dael> fantasai: I can't imagine a case where this is a compat problem.
<tantek> wiser to drop now, reconsider adding in the future
<dael> TabAtkins: Should be safe to readd
<tantek> +1 fantasai proposal
<dael> Rossen_: I wouldn't be opposed. Let's make it a forcing function to those that have impl.
<dael> Rossen_: Obj to removing left and right from align tree
<fantasai> This would be to drop left/right from align-self and align-content
<fantasai> They would remain as part of justify-self and justify-content
<dael> RESOLVED: Remove left and right from align-self and align-content in align L3