[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.

[svgeesus]

Not mentioned so far, but the fact that the low-level font-feature-settings is not additive, and will reset any feature not explicitly set, makes these sorts of mistakes especially common. So retaining basic legibility by disabling footguns seems like a great default.

[css-meeting-bot]

The CSS Working Group just discussed some features should not be disableable, and agreed to the following:

• RESOLVED: If OT spec says a feature is required, UAs can ignore attempts to turn it off.

The full IRC log of that discussion

<TabAtkins> Topic: some features should not be disableable
<TabAtkins> github: https://github.com//issues/7634
<TabAtkins> myles: The OT spec describes that some features are "always applied"
<chris> q+
<TabAtkins> myles: one that is the provoking feature fo rthis issue is rlig, for arabic text
<TabAtkins> myles: if you disable it, arabic text is totally broken
<TabAtkins> myles: But this isn't the onlyf eature described like this
<chris> https://docs.microsoft.com/en-us/typography/script-development/arabic#features
<TabAtkins> myles: our platform text engine, CoreText, makes it impossible to turn off rlig. It's doing you a favor, nobody wants illegible text.
<TabAtkins> myles: But this makes us fail some WPT
<TabAtkins> myles: So I at least want to allow our behavior, but ideally forbid these from being disabled.
<astearns> ack chris
<TabAtkins> chris: Agree. Earlier I was trying to see both sides, but as I did that there's lots of ways to produce examples of how you don't render text
<TabAtkins> chris: It's not that it looks a bit wrong, it completely falls apart. So I do think we should forbid disabling these.
<TabAtkins> chris: So question is, do we just defer to OT, or do we have a list? Then we'd have to keep it up to date as OT changes, which gives me pause.
<TabAtkins> chris: But I want it testable.
<TabAtkins> myles: Is this thought an editorial concern?
<TabAtkins> chris: In the issue you gave a link to OT about ARabic, I agree it's motivating but there are other examples.
<drott> q+
<TabAtkins> chris: So do we just point to them? And if so, how do you test?
<TabAtkins> myles: We do already normatively ref OT spec
<TabAtkins> myles: If we do normatively add a statement forbidding disabling based on OT, this would be testable for a specific version of OT.
<TabAtkins> myles: Dont' want to force a link to a specifci OT version.
<TabAtkins> chris: Right, just don't want a change in 3 years being impossible for them to do bc we currently allow it.
<TabAtkins> myles: I think there's neough overlap we're okay
<astearns> ack fantasai
<TabAtkins> fantasai: You mentioned there's plenty of situations where authors can hurt themselves disabling rlig accidentally
<TabAtkins> fantasai: How accideentally?
<TabAtkins> chris: copy-paste from an example not realizing it works like every other property, not realizing that everything *not mentioned* is turned off.
<TabAtkins> fantasai: So it turns off all features not turned on explicitly?
<TabAtkins> chris: Yes
<TabAtkins> fantasai: My impression is it would leave things as they are and only set explicit ones.
<chris> "The entire property value is set at once. Unlike the font-variant properties, there is no way to modify the inherited value by adding or removing individual features. "
<chris> from the spec
<TabAtkins> drott: me and myles both thought that font-feature-settings doesn't disable things unspecified, it just changes the things given literally
<TabAtkins> fantasai: Right, so to turn off rlig, they ahve to explicitly turn it off.
<TabAtkins> fantasai: If they're being that explicit, i don't see why to make it not work
<TabAtkins> myles: Because they've just broken their text.
<TabAtkins> fantasai: This is intentionally low level, I feel we should just let it be.
<TabAtkins> fantasai: But I udnerstand that some platforms don't let it be turned off.
<drott> q?
<TabAtkins> fantasai: So I think we should say that if OT says it's required, impls should be allowed to not turn it off.
<TabAtkins> fantasai: But I don't think tracking a list of things you can't turn off is what we should be doing here.
<TabAtkins> myles: I think there's a bit of disagreement about what it means to be low level.
<TabAtkins> myles: This is certainly lower than font-variant
<TabAtkins> myles: But I don't think this should be low enough that authors can make their text illegible
<TabAtkins> myles: Almost all features that f-f-s is designed for are swashes or old-style numerals, etc
<TabAtkins> fantasai: Those are already in font-variant, fwiw
<TabAtkins> [discussion about specific examples]
<TabAtkins> chris: Scientific inferiors for formulas, there's no font-variant for that, you need font-feature-settings for it
<TabAtkins> fantasai: So you have to really work hard to keep an rlig off
<TabAtkins> fantasai: Are people actually doing this?
<TabAtkins> TabAtkins: Problem is there's a test for that, and wk is thus failling the test
<TabAtkins> fantasai: So let's make it optional and remove that test
<TabAtkins> drott: Also we have Google Fonts people who want to bea ble to test switching it off and on, agree it's hard to do it by accident
<iank_> (we don't have to remove the test - but we can mark it as .optional)
<TabAtkins> drott: Also sometimes ligatures aren't put in the right spot, put in rlig even tho they shoudl be clig or something, so turning off rlig for non-arabic text can be reasoanble.
<TabAtkins> drott: So I agree we should make it optional to ignore these features.
<TabAtkins> drott: Same position as fantasai
<fantasai> Proposal is to say that if OpenType mandates a feature, the UA is not required to turn it off.
<astearns> q?
<TabAtkins> myles: I think this is the wrong decision, but it's okay
<TabAtkins> iank_: clarification we don't ahve to remove the test, we can mark it as optional
<astearns> ack drott
<TabAtkins> RESOLVED: If OT spec says a feature is required, UAs can ignore attempts to turn it off.
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam

[svgeesus]

The test mentioned at TPAC is now marked .optional