Should vertical-align:middle behave differently when the dominant baseline is not alphabetic? #4495
Comments
dbaron
added
css-inline-3
dbaron
changed the title
|
The The remaining case is when the dominant baseline switches to something else than alphabetical via something else than that property. That can happen if writing-mode is vertical-* and text-orientation is upright or mixed, in which case the dominant baseline is central. That ability also didn't exist in css2.1's time. So, the text in CSS2.1 talks about "the baseline", but back then could either mean "the dominant baseline" or "the alphabetic baseline", as they used to be the same thing. I'd say css2.1 is more ambiguous than wrong. If we go with the interpretation that it meant alphabetical, then the behavior looks reasonable. Last time we discussed this seems to support that behavior as well. Css-writing-mode-3 too is more ambiguous than wrong, but looking carefully, I think it actually does hint in this direction. Section 4.4 says there are two cases where the dominant baseline is used:
Logically, since it's not one of these two cases, "the baseline" discussed in the definition of I'd say that the right thing to do at this point is to resolve the ambiguity in favor of the alphabetic baseline in css-inline-3 and to leave css-writing-modes alone. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<TabAtkins> Topic: vertical align:middle in vertical text<astearns> github: https://github.com//issues/4495 <TabAtkins> fantasai: Afaict from dbaron's description, issue is that v-a:middle has you find the point between the alphabetic baseline and the x-height, and call that "the middle", then use that for alignment <TabAtkins> fantasai: Apparently there's some impls that, in vertical modes, instead of doing that in a sideways fashion, take the central baseline. <TabAtkins> dbaron: I think Gecko does vertical-align:middle based on, not a font-derived central baseline, but a synthesized central baseline. <TabAtkins> fantasai: So I think we should clarify the spec to say you're using the alphabetic baseline even in vertical text. <TabAtkins> fantasai: *Not* the central or hanging or whatever the dominatn baseline is. <TabAtkins> fantasai: So you'll always find the same point. <TabAtkins> fantasai: But when text-orientation is upright, the x-height doesn't have a meaning in the transverse axis, so maybe use central then. <TabAtkins> jfkthame: What about when text orientation is mixed? <TabAtkins> fantasai: Then you're rotating the text, you can still get a meaningful x-height and align there. <TabAtkins> jfkthame: I disagree, this is mostly useful for CJK text and we should be centering. <TabAtkins> fantasai: Then just use the central baseline explicitly. <TabAtkins> fantasai: If that's what you want to change to, tho, we can do that. <TabAtkins> fantasai: So we have severa ldistinctions we make in vertical text.s <TabAtkins> fantasai: First is whether you're in horizontal or vertical typesetting. <TabAtkins> s/typesetting/typographic mode/ <TabAtkins> fantasai: Horizontal mode is trigger by w-m: sideways-rl <TabAtkins> fantasai: In that case we should ensure the conventions are a rotation from horizontal text <TabAtkins> fantasai: Within the vertical typographic modes (vertical-rl/lr modes), we have three text-orientation values. <TabAtkins> fantasai: uprgiht, sideways, mixed <TabAtkins> fantasai: If we want this "Middle" alignment to be avaible for a paragraph in vertical typographic mode, we need to define it the same was as in horiz mode, at the very least when t-o is sideways <TabAtkins> fantasai: But when t-o is upright, that definition is nonsensical. It'll have to be the central baselie. <TabAtkins> fantasai: For mixed, it's a question of do we want to match upright or sideways. <TabAtkins> fantasai: Since "middle" is this weird thing tailored to latin text, I say we should match it to how latin text works, which is the alphabetic/x-height thing. <TabAtkins> fantasai: If someone wants to use actually centrally-baselined stuff, they should say v-a:central; <TabAtkins> fantasai: Open to other opinions tho <TabAtkins> heycam: Kinda feel like I agree with jfkthame, where mixed is for primarily vertical with little bits of rotated horizontal text. So I think you want to align based on majority text. <TabAtkins> fantasai: This isn't a default keyword, you ahve to specifically request middle <TabAtkins> heycam: I see what you're saying, there's no other way to get that before. <TabAtkins> fantasai: So yeah, you'll get the correct (central-aligned) behavior by default. You have to explicitly say "middle" to get this behavior; I agree it's usually weird. <TabAtkins> dbaron: What I'm concerned about is that we don't add half the x-height to anything but the alphabetic baseline. <TabAtkins> dbaron: I think fantasai makes sense; this is something you'd use for a small image you want to line up with the text. <TabAtkins> dbaron: Since there's already a "central" value, and if there *is* an alphabetic baseline around to use, I think we should do fantasai's proposal. <TabAtkins> dbaron: The name is unfortnate, but we're stuck with it. <TabAtkins> jfkthame: 'central' keyword is new, right? <TabAtkins> fantasai: Yeah, we added it for CJK specifically here. <TabAtkins> dbaron: We don't implement it yet, I didn't realize it was there. But its existence influences my opinion here. <TabAtkins> jfkthame: So we're going to have to tell people to stop using middle for their cJK? <TabAtkins> dbaron: It doesn't really work there anyway, it's only good for bicameral scripts. <TabAtkins> astearns: So proposed resolution is to make the middle spot always be what middle uses, as long as the alphabetic baseline and x-height are in the relevant axis. <fantasai> middle should have been called x-middle <TabAtkins> RESOLVED: "vertical-align: middle" always uses halfway between alphabetic baseline and x-height, except in modes where the x-height is meaningless (vertical writing modes with upright text orientation) <dbaron> The followup question is whether the alphabetic | ideographic | central values are stable enough to implement. <TabAtkins> RESOLVED: In such "meaningless" cases, "middle" means the same as "central". |
In both the definition in CSS 2.1 and the definition in css-inline
vertical-align: middleis defined as:Nothing in the Inline-level alignment section of css-writing-modes appears to modify this definition.
Yet, as far as I can tell, this definition really makes sense primarily when the dominant baseline is alphabetic. If you're starting from an alphabetic baseline, adding half the x-height gives a position that could reasonably described as the "middle". If you're starting from a central baseline... I don't think it does.
In web-platform-tests/wpt@07210df @hshiozawa added tests to web-platform-tests that test this behavior for vertical text with a central baseline. Based on https://wpt.fyi/results/css/css-writing-modes it seems that these tests pass in Chrome (but no other engines). Mozilla bug 1220353 covers making them pass in Gecko.
We could try to implement this to pass these tests... but I'm hesitant to do so given that I don't see how the behavior makes sense.
The text was updated successfully, but these errors were encountered: