[css-fonts-4] We can't add new values to the font-synthesis property #1641
Comments
|
cc @fantasai @tabatkins Is there an existing place where we've solved this problem before? |
|
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.) |
|
Alternatively, could have positive and negative values, e.g. The |
|
The problem with this last one is, if |
|
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. |
|
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. |
|
The CSS Working Group just discussed
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 |
|
A bunch of the discussion in #1652 (comment) belongs here. |
|
The CSS Working Group just discussed
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) |
|
Wondering if 'font-synthesis: no-weight' should imply 'style on' rather than 'style off' |
|
The main compat constraint is 'weight' implying 'no-style' and 'style' implying 'no-weight'. |
|
I think that the resolution isn't quite clear on what exactly all combination of values should do. Here is what seems most natural:
|
|
We should make this as minimally magic as possible. I don't like "no-weight" and "weight" having different effects on the "style" value. |
|
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 |
|
@tabatkins I don't have a strong preference about which table ends up being used. Can you provide a better one please? |
|
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:
|
|
Ah, Elika pointed out the rule you seemed to be using, which is "If the declaration contains only If that's the rule, then I strongly disagree with it - that's why my grammar suggestion for the "treat (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.) |
|
The Working Group just discussed
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 |
Trying to compute the status of th previous font-synthesis feature proved it to be untenable as a single feature, or as features that pair `font-syntheis: style` with `font-synthesis-style`. Define a bunch of new features, and gently discourage use of the shorthand in the description. See w3c/csswg-drafts#1641 for background.
Trying to compute the status of the previous font-synthesis feature proved it to be untenable as a single feature, or as features that pair `font-synthesis: style` with `font-synthesis-style`. Define a bunch of new features, and gently discourage use of the shorthand in the description. See w3c/csswg-drafts#1641 for background.
Trying to compute the status of the previous font-synthesis feature proved it to be untenable as a single feature, or as features that pair `font-synthesis: style` with `font-synthesis-style`. Define a bunch of new features, and gently discourage use of the shorthand in the description. See w3c/csswg-drafts#1641 for background.
Trying to compute the status of the previous font-synthesis feature proved it to be untenable as a single feature, or as features that pair `font-synthesis: style` with `font-synthesis-style`. Define a bunch of new features, and gently discourage use of the shorthand in the description. See w3c/csswg-drafts#1641 for background.
Trying to compute the status of the previous font-synthesis feature proved it to be untenable as a single feature, or as features that pair `font-synthesis: style` with `font-synthesis-style`. Define a bunch of new features, and gently discourage use of the shorthand in the description. See w3c/csswg-drafts#1641 for background.
Currently, the
font-synthesisproperty 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?
The text was updated successfully, but these errors were encountered: