[css-text-4] Text-spacing is too strict

[litherum]

https://drafts.csswg.org/css-text-4/#text-spacing-property

The spec states:

ideograph-alpha
Creates 1/4em extra spacing between runs of ideographs and non-ideographic letters.

... and includes definitions of "ideographs" and "non-ideographic letters."

Later, the spec also provides required collapsing rules:

Set fullwidth opening punctuation half-width if the previous character is a fullwidth opening punctuation, fullwidth middle dot punctuation, or ideographic space (U+3000), or if the previous character is a fullwidth closing punctuation of an equivalent or larger font-size. Else set it full-width.
Set fullwidth closing punctuation half-width if the next character is a fullwidth closing punctuation, fullwidth middle dot punctuation, or ideographic space (U+3000), or if the next character is a fullwidth opening punctuation of a larger font-size. Else set it full-width.

When discussing this with our team of designers at Apple, it turns out that we have our own similar behavior for native text. Our design team at Apple does increase spacing between script changes and decrease spacing between adjacent punctuation on a line, and the details of how we do it are similar but don't exactly match JLREQ or CSS. We used JLREQ as an input to the design, but there were other inputs too. From speaking to our designers, it turns out the specific rules for exactly how much space to expand or shrink can vary from one design house to the next.

Therefore, I'd like to propose the following changes to the spec:

