- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Jun 2021 15:03:48 -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.
=========================================
CSS Overflow 4
--------------
- RESOLVED: Accept the edited changes as described by florian (Issue
#4674: scrollbar-gutter is too complex)
- Edits: https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property
- New appendix: https://drafts.csswg.org/css-overflow-4/#sbg-ext
CSS Color Adjust
----------------
- RESOLVED: Accept changes and add only keyword (Issue #5089: Re-add
only to mean "don't auto-adjust me", per WebKit's
behavior)
- RESOLVED: Add forced-color-adjust propagation to apply to root
(Issue #6307: viewport propagation of forced-color-adjust)
- RESOLVED: Add color-only value as described in the issue and
clarified by TabAtkins (Issue #6310: Spec currently
breaks use of currentColor for SVG icons in WHCM)
Variables
---------
- RESOLVED: Accept the proposal [Add an exception to the general
comma-omission rules] (Issue #6345: Whitespace-trimming
and custom properties)
CSS Contain
-----------
- RESOLVED: Add contain:paint to list of grouping properties (Issue
#6202: Should it be possible for an element with
contain:paint to be part of a transform-style:preserve-3d
scene?)
Media Queries
-------------
- RESOLVED: Adopt this media feature as a part of Media Queries
(Issue #6343: Display mode media feature)
CSS Sizing
----------
- A grid of possible cases will be added to issue #6341 (Compressible
elements with aspect ratio) in order to clarify the expected
behavior.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jun/0006.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Christian Biesinger
Oriol Brufau
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Brian Kardell
Brad Kemper
Jonathan Kew
Daniel Libby
Rune Lillesveen
Chris Lilley
Ting-Yu Lin
Peter Linss
Alison Maher
Tess O'Connor
Morgan Reschenberg
Melanie Richards
Florian Rivoal
Jen Simmons
Miriam Suzanne
Lea Verou
Regrets:
Greg Whitworth
Scribe: dael
Rossen: It is 2 minutes past the hour, let's get going
Rossen: As usual, I wanted to ask for any extra agenda items or
agenda changes we want to do
Rossen: Let's assume there are none
CSS Overflow 4
==============
scrollbar-gutter is too complex
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4674
Rossen: Update of the breakout that took place last week
Rossen: It also had spec text added to capture what was decided and
discussed
Rossen: I wanted to give chrishtr or florian a few minutes to recap
and then see if we need resolutions
florian: We had a meeting for about an hour
florian: Talked about scrollbar-gutter, figured out extent of use
cases which are possible to address. Also focus on subset of
values we can be sure are good to ship soon
florian: Make sure we don't paint into a corner with incorrect subset
florian: Stable is 'auto' and 'stable' values with a twist of making
'stable' apply to overflow:hidden state as well
florian: With that addition 'auto' and 'stable' are the core subset
to serve the main use case
florian: The 'both' value to apply to both sides is least
controversial. Everything else has not been deleted but
moved to non-normative appendix of things being explored.
florian: No radical redesign to what has been moved. Discussion
during the call could leave to radical changes, but not
there yet. Just moved off.
florian: One extra thing I did after the call is we had come
complaints names were hard to figure out. I thought 'both'
value was tricky. For now, named to 'mirror' to hopefully be
more explicit
florian: We can bikeshed if you don't like
florian: Spec now includes overflow:hidden with 'stable'; 'both'
renamed to 'mirror'. Everything still being discussed moved
to appendix. Since remaining properties can only do anything
to scroll containers applies to line has been changed from
all elements to scroll container
florian: When we extend to the cases in the appendix may that will
relax but not defined narrow
florian: All this is in place. If that sounds good we leave spec as
if. If it doesn't we have to make changes
<florian> https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property
florian: Main body of text ^
<florian> https://drafts.csswg.org/css-overflow-4/#sbg-ext
florian: Appendix ^
Rossen: Thanks florian
Rossen: Given the extensive changes and discussion during the
breakout I wanted to ask if there were any comments at the
moment. If not we can use summary and links to propose any
changes and then come back to resolve next week
<TabAtkins> +1 to the changes
florian: I will do a bit of triage on the rest of the spec to see
where we're at. If nothing blocking I may ask for a new WD
which could be occasion to bless or reject
chrishtr: I didn't fully understand Rossen; suggesting delay to next
week for resolution?
Rossen: Inviting people to engage in comment now or given extent of
changes we can give it a week for review. Is there are reason
we can't wait?
chrishtr: Don't see reason to wait. It has been 2 weeks since
breakout call
Rossen: Trying to see if people have strong reasons to require the
extra time
chrishtr: If anyone has such a concern we can wait. It didn't
anticipate one
fremy: If everyone in call was fine with changes I think it will be
okay. Would be great to know exact changes we will resolve on
Rossen: That's my point, a lot of people missing on breakout call.
They need full context before we can resolve. florian did a
great job of summarizing, but it's not the details
florian: Other option is assume it's fine and let people raise issues
with no deadline on that
Rossen: Back to the WG and everyone interested. Does anyone need
extra time to review the changes reflected in the spec? Or
are we fine accepting now?
fremy: Would like to review, but fine to accept now and raise issues
later
Rossen: Okay. Anyone else?
Rossen: Not hearing any strong reasons to delay the acceptance of the
changes. Objections to accept the edited changes as described
by florian ?
RESOLVED: Accept the edited changes as described by florian
Rossen: For those who need time to review, please open issues. And
other part is naming of the new values which I'm sure we can
come back to
florian: A heads up that stuff in the appendix is expected to change.
I have ideas, but it's explicitly marked as unstable and no
one is trying to ship that part
CSS Color Adjust
================
Re-add only to mean "don't auto-adjust me", per WebKit's behavior
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5089
<TabAtkins> https://drafts.csswg.org/css-color-adjust/#color-scheme-override
TabAtkins: As discussed earlier we want to re-add auto to turn off
auto adjustment. Means spec had to recognize auto
adjustment. Edits are in and approved by smfr which is
only browser currently doing auto adjusting.
TabAtkins: If people are cool we can accept edits. Also happy to
adjust if there are concerns
<Rossen> https://github.com/w3c/csswg-drafts/issues/5089#issuecomment-844525850
Rossen: Proposal ^
<chrishtr> Looks good to me!
TabAtkins: Yes, end of comment is what went into spec
Rossen: Assuming people have been able to read, additional comments
or objections to accept changes and add only keyword?
RESOLVED: Accept changes and add only keyword
viewport propagation of forced-color-adjust
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6307
alisonmaher: Currently propagating from root and body to viewport.
Since we force colors at used value time we can get
wrong if don't propagate forced-color-adjust to viewport
alisonmaher: We previously resolved not to propagate any new
properties from body to viewport but wondering if we
should have an exception here so forced color does
propagate when set on body
TabAtkins: I see argument for it.
TabAtkins: As not a direct implementer I can't say if it's cool to
add one more to the list, but I can see why it's confusing
to figure out when color comes off body
Rossen: Effect of not doing it? You may have background of viewport
that's different than forced?
alisonmaher: Set forced-color-adjust to none and want background to
be another color we would end up forcing the viewport
background color because it's not none at viewport.
Wouldn't get background color at the viewport
fantasai: Two comments. Seems bad practice to set forced-color-adjust
none on body. Seems a bit user hostile to say I don't care
what you want
fantasai: If concern is tweak color of background we have similar
problem with color scheme. If we propagate one we should
propagate both. Not sure we should; we should encourage
people to set in html
alisonmaher: If we were to do it for forced-color-adjust doing it for
color-scheme would make sense as well
futhark: I was thinking that is it really we should propagate the
property to viewport and not we should take into account
when propagating. When try and propagate background we look
at display value and if it's display:none it's not
propagate. Maybe similar
alisonmaher: Yeah, when look at forced-color-adjust at used value
time we could end up forcing the propagated value of
viewport no matter what.
Rossen: Are options to leave as-is and use this as a soft mechanism
to discourage such usage patterns by authors? On the other
hand we can still add that same question applies to do we add
back color scheme to the list
alisonmaher: Those are two options. One use case from author to set a
background color for svg image which are similar to root
and viewport propagate. To fix that we would need to
propagate from root to viewport. Hoping can resolve on
propagate from root. If doing for root might makes sense
to do from body as well
Rossen: Other opinions?
fantasai: If we're doing from root make sense to do from body as well
statement doesn't make sense. Have lot of properties that
propagate from root but not body so don't think that holds
alisonmaher: If feel we shouldn't do from body I'm okay with that.
Root piece is major thing looking for. Can see author
confusion but wouldn't object
<emilio> +1 for doing it just for the root
fantasai: A bunch of scrolling properties that don't propagate from
body even though overflow does. We locked down to some css
2 properties
Rossen: Not hearing disagreement about root. Sounds reasonable.
Conversation seems to support adding to root. For body we've
been making steady attempts to min exposure that's propagated.
Rossen: Sounds like current consensus is around adding to root but
not body.
alisonmaher: That works
Rossen: Other thoughts?
Rossen: Objections to adding forced-color-adjust propagation to apply
to root
RESOLVED: Add forced-color-adjust propagation to apply to root
<oriol> Note in
https://github.com/w3c/csswg-drafts/issues/6079#issuecomment-816307011
we resolved "No future properties should propagate from
<body> to the ICB"
Spec currently breaks use of currentColor for SVG icons in WHCM
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6310
alisonmaher: This is around handling currentColor. AmeliaBR noted
that SVG icons will not inherit appropriate forced-color
through currentColor.
alisonmaher: 2 solutions. 1) undo the resolution to use forced colors
at used value time. 2) introduce a color-only value that
only adjusted color. Make that default for SVGs. Because
color-only effects svg through currentColor works well
for icon
alisonmaher: Only possible unexpected is an svg ancestor set
forced-color to none the svg would still set to
currentColor. This seems rare so in favor of color-only.
Looking for other opinions
TabAtkins: Definitely need to fix this. Only consideration to fix
issue you raised could the value act as none if inherited
value is none but act as color if it's auto.
TabAtkins: Then it still works as expected
alisonmaher: Good idea. Will need to look into how to impl but could
be good way to handle
TabAtkins: Seems reasonable to add, I'm in favor
Rossen: Proposal to fix the issue through a spec clarification and
not adding color-only value?
TabAtkins: No, still add value. The value acts as alisonmaher and
AmeliaBR spec in auto case. If inherited is none it would
act as none. It would automatically opt-out
Rossen: I see
Rossen: Other opinions or suggestions?
Rossen: alisonmaher do you want a resolution now? Or do you prefer to
go back and figure out if implementable?
alisonmaher: Can resolve and come back if implementation is tricky.
Seems adding color-only value we can resolve on
Rossen: Objections to add color-only value as described in the issue
and clarified by TabAtkins
RESOLVED: Add color-only value as described in the issue and
clarified by TabAtkins
Variables
=========
Whitespace-trimming and custom properties
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6345
emilio: This one; we resolved a while ago on trimming whitespace from
decorations. TabAtkins pointed out some examples invalid in
impl should be valid.
emilio: For system propagating fallback there's no trimming. Felt odd
when impl that if you're using fallback in computed you get
whitespace but if the fallback you have a variable it's
stringed.
emilio: Trimming whitespace from fallback functions would be
simplest. I think in general makes sense
Rossen: Feedback?
TabAtkins: Yes, we absolutely should. That this doesn't work is
accident of css rules for comma omission. You have to omit
comma when not separating but this is the case where lack
of a thing can be a thing. Need something in var to set
the exception that you can set a comma
emilio: fwiw it's very easy to impl
<TabAtkins> `foo(--a,)` is currently syntacitcally invalid, and that
is good for everything *but* `var()`
Rossen: Other feedback? leaverou_ you're active in the issue.
Anything to add?
leaverou_: I added my thoughts to issue. I support that change
Rossen: Objections to adding the spec proposal?
RESOLVED: Accept the proposal
CSS Contain
===========
Should it be possible for an element with contain:paint to be part of
a transform-style:preserve-3d scene?
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6202
TabAtkins: The summary is when you have a preserve-3d transform
nothing prevents a contain:paint participate in the 3d
scene.
TabAtkins: A bunch of properties restricted to force it to become
flat so children are container
TabAtkins: contain:paint should work the same
<smfr> overflow does NOT create a graphical group
TabAtkins: Spec also allows overflow:clip to have children leave
element entirely and florian pointed out that doesn't make
sense.
TabAtkins: If we're having contain:paint to cause flattening we
should have them both
TabAtkins: Proposal: add contain:paint to list of grouping properties
that force it to be flat. Remove clip value form
exceptions so it also causes it to be flat
smfr: I think this is right thing. I think contain:paint causes
stacking but should flatten
smfr: I think TabAtkins said non-visible overflow creates stacking?
TabAtkins: Overflow:clip is on list of values that don't cause
flattening. Feels weird. I think it should
smfr: That's fine. I agree with proposal
<chrishtr> agree that clip and contain:paint should cause flattening
dbaron: I agree as well
Rossen: Other feedback or objections?
smfr: Proposal to make overflow:clip a grouping property.
Implementing it creates stacking context?
florian: Don't think so
smfr: Think it does
dbaron: We do have that grouping properties create stacking context.
That said, I wrote a test a few weeks ago to see what
browsers made group. Tested with transform flattening and
mixed blend and got entirely different results in all
browsers.
dbaron: Given that I think we don't have a good sense of grouping
smfr: Testing with opacity or filters might have given more consistent
smfr: I don't want to separate grouping from stacking context. Would
create complexity
florian: I don't think the grouping are defined to create stacking
dbaron: Don't have a spec for this. I did have understanding that the
set of things grouping is subset of things that create
stacking
<dbaron> the test I'm talking about was
https://dbaron.org/css/test/2018/stacking-context-z-order
TabAtkins: Happy to remove overflow:clip part and just do
contain:paint
smfr: contain:paint can imply overflow:clip. Would love overflow
properties that create stacking, but that ship has sailed
Rossen: TabAtkins just resolve on contain:paint and leave
overflow:clip for now?
TabAtkins: Yes
Rossen: That's the proposal. thoughts or objections?
florian: Thought; maybe misunderstanding. Seems it's not necessary
for overflow:clip to flatten a 3d transform because can
position in 3d model. If when it's time to paint the
projection is outside area you paint you clip
smfr: Please don't make clipping a thing we need in 3d scenes
Rossen: Great conversation that should happen when additional
investigation of overflow:clip takes place
smfr: If we resolve on this do we need to resolve on if will-change
contains side effects. From dbaron's chart it does not have
stacking.
TabAtkins: Can you open as separate issue?
smfr: Yes
<dbaron> I think will-change's definition is pretty clear about
what's supposed to happen...
Rossen: Not hearing objections to contain:paint
RESOLVED: add contain:paint to list of grouping properties
Rossen: Anything else on this?
Media Queries
=============
Display mode media feature
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/6343
florian: Media feature in a non Media Queries spec. Should it move?
florian: Currently in App Manifest spec. Lets you tell if app is in
full screen or normal context or if it has minimal UI
florian: That exists. I think shipped in everything. I think we
should adopt it
TabAtkins: Since it's been shipped it's stable. Happy to pull in.
Should at least mention, but I think we can pull in
Rossen: florian have you been engaged with App Manifest team to make
sure this is their intent?
florian: Request is coming from them
Rossen: Great
Rossen: Objections to adopt this as a part of MQ?
RESOLVED: adopt this as a part of MQ
CSS Sizing
==========
Removing intrinsic aspect-ratio from an image
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6257
TabAtkins: This was agenda+ in an earlier week and discussed. Label
wasn't removed. Was that intentional?
TabAtkins: Still active discussion in issue. Wanted to make sure
something to discuss here.
dbaron: bot's rule is it only removes if there's a resolution
Rossen: Right. Since not resolved it's been kept there. Happy to push
it back to GH for discussion
Compressible elements with aspect ratio
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6341
fantasai: iank noted we allow compressible to compress when have
percent width or max width. We floor with explicit min size.
fantasai: Suggested things with aspect-ratio might want to consider
min in other dimension. aspect-ratio and a min height might
want to floor compression of width
fantasai: Wanted to ask WG if we want to spec that in Sizing 3. No
one impl but iank wants to try
iank: I think FF may impl it in some cases.
Rossen: What is percent resolved in this case?
fantasai: Case where they don't resolve. Want min content
contribution of the item.
fantasai: Usually we use natural size. When have percent width we
allow compress to close to 0. Exists for compat
Rossen: Want to resolve the min width calc base on min-height because
we have aspect-ratio
Rossen: And if min height is also percent?
fantasai: Wouldn't transfer anything, I think
Rossen: And we would favor over min-width that's spec
fantasai: I think we would honor spec min-width
fantasai: iank, what are your thoughts on that?
iank: It would take the maximum if min width and height are spec and
don't agree
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9399
iank: Percent would resolve if they can, similar to today. Can get
cases where percent height will resolve. Link to case^
iank: You can see image is distorted. Doesn't have to be
Rossen: My take is in general this make sense. Too many details. I
think it would benefit if we tried to capture a short table
of interaction and expected resolution
Rossen: And expected values as to if percent or spec and which wins
Rossen: Would this be something iank you want to take on?
iank: I can create a simple table. Should be straight forward. Order
already resolves percent if we can so straight forward
Rossen: Cool. We can bring it next week and resolve
Rossen: I'll give everyone some seconds back
Rossen: We'll start from these issues next week
Rossen: Thank you for calling. Have a great rest of your week
Received on Wednesday, 9 June 2021 19:05:28 UTC