Cascading Style Sheets (CSS) Working Group Teleconference

09 June 2021


alisonmaher, argyle, bkardell_, bradk, cbiesinger, chris, chrishtr, dael, dbaron[m], dholbert, dlibby, florian, futhark, GameMaker, hober, jensimmons, jfkthame, leaverou_, melanierichards, miriam, Morgan, oriol, plinss, rachelandrew, Rossen_, smfr, TabAtkins, TYLin

Meeting minutes

Rossen: We'll start in a couple minutes

Rossen: We'll give another minute and get going

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: Waiting on last minute agenda changes

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 ew can be sure are good to ship soon

florian: Make sure we don't paint into a corner with incorrecct 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, both named to mirror. Everything moved to appendix. Since remaining properties can only do anything to scroll containers applies to line has been changed from all elemetns to scroll container

florian: When we extend to the cases in the appendix may that will relax but not defined narrow

<florian> https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property

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/#sbg-ext

florian: Main body of text ^

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 o nthe rest of the spec to see where we're at. If nothing blocking I may ask for a new WD which could be occation 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 ?

Resolution: 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 adjustingment. Means spec had to recongize. 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 obj to accept changes and add only keyword?

Resolution: Accept changes and add only keyword

[css-color-adjust] viewport propagation of forced-color-adjust

github: https://github.com/w3c/csswg-drafts/issues/6307

alisonmaher: Currently prop from root and body to viewport. Since we force colors at used value time we can get wrong if don't prop forced-color-adjust to viewport

alisonmaher: We previously resolved not to prop any new properties from body to viewport but wondering if we should have an acception here so forced color does prop 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 bg of viewport that's different than forced?

alisonmaher: Set forced-color:adjust to none and want bg to be another color we would end up forcing the viewport bg color b/c it's not none at viewport. Wouldn't get bg 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 bg we have similar problem with color scheme. If we prop one we should prop 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 prop the property to viewport and not we should take into acocunt when prop. When try and prop bg we look at display value and if it's display:none it's not prop. Maybe similar

alisonmaher: Yeah, when look at forced-color-adjust at used value time we could end up forcing hte prop 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? otoh 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 bg color for svg image which are similar to root and viewport prop. To fix that we would need to prop from root to viewport. Hoping can resolve on prop 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 prop 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 prop from body even though overflow does. We locked down to some css 2 properties

Rossen_: Not hearing disagreement about root. Sounds reasonable. Convo seems to support adding to root. For body we've been making steady attempts to min exposure that's prop.

Rossen_: Sounds like current consensus is around adding to root but not body.

alisonmaher: That works

Rossen_: Other thoughts?

Rossen_: Obj to adding forced-color-adjust propagation to apply to root

Resolution: 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"

[css-color-adjust-1] 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) intoduce a color only value that only adjusted color. Make that default for SVGs. b/c 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 inheritied 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_: Prop 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 impl 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

Resolution: add color-only value as described in the issue and clarified by TabAtkins

[css-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 prop 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 simpliest. 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 comna 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

Rossen_: Other feedback? leaverou_ you're in issue?

leaverou_: I added my thoughts to issue. I support that change

<TabAtkins> `foo(--a,)` is currently syntacitcally invalid, and that is good for everything *but* `var()`

Rossen_: Obj to adding the spec proposal?

Resolution: Accept the proposal

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 preserve3d 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 overflow:contain-paint to cause flattening we should have them both

TabAtkins: Prop: 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-visbile overflow creates stacking?

TabAtkins: Overflow-clip is on list of values that don't cause flattening. Feels weird. I think it should

<chrishtr> agree that clip and contain:paint should cause flattenign

smfr: That's fine. I agree with proposal

dbaron[m]: I agree as well

Rossen_: Other feedback or objections?

smfr: Prop to make coverflow:clip a grouping property. Impl it creates stacking context?

florian: DOn't think so

smfr: Think it does

dbaron[m]: We do have that grouping prop create stacking context. That said, I wrote a test a few weeks ago to see what rbowsers made group. Tested with transform flattening and mixed blend and got entirely different results in all browsers.

dbaron[m]: 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[m]: Don't have a spec for this. I did have understanding that the set of things grouping is subset of things that create stacking

TabAtkins: Happy to remove overflow:clip part and just do contain-paint

<dbaron[m]> the test I'm talking about was https://dbaron.org/css/test/2018/stacking-context-z-order

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 b/c 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 nee din 3d scenes

Rossen_: Great convo 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[m] chart it does nto have stacking.

TabAtkins: Can you open as separate issue?

smfr: Yes

Rossen_: not hearing objection sot contain:paint

<dbaron[m]> I think will-change's definition is pretty clear about what's supposed to happen...

Resolution: add contain:paint to list of grouping properties

Rossen_: Anything else on this?

[mediaqueries] display mode media feature

github: https://github.com/w3c/csswg-drafts/issues/6343

florian: Media feature in a non MQ spec. Should it move?

florian: Currently in App Manifest spec. Let's 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 to make sure this is their intent?

florian: Request is coming from them

Rossen_: Objections to adopt this as a part of MQ

Resolution: 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[m]: 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

github: none

[css-sizing-3] compressible elements with aspect ratio

github: https://github.com/w3c/csswg-drafts/issues/6341

fantasai: iank_ noted we allow compressable to compress when have % width or max width. WE floor with explicit min size.

fantasai: Suggested things with a-r might want to consider min in other dimension. a-r and a min height might wantt 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

iank_: in some cases.

Rossen_: What is % 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 % width we allow compress to close to 0. Exists for compat

Rossen_: Want to resolve the min width calc base on min-height b/c we have a-r

Rossen_: And if min height is also %?

fantasai: Wouldn't transfer anything, I think

Rossen_: And we would fav or over min-width that's spec

fantasai: I think we would honor spec min-width

fantasai: iank_ thoughts on that

<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9399

iank_: It would take the maximum if min width and height are spec and don't agree

iank_: % would resolve if they can, similar to today. Can get cases where %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 % 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 % if we can so straight forward

Rossen_: Cool. We can bring it next week and resolve

anything fast?

Rossen_: I'll give everyone some seconds back

Rossen_: We'll start from these issues next week

<chris> Issues 15 and 16 have been resolved meantime

Rossen_: Thank you for calling. Have a great rest of your week

Summary of resolutions

  1. accept the edited changes as described by florian
  2. Accept changes and add only keyword
  3. Add forced-color-adjust propagation to apply to root
  4. add color-only value as described in the issue and clarified by TabAtkins
  5. Accept the proposal
  6. add contain:paint to list of grouping properties
  7. adopt this as a part of MQ
Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).


Succeeded: s/f-c-s/forced-color-adjust

Succeeded: s/from body/from body even though overflow does/

Succeeded: s/value/favor

Succeeded: s/overflow-clip/overflow:clip/

Succeeded: s/[missed]/App Manifest/

Maybe present: emilio, fantasai, fremy, iank_, Rossen