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

[CSSWG] Minutes Seattle F2F 2017-01-12 Part IV: Font color palettes, Font rendering controls, Font loading, Tokyo F2F [css-fonts]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 13 Feb 2017 20:58:35 -0500
Message-ID: <CADhPm3uPkyf3WgZ38zrD_Y2LDb-HADsVu9KCAoToK6DJbmxKxw@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.
=========================================


Font color palettes
-------------------

  - myles introduced his proposal for font color palette controls.
      Spec here: https://drafts.csswg.org/css-fonts-4/#font-palette-control
      Slides here:
https://lists.w3.org/Archives/Public/www-archive/2017Feb/0007.html
      - The group had a lot of questions around the decision to
          allow naming of templates, but not individual colors as
          people felt it may be too limiting.
      - There were also questions about why transitions weren't
          allowed on color palettes, though it was suggested that
          you could resolve the colors in the palette on a per
          element basis instead.
      - The ability to use currentcolor in the default palette will
          be raised as an issue to resolve.
  - RESOLVED: Accept Myles's slimmed down palette control (associate
              a palette name with a font via @rule, assign colors to
              individual palette entries), with variables usable in
              the palette entries, drawn from the element's custom
              properties on use.
  - RESOLVED: Replace the <integer> in font-palette with "normal",
              and make it the initial value. (Choosing a specific
              font palette will require a bound name.)

