W3C home > Mailing lists > Public > www-style@w3.org > January 2015

[CSSWG] Minutes Santa Clara F2F 2014-10-28 Part IV: Fonts

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 2 Jan 2015 09:55:05 -0500
Message-ID: <CADhPm3v2Yya6S0GSHC-ZZOvSx8CAhj2_K-JHjYJa7d=3Z4ZmFw@mail.gmail.com>
To: www-style@w3.org

  - The expressed desire to have Kai classified as a cursive font
      from the Chinese publishing group as a way to distinguish that
      is is a different style garnered a lot of mixed thoughts and
      concern that the group didn't have the expertise to make the
      right decision.
  - There was also concern that Kai isn't widely downloaded as a
      font and more research is needed to see if it's common in
      devices marketed to a Chinese-speaking population.
  - RESOLVED: Topic goes back to the mailing list to find a good

  - RESOLVED: Only download a single font per family when
      unicode-range values overlap

  - Google's proposal for a timeout function for font downloading
      was discussed and fleshed out further.
      - A better definition of when timeout occurs needs to be
      - This also needs to be optional when only the real font will
          do, such as icon fonts.
      - There was neither full opposition or support, so discussion
          will continue on the mailing list.

  - RESOLVED: Start editor's draft of CSS4 Fonts


  Scribe: dael


