- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 29 Aug 2017 17:55:16 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Fonts ----- - RESOLVED: @font-face rules without src descriptor should remain in the om, but should not be used for font matching. (Issue #1133) Likewise @counter-style rules. - RESOLVED: Change font-synthesis to all pairs of keywords and no-keywords. (Issue #1641) - 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. (Issue #1641) - RESOLVED: Font variations will be both properties and descriptors. (Issue #1652) - Briefly discussed issue of variation axes that are font-specific and the fallback problem (which for features is solved by @font-feature-values) - RESOLVED: Rollback to previous state with CSSStyleDeclaration and unmerged interfaces, requiring get/set calls (no .property interface) for @font-face rules in the OM. (Issue #825) - RESOLVED: font-weight is mapped to actual fonts as follows (Issue #1579): Split the weights into three categories: 1) light - < 400 2) medium - 400 <= x <= 500 3) bold - > 500 For light, first search from x => 0, then x => 1000 For medium, search x=>500, then x => 0, then x => 1000 For bold, first search from x => 1000, then x => 0 - RESOLVED: Font selection algorithm has different behavior during animation than Fonts 3; we will add a note to that affect in Fonts 4. (Issue #1579) ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/paris-2017#topics Scribe: fremy Fonts ===== Handling of @font-face rule which lacks font-family or src descriptor --------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/1133 myles: For a long time, @font-face without src is ignored myles: which means it is a parse error and is not there anymore. dbaron: I would argue ignored could mean it's there in the OM but then does nothing. myles: ok, I think it doesn't matter for what I want to think about. myles: In some cases, you can have @font-faces to alter font properties myles: and all browsers accept to do that. myles: So I would like the text to be changed to say that the font-face rule should not be used for font matching myles: but should apply otherwise. dbaron: I think that is the sensible way to "ignore" them. TabAtkins: I have a follow-up question about whether we should apply a similar reasoning to invalid counter styles. dbaron: It would make sense to me. myles: I cannot say that this matches browsers in that case, I have not tested. TabAtkins: Sounds good, but we could decide on a principle and update if needed. astearns: What is the proposition then? myles: (repeats previous proposal) RESOLVED: font-face rules should be in the om, but should not be used for font matching. We can't add new values to the font-synthesis property ------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/1641 myles: font-synthesis is a property that allows to turn on/off the font synthesis. myles: For example font-synthesis: weight allows to generate bolder variants. myles: By default you can synthesize everything. myles: The issue is that if you want to turn one on, you turn off all the other ones myles: which means that new flags will be accidentally turned off by older styles. fantasai: We have a similar problem with text-decoration-skip. fantasai: We decided to create lots of longhands properties. Florian: We don't have quite resolved that but ok. fantasai: The other option is to have foo/no-foo pairs and only reset to false what you specify as off, but if you don't specify things we use the default. Florian: Wait, don't you want the reverse? fantasai: If you omit them, they default to true if true is the default, yes. fantasai: There was a proposal from ChrisL that was similar but used + and - in front of keywords TabAtkins: text-decoration only allows to append new decoration styles but not remove inherited ones Florian: The reason we rejected the equivalent bold/no-bold for text-decoration because it cascades poorly which is the case for text decoration. Florian: This is not quite the case for font-synthesis though-- you almost always want to set everything together rather than cascading separately, so the option is still open now. fantasai: Given that we already follow this pattern for font-variant, I think we should use the bold|no-bold pattern for font-synthesis as well myles: This is my opinion as well. myles: Plus some rule that explains what happens if you ask both. Florian: Should we also also have no-everything? myles: We can discuss this as part of another issue. astearns: Is this ok to make this change? myles: We added small-caps and didn't see a problem myles: but the window is closing of course, the more we add the more difficult it gets to change. astearns: So, proposed resolution is to use pair-keywords values for this property. astearns: Any objection? RESOLVED: Change font-synthesis to all pairs of keywords and no-keywords. fantasai: Do we need to change fonts level 3? myles: Don't think so. TAG Review of variable fonts ---------------------------- GitHub: https://github.com/w3ctag/design-reviews/issues/183 https://github.com/w3c/csswg-drafts/issues/1652 dbaron: drott asked for tag review dbaron: The main feedback was how this should be font properties or descriptors. dbaron: The reasoning should be that some things should be whether you would want the things to apply to fallback fonts or not. dbaron: Over time, system fonts are likely to get more variations. <TabAtkins> Looks like the axises would be best done as an open-ended set of properties, similar to custom properties... <TabAtkins> We can't guarantee that the axis names live in the CSS ident space, so we can't do `font-axis-*` tho. myles: There are two spaces for variation axes. myles: One is for things that are defined for all fonts myles: Other is things that are custom for your own font, which are named in all caps. TabAtkins: What is the ascii range for these names? myles: Less than ascii for sure. myles: No control char or anything, and casing does matter. dbaron: Flip side is animation. dbaron: If you want to animate them, they should be properties. eae: There have been clear request to support that. dbaron: I think it would make sense then to have both to support both use cases myles: This is what font-feature-settings is, minus some stories I rather not start talking about. TabAtkins: How about having a list of values in the axis? TabAtkins: We still need to be able to control them independently. TabAtkins: We can instead allocate a property namespace so that you get a property for each axis. fantasai: What if axis idents are outside ascii range in newer formats? TabAtkins: You can escape any char in identifiers in css. myles: In our impl we would not want weird axis names anyway. astearns: Use case where you have weight animated. myles: You can animate pair by pair. TabAtkins: But you still need to change all of them in same declaration. myles: Additive css would solve that. TabAtkins: Yes. myles: So, based on consensus we need a resolution to add descriptor and keep property. fantasai: Wrt font-specificness of certain axes; we have a similar problem with various stylistic fonts tags you want to turn on and off. fantasai: What we did, we decided to tie them to an identifier that is font-specific via @font-feature-values fantasai: we could take the same approach here. fantasai: This would allow to customize a font-specific thing in particular without affecting other fonts. myles: That works for stylistic alternates because the meaning of "alternate #1" is arbitrary but it doesn't make sense for axis names because the meaning of a value is supposed to be consistent across fonts. TabAtkins: The ranges could not mean the same thing for each font even if the two axises do approximately the same thing astearns: Even the lower-case standardized names, do they have identical ranges? myles: No. myles: Names are consistent between formats, but ranges are not. myles: They are internally consistent per format though. astearns: Could we map one to the other? myles: Yes, we could map to a canonical form. astearns: So could we define a css range? myles: I don't want to get into that. astearns: Anyway, I didn't hear any opposition to have things be both font descriptors and properties as per tag review. astearns: Can we get this resolved? RESOLVED: Font variations will be both properties and descriptors. astearns: Any other issue we should discuss from this review? dbaron: Not really, the rest is mostly editorial. We can't add new values to the font-synthesis property (cont.) ------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/1641 Bert: So font-synthesis: no-foo --> turns off foo but not bar, right? myles: Well, it resets bar to its default. myles: Right now all the other values are on by default, but in the future we could add new things that would be off by default. Bert: Then why should we not change the fonts spec. myles: No, it would just do as today, the spec will still be internally consistent. fantasai: Well, new features will be off by default all the time right? otherwise it will be breaking change. Florian: Not really, because new features could be things that did not exist at all before. Florian: So there would be no possible backwards compat problem. fantasai: And small-caps? myles: It is not in level 3, so no revision to do/ fantasai: But with this we could backport to level 3 fantasai: Wouldn't you want that then? myles: To prevent a browser that supports "small-caps" but "no-smallcaps"? fantasai: Yes. fantasai: We could have small-caps be on in the initial value and also be on if omitted fantasai: The ability to do this is effectively why we are considering having this foo/no-foo syntax. dbaron: Well, I think there is still a change from level 3. TabAtkins: This is not the same default we are talking about. TabAtkins: Now we talk about "default if you omit it in the declaration" not the "default if you omit the declaration". dbaron: Is this widely implemented? myles: No. [dbaron and tabatkins arguing about default vs initial] <TabAtkins> [dbaron kept using "default" to mean "initial value", when I and Myles were purposely using "default" to mean a totally separate concept] dbaron: I would want the default if omitted to be the same as the initial. fantasai: +1 fantasai: If we don't do what dbaron wants, yes, there is not breaking change fantasai: but if we accept to break stuff, we can do default=initial, which makes more sense. astearns: 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 astearns: then come back to this when the key people for this issue agree all together. fantasai: It is a breaking change, so we want to do it sooner rather than later. astearns: What is the proposal then? dbaron: initial = default TabAtkins: "font-synthesis: weight" also turns on "italic" TabAtkins: That is confusing myles: We could three set of keywords. <TabAtkins> none | [ weight || style ] | [ [weight-on | weight-off] || [style-on | style-off] || [smallcaps-on | smallcaps-off] ... ] Florian: Or we can also use the inheritance behavior. Florian: The only case that would be broken would be font-synthesis:initial. myles: Probably not common. dbaron: With this in mind, maybe I am fine with the previous resolution. dbaron: If we need to do something weird anyway, we might as well do what we proposed before dbaron: but keep this as exceptions only for weight and style, and going forward we do default=initial. astearns: So we have three proposals: 1. previous resolution 2. extended keyword set 3. inheritance for omitted values fantasai: 3 would break the meaning for font-synthesis:weight TabAtkins: No, it would not. Florian: We change the initial to no Florian: but the ua stylesheet sets to true on root. astearns: What about small-caps? myles: small-caps is on by default. myles: So font-synthesis:weight allows small-caps. astearns: Do you have a preference, myles? myles: Not really myles: the ua stylesheet case is the most simple and elegant solution, probably. * fantasai doesn't understand the difference between Florian's suggestion and the current situation, other than 'initial' doesn't get you the default behavior TabAtkins: I like florian proposal. <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. <TabAtkins> So author saying `f-s: weight;` would get weight & smallcaps syntheses, but not style. dino: The only issue is we break all:initial, which people do in shadow dom. TabAtkins: Yes, true. fantasai: If we were doing this from scratch, we would have dbaron's behavior. fantasai: How about we break existing content? myles: Places that use it today would then never synthesize small caps. myles: I prefer the alternative. fremy: Why would you do 'all: initial' and not 'all: unset'? astearns: We reached the time limit astearns: I would want to come to a conclusion. dbaron: Two proposals: fixing previous resolution, or breaking existing content <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) astearns: we try to resolve on the the first one dbaron proposed (no objection) 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) CSSFontFaceRule isn't web-compatible ------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/825 myles: cssom for the @font-face rule myles: used to be CSSStyleDeclaration with the declarations inside myles: rule.style.getPropertyValue("font-family"). myles: The spec was then changed myles: instead of having a style, you would have a bunch of strings myles: e.g. rule.family. myles: No browser has made this change. myles: There is existing code that use the old way. myles: We don't want to break that code. myles: Option 1: rollback to old spec text myles: Option 2: get browsers to support the new spec text myles: Option 3: get browsers to support both myles: Option 4: make the "style" property return new type of object that looks like CSSStyleDeclaration but is simpler dbaron: In the old domstyle spec, cssstyledeclaration was simple dbaron: The weird stuff was in css2properties, which had a property for every property in css dbaron: so you could implement both, and most things did. dbaron: That was then changed, and the two were merged dbaron: so now the merge made it more difficult to implement. dbaron: Our implementation doesn't include all the other stuff in @font-face rules, just the 6 original get/set methods. dbaron: We never implemented this merge dbaron: (in gecko). dbaron: My preferred proposal would then to be unmerge things dbaron: (and rollback to use cssstyledeclaration). myles: We still need to explain what happens when we set properties that do not exist in @font-face but do in general style myles: but I don't have a strong opinion in either ways myles: but I would rather rollback the spec, and maybe we can refine after. astearns: So, instead of coming up with a perfect design, we rollback and improve iteratively. TabAtkins: We have copied the design in @font-face TabAtkins: and we have "style" property there TabAtkins: so we cannot be consistent and keep style as CSSStyleDeclaration. myles: Life is terrible, who names these things ;) dbaron: If other implementations are willing to remove css2props stuff, then it leaves less questions to be answered. myles: I don't think we ever implemented these two interfaces. astearns: Any other opinion? TabAtkins: I suspect if gecko is doing it, I guess we could do it. myles: Merge allows rule.style.fontFamily and unmerge does not. dbaron: Yes. myles: webkit does not support this either, <gsnedders> I thought both of those were supported interoperably? <dbaron> gsnedders: rule is CSSFontFaceRule myles: Can we then try to resolve on rolling back to the unmerged version? [no objection] RESOLVED: Rollback to previous state with CSSStyleDeclaration and unmerged interfaces, requiring get/set calls (no .property access) for @font-face rules in the OM. <TabAtkins> I'm confused, why will .style.fontFamily not work? That's one of the descriptors. <dbaron> TabAtkins, we don't have an interface that has .fontFamily and not .backgroundColor... and multiple browsers have gotten away with not implementing either on CSSFontFaceRule.style <TabAtkins> Does that mean you can't change the name of a @font-face via the OM? <dbaron> nope, use setPropertyValue <TabAtkins> Ah, no, it just means that you have to use the getPropertyValue()/etc, not the getters. Properties being reset by the font shorthand -------------------------------------------- GitHub: https://github.com/w3c/csswg-drafts/issues/1349 myles: I made an amazing table, let me paste the link. <myles> https://github.com/w3c/csswg-drafts/issues/1636#issuecomment-317127312 myles: There seems to be consensus that the font shorthand resets what is not specified in it myles: but what the other things are doesn't seem interoperable. dbaron: I think the test is wrong for font-language-override myles: Let me check. TabAtkins: There seems to be things we do support that this test says we don't TabAtkins: so we cannot trust this data. <TabAtkins> font-size-adjust, at minimum - we def support it (it causes the CSSWG blog to display brokenly on a Chromebook >_<) myles: ok, we will discuss this another day then. Animating font weight --------------------- github: https://github.com/w3c/csswg-drafts/issues/1579 myles projects lots of beautiful graphs from the spec myles: Two things here myles: 1. requested font weight myles: 2. available options in the font myles: Then algorithm match one to the others. myles: For historical reasons, if you want 400 and it is not possible myles: search will be 500, then 300, then 200, then ... myles: Variables fonts can have much more arbitrary values myles: So I tried to come up with a solution for generalizing this. myles: The generalization I came up with: 400, then 500, then any value between 400 and 300, then any value between 400 and 600, etc fantasai: Why not directly 400 -> 500 instead of 400 then discretely 500 fantasai: doesn't seem very logical. TabAtkins: The old model did that. fantasai: But you could not express 430, it needed to be multiples of 100. fantasai: The goal of the algorithm was that 400 and 500 were very common values for medium weights, so if you choose one and don't have it, pick the other. fantasai: but 300 is often considered lightweight. fantasai: This proposal preserves the compat, but not the spirit. fantasai: I would prefer to connect the 400 -> 500 range. TabAtkins: Yes, it is less weird. myles: If there is consensus, I am ok with this. fantasai: This would evolve the old algorithm, not run some algorithm after it. fantasai: Proposal means if we did 400 then 500 then 300, now we do 400 -> 500, then 500 -> 300, ... fantasai: Obviously some values will not match. fantasai: because they have been searched already <fantasai> basically play "connect the dots" with the old search points <fantasai> which might go over some ranges multiple times, but of course the UA would optimize those out. (whiteboard discussion) (the discussion seems to be about what fantasai's idea does if you search for 450 not 400) (and related cases like 250 or 550) <TabAtkins> Split the weights into three categories: <TabAtkins> light - < 400 <TabAtkins> medium - 400 <= x <= 500 <TabAtkins> bold - > 500 <TabAtkins> For light, first search from x => 0, then x => 1000 <TabAtkins> For bold, first search from x => 1000, then x => 0 <TabAtkins> For medium, several possibilities. <TabAtkins> Never mind, bolder is better, so medium's category is: search x=>500, then x => 0, then x => 1000 RESOLVED: font-weight matching described before scribe: TabAtkins myles: Previously you could animate font-weights, even though they weren't numbers. myles: You animated a number, then rounded to nearest 100, *then* invoked the font selection algo. myles: So at a particular value of time, say your animation was at font-weight:540. You'd first round to 500, then run font-selection. myles: For variable fonts, you don't have to round. This is a good thing. myles: But rounding might change which case you fall into. fantasai: And when animating between 401 and 450, rounding would make you choose the 400 font, but our new thing would choose the 500 font. myles: So two options: undo what we just did and make it more complicated... myles: Or say that animating font-weights before variable fonts wasn't often used, and just accept the behavior change. fantasai: I think there's not much objection to computing font-weight and its animation to be a general integer. fantasai: But for impls that don't do variable fonts, do we want them to accept any value, or should they still do the rounding? dbaron: There are fonts with more than just 100, 200, etc weights; seems like it would be better to make that work. dauwhe: I have a font with weights spaced every 5. <dauwhe> https://www.typography.com/fonts/knockout/overview/ dbaron: So I think we should just make the change; we'll see if there's any problem. myles: I think we already have an old resolution to let weight accept any integer, actually. dbaron: Does the spec really mean <number> rather than <integer>? myles: <number> is right; variables axises can accept any float in the range. fantasai: So Fonts 3 needs to be updated; do we want to allow it at parse time too? dbaron: I don't think Fonts 3 needs updating; this is a new feature, the property just supports more values than it used to. fantasai: That's fair. TabAtkins: We could probably use a note in Fonts 4 that the animation behavior has changed. myles: Yes. astearns: Objections? RESOLVED: Font selection algorithm has different behavior during animation than Fonts 3; we will add a note to that affect in Fonts 4. topic: break
Received on Tuesday, 29 August 2017 21:56:11 UTC