CSS Text Level 4: the `text-spacing` property and its longhands

[kojiishi]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: CSS Text Level 4
• Specification or proposal URL (if available): https://drafts.csswg.org/css-text-4/#text-spacing-property
• Explainer URL (if available): Chromium design doc 1, 2
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=289130
• Mozillians who can provide input (optional): @jfkthame @masayuki-nakano ?

Other information

[cosmic-zip]

yes

[jfkthame]

In principle this seems a reasonable/desirable feature, though I don't have a good sense of how great the demand is; Masayuki probably has a better idea of that, as it's focus is very much on Japanese & Chinese content. I don't know whether this is something that the average Japanese user sees as a serious quality concern, or more of a typographic refinement that sophisticated designers want but many readers hardly notice.

(There's also the French punctuation aspect, though the Chrome doc suggests this is less of a priority for them.)

From an implementation point of view, doing this in Gecko may be significantly tricky, because it will require adjustments to text shaping (spacing) after line-breaking, which our architecture doesn't currently support. Gecko reflow assumes that line-breaks can be set (and adjusted, e.g. when resizing a block) without affecting text-run shaping and measurements. So that'll need to change.

So IMO we should probably be positive about this from a standards point of view, but avoid implying any commitment to implement at this time; that would require an evaluation of challenges, priorities and resources.

[kojiishi]

Thank you @jfkthame, your comment is very helpful. Each implementer should haver their own different benefits/costs balance. I look forwad to your team concluding this feature is worth the cost.

For the implementation:

...may be significantly tricky, because it will require adjustments to text shaping (spacing) after line-breaking, which our architecture doesn't currently support.

I fully agree that adjusting text shaping (spacing) after line-breaking is tricky. Blink doesn't support it either. This feature can be implemented without doing it. If you decided this feature is worth taking a closer look, please feel free to ping me, I'm happy to discuss more.

[zcorpan]

Thanks @jfkthame.

@masayuki-nakano, do you have any additional considerations or comments?

[masayuki-nakano]

As a native Japanese language user, I have waited this better rendering over a decade! Thank you, @kojiishi -san for your work!

On the other hand, I'm not sure whether text-autospace can be implemented without performance regressions because ideographic character check is required for every character. Looks like Chromium implements the logic as-is. (ccing @makotokato -san) So I'd like to know how much performance regression occurred on Chromium. Similar slowdown should be accepted on Gecko too.

[kojiishi]

Glad to hear Gecko is positive, thank you.

On the other hand, I'm not sure whether text-autospace can be implemented without performance regressions because ideographic character check is required for every character. Looks like Chromium implements the logic as-is. (ccing @makotokato -san) So I'd like to know how much performance regression occurred on Chromium. Similar slowdown should be accepted on Gecko too.

Blink hasn't shipped the text-autospace yet, it's still a prototyping. From the prototype, the degradation in the layout micro benchmarks is roughly 2-3%. This may get worse if the spec becomes more complicated. The current prototype checks only at script boundaries, but the spec may include more cases at least for Chinese. I'll think about the optimization strategy once the spec discussion is more stabilized.

For text-spacing-trim, we see 2-4% degradation in the layout micro benchmarks. There are two approaches, one using halt/chws font features, one without. The latter is probably faster, but it doesn't allow font designers to tune the behavior, so we we went with the font feature approach.

From my experiences, differences like this in the layout micro benchmarks aren't visible to the overall page load performance, but we haven't got all the data yet.