Accessing Kai as a Generic

  Bert: So fonts. First subtopic...
  ChrisL: It's something jdaggett thought we didn't need to.
  Bert: Classification of Kai as cursive.
  jdaggett: I took it out of the draft
  fantasai: I think they'd like it to be reliably returned.
  jdaggett: I had some people say serif too. It's not an interesting
            debate for CSS.
  Bert: What are the downsides of leaving it out?
  jdaggett: I took any reference out and I don't think we should
            declare it either way. The spec was just listing
            examples and if there's controversy we should leave it
  ChrisL: I agree. If there's differences it shouldn't be an example.
  jdaggett: Okay.

  r12a: My understanding is that the Chinese wanted to get to
        somewhere when it would give you something like Kai if you
        select cursive. They'd like to know a way to influence it to
        get the correct font.
  jdaggett: Stepping away from Chinese, the generic cursive is
            somewhat useless because it can be all manner of things.
            It's probably not used that much. It's a random font
            that looks scripty.
  ChrisL: Good examples?

  fantasai: Problem is Chinese use things like a Kai font in a
            similar was to a roman font vs an italic. We need a
            generic way for the distinction where you don't lose the
            semantic. They need a way to switch without providing
            their own font. It's about "I need to express stylistic
  jdaggett: The underlying problem is we don't have availability on,
            you don't have a Kai style font on every system. These
            sorts aren't available across platforms so as a generic
            it's not useful.
  bobtung: There's Kai on Microsoft, on iOS, it's Android that
           doesn't have Kai or Ming. It's important in ebooks, such
           as Chinese. We usually use the Kai for citations,
           quotations, and dialog.
  florian: And you're saying it might not be universal, but it's
  bobtung: Many of them.

  Bert: I'm not hearing progress.
  fantasai: I think it comes down to we say either we don't care
            about your problem,
  fantasai: or we say we'll classify Kai as cursive and use cursive
            vs serif as a way to switch
  fantasai: or we decide we'll do something with font-style and add a
            kai keyword there.
  fantasai: I'm inclined to not do the first option. It should be
            expressible in a generic way.

  florian: What's wrong with creating a Kai category?
  ChrisL: You have to decide what happens when you use it for
          another language.
  jdaggett: To put this in a different context, I think every script
            has a different set of typographic decisions. There are
            broad categories to classify fonts. I think it's not
            really helpful for CSS to try and use generics to
  jdaggett: The idea of a generic is you can use it across systems
            and it's consistent. I don't think it's in this case or
            any of the other cases, like slabserif.
  fantasai: I'm not in favor of increasing the number of generics. I
            think we need the very broad categories we have and they
            serve as a generic fallback font family. I think we
            should solve this specific problem by classifying it as
            cursive or italic or making it a new font style value.

  r12a: So you're saying you'd take Kai out of the serif?
  jdaggett: I don't think CSS is the right place to make this
            decision. It doesn't make sense for us to enter this
  r12a: The proposal was from a Chinese group for the publishing
        industry was that Kai was in the wrong place. I'm asking do
        you want to keep Kai under the serif category or will you
        take it out?
  fantasai: He's already done that.
  r12a: That's fine.
  fantasai: That doesn't solve the publishing industry's problem.

  jdaggett: I think you need font availability consistent across
            the platforms and you don't have that, particularly on
  florian: I don't think this group should go with a large effort,
           but if it's not done here, where?

  Bert: We had two options, a new generic family of Kai wasn't
        popular. Another option was a font style. Is that
  Bert: What would be the downside of that?
  Bert: We're not making progress.
  jdaggett: I think this is better on the list with a wider audience
            that might have knowledge that applies.
  Bert: No new ideas?

  fantasai: One thing we might want to resolve is if we're going to
            address the issue. If we're not we should resolve it now.
            If we're going to find a solution, then the list is
            going to be charged with finding a solution
  Bert: So should we try and come up with a solution, or say it's
        not our business?
  Bert: fantasai says we should solve it.
  bradk: If we don't solve, it will implementors do different
  fantasai: Or no one doing anything.

  dbaron: So what is the issue? Allowing authors to choose a Kai
  ChrisL: Allowing them to say I want two types of fonts, A or B,
          and they're distinct and it should work for more than
  fantasai: That's really vague. I don't think anyone will be
  ChrisL: If not that, we should be providing fonts. We're moving
          that way.
  fantasai: ereaders don't have that option. Lots of devices don't,
            so looking at system fonts is a thing.
  fantasai: Chinese is also a pretty big download. If it's generic
            enough than most Chinese ereaders would have it, you
            don't want to trigger a download.

  jdaggett: I think this requires extra knowledge that's not in the
            room, so I think we should defer to the list.
  Bert: I think we can conclude we won't solve it here, but I want
        to ask, are we going to try and solve it at all, or give up?
  jdaggett: One condition to solve this, a generic requires common
            support across devices. If there is common support then
            having a CSS solution for a generic makes sense, but if
            you don't have a common support there's not much you can
  Bert: And how will we find that out?
  jdaggett: I don't know. Maybe people in the Chinese publishing
            group can come up with a list of fonts?
  r12a: We can take this back to the group of publishers who brought
        this up in Beijing.
  fantasai: We might find the necessary fonts won't be on all
            devices, for example my windows computer will only
            likely have one because I have an English OS.
  jdaggett: It's more Android that you'd worry about.
  fantasai: If it's not targeted at the Chinese market, it won't
            likely have more than one. If we limit to the Chinese
            market we might find the availability.
  jdaggett: Hong Kong too or just mainland?
  fantasai: All of them. If you're looking across the world the
            answer will be no. Will it be on all systems in the
            target audience, we might get a yes, though maybe a no.
            If your criteria is "all systems everywhere needs to
            have these fonts", we won't have that.

  Bert: I think we've discussed enough.
  r12a: bobtung is here and he has a table that shows the major
        systems have Kai, serif, and sans serif, but lets go back to
        the list.
  Bert: So the question is do we want this to go back to the list?
  florian: So list or never or...?
  Bert: Back to the ML and try and solve it, or should we not try.
        We won't have a solution right now. Anyone thinking we
        shouldn't move this to the ML?
  Bert: No one objects, so back to the list for a solution.

  fantasai: So the goal is the list will come up with a solution and
            not entertain not having a solution unless we discover
            it's intractable.
  Bert: Yes. Okay with you jdaggett?
  jdaggett: I'm not really comfortable with it, but we can deal on
            the ML.

  RESOLVED: Topic goes back to the mailing list

