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