- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Nov 2020 19:30: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.
=========================================
CSS Color 4 and CSS Color Adjust 1
----------------------------------
- There were concerns about trying to remove the actual value of
colors from the getComputedStyle return (Issue #5710: Shielding
system colors to avoid fingerprinting) so much of the group was
leaning toward no change and documenting the fingerprinting
risk. However, the group is going to wait a week before
resolving to allow for checking with privacy teams.
CSS Fonts 4
-----------
- RESOLVED: Republish a new WD [of Fonts 4]
CSS Color 5
-----------
- The group discussed the proposal to add currentBackgroundColor to
Color 5 (Issue #5292: Add `currentBackgroundColor` Variable).
The use case is to make it easier to have style elements like
borders be defined based on their background color. During the
conversation there was a fair amount of implementation
complexity uncovered since there is often transparent background
values. Discussion will return to github to determine if the
benefit outweighs the implementation complexity as well as dive
further into the detailed requirements.
CSSOM View
----------
- RESOLVED: For quirks mode only, the scrolling element should
follow same propagation as the overflow:clip (Issue
#5601: Document.scrollingElement doesn't reflect
viewport propagation correctly in presence of overflow:
clip)
- RESOLVED: No change (Issue #5260: No way to access the viewport
size without losing precision)
- emilio will experiment with allowing the viewport size to return
doubles to see if it really causes the compat issues which lead
to the above resolution. If there aren't compat issues he'll
re-open the issue. If there are compat issues he'll create a new
issue to develop a separate API to return the doubles.
CSSOM
-----
- In order to define how rounding should function in CSS (Issue
#5689: Is `round` special in CSSOM?) requires a conversation
around which is the best language to match. Discussion will
continue on GitHub until there's a more definite proposal.
- RESOLVED: Have different interfaces for declarations blocks that
expose a different set of descriptors/properties (Issue
#5649: The way CSSStyleDeclaration exposes properties is
not ideal)
CSS Values
----------
- RESOLVED: Publish a new WD for Values 4
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Nov/0009.html
Present:
Rachel Andrew
Adam Argyle
Joseph Arhar
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Christian Biesinger
Mike Bremford
Oriol Brufau
Emilio Cobos Álvarez
Brandon Ferrua
Simon Fraser
Chris Harrelson
Dael Jackson
Brian Kardell
Jonathan Kew
Una Kravets
Vladimir Levin
Daniel Libby
Chris Lilley
Peter Linss
Alison Maher
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Lea Verou
Greg Whitworth
Regrets:
Megan Gardner
Daniel Holbert
Scribe: dael
Rossen: I think we have quorum at this point and we've given a
couple minutes. Let's get started
Rossen: As usual wanted to call for additional items or agenda
changes necessary
fantasai: One thing
<fantasai> https://github.com/w3c/csswg-drafts/issues/5630
fantasai: I still need a response from WK on ^
Rossen: Is that something that needs group time?
fantasai: Waiting for webkit. Someone needs to answer
smfr: I'll ping myles and see if he can get to it
astearns: I have one
astearns: Last week I started calling out people with old drafts on
TR with the 6 year old CSS Scoping. Another 6 year old /tr
is CSS Shapes. Rossen and I are editors so I'm calling
myself out to get Shapes updated
Rossen: Thank you for calling us out now. We have a race with
TabAtkins to see who updates their 6 year old draft first
Rossen: Anything else?
CSS Color 4 and CSS Color Adjust 1
==================================
Shielding system colors to avoid fingerprinting
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5710
fantasai: We were going over the privacy considerations for color
adjust
fantasai: main issue was way system colors were exposed through
systemColor keywords or when we force because
getComputedStyle returns used value rather than computed
fantasai: Three options. 1) can't fix. 2) computed value gets
returned not the used. Not sure webcompat implications.
3) return a value to getComputedStyle which is not
necessarily the value actually used
fantasai: Could return the same standard values. For forced colors
return the color that would have been the color before we
forced
fantasai: Question is do we want to do something like that? Upside
is reduce fingerprinting. Down side is if author wants to
do something based on system colors they can't do
calculation based on that
chris: I fairly recently added something for deprecated system
colors which was mandatory mapping to non-deprecated. I'm not
sure if that helps but it would mean used color would be same
as a non-deprecated colors
fantasai: This is about non-deprecated. That reduces number of
keywords but problem still exists
<leaverou> if you're interested in web compat, system colors are
only used in 0.2% of pages (any system color)
Rossen: With options 2 & 3 I'm curious if system colors will be that
useful at that point. Lot of guidance on how to use system
colors, especially in settings of forced colors where people
encouraged to use system colors elsewhere if they take
colors in their own hands
Rossen: With that in mind I'm not sure how attainable 2 and 3 will
be from author capability
fantasai: Can still use system color, just can't use a variation on
the system color. You can't compute a value based on
actual value
Rossen: That was my point
chris: I think that's reasonable. I don't see call to modify system
colors. Point is they're semi-standard. If you change no
benefit over spec directly
leaverou: I checked web compat and system colors are only in 0.2% of
pages in http archive
Rossen: That's quite a bit
<leaverou> There is also data per color here:
https://docs.google.com/spreadsheets/d/1sMWXWjMujqfAREYxNbG_t1fOJKYCA6ASLwtz4pBQVTw/edit#gid=279222916
emilio: I was going to point out opposite. Probably we cannot
change. We need to return an actual color. Even though not
used explicitly they're used by default in UA. Pretty sure
people look at getComputedStyle on a select and expect a
color back
Rossen: Related, if we restrict system colors to keywords only would
using them as part of a color function still function?
TabAtkins: Yeah. Exposing actual color to scripts is the thing.
Using them is fine
smfr: If you have special behavior for system colors you have to
track through color modifications like lighter and darker.
You'd have to mask it all the way through
TabAtkins: Yep. Similar to :visited which is tricky
<chris> system colors only used for links now,
https://drafts.csswg.org/css-color-4/#sample
chris: We changed user stylesheet for light/dark. Only three uses
remain ^
iank: I wanted to say I'm a little concerned about compat situation
of changing getComputedStyle. As a webdev I did see code which
would explicitly read out the color from getComputedStyle to
determine if a11y mode is on. Some investigation would have to
check if major web properties broke under a11y modes with this
change
TabAtkins: Ultimately if we say no it's okay. It just needs to be
documented as a fingerprinting risk. If we're okay with
it we can leave as is. It's the only fingerprinting
surface in the spec
iank: Not saying no, saying compat risk
florian: Given these are maintained they could switch. If they are
not there's a risk indeed
Rossen: Sounds like there's go with option 1 which is say no and
document the fingerprinting or take another option based on
additional research and experimentation
Rossen: As a group are we comfortable with option 1? Objections to
say no change on this and we'll document the fingerprinting
exposure?
smfr: I need to talk to privacy people before I agree
Rossen: In that case we'll leave it open as is. In both cases we
need more data before we resolve
Rossen: smfr can you follow up and we bring it back next week?
smfr: Sure.
Rossen: Let's do that. We'll give the Apple folks a week and
depending on how things go we may pick option 1
Wide Review of CSS Fonts 4
==========================
github: https://github.com/w3c/csswg-drafts/issues/4944
Rossen: Do we want a new CR?
fantasai: It's a WD
chris: Yes we do
fantasai: Chris wanted the next as CR but it's not there
RESOLVED: Republish a new WD
CSS Color 5
===========
Add `currentBackgroundColor` Variable
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5292
una: The idea behind currentBackground came from work in color 5
with color mix. Use case I see commonly is unity within an
element where you want a border or a shadow to be related to
the primary color of an element which is usually the background
una: Right now need a separate variable. currentBackground would be
useful here to use the background color.
una: A bit of discussion on issue. Way I see it is because
transparent is default value you look for closest parent with a
color and use that
una: leaverou had a great comment about a current function to take
any inherited keyword. That would work for things like font
weight for text decor.
una: Would love questions, comments, thoughts
leaverou: The clarify my proposal is not for current function to
take any property as an argument. I said this is useful
but since in future we want similar perhaps syntax should
allow for us to add more keywords in future
leaverou: I suggested starting with color and background color. It's
no more complex then keywords but it's more extensible for
the future. If it's a function that's like any property or
longhand that's harder to impl. I wouldn't want to stall
this very useful feature by making it complex
una: Agree. Starting with subset of arguments for current is a great
route
TabAtkins: I have a slight objection to trying to generalize to a
current function because behaviors won't be same.
Discussion in thread about if currentBackgroundColor
would compute to self or would compute at computed value
time and inherit as that color.
TabAtkins: Suspect for background color because transparent we
wouldn't want the behavior of currentColor. Tying
together in one syntax implies similar behavior. Since
our two examples are divergent I'm not convinced we'd
have coherence in our 3rd or 4th
leaverou: Keyword that looks like currentColor also suggests they
might be the same?
TabAtkins: Yes, but we can't avoid that much similarity. A brand new
current has a more implicit guarantee of similar I think
emilio: I want to say on the call xidorn's concerns about
implementation complexity vs benefit. Hesitant about mode
dependencies because get complex. Not sure the use case
warrants another one
una: I think it's a common pattern to have a base color for a
component, cards, sidebar, whatever where you have a color
theme and additional color values for items in that component
based on the theme. I've mostly seen that primary color be the
background. That's the inspiration on existing common UI
patterns
Rossen: Going back to meta point of do we want to pursue...handling
semantics later...is this something we want to pursue as
part of color 5?
Rossen: Use cases and usefulness. Do we have enough merit we can say
it sounds like good to put in?
<leaverou> +1 would want to pursue
<brandon> +1 this would be very useful
fantasai: Question is if the use case is strong enough it outweighs
dealing with implementation complexity. You have to look
through transparent things. If you have an image as the
background the base color is not necessarily the color
because might have semi-transparent on top so it might not
rep the color you want. Also issues with how and when this
computes
fantasai: On the other hand, we have the use case. I believe una it
exists. You can work around with a variable but it's more
work for author to establish a convention and stick to it.
I haven't read deeply into impl complexity. I think that's
what it boils down to. Does it balance out.
chris: My point was about you can...first if you look at examples in
color 5 for contrast they implicitly use background as the
first color for contrast. Simplifies things. On the other
hand you've got partial transparency and you could have an
image color background color isn't used.
chris: At the moment we're sticking a color in there and it's author
convention that it's the background. An improvement is good
even if not bullet proof
leaverou: I wanted to say fantasai raises valid concerns. Would it
be possible to have a syntax for composited background
color. Start from current and go up until you meet opaque
and composite. Use cases from una in need of that, as is
the contrast case
fantasai: What about an image? Have to narrow to a point
leaverou: Images makes it more complex and we don't want to deal.
But there's an algorithm for a single color which you can
plug into color functions.
<gregwhitworth> do we mean true composition because that comes far
after style
<gregwhitworth> so that would need a round trip to compute
<chris> maybe we need a NaC (Not a Color) value
smfr: Running algorithm which leaverou described is expensive. You'd
have to re-evaluate every frame with animations. I don't think
practical.
<gregwhitworth> +1 to smfr
<gregwhitworth> we investigated this for a dynamic accessible focus
rect and decided to not pursue it although I think
that still has a higher likely hood of
implementation given it only applies to focusable
elements
Rossen: Given conversation this generated and the thread on GH we
can go back to GH and continue there and don't resolve
pursue or not now. I see decent support in IRC and decent
amount of concern.
Rossen: I recommend we continue on GH and bring back in a week or two
una: sgtm. Answering about compositing I do think it'll be heavy to
calculate that because happens after paint. We could still do
it with alpha included and we don't use that value and apply
style declarations using that. Lots of places where want alpha
and it multiplies on background color alpha. I don't think it's
as complex as figuring out composited color. That would be
great, but I understand complexity
Rossen: Thanks
Rossen: Sounds like we should go back to GitHub. Okay?
una: Yep
CSSOM View
==========
Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/5677
Rossen: Is zcorpan on or can someone take this?
Rossen: It's a PR we want to approve
Rossen: Added to the agenda a couple weeks ago
Rossen: What did we end up doing last week with the previous PR?
TabAtkins: Should move on unless anyone has reviewed
Rossen: If this was an exercise to get review to the PR so be it
Rossen: Consider yourself asked to review
Document.scrollingElement doesn't reflect viewport propagation
correctly in presence of overflow: clip
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5601
emilio: The overflow propagation section in css overflow and
document.scollingElement disagree. document.scrollingElement
returns the body if overflow was propagated from it. That's
not what it does if account for overflow:clip
emilio: Fix is simple but may be we want to change overflow
propagation behavior
chrishtr: Are you saying in the issue example scrolling elements
should be html not body?
emilio: Yes because overflow is hidden effectively. Not visible. It
propagates as hidden to the viewport
chrishtr: Yep.
Rossen: Your proposal is to go with fix the bug or change overflow
propagation behavior?
<fantasai> wfm
emilio: Change scrolling element to match overflow propagation
emilio: As far as I can tell that's what Gecko does
smfr: Change scrolling element for overflow:clip so it matches
overflow:hidden on root
emilio: Right
emilio: That's what css overflow requires
emilio: Overflow:clip behaves same as hidden in the test case
smfr: What is scrolling element not in quirks?
emilio: document.element
smfr: sounds good
chrishtr: agreed
Rossen: Proposal: For quirks mode only the scrolling element should
follow same propagation as the overflow:clip
RESOLVED: For quirks mode only, the scrolling element should follow
same propagation as the overflow:clip
No way to access the viewport size without losing precision
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5260
emilio: window.innerheight and width are lengths. Bad because you
want viewport width, especially for fractional widths. No
work arounds.
emilio: I know there's history here and that some of OM prep
remained as long intentionally but I don't think this was
one.
emilio: I think we should be able to change
smfr: Sounds fraught with compat risk. Will people parse int on
inner height?
emilio: This came from slight change to Firefox UI that added a half
pixel to UI which reduced viewport. A bunch of sites broke.
I think this fixes more, esp for uses that use zoom-like
things to change viewport size.
emilio: You can always parse it. Right now people set .width to
value of innerWidth and that leaves seams when on fractional
dpi context
emilio: Agree there is risk
emilio: If people think this is not a bad idea I can try to change
gecko and see if other engines will follow. If you're
convinced it can't happen no point to try
smfr: Not convinced but when we tried with other metrics it was a
problem. Other option is new APIs that return doubles. Happy
for you to try and if it works I can try on WK. Needs extended
in the wild tests
Rossen: We tried something similar in IE9 days. We exposed a bunch
of OM and I believe this is one we changed because a lot of
problems. I remember fighting with cnn.com which was
fighting to try and readjust and avoid scrollbars.
Rossen: At that time we could confuse such a large property so I'm
not sure what would be there for small end of the web. I
would not underestimate compat risk
emilio: But inner width and height don't depend on scrollbars. Not
sure it can be the case. But sure.
Rossen: That's the feedback for now. If we proceed another point in
issue from florian where we took a no change for media width
and height. The issue is linked
Rossen: We can follow that
emilio: That was very much the opposite
emilio: As far as I can tell the proposal in the other was rounding
for MQ, right?
florian: As far as I can tell what this means in MQ stays what they
are because make sense that way on OM stays because compat.
End result is inconsistent. If we want consistent we have
to break one
Rossen: Do we favor the risk or the similar. It was the argument of
sticking with compat
emilio: Fair. I think I'm still going to give it a shot. Nightly or
beta to see if there's wreckage. If there is I'll propose a
new API. If that sounds good I don't need resolution
Rossen: Resolve no change, emilio experiments?
emilio: Agree no change for now. Spec shouldn't change without proof
change is compatible
florian: We're not saying it's the end of the story. I don't think
we should close, we should resolve you're investigating
Rossen: Closing and resolving are different. If there's more
information with strong suggestion in opposite we revisit
Rossen: Objections to resolve no change?
RESOLVED: No change
CSSOM
=====
Is `round` special in CSSOM?
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/5689
chris: Context was I was going through cssom definition of
serializing color because we resolved on moving it to color
4. Had a special definition of rounding. Seems there is a
reason, mainly for negative numbers, that you have to spec
chris: Do we want this in cssom or copy to color 4, assume rounding
is rounding? I wanted guidance before I remove the section
TabAtkins: Legit question. Confusing if round up means toward
infinity or away from 0. Ideally shouldn't restate in
algos and we should have a statement in OM about how to
round
TabAtkins: Not sure if Infra has a need
emilio: CSS Values should have something about this because came up
when dividing numbers
Rossen: Had similar discussions around math functions and aligning
to a particular language. Discussion around mod operator
TabAtkins: I suspect match JS because if someone were to impl on
their own that's what would happen
TabAtkins: Apparently C++ and JS differ in default rounding up
TabAtkins: Is it better to match JS, C++, Rust or what?
emilio: Rust does C++ as far as I can tell
TabAtkins: So away from 0
fantasai: C++ probably makes more sense for CSS
Rossen: Trying to avoid whole discussion about how to align better
with math/js/other language which is the discussion we had
before which was heated and we kept coming back to it. I
would suggest take this back to the issue and come back with
a proposal
Rossen: We could spend the next 7 minutes just shifting through
languages
chris: Fine for me
CSS Values 4
============
fantasai: We were just talking values. Values 4 draft is super out
of date
TabAtkins: I think we discussed in past, just waiting on significant
changes list
Rossen: We can call one right now
TabAtkins: Yeah. Changes list is pretty good. Kept reasonably up to
date
Rossen: Objections to publish a new WD for Values 4
RESOLVED: Publish a new WD for Values 4
CSSOM
=====
The way CSSStyleDeclaration exposes properties is not ideal
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5649
emilio: It's a mess everywhere. I made a proposal. Seemed to be
agreement to try and go for it
emilio: Not in love with...need to decide on names. I'm fine
deciding the names on GH or another call
emilio: Idea is to have different interfaces for different
declarations. fontFace only has a set of descriptors. Spec
is sad and doesn't match browsers. Maybe WebKit but it adds
descriptors.
emilio: Agreement from browser engines it's a decent path forward
Rossen: You're okay continuing discussion in GH?
emilio: It would be ideal to resolve on separate interfaces for
declarations that declare different things. Names tbd
TabAtkins: I would love to have this. Please have it
Rossen: Do you have proposal written up? Is it a PR or anything more?
emilio: I can summarize in IRC
fantasai: Go ahead
<emilio> Having different interfaces for declarations that expose a
different set of descriptors/properties
<emilio> declaration blocks* I guess, naming in the spec is wrong
fantasai: I think it's good for each to have different set. Exposing
declarations that don't apply is confusing and may have
future problems
Rossen: I'm hearing support
Rossen: We can resolve to adopt the proposal and you can come back
with more concrete interfaces. Does that work?
emilio: Sounds great
Rossen: Objections to Having different interfaces for declarations
blocks that expose a different set of descriptors/properties
RESOLVED: Have different interfaces for declarations blocks that
expose a different set of descriptors/properties
Rossen: Top of the hour. We have quite a bit of issues for next
week. Thank you all for calling and have a great week. We'll
chat next week
Received on Thursday, 12 November 2020 00:31:17 UTC