Unicode-range issues

  <jdaggett> http://lists.w3.org/Archives/Public/www-style/2014Oct/0472.html
  jdaggett: This is small implementation details about Unicode range.
            Can someone project the link?
  [Trying to find someone to project the link]
  jdaggett: If people bring up the link in IRC, unicode-range allows
            you to say for specified fonts, only download if you're
            using it for this set of characters.
  jdaggett: But sometimes you're pulling down a font just for the
            metrics. So we have three fonts we can download, which
            do we choose?
  jdaggett: You can solve this many ways. You can decide on a
            specific character, on the last font defined, any choice
            is arbitrary. Chrome looks for the first font that
            defines a space character.
  jdaggett: Safari and IE claim to support this, but their
            implementation pulls down the whole font no matter what
            so that's not close to spec. Does it make sense to do
            this or is there a better way?

  ChrisL: I agree it's arbitrary and it's more important that we
          pick something. The space thing is as good as any.
  TabAtkins: Ditto.
  dbaron: I think it's fine. Some units do depend on a particular
          character. The x unit can depend on characters, the ch
          depends on 0. So maybe it should be a 0 character for the
          ch and space for everything.
  ChrisL: If we're doing something arbitrary, why not 0 for
  TabAtkins: I doubt we thought this through much when we
             implemented but if you have spaces, you have 0s likely.
  fantasai: For ch, a consideration was wanting numbers to line up.
            0 will always have the width of the number.
            Numbers typically are things you want to line up so we
            wanted to pick from there.

  jdaggett: Within a font there are a set of non-glyph-specific
            metrics. What I'm getting at is the only thing needed is
            the general font metrics to pick up a font.
  jdaggett: For fonts that depend on a measurement for a glyph it
            should be more specific.
  Bert: I'm hearing any character is fine.
  ChrisL: Given that one thing requires a 0, I think we should use
  dbaron: But if you're doing a thing using actual font metrics, you
          do this.
  fantasai: We use the space to measure the length of tabs.
  ChrisL: Okay. I withdraw that.
  dbaron: I think it's not the question of if it has a space, but if
          the unicode range for the @font includes a space.
  dbaron: If you were looking for a space and the space was in the
          unicode range and the font didn't have it you would
          continue to fall back.

  Bert: So does that give you enough information, jdaggett?
  jdaggett: It seems we can use the space character to choose which
            fonts to look up and I can post the wording change.

  jdaggett: Second issue in that e-mail, in situations with
            overlapping unicode-ranges, the spec needs to be more
            specific about loading behavior where you don't want to
            load all fonts in that family that have a code point.
            You only want to load one at a time.
  jdaggett: If there's some character in the unicode range of two
            different fonts, you want to pull the first font and
            test before pulling the second.

  <ChrisL> I support the proposed restriction on one concurrent
           download per font family
  ChrisL: I was about to agree, but what if you have bold, italic
          and roman?
  jdaggett: No, no. If you look at the match algorithm where this
            would go is set 5 where you've already matched to a
  ChrisL: That's fine.

  Bert: Thoughts on implementation? If you're serializing things may
        slow down.
  ChrisL: If you initiate a download of a larger font you'd have to
          throw it away, so this is saving time.
  jdaggett: In the example you've got a Latin and a fallback and you
            don't want to load fallback unless you really have to.

  Bert: Okay. Different opinions?
  Bert: I see thumbs up.

  RESOLVED: Only download a single font per family when
            unicode-range values overlap

