- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Jan 2020 19:38:04 -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.
=========================================
Upcoming F2F
------------
- Members should tag any github issues that are for F2F discussion.
- A private wiki page will be made by fantasai to coordinate travel.
Open Type
---------
- Any group member with items that should be added to the list of
topics to cover with Open Type should reach out to Chris.
CSS Color
---------
- RESOLVED: Add lab keyword to color() function (Issue #4649: Should
the color() function accept 'lab' as a color gamut
keyword)
- The quick answer to Issue #4647 (Do gradients/animations using lab/
lch colors interpolate in the Lab colorspace?) is yes.
- Going deeper into the issue the group decided that for
transitions and gradients there should be a smart default
that, if the colors use the same space, they're interpolated
in that space. If they're not in the space they'll
interpolate in Lab space. Gradients will have the ability to
select a different space for interpolation.
- Chris will add additional spec details to clarify how displays
should render colors in wider color spaces in order to resolve
Issue #4646 (Should lab() colors which are outside the sRGB
gamut be rendered on capable displays?).
- After looking into issue #4622 more (gray() function produces a
warm, D50 white) it's not really a concern so Chris will close
it no change.
- RESOLVED: Drop gray() function (Issue #4621: Better name for
gray()?)
- RESOLVED: Update WD of css-color-4
CSS Pseudo L4
-------------
- RESOLVED: Close no change (Issue #4626: Layering of highlight
pseudo backgrounds)
- fantasai introduced Issue #4579 (::selection vs
::inactive-selection) however there wasn't time to resolve
during the call.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jan/0001.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Tantek Çelik
Dave Cramer
Elika Etemad
Simon Fraser
Chris Harrelson
Dael Jackson
Brian Kardell
Chris Lilley
Anton Prowse
Manuel Rego Casasnovas
Florian Rivoal
Devin Rousso
Jen Simmons
Alan Stearns
Lea Verou
Scribe: dael
Rossen: It is past the 2 minute mark. Let's get started
Rossen: First, happy new year. Wishing you a great 2020
Rossen: Looking forward to another great year of CSS success
Rossen: As usual, I'll start by asking for additional agenda items
or changes
fantasai: I think some discussion about talking with the Fonts
people at MPEG. Vlad asked us to draft a liaison statement
for next week. May want to discuss
Rossen: Okay. Anything else?
Upcoming F2F
============
Rossen: I have two quick announcements
Rossen: Upcoming F2F
Rossen: In a couple weeks, please start adding agenda items and tag
them as agenda F2F so we can have work to keep us occupied.
Rossen: Other topic is about our CSSWG Wiki
Rossen: I realized we accumulated a number of new members and we
organize and post meetings, attendance, travel, etc. on the
wiki
Rossen: Want to remind everyone this is a public wiki. We can write,
but everyone can read.
Rossen: If adding contact info, flight, hotels, and whatnot keep in
mind it's public. If you don't feel comfortable, just put
your name for attendance.
Rossen: Recently there were people tweeting about this and members
felt uncomfortable because they thought this was private. It
is public.
TabAtkins: SC29 solved this by having a private repo. For exact
meeting and travel details people post to the private
wiki. That's how they get around.
<chris> or we could use the member list
fantasai: If we put logistics in a separate page we can lock that
down
TabAtkins: Really? Let's do that
fantasai: It has per page or per section read/write permissions
bkardell: Do you have to be CSS or W3C member?
* bkardell thinks this makes sense - tc39 split... agenda and stuff
is public, private stuff is member private
fantasai: Wiki is a CSSWG account on plinss server. You have to
register separately. If you need permissions let one of us
know
<tantek> I'm ok with making meeting logistics info (flight dates /
housing) WG private
fantasai: There's groups, public, WG member, and people not in WG
but recognized so they have upgraded permissions
Rossen: But for private travel info this is helpful to us.
Rossen: I'm in favor of locking down travel details so we can share
among ourselves
<jensimmons> +1
Rossen: fantasai if you're familiar?
fantasai: Set it up, sure.
Rossen: Thank you and thanks to folks who brought this up
<tantek> can we agree on making travel details WG private? not just
w3c member private?
<tantek> I don't see a reason to show travel details to non-CSSWG
members
Open Type
=========
Rossen: Other extra item was from fantasai. Is Vlad on?
chris: I'm the SC29 rep so I can help drafting
Rossen: Okay. Do we want to have WG opinion on creating the liaison?
fantasai: Vlad asked us to review any or overview any issues we're
aware of that interact with opentype. I have a handful
which were mostly in what was sent. I wanted to ask WG if
there's any issues they're aware of to put in this
statement where we need opentype to work on or interact
with
florian: I think the list is good. I agree we should have one. If
that's the way it's supposed to be then that's how.
chris: florian I can fill you in on details of how it works after
call
Rossen: Anyone aware of open type issues could help putting details
into chris draft please contact him this week. We're looking
to wrap up this week
fantasai: They wanted it this week because they have F2F next week
CSS Color
=========
Should the color() function accept 'lab' as a color gamut keyword
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4649
smfr: I filed for completeness. It seemed like it should be an
option, no strong opinion
chris: Can, it's just that there's a shorter way to do same
* bkardell thinks it seems good for completeness
smfr: Can make same argument for sRGB
chris: Yes, but that's for legacy. Happy to add if it's helpful,
just an alias
<bkardell> +1 to alias
florian: Why not?
AmeliaBR: Only concern is if we don't define to include it there
might be compat issues later if we want to include it but
people have used it for their own custom colors
chris: That is true, yes
leaverou: Does that mean we add all the other color spaces as well?
AmeliaBR: Assume if we make a color function we'd want to be
consistent
<bkardell> it's good to be able to reason across the platform
consistently
smfr: HSL is in sRGB color space. This was more about being
inclusive of different color spaces. lab, lch, and gray all
use the color space.
chris: Yes, makes sense
leaverou: Fair enough
chris: Should we resolve then?
Rossen: Any other opinions?
Rossen: Objections to add lab keyword to color() function?
RESOLVED: Add lab keyword to color() function
Do gradients/animations using lab/lch colors interpolate in the
Lab colorspace?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4647
smfr: Thinking was if you specify lab colors you want uniform
lightness. If you specify gradient with same lightness you
would expect intermediate to have same lightness. There's an
image in the thread with lab interpolation that looks nice
smfr: Someone would be looking for lightness behavior so makes sense
to interpolate in lab space, but opens questions about if you
have different spaces.
chris: Should be option to say what color space. We should have good
defaults so it works how expected
leaverou: Bigger problem is most lab not in sRGB gamut so results
would be horrible. I think makes sense if two colors in
same space you interpolate in that space. Else we use lab
which is all visible color
florian: Agree with leaverou on the defaults.
<bkardell> agree with lea as well
leaverou: Also preserves web compat so sRGB is in sRGB
AmeliaBR: Nice to be able to upgrade so you can use colors you have
and say have transitions prettier
florian: Need syntax of that
chris: Working color space thing
leaverou: My heuristic only need one color to be lab to get lab
interpolation. Relativizing you wrap one in lab and get
all lab
myles: What's the relationship between this and SVG
`color-interpolation` property?
chris: In svg we have one for filters and one for everything else.
svg had linearized sRGB. In practice we want to regard those
as legacy. We can map to new, but not a great model going
forward
myles: Why is it not a good go forward?
chris: You might want multiple backgrounds each with a gradient and
in different spaces. One property means you control
everything but more likely to want per gradient or per
property
leaverou: Might have a gradient background you define and a
transition from a library you use and filter from
something else
chris: In other words want to avoid changing stuff people depend on
and have unrelated things change under them
AmeliaBR: My main concern is people change color interpolate
property for pretty color and then be surprised by other
aspects of color
AmeliaBR: Related is we have inconsistent implementation on which
browser effects which property every with limited switch
options it has
florian: leaverou's approach solves this. If you want interpolation
in right space wrap one color in lab
dbaron: Wanted to ask how clearly defined it is to interpolate
across any color space given proposal is if colors are in
same space you interpolate in that space
chris: Clearly defined but most rgb space is gamma corrected.
TabAtkins: Clearly defined means canonical representation as number
vector
AmeliaBR: Worth asking because >1 way to vectorize each color space.
If we're able to interpolate in hsl the numeric vectors
are different from RGB, even though both use sRGB space.
Similarly lab has lch which is same space different vector
AmeliaBR: Is need to interpolate in other numbers?
chris: That was a default. There's an opt in to other space
dbaron: Interpolate at least for transitions and animations for
gradients is derived from computed values. There is a
section that already computes away distinction in forms of
specifying. I think it needs to be clearly defined what
values you're working with. We allow @color profile rules. I
don't know a huge amount, but can you derive unique rules
from color profile?
chris: Yes, you can determine vectors and then profile interprets to
colors.
dbaron: Spec should spell it out
chris: There's a few things raised by smfr that are obvious to me
but not others so I plan an editing pass
TabAtkins: What things are we interpolating in. There's gradient,
compositing, transitions/animations. Gradients easy
implementation-wise. We already do it fake because ska
doesn't pre-multiply colors. I think transitions/
animations are driven manually so similarly fine to
switch.
TabAtkins: No idea about implementation difficulty to switch
compositing. Seems deeply tied to library
leaverou: Also filters
TabAtkins: Yes
AmeliaBR: Filters would be tied into deep graphics code
chris: Most likely. Compositing I think most 3D engines do linear
light compositing
smfr: Apple it's non-trivial to change compositing. I think we'll
get into that with working color spaces. I don't think need to
worry when doing intepolation for gradients
florian: My impression as well. Not sure where filters falls, though
myles: chris you said there's an escape hatch. If I have two
gradients I can use both?
chris: Working color space. Maybe want to use keywords too. Maybe
something like the / to separate alpha.
fantasai: Could do that "in <colorspace-keyword>"
AmeliaBR: Yeah. At front of gradient we define geometry and add an
optional one that says do it in lab or sRGB
<florian> +1
myles: Have manual control and if you don't include it the system
guesses sounds like a good solution.
Rossen: Where are we with getting to resolution
TabAtkins: Transitions and gradients in different color spaces we
use a default rule where if in same space do it there,
mixed is lab. Make sure it's explained properly. With
gradients have an explicit opt in to change the space.
Not touching compositing until we figure out working
color space. Need to think about filters
chris: Filters is in linear sRGB so we can leave as is
AmeliaBR: It's a mix. CSS filters are sRGB and manual SVG are linear
RGB but you can change it to sRGB. It's a mess, don't need
messier until we figure out working color space
chris: I think we have enough to close and move to needs edits
Rossen: With resolution?
chris: Title is does it happen in lab. Answer is yes. The specific
question is answered
Rossen: Don't need resolution
chris: Don't think so
Rossen: One ask; can you ask if you can use the illustration in
issue in the spec? It's great and would be super helpful
chris: Agree
<AmeliaBR> +1 to figures and examples!
chris: That use case is fairly pdf specific, but I have been meaning
to add some gradient examples
Should lab() colors which are outside the sRGB gamut be rendered on
capable displays?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4646
smfr: Apple display supports P3 which is wider. Makes sense to allow
an author to get brighter colors. An author working on a lower
gamut display may spec colors outside sRGB and they don't
know it.
leaverou: That can happen. There are monitors smaller than sRGB.
Current colors have this problem
chris: smfr I assumed question was rhetorical and you're saying
chris please document this
smfr: I wanted to it be clear we're not using lab as a way to spec
things immediately converted to sRGB
chris: Yes. Thank you
AmeliaBR: Suggestion is that the default behavior is use max gamut
available on device and if you want clamping you need to
use working color space
leaverou: Could wrap in rgb func
chris: Mainly needs to say use widest gamut possible and therefore
clamp as late as possible
dbaron: Should space say how to deal with displays with narrower
gamuts?
dbaron: Rendering intent in SVG
chris: Yes, exactly. I plan to use that because currently have
horrible per component clamping. As you say there's this
metric that's much more intended
myles: Is this tested?
chris: Reference modes, yeah
<TabAtkins> Hm, testing is interesting here. Does the output's gamut
affect computed values?
<TabAtkins> I don't think it does, so this would be purely visual.
florian: Follow up. When you say gamut is smaller I suspect displays
less then sRGB we pretend is sRGB?
chris: Yes. Highly sub sRGB probably don't have color profiles so
you get what you get.
Rossen: Anything else on this?
gray() function produces a warm, D50 white
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4622
chris: When I wrote the topic I thought it was worse than it is. The
thing you get is round off error which is as TabAtkins said
one part in a million. I should close. I think I was
unnecessarily worried
smfr: Agree. All references use D50 so not using would cause
confusion
chris: If it's ICC workflow it would cause confusion. ICC5 allows
more but not widely deployed
chris: I'll close no change
Better name for gray()?
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/4621
leaverou: gray 100% is white and gray 0% is black. Everyone agreed
different name
leaverou: It's been a long time. I asked on twitter and my blog back
then. I linked to the results.
leaverou: Seems most people don't find it intuitive.
leaverou: People voted for single argument RGB and gray isn't
defined in RGB terms
leaverou: Not sure how much we should take it into account.
leaverou: I still stand by gray isn't a good name. White or black
might be better. white 100% could make sense
leaverou: It's being implemented so change is now or never
<bkardell> should we try to do a post and evangelize with a good
explanation along with the poll, just to check?
AmeliaBR: Agree it's surprising at 100 but gray(70%) to talk about a
gray is something I've seen in design forums. If we are
switching I would argue L or lightness instead of white or
black because then we have same confusion that 0% white is
black
leaverou: L is good. lightness sounds like a filter, but not strong
opinion
AmeliaBR: I have same, lightness is close to brightness. L would be
happy for me
bkardell: Won't people ask what L means?
smfr: Can't google L
<tantek> what does the L in HSL stand for then?
florian: Not sure it's needed, but argument against gray is that in
photographic field people speak as 18% as a middle gray and
they mean 50% in lab. That's the standard gray in
photography
chris: They're talking about luminance
florian: Right so if gray 18% means something else it's not nice
fantasai: White and black are not much better than gray
<chris> monochrome?
Rossen: If we did white or black are we signing up for both?
myles: 0 means none of it. For black(0) would mean same as
black(100) and so that's why I'm for white
chris: What about monochrome? Makes hueless
leaverou: So long
florian: Any color is monochrome
TabAtkins: leaverou hit nail on head. Most suggestions will be
longer than lab(% 0 0) which is what gray does. gray
isn't much of a savings. I prefer stick with gray or drop
function
<chris> lab(foo% 0 0)
<tantek> this sounds like a bunch of new bikeshedding and multiple
options being considered that should first be added to the
list in the GitHub issue comment thread rather than a phone
call
AmeliaBR: Any syntactic problem with making 2nd and 3rd value of lab
optional?
TabAtkins: I don't think there's precedent for that
florian: I like it
chris: I think will be confusing
leaverou: Why privilege one coordinate?
AmeliaBR: Then I would argue drop gray. As florian pointed out
gray(50%) isn't want people think of as 50% in design due
to color space the shorthand isn't helpful
chris: Fine with that
myles: lab seems worse for people that don't know colors. What does
lab mean?
leaverou: rgb is no more intuitive it's just been used for years
AmeliaBR: But people are familiar with it I'd be happy to have a one
function rgb. But let's not have gray function that
doesn't do what people expect
Rossen: Are we saying gray won't work as intended and will be
unintuitive?
Rossen: If we discount that half the people voted for rgbx which
worked at the time everyone else voted gray
florian: We're defining it to work on l of lab and people mean 50%
gray in sRGB space. gray 15% in sRGB is what people would
see with 50% in lab
<bkardell> what about just mono?
fantasai: If using % in lab people will think of it as the gray
function no matter the name. Calling it lightness or gray
or whatever will not change the effect if they're thinking
in sRGB. Why not call it gray?
florian: Call it gray in do it in sRGB
fantasai: gray makes it obvious the midpoint. That's useful. People
that work with gray understand white and black and near
and far ends. Whatever we call it people will be
disappointed because not in the color space they want
myles: Maybe take an optional param
fantasai: Or we do single value lab and rgb functions. This is
syntactic sugar. Want to make most common thing work
chris: A gray thing with an optional param to say warmer or cooler
<AmeliaBR> I'd argue for both `rgb(18%)` expanding to
`rgb(18% 18% 18%)` and for `lab(50%)` expanding to
`lab(50% 0 0)`. Don't use `gray()` because it's not clear
which one it would be.
Rossen: Since people are starting to impl let's get to a resolution
or live with gray. Strong candidate names over gray?
bkardell: monochrome was too long, would mono work?
TabAtkins: Don't generally go for shortening words as makes it hard
to understand
chris: 3 options. Drop function. Keep as gray. Rename it now. smfr
is implementing so can't mess around with name
florian: Which gray is it?
chris: L as currently spec
Rossen: Can we live with dropping?
Rossen: I will take silence as a yes
bkardell: It's less important than lab.
chris: You're not losing anything
Rossen: Objections to drop gray() function?
RESOLVED: Drop gray() function
<bkardell> we can always bring it back up
Rossen: We can go back to these arguments if we re-introduce
fantasai: Should we take up single value lab or rgb as equating to
gray?
<chris> noooooo
TabAtkins: I don't think it's worthwhile enough to take up.
CSS Pseudo L4
=============
Layering of highlight pseudo backgrounds
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4626
fantasai: Confirming we want them to stack and layer. If yes we'll
close no change
AmeliaBR: Makes sense for a selection on top of a spelling error
AmeliaBR: Looks as a highlight on top of what you've got
fantasai: It's on top of what you've got in element tree. It's
multiple highlights
AmeliaBR: If you do red for spelling and transparent yellow for
selection makes sense to stack
dbaron: Fine as long as spec which is on top
fantasai: Yep.
bkardell: Is that a question we can ask devs what they expect?
fantasai: Seems everyone agrees we should layer. If there's an
argument to not we can discuss
smfr: Apple requires layer
fantasai: Objections?
Rossen: Objections to close no change?
RESOLVED: Close no change
::selection vs ::inactive-selection
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4579
fantasai: Relationship between them. It's implemented that
::selection applies to active selection. If your window is
inactive you still have color. Two ways for them to
interact. One is inactive selection is another highlight
and layers on top. Alternative is the cascade together and
one only applies sometimes.
fantasai: Given previous resolution if you're using semi-transparent
for selection and inactive selection and inactive goes on
top of active so we have to cascade
fantasai: Want to know if there's other thoughts
fantasai: If we cascade might want to switch syntax so ::selection
has a function name
AmeliaBR: Is there a compat need to make selection and inactive
selection to be cumulative and not exclusive? Default
behavior is there's different styles
dbaron: Possible to get inactive behavior with selection combined
with other selectors?
fantasai: Based on inactivity of window. Don't have a way to select
dbaron: Make one?
fantasai: Maybe with a MQ?
myles: That's significantly more powerful then what we agreed. Is
there a reason to make more powerful? That's exposing more
info to websites
dbaron: One level think it's more powerful. Another thing it might
be easier to impl because don't have to impl cascading
pseudo elements
fantasai: I think there's a number of websites that would want to
know if cage is active. Is it exposed and do we want to?
florian: Sniff from selection?
fantasai: No
Rossen: Out of time.
Rossen: I propose we leave this open until next time and resolve then
<AmeliaBR> Firefox has a inactive-window pseudoclass:
https://developer.mozilla.org/en-US/docs/WebecauseSS/:-moz-window-inactive
fantasai: Okay
Rossen: Thanks everyone
CSS Color
=========
RESOLVED: Update WD of css-color-4 (approved by Rossen after the
call)
Received on Thursday, 9 January 2020 00:38:36 UTC