Font Rendering Controls
-----------------------

  - RESOLVED: FPWD for font-display (based on
              https://tabatkins.github.io/specs/css-font-display/)

Font Loading
------------

  - TabAtkins will review the open issues.

Tokyo FTF
---------

  - RESOLVED: Industry meetup Thursday afternoon in Tokyo

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/seattle-2017

Scribe: Florian

Font color palettes
-------------------

  myles: [presents the topic, slides:
https://lists.w3.org/Archives/Public/www-archive/2017Feb/0007.html]
  all: [applaud]
  <jensimmons> URL to the spec?
  <astearns> https://drafts.csswg.org/css-fonts-4/#font-palette-control
  <jensimmons> thank you

  TabAtkins: None of the proposals make sense if you cannot change
             the colors in the palettes.
  TabAtkins: Myles said you can't.
  TabAtkins: If you can have functional names for the color (main
             fill, shadow...), and set them to something, then it
             works
  TabAtkins: but that assumes that you can set the colors
             individually, not just select a palette.
  myles: The font contains a list of colors, and palettes are define
         by referring to some colors in that list.
  fantasai: Are all the palettes the same number of colors?
  fantasai: TabAtkins was saying that you want to change the the
            colors in a particular slot of a palette.
  fantasai: Manipulating the colors in the list of colors is not
            useful, but changing colors in a particular palette is.

  surma: So we have a collection of themes, and and you can pick one
         right?
  astearns: Yes.
  myles: So I think this is very confusing
  myles: and would like to propose an alternate syntax.
  myles: [proposal in the presentation]
  gsnedders: What happens if you don't set the base palette.
  myles: We pick something by default.
  Florian: And you not override individual colors?
  myles: Yes.

  <liam> [it might be useful to be able to say 0 white 31black and
         have the intermediate entried filled in linear interpolated
         values?]
  <astearns> liam: not clear whether font palettes are set up in a
             fashion where you'd want to fill entries in that manner
  <liam> astearns, I think if CSS supported it, they would be. Today
         the technology is still very new.

  fantasai: First comment: as an author, are you going to think per
            font, and think across fallbacks.
  fantasai: Will I remember to set the theme for fallbacks?
  TabAtkins: You'll need to do both.
  myles: And you can do both.
  myles: I think both will be popular.
  myles: There aren't many fonts like that yet, so we have limited
         data about that.
  dbaron: What you lose with this proposal is the ability to name
          individual colors within the palettes, right?
  Bert: That's an advantage, you don't have to name things.
  eae: The original proposal let you name the colors, this lets you
       name the theme.
  <liam> [can't see the proposal here :) but not having to name
         things != not able to name things]
  <liam> [css custom properties, or preprocessors though]
  <astearns> proposal: @font-palette-values "Jupiter Sans" "Arizona"
            { base-palette: 3; 1: rgb(); 2: rgb(); }
  <astearns> usage: font-palette: named-palette(Arizona);

  zcorpan: You can use variables to share colors across themes.
  TabAtkins: No you can't, these are not properties, no cascading
  TabAtkins: so you lose the ability to tweak individual colors in
             the palette on a per element basis.
  TabAtkins: You can set up colors using variables for your page and
             use them everywhere, but here you have to repeat
             manually.
  Bert: Can we consider the named palette to be a color?
  Florian: How does that work when using it on things other than
           fonts?
  Bert: You just pick one.
  TabAtkins: Could we reintroduce the naming of the colors as well?

  <liam> shouldn't this go in @font-face ? can it also be made to
         work for SVG e.g. for border images?
  <TabAtkins> liam: Proposal is that you can set up a named palette
              for a particular font, assigning colors to particular
              palette entries by index. If you set up the same name
              for multiple fonts, you can just turn on that
              particular name, and it'll work with font fallback.
  <liam> thanks, Tab

  <esprehn> what does base-palette: 3 do here?
  <TabAtkins> esprehn, It lets you default your palette entries to
              one of the predefined palettes in the font.

  esprehn: Can you set it on the color property instead of the
           font-palette?
  dbaron: In the palette definition, you could define which of the
          color is the one to use when it is used as a generic color.
  <dbaron> (my comment was in response to Tab saying (in response to
           ??) that the named-palette() could be a value of 'color'
           instead)
  <TabAtkins> (I didn't say that, I said it was relatively
              unimportant whether it was in 'color' or
              'font-palette'.)
  Bert: That's what I said.
  astearns: That would allow us to use these constructed palettes
            anywhere you can use a color.
  Florian: That's orthogonal to being able to override individual
           colors in the palette on a per element basis.
  dbaron: That is to enable 'currentcolor' in other color properties
          to match something from the palette, rather than the now
          ignored color property.
  plinss: That doesn't work, because matching a color in the palette
          is not what you want, you need something that visually
          matches the palette
  plinss: which may not be one of these indexed colors.
  Florian: Could be defined as an extra color in the palette, even
           if the font doesn't use it.
  fantasai: But fonts aren't likely to have that entry.

  TabAtkins: Gradients are computed from the colors in the palette
             right?
  myles: Yes.

  esprehn: What happens to the color property?
  myles: It is ignored.
  myles: Today the color property is ignored with fonts that have a
         palette.
  fremy: Using the color property as all the colors in the palette
         would be terrible for emojis.
  <astearns> [esprehn talks about being able to modify all of the
             palette colors to make them redder, darker, etc.]
  esprehn: You may want to influence the spectrum of the colors in
           the palette based on the the color property.
  <TabAtkins> I find it very unlikely that we can do an automated
              color-shift that'll have a good effect in general.
  SteveZ: You don't want that to happen on emojis.
  myles: Your smileys are going to look sick.
  SteveZ: You could use it to change skin tone on a face.

  TabAtkins: Backtracking a bit, was it intentional that you removed
             the ability to give names to individual colors, or just
             a side effect of simplifying
  myles: More of the later
  myles: because that seems less important.
  plinss: Naming the palette slots and being able to control that
          seems very fragile.
  TabAtkins: My main use case is to get some way to use the colors
             you've defined in variables.

  fremy: I am worried about not having the ability to do transitions
         on color palettes.
  myles: That may be a good thing.
  plinss: I don't see why you couldn't do it. May look ridiculous,
          but it should work.
  gsnedders: Is that reasonable to expect font libraries to do that.
  plinss: If you can set colors, you can do that.
  astearns: There are effects that are useful. Make the highlights
            and flares be animated.

  Florian: Just make the var() function in in a palette definition
           fetch the value from the root.
  fremy: That doesn't let you change them on a per element basis.
  TabAtkins: That's ok, I don't care too much about that.
  fantasai: Could you resolve the colors in the palette on a per
            element basis?
  myles: That might be a good idea.
  TabAtkins: It works. More complex, but more in line with how
             variables work.

  esprehn: What if we had a palette(colorindex colorvalue...) syntax?
  TabAtkins: I don't want to expose indexes
  TabAtkins: because they can mean different things in different
             fonts.
  <esprehn> I asked if we could do palette(Name) and palette(1 color
            2 color) and transition by expanding to the long form
            inline
  <esprehn> TabAtkins said no, because the indexes map to a specific
            font, so putting them in a property doesn't work with
            font fallback
  plinss: You can get what esprehn is proposing by [missed] then you
          just use the slot names.
  fantasai: That's what the previous proposal was.
  TabAtkins: With this one you can do that without inventing a new
             naming scheme, just reuse custom properties.
  SteveZ: So if I had Trajan with an Arizona color scheme, I would
          define the mapping to its indexes.
  TabAtkins: Yes.

  TabAtkins: The only downside is that the interpolation without
             exposing an interpolate function.
  fremy: Just animate the color properties.
  TabAtkins: So don't make font-palette animatable, animate only via
             custom properties?
  fremy: Yes.
  SteveZ: Why are there palettes at all?
  myles: You need at least one of them
  myles: to pick a set of colors in a GUI.
  astearns: Because font designers want control.
  fantasai: It depends on the kind of font. For emoji you'd want to
            rely on the font designer for example.

  fantasai: [...]
  myles: Sure.

  <liam> [a current trend in typography is "hand drawn" layered
         fonts, where you put each layer in a different colour]

  Florian: Names internal to CSS should be an ident rather than a
           string.
  Florian: So @font-palette-values "Jupiter Sans" Arizona { ... }
  myles: I wanted to avoid conflicts with light and dark.
  TabAtkins: That's fine.
  TabAtkins: It's a tradeoff between bother authors or our future
             selves.
  fantasai: Counter styles deals with this already.
  fantasai: If you define a custom name that is the same as a
            keyword that already exists, the custom one wins.
  plinss: [mumbles]
  zcorpan: The font name should maybe be inside the brackets.
  zcorpan: Less confusing, especially with font names that might not
           be quoted.
  myles: We can move the font-family name into the descriptors.
  TabAtkins: Or the other way around
  TabAtkins: but let's push that discussion into an issue.

  TabAtkins: I'd like to resolve on the general proposal, and do the
             rest of the bickering in github
  Florian: +1
  astearns: I like that.
  <fantasai> I would also suggest s/base-palette/extends/ to be
             consistent with the terms in @counter-styles

  Bert: You can maybe put the whole thing inside the font palette
        property.
  fantasai: Then you can't reuse it other places.
  Bert: If you don't want to invent a reusable name, you could just
        inline it.
  TabAtkins: An anonymous font palette.
  astearns: We could do that later.
  Bert: yes. that gives us access at the property level

  <fantasai> Currently on the board:
             @font-palette-values "Jupiter Sans" Arizona {
               base-palette: 3;
               1: rgb(...);
               4: var(--stuff);
             }

             selector { font-palette: Arizona; }

  <TabAtkins> Proposal: Accept Myles's slimmed down palette control (
              associate a palette name with a font, assign colors to
              individual palette entries), with variables usable in
              the palette entries, drawn from the element's custom
              properties on use.

  RESOLVED: Accept Myles's slimmed down palette control (associate a
            palette name with a font via @rule, assign colors to
            individual palette entries), with variables usable in
            the palette entries, drawn from the element's custom
            properties on use.

  SteveZ: Typically, the first palette is a bi-color with black and
          a main color, should it use the color from the color
          property.
  fremy: The palette can use current color.
  SteveZ: People wanting to change the color of an emoji, and having
          to define a custom palette just for that seems overkill.
  SteveZ: So using the currentcolor in the default palette would be
          useful.
  SteveZ: Please mark as an issue.

  fantasai: ???
  TabAtkins: The idea was that indexes would only apply to the first
             font, not to fallbacks.
  fantasai: It's not just that, there are also issues with cascading
            and inheritance.
  TabAtkins: True.
  fantasai: There are many ways to end up with a font that's not the
            one you thought about, and then your palette makes no
            sense.
  Bert: Maybe we need a none or default or auto or normal, instead
        of the integer in the font-palette property.
  astearns: It's a bit annoying, but it removes the footgun.

  RESOLVED: Replace the <integer> in font-palette with "normal", and
            make it the initial value. (Choosing a specific font
            palette will require a bound name.)

  fremy: How about the font-shorthand?
  myles: Please file an issue?

