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://
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://
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://
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://
<TabAtkins> https://
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://
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://
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://
[css-color-adjust-1] Spec currently breaks use of currentColor for SVG icons in WHCM
github: https://
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://
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://
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://
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://
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://
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://
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://
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