Font Download Timeouts

  jdaggett: Next issue is the proposal from Google.
  <jdaggett> http://lists.w3.org/Archives/Public/www-style/2014Oct/0434.html
  <jdaggett> https://github.com/igrigorik/css-font-timeout/blob/patch-1/README.md
  TabAtkins: Yes. I will link to...
  Bert: jdaggett did.
  jdaggett: That's the post and the proposal.

  TabAtkins: Right now browsers do different things handling a font
             download that's taking a long time. Firefox and Chrome
             will display nothing for 3 seconds and use the fallback
             until it comes in. Microsoft immediately does fallback,
             Safari shows nothing until the font comes in.
  TabAtkins: These are all geared to when text was the only thing.
             This is for a font-rendering descriptor that lets
             authors control font fallback behavior. These are all
             variants on the mandatory requirement
  TabAtkins: If you have a less necessary font and are okay with the
             user seeing a fallback, you can use swap or optional
             which only uses the font if it's downloaded.

  jdaggett: What happens on re-flow?
  jdaggett: Let's say you hover over an element that changes the
            style, what happens? Do you continue to use the non-
            downloaded font or...?
  TabAtkins: For consistency, for optional or swap if you hit the
             case where you're sticking with fallback for page
             lifetime, you're staying with it.
  fantasai: What about resize?
  TabAtkins: Maybe you won't re-flow.
  jdaggett: This font made it or didn't and then it's like a state
            that's maintained? If I add elements what happens?
  TabAtkins: The name resolves to a particular font at a particular
  jdaggett: So even if I download the font it'll never appear on
            that page?
  TabAtkins: Yes.

  jdaggett: Why is this necessary?
  TabAtkins: The proposed version isn't as necessary. It can be left
             off. The property is if all you know is that a given
             element is important and needs to be displayed you can
             set that at the element level instead of tagging each
             font face.
  TabAtkins: It means that if some elements show up some times you
             might not trigger the font download mandatorily.
  jdaggett: So if I set one optional and one mandatory on a
            different element, what happens to the other element?
  TabAtkins: That don't declare rendering?
  jdaggett: Or additional section. You're saving a piece of state
            and I'm not sure which one.
  TabAtkins: On a per element basis you would override a piece of
             state. So you're okay with your header re-flowing, but
             you don't care about using the fallback on small pieces
             of text.
  TabAtkins: In the example the header always gets the branding it

  jdaggett: Why can't this be done with script?
  florian: As a user I don't like the mandatory and I want the swap
           and I'll put that in my user stylesheet and I can't do
           that if it's script.
  jdaggett: You want this in the user stylesheet?
  florian: I do.

  TabAtkins: The mandatory strategy is pretty easy to do, the others
             are a more involved piece of code, especially the
             optional value.
  TabAtkins: Using the font loading API for the more optional ones
             is more difficult than it might look.
  jdaggett: What's the default?
  TabAtkins: We're not sure.
  TabAtkins: It would be UA defined.
  fantasai: I think it should be auto. The UA should be able to come
            up with other ideas. If we say the current mandatory of
            3 seconds, it doesn't let them come up with something
            that's not a timeout.
  jdaggett: And Firefox isn't a straight 3 sec timeout. We check to
            see if it's progressed after the first 3 seconds and if
            it has we wait another 3 seconds before fallback. So you
            have to be careful not to block.

  TabAtkins: So that seems like it should be UA defined.
  fantasai: Do you have another name besides auto?
  TabAtkins: Yeah, sure auto then
  TabAtkins: Sometimes we just say it's UA-defined
  fantasai: Yeah, and that has to map to one of the other options.

  Bert: Other opinions?
  MaRakow: Is anyone asking for optional? When they never get the
           right font?
  TabAtkins: I'll have to ask for more examples.
  jdaggett: I think the timeout needs to have a definition. Like
            starting when?
  TabAtkins: When the CSS is seen more or less.
  jdaggett: One of the problems is download-able fonts have a lot of
            content and we only look once layout starts we tend to
            not get into a good position in the queue.
  jdaggett: Optional will fail a lot of times.
  florian: It fails on first load.
  TabAtkins: Optional is for fonts that are nice to have but not
  jdaggett: I think some of the resource based is better than CSS
  TabAtkins: I'd like examples.
  jdaggett: It's like you're loading the resource here for use in
            another page.
  TabAtkins: Sure, yes.
  fantasai: That doesn't make sense.
  TabAtkins: You're loading for other pages in the domain.

  fantasai: What happens with iframes?
  TabAtkins: They're a new page. They're a weird element, separate.

  Bert: So do we continue working, or think it's a bad idea?
  jdaggett: I think there's useful stuff, but I'm not sure this
            fine-grained stuff is useful to give to authors. The
            timeout may be something a user wants to set. It's like
            anti-aliasing, it's a preference. I think the swapping
            in and out is, well, does the user want to see the text.
            When I'm on mobile Safari, I don't really care about
            loading the font for 60 seconds and I just want to see
            the text.
  jdaggett: You're making it an author preference.
  TabAtkins: The property value exists to override that.
  jdaggett: As a user I couldn't override.
  TabAtkins: You could apply it to the user stylesheet and who
             cares what the author says.
  florian: And if your browser doesn't allow user stylesheets, get
           another one.

  bradk: Another case for mandatory is if you have icon fonts.
  florian: Mandatory is relevant on icon fonts so it's useful to
           have in the hands of authors. That's the reason why.
  jdaggett: We created the font-loading API to give authors this
            level of control. They should decide how they want to
            introduce it or not. I don't think this has to be
            encapsulated as a CSS property
  TabAtkins: You can use font loading for loading behaviors you'd
             want, but making the common cases simple, the non-
             defaults and better for users. The defaults are hostile
             because they're trying to be conservative.
  fantasai: It's user preference.
  TabAtkins: It's per font. You don't want icon fonts to show with

  fantasai: Are icon fonts the ones that change letters into
  TabAtkins: Yes. The default is tuned for that kind of usage
             instead of fonts that render text. They don't show
             anything until the font is loaded and is bad. We should
             preserve that ability, but being able to do this is
  fantasai: How did we end up in this mess? We've optimized for the
            stupidity. The people that want the right thing now have
            to learn more CSS properties to make your page nice for
            the user.
  TabAtkins: You've described CSS, yes.
  jdaggett: Instead of using icon fonts, if you use an icon image
            and you have the same problem.
  fantasai: Use emoji.
  TabAtkins: Remember we didn't have emoji when we made this.
  florian: I think this needs tweaking, but I think it's worth

  Bert: I heard looking into resource hints should be looked into,
        can it be done with API, though user stylesheets can't.
        Other things to look into?
  bradk: Defining when timeout starts.
  Bert: I didn't hear full opposition or support so it needs further
  TabAtkins: If we're okay to continue on the mailing list.
  fantasai: I say we call it font-loading instead.
  jdaggett: font-rendering is a terrible name

  Bert: There's one more issue on fonts?
  jdaggett: Last thing I wanted approval on was I wanted a CSS4
            fonts so that when people have new ideas we have a
  <fantasai> +1
  fantasai: +1
  TabAtkins: Given my experience, I recommend we make this a delta
             spec and whenever you want to publish it's much easier
             to keep error from creeping in.
  jdaggett: Hopefully everything will be fixed.
  TabAtkins: I hoped that too.
  Bert: So you can work on CSS4 Fonts.

  RESOLVED: Start editor's draft of CSS4 Fonts


  Bert: Okay, back to plinss
  jdaggett: I have to go.
  fantasai: Can you be back?
  jdaggett: After 5pm your time.
  fantasai: We'll save it for you.

  dino: If we're going to break soon, this (Animations) might take
        an hour or more.
  dino: We could briefly talk about while we have krit...the filters
        proposal? Or is something more important?
  dino: Scrolling and animations is all one thing.
  plinss: So break and get back to that.

  [15 min break]
Received on Friday, 2 January 2015 14:55:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:50 UTC