- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Jun 2021 19:01:15 -0400
- 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.
=========================================
Color Adjust
------------
- RESOLVED: Add new keyword to forced-color-adjust as described
above, apply it in UA default stylesheet for SVG root
element (Issue #6310: Spec currently breaks use of
currentColor for SVG icons in WHCM)
CSS Fonts
---------
- The group generally felt that 'size-adjust' could be shipped soon
(Issue #6371: Is the 'size-adjust' descriptor stable enough to
ship?) however they wanted to first get feedback from myles and
publish the FPWD for Fonts 5. The goal is to have a draft ready
in about a month.
- RESOLVED: Switch ic and ch to ic-width/ic-height/ch-width (Issue
#6288: Clarify/reconsider interaction of new
font-size-adjust options with writing modes)
CSS Contain
-----------
- RESOLVED: Add style containment back to 'strict' and 'content'
values of 'contain' (Issue #6287: 'contain: stricter'
like strict + style)
CSSOM View
----------
- RESOLVED: Incorporate visualViewport into cssom-view and add bokand
as editor (Issue #6339: Merge visualViewport into working
group)
CSS Transforms
--------------
- RESOLVED: Clamp to 1px for both getComputedStyle() and
interpolation as well (Issue #6320: clamping of
perspective() function to >= 1px should affect
interpolation | Issue #6346: clamping of perspective()
function should affect resolved value of transform)
CSS Flexbox
-----------
- RESOLVED: Accept edits [in
https://github.com/w3c/csswg-drafts/commit/60ffc4058780d832d880a076fe02788f0cc6e8a7
]
(Issue #5985: Clarify whether collapsed flex items
influence the flex container's intrinsic main size)
CSS Overflow
------------
- There is some clarification needed for issue #4791 (Scrollable
Overflow contributions of zero height/width elements) however the
group ran out of time on the call to go into much detail.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jun/0009.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Christian Biesinger
Oriol Brufau
Elika Etemad
Simon Fraser
Chris Harrelson
Daniel Hobert
Brad Kemper
Jonathan Kew
Daniel Libby
Ting-Yu Lin
Peter Linss
Alison Maher
François Remy
Morgan Reschenberg
Cassondra Roberts
Jen Simmons
Alan Stearns
Miriam Suzanne
Greg Whitworth
Scribe: fantasai
Scribe's scribe: fremy
Color Adjust
============
Spec currently breaks use of currentColor for SVG icons in WHCM
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6310#issuecomment-858112357
fantasai: The current proposal is not gonna get us in good shape in
all cases
fantasai: currently our resolution would not work if the svg has set
its color explicitly
fantasai: so my new proposal is that if the color is originating from
outside the svg then we recolor, but if not then we keep it
fantasai: Proposal is to add a new keyword for that magic behavior
which depends on the origin of the value of color
fantasai: (if you are not inheriting from outside, then we don't
reset the color)
alisonmaher: I agree with the proposal
alisonmaher: only problem I wanted to ask about was whether we can do
at computed value time
alisonmaher: if we take the used value of the color, might expose the
color where otherwise wouldn't
TabAtkins: :visited won't be exposed that way
TabAtkins: That's done by selector-hacking
TabAtkins: and the rest of colors are already automatically exposed
via getComputedStyle
TabAtkins: because getComputedStyle returns used value of color
TabAtkins: so not sure there's info leakage problem
Rossen: While we're on the topic, wrt TAG review
Rossen: We convinced ourselves that having a grouping of color values
that we essentially return just defaults for, and lie about
the computed or used values
Rossen: colors used for fingerprinting
Rossen: could be a good path forward
Rossen: These are magic values, you won't get the actual values
though getComputedStyle
Rossen: benefit of user for privacy
fantasai: That's a separate issue, here
https://github.com/w3c/csswg-drafts/issues/5710
fantasai: In that issue there are further comments there that says
why it's probably not possible
fantasai: but this is not linked to our current issue here
astearns: If we end up doing anything special for particular sources
of colors
astearns: If we add this new mechanism, we'd have to do whatever
magic here, too
fantasai: You'd also have to taint Canvas, and a lot of other things,
yeah.
astearns: alisonmaher is it enough to note that, whatever protections
would end up happening here also?
alisonmaher: We're storing [?] in chrome, so would be possible to do
at used-value time
fantasai: The issue is that would have to track this down the tree
fantasai: and this type of tracking is usually done via inheritance
fantasai: I don't think implementations have a special inherit for
colors
alisonmaher: We inherit that info separately in Chromium
astearns: So what do we resolve to deal with this
fantasai: We need to add a new value
fantasai: We need to a new value to forced-color-adjust
fantasai: as described in
https://github.com/w3c/csswg-drafts/issues/6310#issuecomment-858112357
fantasai: We can call it something else, but need something that
behaves like that
astearns: New value, not something to add to default?
TabAtkins: Yes, absolutely
TabAtkins: and needs to be set in default UA stylesheet for SVG root
element
astearns: Exposed to author styles?
TabAtkins: Yes; don't want it to be special unspecifiable magic
astearns: So proposed resolution is to add this keyword
astearns: and to add that to the default UA stylesheet
RESOLVED: Add new keyword to forced-color-adjust as described above,
apply it in UA default stylesheet for SVG root element
fantasai: Other than this issue
<fantasai> https://github.com/w3c/csswg-drafts/labels/css-color-adjust-1
fantasai: we have no other remaining issue for the spec
fantasai: so our plan is to make the edit
fantasai: publish a new draft
fantasai: and ask for last comments before trying to propose to make
a recommendation
fantasai: So, heads up
astearns: And get wide review?
fantasai: We already have sent an email in December
<fantasai> https://github.com/w3c/csswg-drafts/issues/5768
astearns: Sounds like a good plan
CSS Sizing
==========
Compressible elements with aspect ratio
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6341
iank: Added table kinda late, can punt to next week if we want
CSS Transforms
==============
Clamping of perspective() function to >= 1px should affect interpolation
------------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6320
astearns: is dbaron on the call?
fantasai: we can skip for a later time
CSS Fonts 5
===========
Is the 'size-adjust' descriptor stable enough to ship?
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6371
jfkthame: We've implemented size-adjust descriptor in Firefox
Nightly, and want to know if stable enough if we can ship
to release
jfkthame: My understanding is that Chrome is also wanting to ship soon
<chrishtr> agree it's good to ship
fantasai: I think the descriptor is pretty stable
fantasai: The way it is defined is standard and I don't anticipate
issues
fantasai: so I think it's probably fine to ship
fantasai: but we need to publish a First Public working draft first
fantasai: This could happen very soon
astearns: Any other concerns?
smfr: Let's ask Myles, he's not here today
astearns: Sounds good, also we still need an FPWD
<fantasai> https://www.w3.org/TR/css-fonts-5/
<fantasai> 404 ^
astearns: It's most important to publish FPWD, but even for a regular
WD would like to publish before group says "you can ship" :)
astearns: So let's get edits in and get Myles' comments
astearns: but generally seems like it'll be OK
jfkthame: Would help to know schedule.
fantasai: we can get a draft within a month
CSS Contain
===========
'contain: stricter' like strict + style
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6287
TabAtkins: Some time ago we removed 'style' from set of containments
applied by 'strict'
TabAtkins: Since at-risk, unsure if FF would implement
TabAtkins: no longer at-risk
TabAtkins: Question is should we have a keyword that applies 'strict'?
TabAtkins: If so, should we add a new keyword or build it back into
'strict'?
TabAtkins: chrishtr commented that he thinks it'd be fine to add into
existing 'strict', and willing to do experimentation in
Chrome
fremy: I agree, makes sense to me
<dholbert> Sounds fine by me
oriol: Wouldn't just be strict, but also ...
oriol: content
TabAtkins: content used to be 'strict' without 'size', so add to that
as well
fantasai: sgtm
astearns: So proposed resolution is to add back in style containment
to 'strict' and 'content' values of 'contain'
astearns: Any objections?
RESOLVED: Add style containment back to 'strict' and 'content' values
of 'contain'
<chrishtr> I will get this change made in Chromium asap so we can get
canary channel feedback. Will report back if there are any
found.
CSSOM View
==========
Merge visualViewport into working group
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6339
<TabAtkins> https://wicg.github.io/visual-viewport/index.html
TabAtkins: visualViewport spec that allows getting bounds of visual
viewport in JS
TabAtkins: has been implemented cross-browser for awhile
TabAtkins: probably should be on standards-track
TabAtkins: suggestion is to put into cssom-view
<fremy> LGTM
fantasai: Who is gonna be editor?
TabAtkins: bokand is editor of visual viewport spec... and is a
member of CSSWG
TabAtkins: Could just add him
smfr: Emilio and I are editors of CSSOM-view, and would appreciate
editorial help
fantasai: Sounds like a good idea to have one more person on this
TabAtkins: chrishtr, can we volunteer bokand?
chrishtr: We can try, and if he's busy, we'll find someone else on
our staff
astearns: So propose to incorporate visualViewport into cssom-view
and add bokand as editor
RESOLVED: Incorporate visualViewport into cssom-view and add bokand
as editor
fantasai: One more comment
fantasai: It's a bit weird how things happened here
fantasai: We are not doing standardization, we are doing documentation
fantasai: I don't find this workflow appropriate
fantasai: So I agree to do it here, but it's worth noting I think it
is not a good workflow
fantasai: It's too late to make any changes now, so it's not exactly
accurate to say you're shifting it to the CSSWG for the
"standardization" process
astearns: I agree
astearns: That said, it happens, and we can't change it
astearns: and documentation is still good
TabAtkins: Also, it shipped in multiple browsers
TabAtkins: Discussion happened, in another venue
TabAtkins: but patent protection was not part of this, and this is
not ideal
<TabAtkins> Like, look at the issues list, showing definite
cross-browser discussion
https://github.com/WICG/visual-viewport/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
Transforms
==========
Clamping of perspective() function to >= 1px should affect
interpolation and clamping of perspective() function should
affect resolved value of transform
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6320 &
https://github.com/w3c/csswg-drafts/issues/6346
dbaron: Discussing 6320 and 6346 together
dbaron: Group resolved that values less than 1px should be clamped to
minimum of 1px
dbaron: At the time, discussed as a render-time clamp
dbaron: I tried implementing this. Believe I was the first
dbaron: In the process, became clear that the time at which it became
clamped was the time you convert to a matrix
dbaron: Problem with zero is that it puts infinite components into
the matrix
dbaron: There are 3 different ways convert to a matrix
dbaron: 1) need to render, to find used value
dbaron: 2) find resolved value for getComputedStyle()
dbaron: computed value of transform function is "as specified with
lengths made absolute"
dbaron: but resolved value is a matrix
dbaron: The third one, which is maybe more interesting, is
interpolation
dbaron: Perspective function gets interpreted as matrices
dbaron: if you were to not clamp, and then interpolate from 0 to 2px,
dbaron: entire range of animation would be clamped to 1px during
render time, because animating from infinity to 0.5
dbaron: which crosses 1 basically right when it gets to 0.5
dbaron: Conclusion was do the clamp anytime I convert to matrices
dbaron: so for getComputedStyle and for interpolation also
dbaron: I've already implemented this in Canary ... does anyone think
we should do something different?
dbaron: Not clear to me what that could be
smfr: Seems fine. What happens when perspective property or transform
with only perspective, not converting matrices, do we need to
describe behavior there?
dbaron: For perspective property, group explicitly resolved in 3084
that the animation should be different
dbaron: so perspective property should interpret as specified
dbaron: 2nd point, spec says that even a perspective() on its own
gets interpolated as matrix
dbaron: it describes the rules for interpolating matrix and
perspective as the same thing
dbaron: so decompose and do the pieces
dbaron: for perspective it's trivial
dbaron: but still the decomposition that gets interpolated is the
matrix component, so ?? reciprocal
smfr: So that part is affected by your proposal
dbaron: Yes
smfr: I think it's reasonable
smfr: As long as we agree on where conversions to matrices happen
dbaron: Issues I filed are in terms of this should happen for
interpolation and this should happen or getComputedStyle
dbaron: but rational was "wherever convert to matrix"
smfr: Sounds fine
astearns: So original resolution for 413, did that cover resolved
value?
dbaron: No, said "for purpose of rendering"
astearns: So have a resolution for rendering, and you're saying
extend to interpolation and resolved value
astearns: Any other opinions?
astearns: ... implementation detail?
dbaron: When editing spec, I'll see if it makes sense to fit that
note in
[scribe missed, but guesses note was about the "convert to matrix"
rationale]
RESOLVED: Clamp to 1px for both getComputedStyle() and interpolation
as well
dbaron: Possible not web-compatible, but can figure that out when we
have data
CSS Fonts
=========
Clarify/reconsider interaction of new font-size-adjust options with
writing modes
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6288
jfkthame: Was working on implementing in Gecko, and it occurred to me
that the behavior that falls out for the new ch and ic
units probably isn't what we really want
jfkthame: If you set font-size-adjust: ch 0.4, for example, and then
use vertical writing mode with upright typesetting
jfkthame: you'd get completely different scaling
jfkthame: Seems that would be unexpected and undesirable
jfkthame: Expectation would be that font + font-size-adjust should
give consistent results
jfkthame: So my suggestion is that it applies in the horizontal axis
jfkthame: so not quite the same as the units
jfkthame: so maybe need to rename to make more explicit what they are
astearns: I think I'd like ch-width name
astearns: Very explicit
jfkthame: We'd have the option of introducing a ch-height for
vertical mode, but usage expected to be quite different
fantasai: That would be more difficult than helpful
fantasai: The vast majority of the authors won't need that second
number
fantasai: I would be ok with it if it is optional
fantasai: and sets to no effect
astearns: I think that was the proposal
fantasai: Currently if you wanted to have an effect in the vertical
axis, we have a syntax for two values
fantasai: The disadvantage of that is that you might want different
values for the different axes
fantasai: but given few people would want to use two values
fantasai: Maybe we should just have one value and be clear about what
it means
fantasai: and when would you know which one you want, if both are
specified?
astearns: Were we going to have ic-height and ic-width that can set
at the same time?
jfkthame: No, just one at a time
astearns: So proposed resolution is to replace ic and ch with
ic-width ic-height and ch-width
astearns: to lock things to the appropriate axis and make that
explicit
fantasai: The one thing we might consider is adding 'ic' and having
it compute to 'ic-width' or 'ic-height' as appropriate to
the writing mode and then inherit as that computed value
fantasai: Worth consideration, but I haven't thought about it much
astearns: But whatever value you add to that ic would be based on one
or other metric, so unlikely to have single value that
works for both
fantasai: unless you're using 1em, in which case no effect except for
non-square fonts anyway...
jfkthame: [...]
jfkthame: Could look into it, but doesn't seem worth the complexity
RESOLVED: Switch ic and ch to ic-width/ic-height/ch-width
Flexbox
=======
Clarify whether collapsed flex items influence the flex container's
intrinsic main size
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5985
TabAtkins: Just got approval from dholbert so probably easy
TabAtkins: dholbert noticed that collapsed flex items aren't
explicitly excluded from intrinsic size calculation
TabAtkins: so we updated to explicitly skip those items
<fantasai> commits are
https://github.com/w3c/csswg-drafts/commit/60ffc4058780d832d880a076fe02788f0cc6e8a7
TabAtkins: We made the fix, just wanted WG confirmation it's OK
<cbiesinger> I haven't read the text but your description sounds good
astearns: Proposal to accept?
RESOLVED: Accept edits
CSS Overflow
============
Scrollable Overflow contributions of zero height/width elements
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4791
fantasai: Seem to have weird but interoperable behavior here,
question was should we spec it
iank: Not so weird, we compute the "inflow" bounds
iank: ...
iank: If you add a transform to the item and move it outside the
scrollable area
iank: all browsers transform out
iank: If something is zero area, it doesn't itself contribute, but it
might contribute to "inflow bounds"
fantasai: ???
iank: If you have something like a grid area, that's where we
determine where to put the "padding" to contribute to overflow
iank: Here it's the body element contributing to the scrollable area
fantasai: OK, so need to set body to zero to test correctly and issue
is invalid?
iank: Question of adding to overflow is just if it's empty
fantasai: Actually, there is an issue, but it's just that if the
border area is empty, we need to exclude from the
scrollable area
iank: Yea, but also this other thing
Received on Wednesday, 16 June 2021 23:02:12 UTC