Font Rendering Controls
-----------------------
  Scribe: fantasai

  <dbaron> https://tabatkins.github.io/specs/css-font-display/
  dbaron: So, this is a spec that Tab proposed a few years ago and
          for some reason we never accepted it as an ED.
  dbaron: It's in Tab's personal github, we have an implementation
          in Gecko prefixed off because it's just in Tab's repo.
  TabAtkins: So do we.
  Florian: So we can go straight to CR!
  <laughs>
  <Tab attempts to pronouce FPWD>
  <TabAtkins> fuh-pwid

  dbaron: This comes from me going through our list of features we
          have implemented and prefixed off, and figure out why
          they're prefixed off and if we can ship them.
  myles: How about putting it into css-font-loading?
  Florian: Small scoped modules are easy to work with. This is
           fairly self-contained, so keep it that way?
  myles: If it does goes into Fonts, does that make you co-editor?
  myles: My opinions have changed.
  <dbaron loses his implementation hook>

  astearns: Any objections to FPWD?
  SteveZ: I'd like to object.
  SteveZ: If people are going to find things, keeping it split out
          much harder.
  <dbaron finds his implementation hook>
  astearns: I'd like to keep them separate for the sake of moving
            quickly.
  fantasai: We could consider merging the two specs once they're in
            CR.
  SteveZ: Please cross-reference extensively.
  gsnedders: Let's get an FPWD asap so we can start the 150-day
             counter.

  RESOLVED: FPWD for font-display

