[css-fonts-4] Some font features should not be disable-able

[litherum]

Inside the Script development specs section of the OpenType spec, it shows how certain features are "always applied" for certain scripts.

One reason for this is that these features are required for legibility.

Another reason for this is, in the words of one of our platform text engineers (specifically about Arabic and rlig, which is one of the "always applied" features):

Some Arabic fonts are fantastically complicated with all sorts of interlocking features, and I can imagine at least one of them will break in completely unexpected ways if rlig is not applied.

In the Cocoa ports of WebKit, we ensure that these "always applied" features are, in fact, always applied, regardless of what font-feature-settings indicates. We believe this is the best policy for user agents in general. We're not aware of any case where an author would intentionally want their text to be broken/illegible, and there are plenty of situations where an author could shoot themselves in the foot by disabling rlig (or others) accidentally.

(This is proposal is relevant to css/css-fonts/font-variant-ligatures-11.html, which the Cocoa ports of WebKit are intentionally failing.)

[Crissov]

font-feature-settings is a low-level property. It’s there for authors to shoot themselves in the foot with. Many do. Let them.

For higher-level properties I would agree.

[svgeesus]

On the one hand, the "r" in rlig is for required.

On the other hand, there is a need for styling the "incorrect" class

<p>Arabic letters have initial, medial, final and isolate forms
which means that they join together, even when separated by markup:
<span class="correct">ع</span>ع<span class="break">ع</span>
and render like this
<span class="correct">ععع</span>
not like this
<span class="incorrect">ععع</span></p>

Although, zwnj can always be used for these contrived examples.

[svgeesus]

(Example from ALReq although they illustrate it with images)

[faceless2]

We have WPT tests that do this with ZWNJ, eg text-encoding/shaping-no-join-001.html

As the only examples so far demonstrate arabic glyph-shaping, we should also consider the case where you might want to turn on a feature, eg init or medi to show the glyph forms. But it all seems pretty specialised, and while demoing glyph forms in Arabic almost works as a use-case, disabling (for example) nukt in Devanagari is going to just give nonsense shapes as I understand it.

Rather than mandate it one way or another, would be it acceptable to add a note to the effect that turning off (or on) rules that are required for language shaping is not advised and is UA dependent? We've long had font-variant-ligatures-11.html marked as invalid, as we also don't allow turning off rlig.

[litherum]

If an author really wants to get this wrong, they have ample opportunity:

1. Custom webfonts
2. PUA characters
3. Unicode presentation forms
4. ZWNJ sequences
5. (I hesitate to even bring it up, but) Images (as above)

Doing font-feature-settings: 'rlig' off is too easy for an author to do (and totally break all connected scripts).

Also, I should say, there is nothing a Core Text client can do to disable these features. Even if you tell Core Text to disable them, Core text won't, because, well, they're always enabled. We view this as a good thing.

[litherum]

(Removing the Agenda+ label to give discussion time on GitHub before this issue makes it to the call.)

[svgeesus]

In general, although I tried to see both sides in my earlier comment, I am much more in favor of helping authors to do the right thing. Demonstrating what the wrong thing looks like, is an edge case and can already be done in multiple ways.