Open jbasoo opened 3 months ago
Especially but not only within justified alignment, the actual width of inter-word spaces is flexible. That seems to make sp
less usable than ch
.
Especially but not only within justified alignment, the actual width of inter-word spaces is flexible. That seems to make
sp
less usable thanch
.
@Crissov Good to know, how is the width calculated? Is the U+0020 character fully flexible in each instance or do browsers sometimes choose different space characters?
I don't think justification would be relevant here; an sp
unit would simply be based on the default advance of the space character of the first available font. It would be unaffected by things like kerning, letter-spacing, justification, contextual alternate glyphs, etc.
Whether a new unit is actually useful enough to justify its existence is unclear to me... in most cases, it seems like ch
is equally usable, and I think examples such as
Accurately increase word spacing
word-spacing: 1sp;
Accurately remove word spacingword-spacing: -1sp;
might be better addressed by allowing word-spacing
to accept percentage values, which would resolve against the default word spacing.
Regarding
While adding space glyph advance measure unit could be helpful, does this open the door to requests for units for other glyphs? If so, should an additional function to return the advance measure of any glyph be explored?
I'd be pretty hesitant to start down this road. We'd have to either decide what fallback value to use if the requested character isn't supported by the first available font (and if we're using fallbacks, the point of measuring specific characters may be largely defeated), or else deal with the issue that every character might resolve to a different font resource, depending on character coverage/unicode-range usage. Yes, the browser already has to deal with this when rendering text, but I don't think all that complexity should be pushed down into the definition of a CSS unit.
(We already have to deal with this for two specific characters to support the ch
and ic
units, which are defined in terms of "the font used to render it" rather than "the first available font". But let's not open this up to the entire Unicode space of a million codepoints just to resolve CSS units. If a page really wants to measure arbitrary characters, there are ways it can do so through JS.)
Related issue with some earlier discussion: #3232.
should an additional function to return the advance measure of any glyph be explored?
A potential problem here is that the CSS text is only referencing abstract characters, not specific glyphs (there is no way to directly reference specific glyphs in CSS, you only access them indirectly through combinations of characters, fonts, font features, etc). While in many cases it is a simple relationship where only 1 glyph represents 1 character, that is definitely not always true.
But if you did make a space unit for any arbitrary character based on the current font and text shaping situation (as with the ch
unit), and you’re going to allow for more complex mapping, why stop at one character and not allow multi-character text strings?
@jfkthame Thanks for the previous discussion reference. Percentage-based word-spacing
sounds like a nice way to solve that particular use case.
The word/letter-spacing
examples came up as I was exploring other potential use cases, however the initial scenario that prompted the proposal was usage of 0.Xch
as a rough space measure for gap
in flex/grid contexts when placing an icon next to text, such as on a button or in a tag list. It occurred to me that if the font rendered is not what the author expects then an estimated ch
value would probably be a bit off. Like you said about the ch
and ic
units, the value should be defined in terms of "the font used to render it." Considering network speeds and user preferences affect the rendered font, authoring a ch
estimate according to one font but the user potentially seeing another carries some risk.
Personally I only use JS as a last resort when it comes to layout, as it can be fragile, so I just use an approximate ch
at the moment.
While in many cases it is a simple relationship where only 1 glyph represents 1 character, that is definitely not always true.
@nicksherman That certainly would make things more difficult. Does ch
already take the entire text shaping situation into account?
why stop at one character and not allow multi-character text strings?
That's the slippery slope I thought might happen. The ch
unit prompted me to think that a space unit might be possible, then people might want units for other characters at which point a generic function would be more desirable, and then multi-character strings could be called for. It could open up some interesting possibilities but there's not much call for it and probably not the easiest to implement.
Background
There is currently no reliable way of knowing the advance measure of a space glyph. It can be estimated using
ch
unit, however this is not very precise and will change depending on whichever font from the stack is being rendered. Ansp
unit would improve ergonomics and could potentially open up new design possibilities, as outlined in the "Use Cases" section. Given that glyph metric units already exist (ex
,ch
), perhaps some of the technical details for this proposal have already been implemented.Proposal
Add
sp
andrsp
units which represent the advance measure of the space (U+0020) glyph. It may be desirable to follow the same logic as thech
unit spec, including fallbacks where it is impossible or impractical to determine the measure of the space glyph.Use Cases
word-spacing: 1sp;
word-spacing: -1sp;
letter-spacing: 3sp;
gap: 1sp;
Initial exploration of these uses can be found on Codepen.
Questions & Concerns
margin: am('M'); /* advance measure of the "M" glyph */
margin: am(' '); /* advance measure of the space glyph */
inline-size: max(am('W'), am('o'), am('r'), am('d')); /* faux-monospace using the largest advance measure from a list of glyphs */