Font Loading
------------

  plinss: BTW, font-loading has been in LC since May 2014.
  [process discussions]
  dbaron: Two issues in GitHub and 6 in the spec
  ACTION: TabAtkins Deal with issues on font-loading so it can go to
          CR
  <trackbot> Created ACTION-821

  fantasai: Btw, when is Transitions going to CR? We resolved to do
            that a couple years ago as well
  dbaron: People keep raising more issues.

Tokyo FTF
---------

  skk: Prepared this slide to describe
  <astearns> April 18-21
  skk: 18th is Houdini, other three days for CSSWG.
  skk: On ML I proposed a JP Industry Meetup
  skk: As we did in Sapporo TPAC.
  skk: In addition, also have a Vertical Writing Web Award.
  skk: Result will be decided in March, so we can present to this WG.
  skk: Would like to have some joint meeting time slot.
  skk: Proposed at first the 17th
  skk: But yesterday, was suggested that 17th not so good because
       18th is Houdini, and industry meeting is preferred closer to
       CSS meeting which is more related.
  <dbaron> Note the AC Meeting is Sunday evening through Tuesday in
           Beijing
  skk: So, proposal to change 20th to half day CSS and half day JP
       industry meeting
  skk: Then follow by dinner.
  skk: That maybe helpful for discussions.
  skk: Is there preference for Monday or half-day Thursday?
  Florian: We need to announce to Japan, so need to make final
           decision asap.

  Rossen: What time were you thinking about starting?
  skk: I haven't decided well, but from my mind 1pm-6pm in the
       afternoon.
  Florian: If we feel this might be reducing CSS meeting too much is
           to also consider expanding dual-track to parallelize
           Houdini and CSS.
  fantasai: Are we more likely to successfully dual-track JP meetup
            with Houdini or with other topics in CSS?
  astearns: CSS is a bigger group so Houdini seems more likely.
  <astearns> what I meant is that we'll get more participants in the
             industry meetup if we have it on a CSS day
  Rossen: Thursday afternoon seems likely.
  Rossen: We can decide later if we have critical mass to dual-track
          the afternoon on another topic.
  Rossen: But having on a separate day, especially if it extends the
          number of meeting days, is maybe hard to justify
  Rossen: So I think this plan makes more sense.
  skk: OK, I will announce for Thursday industry meetup
  skk: I will notify everyone of the time schedule

  RESOLVED: Industry meetup Thursday afternoon in Tokyo

  <astearns> provisionally meet week 1 or 2 in Aug, in Europe
  <astearns> checking hosting availability for those dates
  <Bert> My meeting rooms in Sophia-Antipolis are all available.
         Hotels I don't know...
  <rachelandrew> just noting that week 1 and 2 in Europe is prime
                 school holiday season. Expensive hotels and
                 airports are interesting.<div
id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
	<tr>
        <td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
		<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
		</td>
	</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Tuesday, 14 February 2017 01:59:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 14 February 2017 01:59:41 UTC