[css-inline-3] The behavior when one value is specified for text-box-edge

[kojiishi]

There was a web developer feedback to the Blink's experimental implementation for when one value is specified.

The current spec says:

If only one value is specified, both edges are assigned that same keyword if possible; else text is assumed as the missing value.

The feedback says, if only one value is specified, to assume the alphabetic under edge instead of text if the over edge is cap or ex, to make it more intuitive.

Does this look like a reasonable change? @fantasai @Clqsin45 @nt1m @argyleink @chrishtr @bfgeek

[fantasai]

Defaulting to alphabetic is a more aggressive setting, since alphabetic means you will almost definitely be clipping glyphs. I went with text as the default because if the author isn't strongly wanting to clip to the alphabetic baseline, I thought we should be more conservative. At least that was my thinking here.

It's also more symmetrical to use text: if you specify only alphabetic, then what should the top be? It shouldn't default cap because that has very poor i18n, since there are many scripts that use the alphabetic baseline, but their top edge is different from cap.

[kojiishi]

Defaulting to alphabetic is a more aggressive setting, since alphabetic means you will almost definitely be clipping glyphs. I went with text as the default because if the author isn't strongly wanting to clip to the alphabetic baseline, I thought we should be more conservative. At least that was my thinking here.

That makes sense, thank you for the background. I agree text is safer. cap and ex are "unsafe" values as you mentioned, so the suggestion to pick the unsafe under edge may be reasonable if we limit it only for these two values?

if you specify only alphabetic, then what should the top be?

Isn't it invalid to specify only alphabetic? That's our interpretation of the spec, and our current implementation rejects it. Did we miss something?

@michaeltaranto Thank you for your feedback, please see discussion here, we appreciate your comments if any.

[fantasai]

so the suggestion to pick the unsafe under edge may be reasonable if we limit it only for these two values?

cap is not so unsafe for many writing systems, since only accent marks go above it. For English, for example, basically nothing goes above the cap height except small bits of serifs etc. ex is definitely very aggressive, but I think we don't want to make an exception just for ex.

Isn't it invalid to specify only alphabetic? That's our interpretation of the spec, and our current implementation rejects it. Did we miss something?

Ah, no, that's my mistake. :) We could allow it, but I suppose there's no real use case. But that would allow re-ordering which might be convenient, so I'll open a separate issue.

[kojiishi]

cap is not so unsafe for many writing systems

"Many writing systems" sounds like a bit too strong to me, when all diacritical marks of Latin scripts, CJK glyphs, and all tall scripts are beyond cap.

But I don't have strong opinions either way. @michaeltaranto are you happy with the above responses?

[michaeltaranto]

Thanks for including me on this, and sorry for what seems like initial confusion in this issue. Just to clarify, I am not proposing the change the default bottom edge for all values to alphabetic.

The point I am making in the linked comment is that when a user opts to trim to cap or ex that should be the outcome. Both of these terms are measured from what has been defined in CSS as the "alphabetic baseline", so setting either cap or ex and not having the correct bottom edge is actually misleading.

I would propose that the outcome for single value text edges be as follows:

With the following updates to the value definitions in the spec:

Edge	Definition
text	Use the text-over baseline as the over edge and text-under baseline as the under edge.
cap	Use the cap-height baseline as the over edge and alphabetic baseline as the under edge.
ex	Use the x-height baseline as the over edge and alphabetic baseline as the under edge.

[fantasai]

@michaeltaranto For a lot of fonts, the ascent is actually much higher than the cap height. So while your chart looks very nice, it doesn't actually match reality since what you're describing as ascent+descent is actually not the set of metrics that you get with text. (This is a lot more true in fonts that range outside of the English alphabet.) The closest to it would probably be cap+text.

The text keywords match up to the text-top and text-bottom values of vertical-align, which matches to the boxes you see below:

The logic of matching it up to the cap and ex units does make sense. I just worry about people trimming more than they thought they were, if they are trying to only adjust the top line to cap to get the effect in your second diagram.

[michaeltaranto]

@fantasai 100% agree (this was part of my original feedback) — I was merely trying to follow the design presented in the draft spec (Figure 5) to keep the discussion here focused. I too disagree with the conflation of the ascent and cap height metrics, but something to address throughout the spec separately.

Worth noting, Figure 5 in the draft spec also has a mistake, the value in the middle example should be cap not text which was the cause of my mis-representation of text being ascent to descent.

I would say I find these comments above to be contradictory:

For a lot of fonts, the ascent is actually much higher than the cap height

For English, for example, basically nothing goes above the cap height except small bits of serifs etc

which as we are saying, the ascenders and other diacritic marks certainly do extend beyond cap height in many fonts.

Honestly i don't mind having to specify both edges, but i do find it a little confusing that CSS has decided to choose what terms it shares with typography and font metrics. For example, providing cap as a unit, trim edge etc and it not being relevant to all character sets, while diverging from baseline in favour of alphabetic to try and scope to some character sets (yes i have read the naming stuff discussion, and i agree with @jwssnr's comments).

I would love to see:

text-edge: cap baseline;

It's even illustrated as baseline in the spec images!

But hey, thats my opinion. Happy to discuss further, and appreciate all your time on this.

[fantasai]

Discussing with @kojiishi, our proposal is to just require specifying both edges, unless the keyword can be duplicated. This avoids any surprises from defaulting the second keyword to something unexpected; and we can relax the rule later if we want.

[fantasai]

@michaeltaranto The problem with baseline is that the baseline is changeable. For example vertical-align: baseline defers to the baseline specified by dominant-baseline (of which central is an option, and definitely not something you want to trim to).

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] The behavior when one value is specified for `text-box-edge` , and agreed to the following:

• RESOLVED: 2 values are required unless the single value provided can be doubled

The full IRC log of that discussion

<matthieud> fantasai: koji got developer feedback about when only one value specific for tex-box-edge it' s confusing that it default to text edge for the unspecified
<matthieud> fantasai: the reason the default is text because it's always valid, conservative value
<matthieud> fantasai: the other current keyword like alphabectif trim agressively
<matthieud> fantasai: we should not change the default for this reason
<matthieud> fantasai: but we can require 2 keywords
<kizu> +1 to requiring both
<matthieud> fantasai: in any case when that keywords can' t be double (like `cap cap` is not valid)
<matthieud> florian: the original design makes sense but not gonna object to change
<Rossen16> q?
<matthieud> PROPOSAL: 2 values are required unless the single value provided can be doubled
<florian> 0
<matthieud> RESOLVED: 2 values are required unless the single value provided can be doubled

[jensimmons]

I believe this resolution was a mistake, so I opened a new issue asking to revert it.
#11460