Re: [csswg-drafts] [css-inline-3] Baseline alignment of text (#5647)

“This alignment should be enabled by default, and is script-aware.” -- what exactly does that mean, and how are we going to get interop on it? Early versions of the text specs did default to undefined "automatic" behavior, but we changed to defined behavior so that authors could get predictable results.

“But this isn’t what they wanted. They wanted their B to hang, but here it’s not (apparently) hanging; it’s in some random place in the middle of the line.” Let's tweak this example a bit. Hanging baseline was intended for Indic, right? So let's throw in some Indic into this span, rendered in the primary font, along with some numerals because everyone uses numerals. Next, add in a few Greek letters in the fallback font. Wouldn't you want them to align with the numerals along the alphabetic baseline of the span? In this case, with more content in the box, the described behavior would actually make sense.

Now let's step away from Indic for a bit, as I've had various people argue about whether it does in fact use a hanging baseline or not, and let's look at an alternate baseline that definitely *is* used: the central baseline in vertical text. Stick a (sideways) non-CJK quotation or math formula in there, and you'll want to align the entire contents of that span on a dominant alphabetic baseline, not a central baseline, even though you want the span as an item to be centrally-aligned to the vertical text.

“[make alignment-baseline inherit and] delete dominant-baseline” Keep in mind also that `vertical-align: text-top | middle | text-bottom` maintain the default dominant baseline, even as they align the specified baseline of the child to the parent. We already have this divergent behavior between the alignment baseline of a box and the dominant baseline within it: we can't entirely get rid of it.

If a shorthand that sets `alignment-baseline` and `dominant-baseline` together on a box would be convenient, totally makes sense to add that. But I'm not convinced we can get rid of the non-inheriting property and just have an inheriting one that sets both the alignment and dominant baseline on a box.

“none disables baseline alignment for descendants.” There's no such thing as disabling baseline alignment. The default behavior aligns on the alphabetic baseline. That happens to correspond to aligning the zero coordinates so the text engine isn't thinking about it too hard, but it's still a type of baseline alignment.

“Even within a single line, I can imagine wanting something like font-size: 200% to automatically create new reference baselines.” It's very clear to me that a font-size change should trigger a resetting of the baseline tables. Otherwise when you try to align child content to the top or central or whatever baseline, it won't look like it's aligning to its surrounding content. It's just floating around somewhere random, as you say. This exactly the type of problem I wanted to avoid.

For the case where the font changes but the font size doesn't, it's less clear whether the baseline table should reset. But I'm not convinced that re-using the root inline's first available font’s baseline table throughout is the best default behavior; and if it's not clear, we may as well make the default behavior consistent with what happens on a font-size change.

As for the idea of having a single baseline table that punches through inline boxes, I can imagine some use cases for that exist, so a control to enable that isn't unreasonable. But I think we need to look at realistic use cases more carefully, as I'm not sure pulling the root inline's first available font through to the entire contents of the line is the right answer. We might need more control over how that baseline table gets constructed.

-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5647#issuecomment-769663019 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 29 January 2021 08:39:56 UTC