W3C home > Mailing lists > Public > www-style@w3.org > July 2018

[CSSWG] Minutes Sydney F2F 2018-07-03 Part IV: Fonts 4 [css-fonts-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 19 Jul 2018 20:27:11 -0400
Message-ID: <CADhPm3uBZsnGEsPzA50b99387E0Mi-+Zup1yebY8=MJgqvTeog@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.

CSS Fonts 4

  - RESOLVED: If the author specifies oblique, and synthesis is on, we
              fall back to synthesized oblique. (Issue #514)
  - RESOLVED: The fallback list for oblique is synthesized oblique,
              italic, roman, next font. The synthesized step is
              skipped if font-synthesis is turned off. (Issue #514)
  - The group will ask the TYPO group to review the previous two
      resolutions once they're in the spec to ensure they match author

  - RESOLVED: Close the issue no-change, fantasai to write a comment
              for opentype spec authors (Issue #519: Italic & Oblique
              benefit from not including a <number>)
  - RESOLVED: "font-named-instance" descriptor in @font-face with
              values 'none' or <string> and in the
              font-variation-resolution between step 4 and step 5
              (Issue #525)
  - RESOLVED: Move this issue (Issue #2540: Content authors want to
              modify style based on the presence of color fonts) to
              be a more general issue [because there is a larger need
              for properties to know if a resource downloaded properly
              and this should be a part of that larger conversation].


Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule
Scribe: heycam

[ A section of the group did a breakout on Transforms, Animations,
    Transitions - all open issues (see previous minutes). They
    rejoined the Fonts conversation after about an hour ]

CSS Fonts Level 4

  <fantasai> https://github.com/w3c/csswg-drafts/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3A%22Agenda%2B+F2F%22+label%3Acss-fonts-4

font matching should not favor italic as a fallback for oblique
  github: https://github.com/w3c/csswg-drafts/issues/514

  myles: This is pretty straightforward
  myles: I migrated this issue on behalf of jkew
  myles: Currently the way the spec is worded, if you say you want an
         italic font, the algorithm says UAs will try to match oblique
         ones afterwards
  myles: and vice versa
  myles: Jonathan Kew says this isn't how it used to be
  myles: Used to only go in one direction, fallback from italic to
  chris: Correct, CSS 2.1 just went one way
  florian: Did we change it bidirectional intentionally?
  florian: or just felt like the right thing to do at some point?
  myles: It was not intentional, don't think it was discussed in the WG
  chris: Also has a variable fonts interaction, with the italic axis
  myles: It's somewhat involved, but doesn't fundamentally
  myles: There are italic and oblique fonts, can be expressed with
         italic axis

  myles: I don't have a particular thought about this
  myles: Seems like there are some arguments to change it back
  myles: no arguments from me to keep it as it is
  astearns: Some people on the thread say it should stay as it is
  astearns: to avoid synthesizing things
  chris: But we also have a property to turn off synthesizing if you
  fantasai: [reads jfkthame's position]
  <fantasai> jfkthame's position:
  fantasai: I think it makes a good argument about making a
            distinction between oblique and italic
  fantasai: but there are two cases here
  fantasai: If you don't have oblique, instead of falling back to
            italic, use slanted normal
  fantasai: but if we've turned off font synthesis for italics, you
            can't have a slanted normal face
  florian: Then what?
  fantasai: Only choice for fallback then are use italic or normal
  chris: Then you fall back to normal face
  fantasai: Which risks losing the distinction between normal and
  fantasai: More important than the distinction between oblique and
  chris: Risks both ways
  chris: If someone explicitly wants oblique, it's probably in
         contrast to italic, like in some math
  florian: They may be
  florian: probably? not sure

  myles: I think it would be valuable to know which browsers do what
  myles: In WebKit italic and oblique are the same
  myles: Is that true in other browsers?
  frremy: Edge does have a difference
  frremy: and we can choose the angle
  eae: Blink is the same
  fantasai: If you have a family with italic and oblique and normal,
            if they choose italic or oblique, they should get what
            they requested
  fantasai: We have syntax to distinguish them, implementations
            should, too.
  myles: Now the spec allows our behaviour
  frremy: I recall in Firefox it's different
  emilio: Since Jonathan filed the issue, I assume so
  myles: So WebKit is the only one to treat them the same

  fantasai: Going through Jonathan's logic, there's a preference if
            you specify oblique, do that, then synthetic second, then
            what comes third?
  fantasai: If synthesis is disabled
  fantasai: I argue fall back to italics at that point
  [general hmms....]
  chris: I'm slightly worried about that, it's a third option nobody
         is asking for
  fantasai: Nobody was asking about the case of synthesis disabled

  frremy: Does anyone support disabling synthesis?
  myles: Firefox and WebKit do
  florian: What's the scope?
  astearns: In the @font-face rule

  florian: I think I will argue that if you disable fake italics, you
           never disable fake oblique
  myles: I don't believe there's any implementation that models fake
         italics as anything other than fake oblique
  florian: if you asked for oblique, and you've disabled font
           synthesis, you should still get synthesized oblique
  myles: No
  chris: That's not true
  chris: First, the definition of "fake"
  chris: In variable fonts there's an axis called ital which is the
         oblique axis
  chris: That shouldn't be turned off by turning off fake oblique
  florian: I'm saying you should never be able to disable fake oblique
  myles: No
  myles: Web authors mean it when they say disable synthesis of
  fantasai: If you have the font you use it no question
  fantasai: There's a big difference between what the UA can do and
            what the designer intended for italics.
  fantasai: For obliques, the difference is much smaller
  myles: I understand that distinction, every author I talked to [....]
  astearns: I hear if synthesis is disabled, it means never change the
  astearns: They happen to know that this font family has an oblique
            face, but the web font package forgot to download it, they
            still don't want a synthesized oblique
  florian: For italics I totally buy it
  florian: less convinced for oblique
  eae: Why not make it explicit, for oblique?
  florian: Sure
  florian: but people disabling synthesis in general, I think allowing
           synthesizing oblique is ok
  myles: font-synthesis talks about weight and style
  astearns: Style should block both italic and oblique. If you want to
            distinguish them, it would need a new value
  florian: So then what do we display

  fantasai: there are two proposals. Jonathan Kew's is, if you don't
            have oblique, you fall back to synthesis
  fantasai: Alternative is to fall back to italic if it exists
  florian: It's arbitrary
  florian: It's possibly true author is trying to contrast italic and
  fantasai: Can't think of a case when you want to contrast with
            oblique but not also contrast with roman

  koji: Author is specifying oblique explicitly
  koji: I don't think they care what it looks like if synthesis is

  fantasai: If the author specifies oblique, and synthesis is on, do
            we fall back to italics or synthesized oblique?
  frremy: Synthesized oblique
  chris: Agreed

  RESOLVED: If the author specifies oblique, and synthesis is on, we
            fall back to synthesized oblique.

  myles: Now it's legal in the spec to alias oblique and italics
  myles: I think this would make this impossible
  astearns: We're reverting back to the CSS 2 definition
  chris: So far
  frremy: I think the spec is very broad
  frremy: If you alias both of them, this section doesn't apply
  frremy: since you don't have a font-style that's oblique
  florian: Is this lack of distinction something you pro-actively want
           to preserve?
  myles: Haven't investigated how difficult it would be to get rid of
  myles: Don't know how CoreText differentiates the two
  myles: Given Chrome uses CoreText, I guess it's ok

  <tantek> I feel like we need more typographer expert opinion to make
           a more informed decision about these things. We should have
           discussed this in April when we could have asked a bunch of
           Typolabs people

  skk: If oblique is specified, which direction?
  myles: In horizontal it's well defined
  skk: In vertical? There's no definition
  florian: We have an issue open for that
  dbaron: We spent half a day talking about it once
  <dbaron> prior discussion of synthesis direction in vertical text
           was I think

  astearns: Other part is if font-synthesis for style is turned off
  chris: If there is already an italic, do we use that in preference
         to normal?
  fantasai: I think we should
  astearns: I think we should not
  florian: My preference is synthesize anyway, but I've heard the
  frremy: Fall back to normal is my normal
  chris: Me too
  astearns: Turning something off makes a path available that wasn't
            there before
  fantasai: No, it just means you've got a list of four preferences
            instead of three
  fantasai: non-synthetic oblique, synthetic oblique, italics, normal
  astearns: I'm saying when synthesis is on, you don't have a path to
            get from oblique to italics
  astearns: Weird to add that path when synthesis is turned off
  fantasai: You have it by having oblique in the font selection
  frremy: There may be a case, if you have a font with a custom font
          without a normal version, but does have an italic, you can't
          synthesize ...
  florian: Just put it in your fallback chain
  fantasai: You can't
  fantasai: I think François’ point is good
  fantasai: There are fonts that only have italic
  fantasai: So my pref is that we should have italics in that fallback
            chain, either before or after normal

  myles: [writes some options on the board]
  florian: If there is no roman, do you choose italic as fallback
  fantasai: We can also not decide this now
  tantek: Yes
  chris: They will say never synthesize!
  florian: They typically don't know about fallback on the client side
  tantek: I don't agree
  tantek: Typo Labs people were very aware of web ecosystem and how
          font loads fail
  tantek: I think they understand the context
  florian: Fair enough

  myles: One other issue. Oblique is not the initial value of
         font-style, so turning on oblique is an author saying "make
         it not the normal way it looks"
  myles: so probably shouldn't put normal before italic
  chris: Good point

  RESOLVED: The fallback list for oblique is synth oblique, italic,
            roman, next font. The synth step is skipped if
            font-synthesis is turned off.

  astearns: Let's consult with typo experts to see if it matches
  chris: Let's put it in the spec and then ask them

  <skk> Last Tokyo F2F, people from DTP said no oblique exist in
        Japanese vertical writing type setting. But recent ebook
        related people want to use italic/oblique font style.

Italic & Oblique benefit from not including a <number>
  Scribe: frremy
  github: https://github.com/w3c/csswg-drafts/issues/519

  chris: I read the entire issue, and didn't understand what the issue
         was about
  myles: I think the proposal is relative to variable fonts
  myles: You started being able to say "oblique 30deg"
  myles: Would prefer this not to be allowed
  chris: Why? you can still not define it if you don't want
  fantasai: Otherwise you get the value defined in the spec
  fantasai: not a value taken from the font
  myles: If you specify "oblique 0" you get roman
  myles: but with variable fonts, but you could make a 0deg oblique

  fantasai: Is there a field that says what the preferred oblique
            angle is?
  myles: There is the concept of named instances
  myles: you can say then "oblique" is this set of values
  chris: But the names are not standardized
  myles: Right, this isn't formal enough for us to rely on
  myles: There might be one in there with italic, but there might be
  chris: And it could be localized
  chris: so let's not do this

  chris: Proposal is to close no action
  myles: I agree
  fantasai: And add a comment that if this is wanted the Opentype spec
            adds some field for a value then we can consider using
            that instead of 14
  fantasai: otherwise we will not do anything

  RESOLVED: Close the issue no-change, fantasai to write a comment for
            opentype spec authors

Access to named instances in variable fonts
  github: https://github.com/w3c/csswg-drafts/issues/525

  myles: This is one of the top requests I get from typographers
  myles: Named instances are how you can associate a string with a
         position in the variable axises space
  myles: They want to be able to use them
  myles: The only way I see would be a property taking that name, and
         overrides every other property
  myles: but that isn't great

  heycam: Could we create a shorthand that would override these
  myles: The problem is that the axes are not always linked to the css
  eae: And the axes might have similar names but be used for things
       unrelated to what css means

  chris: Another way for doing that is to add a new descriptor in
  florian: Does that turn-off all properties that would be used for
  florian: We can ignore all the values specified elsewhere
  fantasai: We could pull the named instance, apply CSS modifications
            on top of it.

  heycam: But what if you want to start from a point, the named
          instance, then tweak one or two axes only?
  florian: Can we add a new initial value "auto" that is ignored by
           default but would override named instances otherwise?
  fantasai: You pick a specific point in the space, and use that as an
            @font-face directly
  fantasai: and then you can say what it is even if this is not what
            the font says it is
  fantasai: You should be able to do this for axes
  chris: The downside is that authors might use the named instances
         and opt out of the axes
  chris: First model is you ask one specific font and use it
  chris: Second model is the css model, you create families and use
         properties to change within the families
  fantasai: We could also override the named instances's standard axes,
            like the weight
  fantasai: So we pull the named instance, set the various
            non-standard axes according to the named instance's
  fantasai: but set the standard axes according to the CSS system
  fantasai: which might override what the named instance would
            otherwise be, but keeps the CSS system and the font
            settings aligned
  fantasai: E.g. if someone picks out an extra-black instance, but
            doesn't set it to font-weight: 800, then we apply
            font-weight: 400.

  myles: I think there are two design requirements
  myles: First is that fonts don't always download
  myles: Content blockers can for instance drop fonts, so we need to
         be resilient to font not being downloaded
  myles: Second is that the nested cases, where a span needs to be
         able to bold from its parent
  myles: We know that because we allow "Arial Bold" for instance as a
         font family
  myles: but we do this in a smart way, so if you unbold, you get back
  chris: So, we would have the same kind of game in this case, correct?
  myles: Yes
  chris: The advantage of having the named instance in the descriptor
         is that you can use the properties on the child element the
         normal way
  chris: which might be in that font-family or not, but this is the
         same as css from that point

  florian: I'm wondering if we named instances control things that are
           not css-y, then these values should be controllable by css
  florian: but does a named instance need a value for all axes?
  myles: Yes, it does have a value for every axis
  myles: So your proposal is not possible, because there is no default
  florian: We need a way of saying "this font-descriptor value is for
           font-matching only" or "this value is a set value, ignore
  chris: Basically, this is all because of variable fonts
  chris: Before we defined a nice set of things and it worked out
  chris: but with the ranges we have now, it would create many values
  florian: If you set a named instance, and don't use descriptor for
           weight, the range will continue to apply, override the
           named instance
  florian: but if your descriptor is explicitly set, then you would
           stick to that value
  florian: For instance "font-weight: <something>" and then you don't
           use the value from the font instance

  myles: In the spec right now, there are many places from which the
         axes values can come from
  myles: There is a specific order
  myles: In this order, descriptor are early, css is after
  myles: We could say that the named instance applies where exactly it
         appears in the order
  myles: then you continue to apply further rules as usual
  [myles summarises the precedence rules from
    https://drafts.csswg.org/css-fonts-4/#font-feature-variation-resolution ]
  myles: My proposal is that we could add a new signal to this
  myles: that would be the named instance
  myles: and it would be applied very early, other things come after
  florian: What ordering are you proposing exactly?
  <myles> https://drafts.csswg.org/css-fonts-4/#feature-variation-precedence
  myles: Between step 4 and step 5
  myles: a new descriptor that is either auto or string
  myles: If the value is a string, you look at the font, find that
         value and apply the axes
  chris: I like that
  eae: That seems nice
  eae: but if you fallback then these values don't apply
  eae: You could have one single glyph that uses another font
  fantasai: But then you have the issue that the axes might not be
            what css thinks they are
  myles: It's a little scary if we want to apply the axes of one font
         file, figure out if you are bold, then use these values in
         another font
  myles: If the first font doesn't load, then you get a different
  fantasai: Yes, I think if you want this, you should also set
            font-weight: bold and that would fallback properly
  eae: Authors might not do that
  myles: They will need to, because the ordering I propose will have
         font-weight win over the named instance
  myles: With this proposal, the named instance will set bold, but the
         font-weight will override this later
  fantasai: So the values we use to render are the ones that are in
            the computed styles
  florian: And discoverability?
  florian: Better devtools?
  (general support for myles proposal)
  PROPOSAL: descriptor in @font-face with values "auto" or "<string>"
            and in the font-variation-resolution between step 4 and
            step 5, we lookup the values of the named instance in the
            font and apply them

  frremy: Can we make it a list of names?
  frremy: So that way you can handle fallback fonts kind of better
  florian: Are you matching the lists? or just go through the whole
           list per font in src?
  myles: We can extend it later to do that, if needed
  astearns: Let's not do this, we can do this later if we want
  myles: It is backwards compatible to convert this to a list later
  frremy: Ok, sounds good

  dbaron: But what if you have different font files?
  dbaron: What if you want different names per font file in the src
  myles: You should only use src lists for cases when the browsers
         support different formats
  various: No, we don't want to do that
  myles: Not different files
  chris: myles: Let's do this later
  dbaron: What if instead of a separate descriptor you have a function
          that goes in the src: descriptor
  astearns: If you want that, I think you want that at the "src" level
  myles: If we want to extend this, we can come up with new ways later

  (bikeshedding about the name)
  (font- prefix because all of them have that)
  (-named-instance because that is what this is called in the spec)
  chris: I like font-named-instance, let's use that.
  astearns: So we seem to be converging font-named-instance
  florian: I'm not going to object

  RESOLVED: "font-named-instance" descriptor in @font-face with values
            "auto" or "<string>" and in the font-variation-resolution
            between step 4 and step 5

  (one more cycle of the bikeshedding, but the arguments are about the
  fantasai: We can rename things in spec, that's an editorial change
  fantasai: When we expose terminology through syntax, can chose a
            better name if we want
  chris: Yes, but I still prefer what we resolved
  heycam: Can we use "none" instead of "auto" though?
  RESOLVED: s/auto/none in previous resolution

Content authors want to modify style based on the presence of color
  github: https://github.com/w3c/csswg-drafts/issues/2540

  myles: This one can probably fit in a few minutes
  myles: The idea is that color fonts are so important to the design
         of the website that you should be able to chose other styles
         of the page depending on whether the browser supports colors
  myles: like a media query
  florian: Is that related to the media query for image types?
  florian: Maybe you could load some font type, then you load another
  leaverou: You can detect variable fonts with font-weight: 399
  fantasai: Not entirely because the browser supports it but the os
            could not support it
  fantasai: font-loading could be turned off, or the download didn't
  fantasai: So the relevant question is "did my font load"
  fantasai: and we don't have the means to create this right now
  florian: Custom media query?
  myles: This should be in javascript

  dbaron: We had a discussion a while ago, and we had resolved to add
          a few @support things
  dbaron: and TabAtkins and I didn't work them into the spec
  dbaron: We should start with these easy features first
  dbaron: and then we should think about more complex things, if we
  heycam: We can maybe add @supports for the font descriptor values
  fantasai: Yes, but the font might not have been loaded, so your
            styles will still be wrong
  chris: So whether or not you *can* load isn't good enough
  myles: Which is why I recommend javascript

  florian: Does the same argument apply for image formats?
  astearns: Seems like to me
  florian: Though an svg image, if you download it, you can maybe not
           support one of its feature
  TabAtkins: svg are very complex, but most images are pretty much the
  florian: I still believe it's the same problem, it's a continuous
  fantasai: I think we are not going to solve this in fonts-4 either
  fantasai: so let's discuss this maybe in conditionals-4
  myles: So let's close the font spec issue, and redirect to a more
         general issue
  fantasai: We want to frame this as "did this resource download and
            load properly"

  RESOLVED: Move this issue to be a more general issue

Received on Friday, 20 July 2018 00:28:06 UTC

This archive was generated by hypermail 2.3.1 : Friday, 20 July 2018 00:28:06 UTC