[css-fonts-4] We can't add new values to the font-synthesis property

[litherum]

Currently, the font-synthesis property accepts a list of types of synthesis that the browser is allowed to perform: synthetic bold, synthetic oblique, and synthetic small-caps. The initial value of this property is listing everything, so the browser is allowed to synthesize everything.

Most web authors I've talked with want to turn off a particular kind of synthesis (rather than turn on a particular kind of synthesis). Therefore, if a web author wants to turn off synthetic bold, she may write font-synthesis: style small-caps.

Unfortunately, this means that, if we (the CSSWG) add a new type of synthesis that is allowed (for example, this may occur in the future with font variations), this existing style sheet won't get our new type of synthesis (because the list is opt-in rather than opt-out).

Given that multiple browsers have already shipped this property, I'm not sure what we can do about this. Does anyone have any ideas, or are we just out of luck?

[litherum]

cc @fantasai @tabatkins Is there an existing place where we've solved this problem before?

[fantasai]

The most similar thing is text-decoration-skip, where we resolved to split it out into longhands. (I haven't edited that in yet, IIRC the discussion was Seattle 2017.)

[fantasai]

Alternatively, could have positive and negative values, e.g.

font-synthesis: [ bold | no-bold ] || [ oblique | no-oblique ] || [ small-caps | no-small-caps ]

The font-variant property has some similar pairs.

[fantasai]

The problem with this last one is, if font-synthesis is sufficiently well-deployed, then bold will be expected to turn off oblique, but following a typical scheme for this would leave it to its initial state which is on. We could solve that by having each value have its own default with style and weight values being off by default (and set to on in the UA default style sheet).

[svgeesus]

I was about to suggest positive and negative values, I see fantasai beat me to it, although I was thinking of actual - and + in the values.

This conveniently allows the common use case, which is disallowing a particular type of synthesis: -bold for example

We could also say that the existing, deployed syntax is equivalent to +bold +style +small-caps which then means that it is not equivalent to +new-thing and is thus extensible.

[litherum]

Given @fantasai’s comment about existing deployment, it seems prudent to do this sooner rather than later. The longer we wait, the harder it will be to fix this.

[css-meeting-bot]

The CSS Working Group just discussed can't add new values to font-synthesis, and agreed to the following resolutions:

• RESOLVED: change font-synthesis to all pairs of keywords and no-keywords

The full IRC log of that discussion

<fremy> Topic: can't add new values to font-synthesis
<fremy> github: https://github.com//issues/1641
<fremy> myles_: font-synthesis is a property that allows to turn on/off the font synthesis
<fremy> myles_: for example font-synthesis: weight allows to generate bolder variants
<fremy> myles_: by default you can synthetize everything
<fremy> myles_: the issue is that if you want to turn one on, you turn off all the other ones
<fremy> myles_: which means that new flags will be aciddentally turned off by older styles
<fremy> fantasai: we have a similar problem with text-decoration-skip
<fremy> fantasai: we decided to create sub longhands properties
<fremy> Florian: we don't have quite resolved that but ok
<fremy> fantasai: the other option is to only reset to false what you specify as off, but if you don't specify things we use the default
<fremy> Florian: wait, don't you want the reverse?
<fremy> fantasai: if you omit them, they default to true if true is the default, yes
<Rossen> !add
<fremy> fantasai: there was a proposal that was similar but used + and - in front of keywords
<fantasai> s/proposal/proposal from ChrisL/
<fremy> TabAtkins: text-decoration only allows to append new decoration styles but not remove inherited ones
<fremy> Florian: the reason we rejected the equivalent bold/no-bold for text-decoration because it cascades poorly which is the case for text decoration
<fremy> Florian: this is not quite the case for font-synthesis though so the option is still open now
<fremy> fantasai: given that we want to follow that pattern for other things like variant, I think we should do that as well
<fremy> fantasai: ... for font-synthesis
<fremy> myles_: this is my opinion as well
<fantasai> s/want to/already/
<fantasai> s/other things like /font-
<fremy> myles_: plus some rule that explains what happens if you ask both
<fremy> Florian: should we also also have no-everything?
<fremy> myles_: we can discuss this as part of another issue
<fantasai> s/do that/use the bold|no-bold pattern/
<fremy> alan: is this ok to make this change?
<fremy> myles_: we added font-caps and didn't see a problem
<fremy> myles_: but the window is closing of course, the more we add the more difficult it gets to change
<fremy> alan: so, proposed resolution is to use pair-keywords values for this property
<fremy> alan: any objection?
<fremy> RESOLVED: change font-synthesis to all pairs of keywords and no-keywords
<fremy> fantasai: do we need to change text level 3?
<fremy> myles_: don't think so
<fantasai> s/text/fonts/
<myles_> https://github.com/w3ctag/design-reviews/issues/183

[dbaron]

A bunch of the discussion in #1652 (comment) belongs here.

[css-meeting-bot]

The CSS Working Group just discussed font-synthesis, again (though a bunch of it was in the previous topic), and agreed to the following resolutions:

• RESOLVED: make default values: weight (off), style (off), small-caps (on), make the initial value 'weight style', and add keywords no-weight, no-style, and no-small-caps.

The full IRC log of that discussion

<dbaron> Topic: font-synthesis, again (though a bunch of it was in the previous topic)
<fremy> fantasai: but if we accept to break stuff, we can do default=initial, which makes more sense
<dbaron> github: https://github.com//issues/1641
<fremy> alan: seems like we want a new issue, and try to come up with a new design for this, and discuss this in a smaller group
<fremy> alan: then come back to this when the key people for this issue agree all together
<fremy> fantasai: it is a breaking change, so we want to do it sooner rather than later
<fremy> alan: what is the proposal then?
<fremy> dbaron: intial = default
<fremy> TabAtkins: "font-synthesis: weight" also turns on "italic"
<fremy> TabAtkins: that is confusing
<fremy> myles_: we could three set of keywords
<TabAtkins> none | [ weight || style ] | [ [weight-on | weight-off] || [style-on | style-off] || [smallcaps-on | smallcaps-off] ... ]
<fremy> Florian: or we can also use the inheritance behavior
<fremy> Florian: the only case that would be broken would be font-synthesis:initial
<fremy> myles_: probably not common
<fremy> dbaron: with this in mind, maybe i am fine with the previous resolution
<fremy> dbaron: if we need to do something weird anyway, we might as well do what we proposed before
<fremy> dbaron: but keep this as exceptions only for weight and style, and going forward we do default=initial
<fremy> alan: so we have three proposals
<fremy> 1. previous resolution
<fremy> 2. extended keyword set
<fremy> 3. inheritance for omitted values
<fremy> fantasai: 3 would break the meaning for font-synthesis:weight
<fremy> TabAtkins: no, it would not
<fremy> Florian: we change the initial to no
<fremy> Florian: but the ua stylesheet sets to true on root
<fremy> alan: what about small-caps?
<fremy> myles_: small caps is on by default
<Bert> (Idea: Disallow mixing positive and negative keywords. E.g., assume initial value is 'a b d' and you set 'a c', then only a and c are on. If you set 'no-a no-c' then b and are on, i.e., the initial value minus the ones that were turned off.)
<fremy> myles_: so font-synthesis:weight allows small-caps
<fremy> alan: do you have a preference, myles?
<fremy> myles_: not really
<fremy> myles_: the ua stylesheet case is the most simple and elegant solution, probably
<fremy> TabAtkins: I like florian proposal
<fremy> dino: the only issue is we break all:initial, which people do in shadow dom
<fremy> TabAtkins: yes, true
<fremy> fantasai: if we were doing this from scratch, we would have dbaron's behavior
<TabAtkins> Florian's proposal: initial value is `font-synthesis: no-weight no-style smallcaps`, UA style is `:root { font-syntheses: weight style smallcaps;}`. Omitting a keyword defaults it to the initial value for that keyword.
<fremy> fantasai: how about we break existing content?
<TabAtkins> So author saying `f-s: weight;` would get weight & smallcaps syntheses, but not style.
<fremy> myles_: places that use it today would then never synthetize small caps
<fremy> myles_: i prefer the alternative
<fantasai> fremy: Why would you do 'all: initial' and not 'all: unset'?
<fremy> alan: we reached the time limit
<fremy> alan: i would want to come to a conclusion
<fremy> dbaron: two proposals: fixing previous resolution, or breaking existing content
<Bert> (idea2: use Chris's +/-. If you use a + or -, then the rule becomes "additive" :-) (relative to the initial value. 'font-synth: +weight' does not turn style off.)
<dbaron> Proposed resolution: make default values: weight (off), style (off), small-caps (on), make the initial value 'weight style', and add keywords no-weight, no-style, and no-small-caps.
<dbaron> More breaking option: make default values: weight (on), style (on), and small-caps (on), make the initial value 'new keyword to be determined', and add keywords no-weight, no-style, and no-small-caps
<dbaron> (although there's actually the alternative option to not have the non-default no-* variants)
<dbaron> (that alternative applies to both options)
<fremy> alan: we try to resolve on the the first one dbaron proposed
<fremy> (no objection)
<fremy> RESOLVED: make default values: weight (off), style (off), small-caps (on), make the initial value 'weight style', and add keywords no-weight, no-style, and no-small-caps.
<dbaron> (at least for now, may discuss further)

[fantasai]

Wondering if 'font-synthesis: no-weight' should imply 'style on' rather than 'style off'

[fantasai]

The main compat constraint is 'weight' implying 'no-style' and 'style' implying 'no-weight'.

[litherum]

I think that the resolution isn't quite clear on what exactly all combination of values should do.

Here is what seems most natural:

Compliance Level	Synthesis enabled?	Weight	Style	Small-caps
Fonts 3	font-synthesis: none	❌	❌	❌
Fonts 3	font-synthesis: weight	✅	❌	✅
Fonts 3	font-synthesis: style	❌	✅	✅
Fonts 3	font-synthesis: weight style	✅	✅	✅
Fonts 4	font-synthesis: small-caps	✅	✅	✅
Fonts 4	font-synthesis: no-weight	❌	✅	✅
Fonts 4	font-synthesis: no-style	✅	❌	✅
Fonts 4	font-synthesis: no-small-caps	✅	✅	❌
Fonts 4	font-synthesis: no-weight no-style	❌	❌	✅
Fonts 4	font-synthesis: no-weight style	❌	✅	✅
Fonts 4	font-synthesis: all	✅	✅	✅
Fonts 4	font-synthesis: weight no-weight	Parse Error