Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
litherum opened this issue Jul 21, 2017 · 18 comments

Comments

Projects
None yet
7 participants
@litherum
Copy link
Contributor

commented Jul 21, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 21, 2017

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

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented Jul 21, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Jul 21, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Jul 21, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 31, 2017

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.

@astearns astearns removed the Agenda+ F2F label Aug 1, 2017

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Aug 3, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 3, 2017

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

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Aug 3, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Aug 3, 2017

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

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented Aug 3, 2017

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

@litherum

This comment has been minimized.

Copy link
Contributor Author

commented Aug 3, 2017

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
@tabatkins

This comment has been minimized.

Copy link
Member

commented Aug 3, 2017

We should make this as minimally magic as possible. I don't like "no-weight" and "weight" having different effects on the "style" value.

@tabatkins

This comment has been minimized.

Copy link
Member

commented Aug 4, 2017

Whoops, my last comment was made before the thread updated with Myles' comment.

I also quite disagree with that table - I have no idea what the underlying rule is determining that. In particular, why does weight give style a , but no-weight gives style a ? The small-caps value makes sense - it defaults to if not otherwise specified, but I can't tell the rhyme or reason behind what value weight/style get when omitted.

@litherum

This comment has been minimized.

Copy link
Contributor Author

commented Aug 4, 2017

@tabatkins I don't have a strong preference about which table ends up being used. Can you provide a better one please?

@tabatkins

This comment has been minimized.

Copy link
Member

commented Aug 5, 2017

I was under the impression from your comments during the meeting that you wanted "specified values as specified, omitted values as their default", with weight and style defaulting to off, and smallcaps defaulting to on. That would produce this table:

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
@tabatkins

This comment has been minimized.

Copy link
Member

commented Aug 7, 2017

Ah, Elika pointed out the rule you seemed to be using, which is "If the declaration contains only weight or style, turn the other one off, per legacy Fonts 3 behavior. Otherwise, anything omitted defaults to on." (You didn't have a row for weight small-caps, so I don't know if you'd set style on or off in that case.)

If that's the rule, then I strongly disagree with it - that's why my grammar suggestion for the "treat weight and style as legacy" separated it out completely into a legacy term, and used weight-on and weight-off instead in the "assume everything is on by default" term.

(It's better to describe the rule rather than sketch out a table, so we don't have to play these inference games with each other.)

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Jul 3, 2018

The Working Group just discussed font-synthesis forwards-compat with new values, and agreed to the following:

  • RESOLVED: move font-synthesis to long-hands, and simplify the shorthand
The full IRC log of that discussion <fantasai> Topic: font-synthesis forwards-compat with new values
<fantasai> github: https://github.com//issues/1641
<frremy> fantasai: at a f2f we resolve to change font-synthesis to invert the behavior since we change from you have to specify what you want to synthetize
<frremy> fantasai: to specify instead what you don't want to synthetize
<frremy> fantasai: wanted to clarify the resolution
<frremy> myles: not much thought, except I'd not want to break existing content
<frremy> astearns: but are you fine with the resolution?
<frremy> TabAtkins: (discussion about what rule maps to the spec)
<frremy> fantasai: the table doesn't help with forwards-compat
<frremy> fantasai: the current behavior if you don't specify font-synthesis which allows weight+style+font-caps
<astearns> s/the resolution/tab's table/
<frremy> fantasai: if you say font-synthesis: weight you already weight+font-caps
<frremy> TabAtkins: the table is meant to ease the compat
<frremy> TabAtkins: font-caps is not a legacy value
<frremy> TabAtkins: unspecified parts of the property default to on/off depending on legacy requirements
<frremy> florian: we had a similar discussion with font-...-skip and we had settled on a shorthand
<frremy> chris_: we can keep adding long-hands as we see fit
<frremy> florian: I think this is the only sane thing to do
<frremy> myles: then we can use Tab's table for the shorthand
<frremy> myles: ok, so the proposal is to have three properties "font-synthesis-weight, font-synthesis-style, etc..."
<frremy> myles: three values, each should have default to "auto" and "none", two first one are auto, last one is none
<frremy> fantasai: I don't like font-synthesis no-caps disable everything
<frremy> myles: since nobody implemented font-caps, we get rid of them in the shorthand
<frremy> myles: so the problem just disappears
<TabAtkins> s/font-caps/small-caps/
<TabAtkins> font-synthesis: all | none | [weight || style], with effects as in my table
<myles> Proposal: 3 new properties: font-synthesis-weight, font-synthesis-style, and font-synthesis-small-caps, all with grammar "auto | none" with initial values "auto", all inherited, and the "small-caps" "no-small-caps" and "no-style" and "no-weight" values are removed from the font-synthesis grammar, and the no
<astearns> 'as in my table' could also be 'as currently specified in fonts-3'
<myles> s/and the no//
<frremy> (joke on a "force synthesis" option)
<TabAtkins> "joke"
<frremy> astearns: any objection on the proposal as stated in irc
<frremy> RESOLVED: move font-synthesis to long-hands, and simplify the shorthand
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.