W3C home > Mailing lists > Public > www-style@w3.org > August 2017

[CSSWG] Minutes Paris F2F 2017-08-03 Part III: Fonts [css-fonts]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 29 Aug 2017 17:55:16 -0400
Message-ID: <CADhPm3seckagHa_dKQ3CS5LWbGH8QNS-XHtKam0o7acH2J_-+w@mail.gmail.com>
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.


  - 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
  - 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
              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)


Agenda: https://wiki.csswg.org/planning/paris-2017#topics

Scribe: fremy


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
  myles: In some cases, you can have @font-faces to alter font
  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

  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

  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
  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
  <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
  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
  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
  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,
  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
  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
  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
  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
  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
  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
  myles: Probably not common.

  dbaron: With this in mind, maybe I am fine with the previous
  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
  <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
  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
  <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
  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
  [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
  <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
  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
  <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
  myles: For variable fonts, you don't have to round. This is a good
  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
  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
  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

This archive was generated by hypermail 2.3.1 : Tuesday, 29 August 2017 21:56:12 UTC