16:58:22 <RRSAgent> RRSAgent has joined #css
16:58:22 <RRSAgent> logging to https://www.w3.org/2021/11/10-css-irc
16:58:24 <Zakim> RRSAgent, make logs Public
16:58:25 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:58:36 <Morgan> Morgan has joined #css
16:59:13 <smfr> smfr has joined #css
16:59:28 <Rossen_> present+
17:00:09 <Morgan> present+
17:00:20 <smfr> present+
17:00:21 <jensimmons> present+
17:01:24 <fantasai> present+
17:01:29 <alisonmaher> alisonmaher has joined #css
17:01:34 <alisonmaher> present+
17:01:40 <oriol> present+
17:02:23 <miriam> present+
17:02:25 <fantasai> scribenick: fantasai
17:02:35 <bradk> bradk has joined #css
17:02:48 <faceless> present+
17:02:59 <bradk> present+
17:03:07 <dholbert> dholbert has joined #css
17:03:13 <dbaron> dbaron has joined #css
17:03:15 <fantasai> Topic: URLs vs Fetch
17:03:19 <fantasai> github: https://github.com/w3c/csswg-drafts/pull/6715/files
17:03:19 <dbaron> Present+
17:03:20 <TabAtkins> present+
17:03:29 <dholbert> present+
17:03:36 <dbaron> github: github: https://github.com/w3c/csswg-drafts/pull/6715
17:03:40 <drott> fantasai: areas where we need to better integarte with the fetch spec
17:03:48 <dbaron> github: https://github.com/w3c/csswg-drafts/pull/6715
17:03:54 <drott> fantasai: chris recently merged PR contributed by contributor
17:04:23 <chris> chris has joined #css
17:04:35 <drott> fantasai: we need those to be reviewed - and ask to publish these changes
17:04:36 <chris> present+
17:04:45 <chris> rrsagent, here
17:04:45 <RRSAgent> See https://www.w3.org/2021/11/10-css-irc#T17-04-45
17:04:49 <fremy> fremy has joined #css
17:04:57 <drott> ikilpatrick: did these get reviewed by anna or nicole?
17:05:09 <drott> tab: I did review it
17:05:32 <drott> tab: anna and domenic coordinating on reviewing...
17:05:46 <chris> Yeah I reviewed it too
17:05:46 <fantasai> s/anna/anne/
17:06:01 <drott> fantasai: if it sounds like it's been reviewed, then I'd suggest to accept the changes
17:06:17 <dbaron> s/nicole/Dominic Denicola/
17:06:33 <drott> > s/nicole/Dominic Denicola/ - sorry about, that, of course
17:06:42 <fantasai> i/github: github:/scribenick: drott/
17:06:46 <fantasai> scribenick: fantasai
17:07:01 <fantasai> Topic: Initial Counter Value of reversed list and increments
17:07:03 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6797
17:07:14 <fantasai> oriol: Define reversed counters
17:07:25 <fantasai> oriol: either specify start explicitly or calculate automatically
17:07:30 <fantasai> oriol: I think algorithm doesn't make sents
17:07:41 <fantasai> oriol: if don't have any counter-set, some of the increments of the items for the counter
17:07:47 <fantasai> oriol: but first increment is counted twice, not once
17:07:54 <fantasai> oriol: and then sum is adjusted by -1 to get start value
17:08:09 <fantasai> oriol: counting the first increment twice, the reason might be otherwise last item will have value of ??
17:08:16 <fantasai> oriol: but in case of -1, we want the last item to get a value of 1
17:08:24 <fantasai> oriol: if all increments are the same
17:08:31 <fantasai> oriol: when they are different, I think we should actually repeat the last increment
17:08:34 <fantasai> oriol: I have some examples in the issue
17:08:40 <fantasai> oriol: if list with all increments -1
17:08:52 <fantasai> oriol: and take one item in middle of list to -2, this only affects preceding items
17:08:55 <dino> dino has joined #css
17:09:03 <fantasai> oriol: but if we change first item, this will affect the value of the last item
17:09:09 <fantasai> oriol: and modify all values in the list
17:09:13 <fantasai> oriol: which seems unexpected
17:09:30 <fantasai> oriol: another issue with counter-set, you have some increment there and the with counter-set
17:09:38 <fantasai> oriol: start without counter-set, and item with value 2
17:09:49 <fantasai> oriol: and then we assign counter-set: 2
17:09:52 <fantasai> oriol: this should have no effect
17:09:58 <fantasai> oriol: probably it's what the author expects
17:10:03 <argyle> argyle has joined #css
17:10:05 <fantasai> oriol: with current spec this can have an effect
17:10:11 <argyle> present+
17:10:12 <fantasai> oriol: in issue itself I proposed how to update the spec
17:10:24 <fantasai> oriol: Also variant of spec text taking into account resolution from 6738
17:10:30 <fantasai> oriol: where we decided to skip elements that are hidden
17:10:37 <lea> lea has joined #css
17:10:40 <lea> present+
17:10:40 <fantasai> oriol: so only non-zero increments
17:10:47 <fantasai> oriol: Mats said it makes sense
17:10:53 <fantasai> oriol: and he already has an implementation
17:11:05 <Rossen_> q?
17:11:11 <fantasai> oriol: so suggest to take this change
17:11:26 <fantasai> Rossen_: sounds like a reasonable change, any others with an opposing opinion?
17:11:29 <fantasai> [silence]
17:11:35 <TabAtkins> +1 btw
17:11:37 <fantasai> Rossen_: objections?
17:11:48 <fantasai> RESOLVED: Accept proposal
17:11:53 <TabAtkins> (i assumed this was gonna be included in the issue we talked about during the f2f last week)
17:12:09 <fantasai> Topic: [css-mediaqueries-5] Clarifications on [video-]dynamic-range MQs
17:12:16 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6793
17:12:47 <fantasai> florian: We have 2 MQ which are similar, dynamic-range and video-dynamic-range
17:12:50 <fantasai> florian: 2 issues in 1 here
17:13:02 <fantasai> florian: one is primarily editorial, doing poor job of explaining the difference between these two queries
17:13:21 <fantasai> florian: notion of video plane is fairly rare concept that relates to TVs and how they have unusual screen buffer impls that we can query separately
17:13:40 <fantasai> florian: core question raised in this issue, besides clarification
17:13:44 <chris> +1 to that editorial clarification
17:13:47 <fantasai> florian: is that we have 2 values: high and standard
17:14:03 <fantasai> florian: You might assume, and this apparently is what Safari did, that any device will match standard and some will match high as well
17:14:08 <fantasai> florian: this is not how currently specced, though
17:14:14 <fantasai> florian: devices expected to match one or the other
17:14:20 <fantasai> florian: not standard and high simultaneously
17:14:29 <chris> q+
17:14:35 <fantasai> florian: The query about color-gamut does behave differently, it has 3 values
17:14:54 <fantasai> florian: and these are additional, when you match broader gamut you also match narrower one
17:15:12 <fantasai> florian: unclear what we should do here
17:15:12 <Rossen_> q?
17:15:31 <Rossen_> ack chris
17:15:35 <fantasai> chris: I agree, media capability does the same thing, of using supersets
17:15:41 <GameMaker> GameMaker has joined #css
17:15:46 <fantasai> chris: overall I think it's a better model, think we can easily make spec say that
17:15:47 <GameMaker> present+
17:16:00 <fantasai> chris: the reason to do it is that when we add super-high later on, we want it to be a superset that still passes high
17:16:10 <chrishtr> present+
17:16:12 <fantasai> chris: so I think we should change the spec; not because it's what implemented, but because it makes more sense
17:16:27 <fantasai> dbaron: Wanted to add, think there's a 3rd issue
17:16:39 <fantasai> dbaron: currently wording in spec about combo of UA and output device
17:16:45 <fantasai> dbaron: needs clarification what the UA part of it means
17:17:02 <chris> see also https://w3c.github.io/media-capabilities/#hdrmetadatatype
17:17:10 <fantasai> dbaron: definition of high says, combination of UA and output device fulfill all the following criteria
17:17:24 <fantasai> dbaron: there are a number of ppl in the issue saying that the UA bit should be ignored, and should only be query about the output device
17:17:31 <Rossen_> ack dbaron
17:17:38 <fantasai> dbaron: but if this is question of UA capability, which are you considering if UA can do for some things but not others
17:17:50 <florian> q?
17:17:50 <fantasai> dbaron: e.g. videos but not images, or ...
17:17:54 <chris> q+ to also mention HDR is opt-in and can change dynamically
17:18:06 <fantasai> florian: I suspect querying device and not UA is useless
17:18:20 <fantasai> florian: because if the UA isn't able to access the capability, it's not helping you
17:18:27 <fantasai> florian: but if capability varies within UA, that's a problem
17:18:44 <fantasai> Rossen_: Is one a superset of other? Is UA superset of device?
17:18:49 <fantasai> dbaron: I wouldn't think of it that way
17:18:56 <fantasai> florian: We're querying union of both
17:19:03 <fantasai> florian: need both UA and device to be capabe
17:19:12 <fantasai> chris: Also, HDR capability can vary over time
17:19:16 <fantasai> chris: high power usage
17:19:19 <fantasai> chris: so off by efault
17:19:23 <fantasai> chris: so need to know that it can change
17:19:35 <fantasai> chris: One, is the device capable of HDR mode, and then two, is it in that mode?
17:19:36 <Rossen_> s/Is UA superset/Is UA subset/
17:19:38 <fantasai> chris: we are mixing those two up
17:19:40 <fantasai> florian: we do
17:19:42 <Rossen_> ack chris
17:19:42 <Zakim> chris, you wanted to also mention HDR is opt-in and can change dynamically
17:20:21 <Rossen_> ack fantasai
17:20:23 <drott> fantasai: we should take a resolution to change the query to superset model
17:20:29 <drott> fantasai: multiple things to be clarified
17:20:43 <drott> fantasai: let's ask editor to go back to the thread to work out results
17:20:54 <drott> fantasai: a lot of the clarifications are straightforward
17:21:03 <drott> fantasai: need a resolution to change the media queries
17:21:20 <fantasai> florian: Don't quite agree, question of capability or in HDR mode currently
17:21:25 <fantasai> florian: or videos vs images etc.
17:21:33 <fantasai> florian: not quite clarification, is change in functionality
17:21:41 <fantasai> florian: puzzle how to answer if we don't change the syntax
17:21:50 <chris> q+
17:21:56 <fantasai> florian: so can do things fantasai highlighted, but not enough to solve the issue
17:22:00 <Rossen_> ack chris
17:22:10 <fantasai> chris: media capabilities spec talks about capability, "can the device do it"
17:22:20 <fantasai> chris: if we clarify that way, need the other query as well
17:22:33 <fantasai> chris: the capability and concrete "am I in this mode" are separate
17:22:43 <fantasai> florian: Is it expected to remain this way?
17:22:57 <fantasai> chris: especially for mobile, definite power drained
17:23:07 <fantasai> chris: can be switched automatically, doesn't require user action
17:23:13 <fantasai> chris: but there needs to be a capability
17:23:23 <fantasai> chris: and need to know which mode you're in
17:23:40 <drott> fantasai: i think we should spec as being able to use the switch
17:24:06 <drott> fantasai: from a media queries point of view, how are we styling the document - many of those questions on depend on current mode
17:24:29 <drott> fantasai: [missed parts]
17:24:44 <fantasai> florian: what do we do about if UA can do for images and video but not CSS colors?
17:25:06 <fantasai> florian: or some other variation?
17:25:14 <fantasai> florian: should we consider the UA does or does not fulfill the criteria?
17:25:23 <fantasai> florian: or do we think about query in a different way
17:25:45 <fantasai> florian: I haven't thought about deeply, but maybe you would have high-dynamic-range: video | canvas | etc.
17:25:54 <fantasai> florian: and would get something true if that specific thing is in HDR mode
17:26:08 <fantasai> Rossen_: sounds like a convesation to continue in GH
17:26:16 <fantasai> Rossen_: and doesn't seem we're ready to resolve just yet
17:26:39 <chris_> chris_ has joined #css
17:26:40 <fantasai> Rossen_: propose we stop here, and then after working out proposal in issue, bring back and we'll record a resolution
17:26:48 <fantasai> Rossen_: but hopefully attracted some help on this issue
17:27:02 <fantasai> Topic: [css-position] abspos semi-replaced elements
17:27:08 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6789
17:27:24 <fantasai> iank_: Bunch of history here
17:27:34 <fantasai> iank_: When we have width/height=auto
17:27:41 <fantasai> iank_: can either shrink-to-fit or stretch in that axis
17:27:51 <fantasai> iank_: in Grid Layout, most items will stretch except replaced elements
17:28:08 <fantasai> iank_: every layout mode make these decisions
17:28:23 <fantasai> iank_: semi-replaced element in block layout, frex, is shrhink-to-fit
17:28:44 <fantasai> iank_: Question is about abspos semi-replaced element, say with inset: 0
17:29:03 <fantasai> iank_: Firefox stretches in block axis, shrink in inline
17:29:06 <plinss> present+
17:29:08 <fantasai> iank_: webkit stretch both axes
17:29:10 <fantasai> iank_: chrome ...
17:29:16 <fantasai> iank_: So what do we want to do here?
17:29:34 <fantasai> iank_: previously FF team strongly wanted shrink-to-fit here
17:29:58 <fantasai> Rossen_: anyone from FF?
17:30:13 <TabAtkins> As I said in the issue a few minutes ago, "every divergence that buttons make from a standard inline-block is unfortunate."
17:30:38 <fantasai> Rossen_: Do we shrink-to-fit in both axes, or stretch in both axes, to make behavior symmetric and consistent
17:30:42 <TabAtkins> Because it has been asserted quite confidently in the past by implementors that buttons were *not* replaced elements, and were fully described solely by inline-block behavior ^_^
17:30:58 <fantasai> dholbert: Don't have an answer atm, but will take a look
17:31:09 <Rossen_> q?
17:31:14 <drott> fantasai: tab and i figured that
17:31:24 <drott> fantasai: since webkit implements stretch on both axis
17:31:28 <drott> fantasai: that makes it web compatible
17:31:49 <drott> fantasai: [missed] you can always get the other behavior by switching alignment
17:31:50 <Rossen_> ack TabAtkins
17:31:54 <Rossen_> ack fantasai
17:31:57 <fantasai> TabAtkins: In the past, impl have said that buttons aren't replaced elements
17:32:08 <fantasai> TabAtkins: and fully described by inline/block behavior, so the more we can make that true the better
17:32:19 <fantasai> TabAtkins: having them stretch by default would make them match non-replaced
17:32:31 <fantasai> iank_: I'm fine either way, but historically FF folks have been very strong in their opinion wrt shrink-to-fit
17:32:42 <fantasai> Rossen_: OK, let's give dholbert some time to look through it
17:32:51 <fantasai> Rossen_: if we can resolve on this later on in the call, great, if not, bring back next week
17:33:04 <fantasai> Topic: [css-color] [css-color-adjust] Consider reversing the resolution of #3847
17:33:11 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6773
17:33:52 <fantasai> emilio: We made system colors compute to themselves because wanted them to react to color-scheme
17:34:11 <fantasai> emilio: but that's not behavior any agent has, and when you do that you get lacking contrast if color scheme changes but you didn't change the bgcolor
17:34:18 <fantasai> emilio: not quite clear to me what Blink is doing
17:34:37 <fantasai> emilio: but, computing system colors to the keywords themselves also causes complexity
17:34:47 <fantasai> emilio: with interpolation, issues open since we resolved that
17:34:52 <Rossen_> q?
17:34:54 <TabAtkins> q+
17:35:12 <fantasai> emilio: So can we undo that resolution?
17:36:04 <fantasai> TabAtkins: A couple of points emilio made are present today regardless
17:36:04 <Rossen_> ack TabAtkins
17:36:18 <fantasai> TabAtkins: e.g. complexity of interpolating color, currentColor resolves at used-value time
17:36:23 <fantasai> TabAtkins: exact same case for system colors
17:36:38 <fantasai> TabAtkins: also has a point about needing to set system colors in pairs, and yes, you do, and spec says you should always do that
17:36:47 <fantasai> TabAtkins: it's very easy to get messed up and have bad colors if you don't, in general
17:37:10 <fantasai> TabAtkins: if we compute system colors and computed value time, then whenever color-scheme changes, in particular if you go across any embedding boundaries, shadow boundaries, they'll be messed up as well
17:37:25 <fantasai> TabAtkins: they'll assume in light mode and responsibly use system colors, get wrong colors inheriting in
17:37:31 <fantasai> TabAtkins: so I think the current specced behavior is the best
17:37:48 <fantasai> TabAtkins: chrome's behavior is weird and inconsistent right now, but once matches spec, I think it will be reasonable behavior
17:37:55 <fantasai> TabAtkins: and won't save any complexity but changing it
17:37:58 <fantasai> s/but/by/
17:38:13 <fantasai> emilio: Not about setting colors in pairs, but about changing color scheme
17:38:20 <fantasai> emilio: if ...
17:38:46 <fantasai> emilio: if you make system colors compute to themselves, forced-color-adjust: preserve-parent-color is like forcing to resolve their values, which is pretty odd
17:38:50 <fantasai> emilio: we're landing workarounds...
17:38:55 <fantasai> emilio: I disagree that this doesn't introduce complexity
17:39:08 <alisonmaher> q+
17:39:09 <fantasai> emilio: preserve-parent-color is literally working around this behavior
17:39:57 <fantasai> TabAtkins: ppc is about forced-color-adjust, where we want SVG to be able to opt out of being forced-colored, but still be able to respond to system colors coming in
17:40:10 <fantasai> TabAtkins: We have plenty of SVG in the wild that want to respond to outside color and set some of their own colors as well
17:40:23 <fantasai> TabAtkins: to work in forced color mode, need some way to tell whether receiving system color vs other color
17:40:35 <fantasai> emilio: not true, FF behaves correctly right now [...]
17:41:22 <fantasai> alisonmaher: ppc was a workaround due to handling forced-colors mode, not about system colors computing to themselves
17:41:28 <Rossen_> ack alisonmaher
17:41:47 <fantasai> emilio: to me, both are related. If don't preserve ??? then can't at used value time
17:42:03 <fantasai> alisonmaher: in Chrome we do implement this workaround. We also haven't shipped system colors computing to themselves yet
17:42:28 <fantasai> alisonmaher: Essentially piggybacking on top of, have an implementation where it computes to itself, so workaround with impl that hasn't shipped yet
17:42:35 <fantasai> Rossen_: so building on the capability but not exposed?
17:42:36 <fantasai> alisonmaher: yeah
17:42:48 <Rossen_> q?
17:42:57 <fantasai> emilio: We define system colors to compute to themselves
17:43:10 <fantasai> emilio: you need to implement forced-colors at used value time and vice versa
17:43:22 <fantasai> emilio: complexity comes from making both forced colors and system colors compute at used value time
17:43:45 <drott> fantasai: if we don't make the system colors compute to themselves
17:43:57 <drott> fantasai: if you switch scheme, it won't have any effect - which is not expected
17:44:13 <fantasai> emilio: Let's say have a dark background and background is Canvas
17:44:23 <fantasai> emilio: if you just change color-scheme you get illegible text
17:44:32 <fantasai> dbaron: if they don't compute to themselves, you run a restyle
17:44:50 <drott> fantasai: if you have an element that is color-scheme dark, inside one with color-scheme light
17:45:00 <drott> fantasai: are you going to have light or dark? or what's happening inside?
17:45:10 <drott> fantasai: if you move it out, you'd expect it to stay on that
17:46:03 <fantasai> fantasai: but it inherits different resolve colors depending on parent color scheme
17:46:22 <fantasai> fantasai: to get colors you expect, you can't rely on system colors inheriting, have to re-declare them when declaring color-scheme
17:46:35 <Rossen_> q?
17:46:40 <TabAtkins> Form what I can tell, emilio, you're saying that if authors don't set colors in pairs, they can get bad results. Is that right?
17:46:58 <fantasai> emilio: need to restyle anyway, need to set at least the backgrounds, so can't rely on inheritance otherwise get broken behavior
17:47:39 <fantasai> emilio: always need to set in pairs, but even if you do, but if you change color-scheme without setting any color then behavior is broken if they compute to themselves
17:47:51 <fantasai> emilio: because changing only foreground color and bg color doesn't change because not inherited
17:48:30 <fantasai> Rossen_: Given the complexity of these different combinations and where Chromium implementation is, in its inconsistent state, I propose we continue to work on this issue in GH
17:48:30 <chris_> "Authors may also use these keywords at any time, but should be careful to use the colors in matching background-foreground pairs to ensure appropriate contrast, as any particular contrast relationship across non-matching pairs (e.g. Canvas and ButtonText) is not guaranteed."
17:48:46 <fantasai> Rossen_: and once more implementers as well as others have a stable conclusion, can bring it back for resolution
17:48:46 <chris_> https://drafts.csswg.org/css-color-4/#css-system-colors
17:48:55 <fantasai> Rossen_: going in circles here trying to define expected behaviors
17:49:02 <fantasai> Rossen_: as well as what everyone is talking about
17:49:10 <fantasai> emilio: Yeah, agree, I think we're talking past each other a bit
17:49:17 <fantasai> Rossen_: ok, well thanks for opening issue
17:49:18 <chris_> Also "The following system color pairings are expected to form legible background-foreground colors:"
17:49:22 <fantasai> Rossen_: let's move on to next issue
17:49:28 <fantasai> Topic: @color-profile to L5
17:49:35 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6765
17:50:05 <fantasai> lea: Custom color spaces have not gotten same implementer interest of other features in L4
17:50:15 <fantasai> lea: and complicate a lot of discussoins due to custom color spaces
17:50:24 <fantasai> lea: also had some ideas that depend on L5 features
17:50:29 <TabAtkins> q+
17:50:30 <fantasai> lea: so suggestion is to defer to L5
17:50:49 <fantasai> lea: but Tab raised that device-cmyl() depends on it
17:50:57 <fantasai> lea: which is implemented only in print impls
17:51:06 <fantasai> lea: Suggest is to also defer device-cmyk()
17:51:10 <chris_> q+
17:51:16 <fantasai> TabAtkins: I agree with this, and there's a lot of interesting things to work on here
17:51:17 <Rossen_> ack TabAtkins
17:51:25 <fantasai> TabAtkins: that could use time to bake without holding up L4
17:51:29 <fantasai> chris_: I also agree
17:51:31 <bradk> bradk has joined #css
17:51:38 <Rossen_> ack chris_
17:51:51 <fantasai> chris_: also have some feedback, have a descriptor called 'components' that doesn't appear to do anything because what it affects is in L5, so another reason to move
17:52:04 <fantasai> Rossen_: so proposed to move @color-profile and device-cmyk() to L5
17:52:13 <fantasai> RESOLVED: Move @color-profile and device-cmyk() to L5
17:52:45 <fantasai> Topic: [css-color-4] Expose Linear-light sRGB as CSS syntax?
17:52:52 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6087
17:53:04 <fantasai> chris_: Linear-light sRGB is sRGB without gamma function
17:53:08 <fantasai> chris_: already extended beyond 0 and 1
17:53:13 <fantasai> chris_: some hardware uses this to do HDR
17:53:19 <fantasai> chris_: used in WebGPU and Canvas
17:53:29 <fantasai> chris_: also SVG filters do all their work in this mode
17:53:40 <fantasai> chris_: We export the term for re-use, but don't expose it to authors
17:53:45 <Rossen_> q?
17:53:47 <fantasai> chris_: so question is do we want to do that
17:53:54 <fantasai> smfr: WebKit supports adding this
17:54:06 <fantasai> chris_: does anyone object?
17:54:20 <fantasai> chris_: Just notice that it has a much higher precision function than sRGB
17:54:27 <fantasai> chris_: so you will need a half-float to hold these values
17:54:54 <fantasai> RESOLVED: Add srgb-linear color space
17:55:33 <fantasai> Topic: [css-cascade-6] Strong vs weak scoping proximity
17:55:56 <fantasai> TabAtkins: Right now, scoping spec cascade-6 is intentionally ambiguous on exactly where scoping sits in cascade
17:56:20 <fantasai> TabAtkins: offers two options: less strong that specificity (just stronger than order of appearance) and another that's stronger that specificity
17:56:32 <fantasai> TabAtkins: Given it's currently ambiguous, makes difficult to do test implementation
17:56:41 <fantasai> TabAtkins: Would like to do a test implementation, and prefer weak scoping
17:56:58 <fantasai> TabAtkins: I've argued in the thread about why the weaker scoping is the better way to go, going for strong would be a mistake imho and make things less usable for authors
17:57:11 <fantasai> TabAtkins: but for the moment, I think we should at least currently resolve to go with weak scoping
17:57:14 <fantasai> TabAtkins: and revisit later
17:57:39 <fantasai> TabAtkins: fantasai said in issue, she believes that related features have been released to make a decision
17:57:45 <Rossen_> q
17:57:49 <fantasai> TabAtkins: that would delay scoping feature by a year or two
17:58:01 <fantasai> TabAtkins: and I don't think the input we'd get would be worth that level of delay
17:58:23 <Rossen_> ack fantasai
17:58:32 <drott> fantasai: no problem if chrome wants to go ahead and do prototyping of weak scoping
17:58:45 <drott> fantasi: exactly how it works will be fundamental to how css is used
17:59:03 <drott> fantasai: need to be diligent and figuring it out
17:59:14 <drott> fantasai: 6 months timeframe is reasonable for that
17:59:18 <TabAtkins> (I really, *strongly* think that going with "strong" scoping would be making a serious mess, but I argued that in volume in the thread already.)
17:59:21 <drott> fantasai: scoping feature is desired and useful
17:59:24 <Rossen_> +1 to fantasai point ^
17:59:35 <fremy> Is this discussed in any GitHub issue?
17:59:41 <drott> fantasai: more important to get it right, first time around - waiting 6months to a year is reasonable for the proprotion of this feature
18:00:11 <TabAtkins> fremy: Yes, in the github issue linked in the agenda and right here, a few lines up
18:00:25 <drott> fantasai: i suggest to resolve with sth like: "the WG is leaning towards weak proximity and thinks it's the right way for prototyping"
18:00:40 <fantasai> fantasai: but keep the issue open for discussion
18:00:48 <TabAtkins> (oh, it *hasn't* been linked)
18:00:53 <miriam> +1
18:00:54 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6790
18:01:18 <fantasai> RESOLVED: WG leans towards weak proximity at this time, and recommends this direction for prototyping to get more feedback
18:01:30 <fremy> It hadn't been linked indeed; this is why I was confused about it ^_^
18:01:43 <fantasai> Topic: Meeting Closed.
18:01:59 <Rossen_> Topic: end
18:02:13 <Rossen_> Zakim, end meeting
18:02:13 <Zakim> As of this point the attendees have been Rossen_, Morgan, smfr, jensimmons, fantasai, alisonmaher, oriol, miriam, faceless, bradk, dbaron, TabAtkins, dholbert, chris, argyle, lea,
18:02:16 <Zakim> ... GameMaker, chrishtr, plinss
18:02:16 <Zakim> RRSAgent, please draft minutes v2
18:02:16 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/10-css-minutes.html Zakim
18:02:18 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
18:02:22 <Zakim> Zakim has left #css
18:15:47 <gtalbot> gtalbot has joined #css
20:38:46 <dholbert> dholbert has joined #css
22:42:45 <geheimnis`> geheimnis` has joined #css
23:05:40 <vit> vit has joined #css