- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Feb 2020 21:38:02 +0200
- 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 Pseudo 4
------------
- There is an announced intent to ship the WICG Custom Stats Pseudo
Class spec ( https://github.com/w3c/csswg-drafts/issues/4805 |
https://wicg.github.io/custom-state-pseudo-class/ ). The TAG
recently gave their review and the working group discussed the
proposal and the feedback on the call.
- Though this proposal only exposes a boolean value the pseudo class
was designed to allow extension to multiple values in the
future. There was concern that the JS API did not appear to have
the same extensible design.
- Several people were interested in exploring changing the name from
:state to :--name though if the name changes :path should also
change.
CSS Color Adjust
----------------
- RESOLVED: If the color scheme of an iframe differs from embedding
document iframe gets an opaque canvas bg appropriate to
its color scheme (Issue #4772: `color-scheme` should
affect embedded iframes)
CSS Images
----------
- RESOLVED: Add this [text to allow dithering] to Images 3 and 4
(Issue #4793: Allow dithering as a gradient-painting
strategy)
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Feb/0021.html
Present:
Rachel Andrew
TabAtkins
Rossen Atanassov
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Javier Fernandez
Simon Fraser
Chris Harrelson
Daniel Holbert
Dael Jackson
Dean Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Stanton Marcum
Anders Hartvoll Ruud
Christopher Schmitt
Jen Simmons
Alan Stearns
Lea Verou
Regrets:
Florian Rivoal
Scribe: dael
Rossen: We are 2 minutes past the hour
Rossen: Let's get started
Rossen: As usual I wanted to ask if there are any additions to the
agenda you want or changes to it?
Rossen: I have a couple of things to start with
Rossen: Potentially push the 2nd item toward end of the call
Rossen: Other things I wanted to talk about where we have upcoming
F2F which is going to be in Cork Ireland at end of April
Rossen: Given this is usually the time people start booking travel
the one thing I wanted to bring to attention is all the
COVID-19 virus happenings
Rossen: I don't know if this will be effected but use your best
judgment when booking. We're nearing time when affordable
travel window is closing
Rossen: Anything else about the F2F from organizer PoV?
Rossen: Assuming we're good. I know hober isn't on.
smfr: As far as I know everything is fine
Rossen: Yep, nothing to be concerned about yet but hard to predict
jensimmons: Glad you brought this up Rossen. It seems likely to
sweep through Europe. I've heard people recommend travel
insurance.
jensimmons: Something for group to think about at what point do we
call this. What would it look like.
TabAtkins: Similar to when there was the reactor meltdown in Japan
and we almost didn't make quorum but had enough to hold
it. We'll look for people to drop out and monitor for if
we make quorum
Rossen: Yep, I think we'll monitor. I don't want people to freak out
for no reason, but things are escalating
CSS Pseudo 4
============
Custom state pseudo class proposal
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4805
Rossen: This is about a custom state pseudo classes. Being worked on
in WICG.
Rossen: Ready to be shipped by chrome in I believe 82 which is 4 or
6 weeks from now-ish. I don't know exact dates for when it's
on by default but feature will be spread and enabled for
large amount of users
Rossen: Some of TAG feedback was around shape of API and it only
allows bool state checks
Rossen: This was acknowledged by feature authors but dismissed as
can live with for now
Rossen: Talking about with WG is I looked through past feature
discussion and didn't see this covered. Before it's too late
wanted to give air time with group and gather if any
reservations or concerns
bkardell: I wanted to mention that a whole bunch of people from WG
have been involved in design and discussion. This is like
constructible stylesheets where that's the case and it's
hard to know right venue for discussion. Given there's
history and thought would it make sense to present a bit
about it?
Rossen: Sounds great. If you want to take a couple minutes and frame
the feature and intent it would be great. Are you the right
person or should we ask somebody else?
bkardell: I suppose I could, but TabAtkins is on and can do a good
job
TabAtkins: Been a bit since I looked at it. Core deal is custom
elements sprout a new DOM token map that takes strings.
Can match with :state you say :state(token) and it can
match
TabAtkins: Reason is you want to expose internal selectors can match
without manipulating visible dom. Shadow dom is a lot
about exposing attributes without impacting outside.
Design is canted toward that direction where it's bool
token or not. Future room for name and value but right
now it focuses on class
bkardell: Not unlike :focus, :hover internal states
TabAtkins: That's what it's meant to be able to expose. Internal
states like that. It could be done via a class but b/c
it's UA it's pseudo classes
Rossen: Questions here. Is the current proposal in it's form going
to preclude addition of anything other than bool?
TabAtkins: No. Syntax is easily extensible to allow it when we want
to do it.
Rossen: And this was major concern raised and attempted to be
debunked in issue I linked to. It was that there are no
interesting bool states and no need to feature creep.
Checkbox has 3 states and things like that. As long as
non-bool aren't precluded in the future this is not too bad
TabAtkins: Correct. Nothing would prevent that in the future
<bradk> So, not really for things similar to ‘nth-child()’ ?
emilio: This is for top level custom element, right? Find it weird
it works for custom and not regular elements. Exposing
states from parts they must be custom or different like
tokens. It's a bit ugly
emilio: Let's say you want to expose a state in a component. It
would only work if the part is a custom element. If you
don't want custom for example if it's SVG you need part
elements instead using :state which is meh. Why doesn't it
work for all elements?
TabAtkins: Main reason is...easier to put this structure on the root
instead of arbitrary elements. You articulate a good use
case for parts of shadow element exposing states.
Ordinary element can just use class and multi ways for
same thing is weird. Leads to there is a way to do bool
state in parts which is add more part names. Parts are
basically classes and states are basically classes
emilio: Could use same argument to say top level element can use
class
TabAtkins: But then if you use class component messes with outer
page visible section which we try and avoid, especially
with things like aria stuff we're trying to mess with.
Exposing controls without visible extra attributes is the
goal of shadow dom. That's what's different for class.
Doesn't apply to state vs part
emilio: Okay, I can buy that. A bit weird to have 3 ways to attach
bool token to element
bkardell: If you read the issue there is a desire to have parity
where we could do the same thing on focus and hover type
elements. They work today and it would be handy to have a
custom element where you can have state. I agree this
isn't solving all problems like this but I think the idea
here is limit the scope
plinss: Two concerns
plinss: I accept that majority of use cases are bool. There are
examples of non-bool state. Happy it's extensible in css but
JS api is not in a way that's dev friendly. There's already
things that are map-like but we don't use map api. I'd like
work done on api to make it more future proof. I'd like it
to be able to handle non-bool cleanly
* emilio agrees with plinss
plinss: Second is should it be :state or :--[name] and really make
it a custom pseudo class and not an odd pseudo class called
state
TabAtkins: Not a bad suggestion. Alright.
plinss: If we change this to :--[name] I'd like to see part do the
same for consistency. For syntax they should be a unit. I
have other issues with :part but that's separate convo
<bkardell> I have brought this up in the past, I think :--name is
more interesting, but I think the argument is made this
is diff and specifically about a kind of parity
fremy: I think plinss brought a good point. Thinking similar. I
understand TabAtkins' argument about need for aria mapping
not changing with setting attribute. But we could do same as
:part Maybe we want JS API to be able to remove values not in
attribute
fremy: I don't understand why we need :state and :part. Why can't we
have same API that applies on the same thing as :part. Maybe
it's a point to think about
plinss: That ties into my issues about part. I think it's valid to
have custom state and custom part. How part is now is like a
pseudo class and I'd like to be a pseudo element thing. Then
it makes sense to have them as 2 things
<bkardell> can I ask how is it the same as parts, it seems not the
same to me... ?
<bkardell> +1 what peter said
<bkardell> and to what emilio said :)
fremy: Can query multiple part things, but I was going to mention
that [missed]
fremy: It does make sense, fine.
TabAtkins: Switching to :-- we're switching to tag name not class
name. Requires if people to decide if it's class name or
part name like. Maybe shouldn't expose to authors.
TabAtkins: Can we put this in GH repo? This is good.
plinss: I raised this in TAG review and didn't get a fair shake I
felt. It would be good if it's addressed. You and I can
haggle on :part separately. This is about :state for now
Rossen: Given we're 30 min into call I think reasoning and
motivation to put this in group is achieved. Raising
awareness and getting right people while we can provide
feedback and engage with folks getting ready to ship.
Rossen: I see two people on queue. I'd prefer to move on unless
emilio or bkardell want to bring something pressing
bkardell: One thing before it's lost. Of course I 100% agree with
plinss with wanting to see :-- for custom pseudoclass and
pseudostate.
bkardell: Question worth getting plinss and group thought is if
that's the same as this or if this is discrete and about
custom elements. It's been portrayed to me that they are
different. Encapsulating state is a different things then
a general purpose pseudo class
bkardell: Interesting to think about
Rossen: Let's continue in linked gh and WICG.
Rossen: We'll also take this is TAG
<fantasai> Fwiw wrt :--statename vs :state(statename), I think
latter is better, clearer, more consistent with
::highlight(), easier to extend
Media Queries 5
===============
Rossen: Skipping 2nd topic because florian is not on, but I
encourage you to review
( https://github.com/w3c/csswg-drafts/issues/2370 ).
Rossen: This is about having the first working draft published and a
new issue being added to MQ 5 post that decision. Question
is would it be fine to fold the new issue intp fpwd or roll
prefers-reduced-data back out and publish fpwd
chris: We're unable to publish fpwd where there's a delta spec
currently. Letting people know that even though it was a few
weeks ago with resolutions those are still on the queue
CSS Color Adjust
================
`color-scheme` should affect embedded iframes
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4772
Rossen: This was added by Chrome folks
chrishtr: Problem with dark backplate behind iframe is it's not dev
controllable. Proposal is there be a white or black
backplate of an iframe if the owner element has a
different color-scheme
chrishtr: A frame with an iframe have both dark you get that. One
light and one dark backplate you get this.
chrishtr: backplate is the canvas behind the root element
<fremy> +1 to chrishtr's proposal
<dbaron> Is this specifically black/white background, or is it dark/
light background? (i.e., are we requiring exactly black/
white?)
<dbaron> (seems like it should match what's required for the root
document)
AmeliaBR: Document canvas. We have legacy issue that iframes don't
have document canvas but we also have expectation that if
child document says it supports darkmode it assumes part
of that package is browser painting dark canvas. One
document embedded in the other and one does darkmode
switch things can get unreadable. Proposal is iframe
canvas is by default transparent unless mismatch between
embedding element and root element. With mismatch you draw
opaque canvas on
emilio: With used color scheme of iframe?
AmeliaBR: Yes. canvas system color of root element of iframe
emilio: Makes sense
AmeliaBR: Might not always be great for svg. Might need an issue
that this may only apply to iframes or something. Not sure
which is worse, color mismatch or chance at a transparent
background. Specifically for webpage and iframe this
should handle most cases. Open issue on svg
Rossen: Detectable from within frame?
AmeliaBR: Shouldn't be. No way within doc to tell what the canvas
color is because it's before root background so not
accessible to cssom
emilio: Work for cross origin iframes?
Rossen: That's why I asked. If there's additional information
provided through mechanism to cross origin that's not today
AmeliaBR: Shouldn't be a way from embedded to tell if opaque drawn
or not. Might be a user tricking way for parent doc to
figure out if content is transparent based on if user can
read content. I don't think there's a direct dom way outer
document could tell
TabAtkins: Other than tricking user the information isn't exposed to
embedding or embedder
emilio: Timing attacks from masking iframes and I'm assuming drawing
opaque background is cheaper you could get creative
chrishtr: Isn't that potential risk anyway?
emilio: Would allow you to detect if there's a difference assuming
you can detect painting of background
AmeliaBR: Maybe add a warning to avoid the timing attacks by taking
care when optimizing rendering into opaque iframes
Rossen: Besides the note sounds like consensus around how it should
work. Any additional comments or objects to making the
canvas of embedded documents match canvas of embedding
document by either matching internal color scheme or
applying opaque canvas in a case of mismatch
emilio: Assuming designing a doc designed to be embeddable can you
design to match? I guess not and this does not solve. Mostly
curious
AmeliaBR: That was my other proposal. The support color scheme
option on child doc interpolation based on parent and that
was possible cors issue because then child doc would be
able to tell...
emilio: Yeah
emilio: Okay. No concern.
Rossen: I didn't hear objections
TabAtkins: If the color scheme of an iframe differs from embedding
document iframe gets an opaque canvas bg appropriate to
its color scheme
dino: If owning doesn't provide color?
AmeliaBR: Legacy color scheme is still considered
RESOLVED: If the color scheme of an iframe differs from embedding
document iframe gets an opaque canvas bg appropriate to
its color scheme
CSS Images
==========
Allow dithering as a gradient-painting strategy
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4793
TabAtkins: webkit uses dithering to make gradients better. This is
great. Spec does not allow and dictates every pixel.
Technically webkit violates but I think spec should allow
in both css and canvas
<smfr> (and svg gradients)
<dino> Related PR on WPT -
https://github.com/web-platform-tests/wpt/pull/21647
TabAtkins: If no one objects I'd like to add a few paragraphs to
images to allow dithering. Not sure if you want to say
yeah you can dither or if we want to put some
restrictions where you should be close like we do for box
shadow.
<dbaron> A downside of this means it becomes even more difficult to
reftest gradients...
bradk: If it displays and you only have 256 colors no dithering?
TabAtkins: CSS doesn't recognize less the 24 bit color. Otherwise no
it does define what the display color should be
dino: CSS spec defines theoretical color. If you display on black
and white monitor that's not css problem
dino: I referenced PR where I changed test to allow dither. It's 2
out of 256 slots can be different in any channel. In practice
our dithering is in that range an not all bands.
dino: Reason we do this is because it does make gradients look
better.
Rossen: Let's see if we can move to resolve
Rossen: Sorry chris I didn't see the queue
<bradk> Sorry
chris: I agree we should allow this. Surprised reading of spec means
it's disallowed. This is wide practice where you need to do
things like dither. For testing we need to sample on small
area so it averages and you get mean result. I'd be
astonished if we disallow
leaverou: Shouldn't disallow better visual result for testing
<fantasai> +1 to leaverou
TabAtkins: No one is arguing don't allow dither. I defined what the
color of a gradient should be and didn't think about
dithering it around.
<smfr> you can still do reference testing with some SVG filter stuff
to batch the pixel values
chris: Disagreement I have is 5%, what does that mean. 2 counts in
rgb is noticeable in some places. I was suggesting delta-e,
maybe that's hard to do. 5% is meaningless.
TabAtkins: I don't care that much, you won't dither badly. It's what
boundaries can we put on tests to pass a good
implementation and not pass a bad one. We did 5% on
shadows because that lets you say here's the ideal and
get close to it. I was going for same deal where it
detects when you've gone widely off
AmeliaBR: Do we have useful reftests for shadow blurring or is that
arbitrary rule in spec?
TabAtkins: Don't know
dbaron: At least one test which I wrote
<fantasai> Here is dbaron's test
http://test.csswg.org/suites/css-backgrounds-3_dev/nightly-unstable/html4/box-shadow-blur-definition-001.htm
chris: In general hardly have tests for gradients b/c hard to figure
out how to do automatic reftest
smfr: You use svg image and then mask out areas that should be
solid. We have tests in wk
<chris> can you sent those wk tests to wpt?
<bradk> Are monitors with larger than normal color gambits not
allowed to display more colors in the gradients?
dbaron: Is there a spacial requirements for the dithering? Is it
color distance, spacial distance or both?
TabAtkins: I had example text and my intention was color distance of
ideal color
dbaron: wk test depends on spacial distance
TabAtkins: Can you describe that?
dbaron: That's what I heard from smfr but maybe he can explain. I
thought her said it was for solid segments and masking
pieces of boundary
smfr: With continuous gradients you can do component transfer on top
to posterize the gradient, convert a range to a flat color.
Hides some issues but lets you test interp color stops
TabAtkins: Artificial banding to get close to idea
smfr: Correct
<dino> If you pick the components correctly, you can emphasize the
banding in the gradient, and then mask out the relevant
portions.
<dbaron> smfr also said before the minuted part that they or (or you
can) do that for solid parts
chris: Two types of dithering. One is higher precision. Calc color
and dither to get mix.
chris: More common is dither position on gradient so if you have
linear instead of a vertical line you fuzz that. I think FF
is doing that. We need to allow both
chris: smfr or dino can you confirm?
chris: [repeats] I'm assuming you're doing the latter, dither on
gradient axis.
smfr: I don't think it's directional, jut adding noise
dino: When I suggested a test that you show I'm testing, not what we
do. It's a noise filter on result
chris: I see
smfr: It's not wk it's the underlying graphics that's using gpu
shaders and stuff
<smfr> example of a test using feCompontentTransfer:
https://codepen.io/smfr/pen/OJVpwoR
chris: Seem to have consensus spec shoudl say this, question of how
AmeliaBR: Can we resolve on general spec and then get people to give
specific examples of how to test?
Rossen: Yep.
Rossen: Obj to Add this to Images ?
TabAtkins: I'll put it in 3 and 4
Rossen: Objection to add this to Images 3 and 4
RESOLVED: Add this to Images 3 and 4
Rossen: Anyone with tests they can contribute to wpt please convert
them so they can be used as ref tests
Rossen: There's a few items we'll push to next week as well as MQ
Rossen: Next call is APAC time
Received on Wednesday, 26 February 2020 19:38:45 UTC