1. In the above description of ideographic-alpha and ideographic-numeric, change "Creates 1/4em extra spacing between" to "Creates extra spacing between."
2. Provide some wiggle room around what the UA determines as "ideographs" and "non-ideographic characters" for the purpose of this property. The spec should continue to state that the desire is to add spacing between ideographs and non-ideographic letters, but the spec should let the classification be UA-dependent.
3. Remove "(or the font has proportional fullwidth punctuation glyphs)." Fullwidth characters should be fullwidth; if they're not, the font is broken.
4. In the Fullwidth Punctuation Collapsing section, change "Set fullwidth ... punctuation half-width if the" to "Set fullwidth ... punctuation narrower". Similarly to above, allow some wiggle room around exactly which characters this rule applies to.
5. Also, modify the Fullwidth Punctuation Collapsing section to allow for extra UA-dependent or platform-dependent rules that are not present in the spec. These other rules should be allowed to affect non-punctuation characters.
6. All of these text-spacing rules should be locale-sensitive. When a UA sees lang="ja" on content, it should be free to modify the spacing differently than when it sees lang="zh-Hans".
7. Once the text-spacing rules are locale-sensitive, delete the punctuation value. Make the mechanism for opting-out of fullwidth punctuation collapsing also opt out of the French narrow no-break space thing.
8. Values ideographic-alpha and ideographic-numeric improve typography, and should be in the initial value of the property. (We realize this may not be possible given web compat, but we'd like to at least try.)

The goal of these modifications is not to wreck the intention of the property, but just to allow for more flexibility for different publishing houses to match their own internal style guide. For all of these relaxations, we can certainly add in some explanation about what good choices would be for a new implementation.

P.S. "Unless text-spacing is set to space-adjacent or none" is perhaps not what is meant, since this property includes a bunch of other values in addition to those. Perhaps it should be "Unless text-spacing includes space-adjacent or none?"

[css-meeting-bot]

The CSS Working Group just discussed Text-spacing is too strict, and agreed to the following:

• RESOLVED: Add a new text-spacing:auto value, which is not the initial value.

The full IRC log of that discussion

<heycam> Topic: Text-spacing is too strict
<heycam> github: https://github.com//issues/3229
<heycam> myles: this is about text-spacing property, has a buynch of examples that control spacing between script changes on a single line
<heycam> ... desirable for mixed CJK and latin on a single line
<heycam> ... good typo style says if you have a bunch of ideographic characters then some latin words, between those two things should be a bit of extra space
<heycam> ... also things like because CJK punctuation tried to fit in a whole em block there's usually a lot of white space
<heycam> ... two punctuation characters next to each other is to push them together
<heycam> ... this is a good thing
<heycam> ... the concern we have is that there are different typographic design houses with different style guides
<heycam> ... and how much space to add between full width kana vs a latin character, etc.
<heycam> ... so different design studios have different rules abotu where they insert these spaces and how much to add
<heycam> ... we'd like to implement this property, but the definition is very strict
<heycam> ... lists which characters and how much space to add
<heycam> ... we understanding this came from jlreq, and that's a good starting place, but since this is up to typo conventions of the platform you're on, it would be good to looosen this for some wiggle room
<heycam> ... I've listd a few examples
<heycam> florian: without going throguh the examples, at the conceptual level yes there are different opinions on spacing
<heycam> ... some of these topics we can find agreement on, others not
<heycam> florian: for people who don't care, it doesn't matter
<heycam> ... for people who do care, they will only turn it on if it's predictable
<heycam> ... if they can't quite know what they'll get out of it, they'll do it manually
<heycam> myles: this is a property for changing general behavior, I understand a particular publisher doesn't like the way a particular impl or the whole web does it, and they may impl it thsemelves
<heycam> ... but a ua should be able to improve the typography of the entire web
<heycam> astearns: if you loosen things, you have an inconsistency between UAs, and authors are put in a bind
<heycam> ... the problem your'e pointing out means we need more properties to change the way we deal with spacing to hit those uses cases
<heycam> ... so a publishing house could say this variation is the one I want
<heycam> myles: I don't think the proposal is contrary to that
<heycam> ... the thing that I'm aiming for is a way to have platform dependent spacing
<heycam> ... also having a way to have a specific well defined one, that's great too
<heycam> ... conceptually an auto value is distinct
<heycam> florian: could we keep the existing auto value as that? [...]
<heycam> koji: I think I'm with myles in general. I agree with florian that some people want exact typographic characteristics, but currently we dont have anyhting
<heycam> ... two things that people want. if we dont have either, better to start with a looser definition
<heycam> ... if they say they really want some particular behavior we can add some more strict definitions
<heycam> florian: I think having an auto value would be nice for that general case of 'I want better typo'
<heycam> ... I'm concerned that this will cause compat problems
<heycam> ... that's when you end up with 1 line in one browser and 2 lines in another
<heycam> ... I wouldn't be opposed to an auto value, but that is a concern
<heycam> ... make the existing values fuzzy doesn't sound great
<heycam> myles: i share concern about web compat
<heycam> ... there would need to be an investigation phase
<heycam> florian: adding another value would be nice
<heycam> ... if we start changing in different browsers what they do that sounds scary
<heycam> myles: the question about whether it should be the default value, I don't think we have information yet
<heycam> florian: I suspect auto can't be default
<heycam> fantasai: i would love it if auto did beautiful typo by default
<heycam> drott: ...
<heycam> florian: there are many things affected by this property. in the french context, you have a space before a column, a narrow non breakable space
<heycam> ... but not in markup
<heycam> ... this property allows you to inject the right kind of space
<heycam> ... you could give some flexibility to the browser, to choose 1/4em or 1/6em
<heycam> ... there's also things relating to collapsing white space
<heycam> ... e.g. in CJK punctuations
<heycam> ... the boundary between characters
<heycam> drott: my question was how many values would we need
<heycam> ... to make it possible for the user to specify that
<heycam> ... within a run of the same script could be handle by opentype
<heycam> ... but how many additional ones would be needed
<heycam> fantasai: the spec triggers the opentype features when the settings are set
<heycam> ... you might want to be able to control particular spacing operations, so we will use the right OT things, but it won't do them automatically
<heycam> ... trimming/spacing controls depends on context
<heycam> ... and it crosses text runs in the same language
<heycam> ... OT can't do this for us
<heycam> ...but we can use OT to do the glyph transformations or make full width be typset half width for example
<heycam> myles: so you're asking how many combinations are required to do....?
<heycam> drott: one was 1/4 em ...
<heycam> florian: the existing property have 15 keywords
<heycam> ... not all combinations of them are valid
<heycam> drott: for these 15, I'm trying to get an idea of how many lengths you'd need to specify
<heycam> ... just to gauge how many additional values you'd need
<heycam> fantasai: if we're adding control over lengths, it would be in a separate property, so you could switch the behavior on and off without having to reset at every stage the length you want to set
<heycam> florian: do we want to resolve on an auto value, which lets the UA do whatever it feels like?
<heycam> fantasai: the initial value is normal
<heycam> ... happy with that or add an auto to do something
<heycam> myles: is there interop on what normal means?
<heycam> florian: yes, the initial value is what the web does today
<heycam> ... it's just not good typography
<heycam> ... for now, the auto value, isn't the default, since it's different from what UAs do
<heycam> fantasai: if you want to try having it be the initial value ...
<heycam> florian: that's going to break every good typographic website
<heycam> ... if you do it on top of them doing it manually
<heycam> ... maybe the spacing between latin and ideographic might be web compatible?'
<heycam> ... I suggest adding an auto and experimenting with it
<heycam> fantasai: if they're experimenting to see with what the initial value can do, may as well do it for normal itself
<heycam> myles: right now I think adding a new auto value is the best way to go
<heycam> RESOLVED: Add a new text-spacing:auto value, which is not the initial value.
<heycam> florian: I encourage looking at what subset of auto behavior could move to the initial normal value
<heycam> -- lunch break until 1pm --
<heycam> (1:10pm)
<eae> ScribeNick: eae

[xfq]

Maybe we should mention other ways of adding spacing between ideographs and non-ideographic letters and rules of fullwidth punctuation collapsing in {c,j}lreq too.

In the mean time, I agree that the lreq documents are not normative and the exact rule varies from one design house to another, and we should add a UA-dependent (and locale-sensitive) auto value. Although (unfortunately) that value can't be the default, we can experiment with it and see if we can have any strict definition later.

---

FWIW, here are some of the relevant sections in jlreq/clreq:

• jlreq § 3.2.6 Handling of Western Text in Japanese Text using Proportional Western Fonts
• clreq § 3.2.4 Handling Western Text in Chinese Text Using Proportional Western Fonts
• jlreq § 3.1.4 Positioning of Consecutive Opening Brackets, Closing Brackets, Commas, Full Stops and Middle Dots
• clreq § 3.1.6 Compression Rules for Punctuation Marks (it is being rewritten Rewrite of Compression Rules for Punctuation Marks 标点符号的挤压 clreq#221)

[macnmm]

it turns out the specific rules for exactly how much space to expand or shrink can vary from one design house to the next.
+1000

You cannot do spacing and especially adjustments to spacing for line compression in a one-size-fits-all manner for Japanese. Each context may have its own requirements that only the content author would know. Allowing at least the UA to be flexible is one thing, but also for the content creator to have control over some of the spacing decisions is needed.

[litherum]

You cannot do spacing and especially adjustments to spacing for line compression in a one-size-fits-all manner for Japanese.

I believe the resolution reached by the Working Group satisfies this. Adding a new value of auto doesn't limit authors' ability to specify any of the other values.