You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-inline-3][css-text-3] Clarification on vertical-align shorthand and text boundary shaping #13277
Hey, I'm working on Firefox's implementation of the vertical-align shorthand (https://bugzil.la/1830771) and associated alignment-baseline and baseline-shift properties. I had a question on the expected behavior of the shorthand.
Text shaping must be broken at inline box boundaries when [...] vertical-align is not baseline.
I think this WPT itself was probably already wrong, because it tests the shaping break using vertical-align: 0, which CSS2 explicitly says is the same as baseline. I can fix this test during my implementation.
My primary question is about how baseline-source fits into this. If the css-text-3 condition of vertical-align is not baseline is accurate, then that means any non-initial value for baseline-source, alignment-baseline, and baseline-shift would break shaping. The last two are clear — a different baseline or a non-zero shift should break shaping. But should a non-auto value of baseline-source do that too? I would think that if changing it to first or last would have an actual effect on text shaping, then that means it would have been broken anyway.
If baseline-sourceshouldn't impact shaping, then does the css-text-3 specification need to change this vertical-align condition to specifically 'alignment-baseline' is not 'baseline' and 'baseline-shift' is not '0'?
Ah, thanks for clarifying on baseline-source. I'm curious about how the "applies to" change for baseline-source is implemented in practice -- does that mean that a declaration like baseline-source: first for an inline box is invalid, or that the declaration is valid but has no effect (this is my understanding)? If the latter, then is 'vertical-align' is not its initial value still ambiguous, since the specified / computed value would be the non-initial value? Maybe there's something about "used values" here, I'm not sure.
I'm curious about how the "applies to" change for baseline-source is implemented in practice -- does that mean that a declaration like baseline-source: first for an inline box is invalid, or that the declaration is valid but has no effect (this is my understanding)?
Valid but no effect, at least as far as effects baseline-source is trying to have.
If the latter, then is 'vertical-align' is not its initial value still ambiguous, since the specified / computed value would be the non-initial value? Maybe there's something about "used values" here, I'm not sure.
It wouldn't be ambiguous. vertical-align is a shorthand property, so if any of its longhands (including baseline-source) are not at their initial value, then vertical-align isn't either. So in a way, baseline-source does have an effect on inlines, but only indirectly.
Arguably, it'd mildly unfortunate to break shaping due to baseline-source when baseline-source itself has no effect, but then again, since it has no effect, it's unlikely to be used in this context, and so it shouldn't really matter either way.
We probably could make an exception, but if it wouldn't make a difference in practice, why bother?
Oh, got it. So nothing actually changes in the behavior of text shaping, since the initial value was already baseline. But rather we're expecting that authors wouldn't set baseline-source on inline boxes, so it doesn't actually matter. (I misunderstood the combination of edits, I thought it was trying to prevent the unfortunate effect.)
The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.
Proposed Resolution: Accept edits clarifying that that baseline-source doesn't apply to inline boxes
Activity
emilio commentedon Jan 2, 2026
cc @jfkthame
Bug 2008335 - Fix boundary shaping WPT to properly test non-initial b…
Fix boundary shaping WPT to properly test non-initial baseline-shift …
Fix boundary shaping WPT to properly test non-initial baseline-shift …
Bug 2008335 - Fix boundary shaping WPT to properly test non-initial b…
Bug 2008335 - Fix boundary shaping WPT to properly test non-initial b…
Bug 2008335 - Fix boundary shaping WPT to properly test non-initial b…
Fix boundary shaping WPT to properly test non-initial baseline-shift …
Bug 2008335 - Fix boundary shaping WPT to properly test non-initial b…
5 remaining items
fantasai commentedon Aug 11, 2026
Pushed up edits to this effect. Agenda+ Async to check that everyone is happy with this. CC @bfgeek
kbhomes commentedon Aug 11, 2026
Ah, thanks for clarifying on
baseline-source. I'm curious about how the "applies to" change forbaseline-sourceis implemented in practice -- does that mean that a declaration likebaseline-source: firstfor an inline box is invalid, or that the declaration is valid but has no effect (this is my understanding)? If the latter, then is'vertical-align' is not its initial valuestill ambiguous, since the specified / computed value would be the non-initial value? Maybe there's something about "used values" here, I'm not sure.frivoal commentedon Aug 13, 2026
Valid but no effect, at least as far as effects
baseline-sourceis trying to have.It wouldn't be ambiguous.
vertical-alignis a shorthand property, so if any of its longhands (includingbaseline-source) are not at their initial value, thenvertical-alignisn't either. So in a way,baseline-sourcedoes have an effect on inlines, but only indirectly.Arguably, it'd mildly unfortunate to break shaping due to
baseline-sourcewhenbaseline-sourceitself has no effect, but then again, since it has no effect, it's unlikely to be used in this context, and so it shouldn't really matter either way.We probably could make an exception, but if it wouldn't make a difference in practice, why bother?
kbhomes commentedon Aug 13, 2026
Oh, got it. So nothing actually changes in the behavior of text shaping, since the initial value was already
baseline. But rather we're expecting that authors wouldn't setbaseline-sourceon inline boxes, so it doesn't actually matter. (I misunderstood the combination of edits, I thought it was trying to prevent the unfortunate effect.)astearns commentedon Aug 17, 2026
The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.
Proposed Resolution: Accept edits clarifying that that
baseline-sourcedoesn't apply to inline boxesastearns commentedon Aug 24, 2026
RESOLVED: Accept edits clarifying that that
baseline-sourcedoesn't apply to inline boxes