15:55:05 <RRSAgent> RRSAgent has joined #css
15:55:05 <RRSAgent> logging to https://www.w3.org/2022/09/15-css-irc
15:55:08 <Zakim> RRSAgent, make logs Public
15:55:09 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:56:11 <heycam> heycam has joined #css
15:58:43 <myakura> myakura has joined #css
16:00:14 <foo> foo has joined #css
16:00:35 <Morgan> Morgan has joined #css
16:01:05 <Rossen_> ppl on the call - can you hear the room?
16:01:13 <GameMaker> GameMaker has joined #css
16:01:15 <Morgan> yes!
16:01:26 <duga> duga has joined #css
16:01:49 <JakeA> http://wpt.live/css/css-sizing/aspect-ratio/replaced-element-028.html - this test asserts that `aspect-ratio` does not apply to broken images. All browsers pass this test. However, I think the intent of the test is that `aspect-ratio` should be ignored because the failed image should display as `inline`. However, that is not true in Chrome and Safari (it's like `inline-block`. So, by passing this test, it feels like Chrome and Safari are doing it
16:01:49 <JakeA> wrong. Can anyone confirm?
16:01:55 <alisonmaher> alisonmaher has joined #css
16:02:12 <smaug> smaug has joined #css
16:02:45 <dbaron> Present+
16:02:52 <kevers> present+
16:02:53 <Morgan> present+
16:02:54 <flackr> flackr has joined #css
16:02:55 <GameMaker> Present+
16:02:55 <alisonmaher> present+
16:02:57 <dandclark> present+
16:02:58 <flackr> present+
16:03:05 <heycam> present+
16:03:14 <miriam> present+
16:03:24 <Rossen_> present+
16:03:40 <florian> present+
16:03:49 <JakeA> present+
16:03:55 <heycam> Scribe: Cameron
16:03:59 <heycam> ScribeNick: heycam
16:04:06 <TabAtkins> present+
16:04:55 <castastrophe> castastrophe has joined #css
16:05:18 <fremy> fremy has joined #css
16:05:37 <tantek> tantek has joined #css
16:05:47 <bkardell_> bkardell_ has joined #css
16:05:56 <jondavis> jondavis has joined #css
16:05:58 <smaug> present+
16:06:02 <jondavis> present+
16:06:05 <iank_> present+
16:06:13 <castastrophe> present+
16:07:23 <ydaniv> ydaniv has joined #css
16:07:41 <rachelandrew> present+
16:07:52 <prushforth> prushforth has joined #css
16:07:56 <emilio> present+
16:08:37 <iank_> Ian Kilpatrick, Google
16:08:48 <rego_> Manuel Rego, Igalia
16:08:51 <prushforth> present+
16:08:51 <rego_> present+
16:08:55 <andreubotella> andreubotella has joined #css
16:09:50 <prushforth> Peter Rushforth, Natural Resources Canada
16:10:15 <drott> present+
16:10:53 <heycam> Topic: Approaches for dispatching highlight pointer events
16:11:00 <heycam> dandclark: problem we're trying to solve is making custom highlights interactives
16:11:09 <heycam> ... for scenarios like custom spell check, annotation popups over words
16:11:18 <heycam> ... a few months ago I came to the WG with a proposal for adding eventing for highlights
16:11:26 <heycam> ... when tehre's a pointer event, a highlight, we get a first crack at it
16:11:31 <heycam> ... dispatch events at highlights in priority order
16:11:39 <heycam> ... if none preventDefault() it, we give it to the normal DOM element
16:11:40 <florian> github: https://github.com/w3c/csswg-drafts/issues/7513
16:11:47 <heycam> ... goal here would be to allow non-coordinating highlight libraries to do reasonable things
16:11:51 <Rossen_> q?
16:12:05 <heycam> ... if you have say a spell check library, and a annotation library running, stopping propagation of an event would avoid two popups at once
16:12:18 <heycam> ... normal event propagation would allow this coordination without the 2 librariers knowing about each other
16:12:25 <heycam> ... however this is somewhat complicated, there was a simpler competing proposal
16:12:42 <heycam> ... providing "highlightsFromPoint", put a click event on the body, when there's a click pass the coordinates into this function
16:12:53 <heycam> ... some discussion for coming up with schemes where the events could then be dispatched in a manual way to highlights
16:13:04 <heycam> ... discussed in the issue, not a great way for non-coordinated libraries to coordinate an event loop
16:13:20 <heycam> ... that said, I think it's maybe worth pursuing this as a MVP API
16:13:21 <ri> ri has joined #css
16:13:27 <heycam> ... seems like a useful addition to the platform
16:13:48 <heycam> ... if in practice there turns out to be issues with non-coordinating highlight libraries working together, we then go back to pursue highlighting events in addition to that
16:13:53 <heycam> ... CSS.highlights.highlightFromPoint()
16:13:56 <heycam> ... some issues with shadow DOM
16:14:05 <TabAtkins> Seems useful to me. The coordination issue still needs to be addressed, but I don't think that blocks this as a useful ability. I like the API discussed.
16:14:09 <heycam> ... first let's get some feedback from the group. is this worth it as an initial step?
16:14:12 <Rossen_> q?
16:14:22 <flackr> +1 MVP of highlights from points seems useful even if we add events
16:14:40 <heycam> TabAtkins: seems useful to me. agree the coordination issue needs to be resolved, but that shouldn't block this useful primitive
16:14:48 <heycam> ... if this blocks general abilities, I still think it's worthwhile
16:14:52 <heycam> ... I like the API shape in the proposal
16:14:58 <emeyer> emeyer has joined #css
16:15:00 <TabAtkins> s/this blocks/this unblocks/
16:15:05 <emeyer> present+
16:15:06 <fremy> present+
16:15:23 <heycam> olli: I agree this is probably good enough for now
16:15:32 <heycam> ... might need to think about shadow DOM for now, but we can tweak the proposal for that
16:15:35 <Rossen_> q?
16:15:57 <heycam> s/olli/smaug/
16:16:02 <heycam> dandclark: seem to have agreement on adding this
16:16:07 <heycam> ... would be good to dig into the shadow DOM issue
16:16:18 <heycam> ... does it go on DocumentOrShadowRoot?
16:16:29 <heycam> Rossen: let's resolve on adding the API, if we still have time at the end of this slot, we can come back to this issue
16:16:55 <dbaron> (My initial reaction is that DocumentOrShadowRoot is a good location because then it lives next to elementFromPoint, which it is similar to.)
16:17:03 <heycam> RESOLVED: Add the highlightFromPoint() API to CSS.highlights or DocumentOrShadowRoot
16:17:37 <heycam> Topic: Publish css-contain-1
16:17:40 <heycam> https://lists.w3.org/Archives/Member/w3c-css-wg/2022JulSep/0192.html
16:17:57 <heycam> florian: two years ago we published a rec of css-contain-1
16:18:01 <heycam> ... since then we've made some editorial tweaks
16:18:05 <heycam> ... 3 candidate changes
16:18:24 <heycam> ... if you remember the process 2020, we can make normative changes in a rec through a process of annotating them as editorial in the rec, then if they're editorial we can republish without permission
16:18:34 <heycam> ... and use that to highlight things we want to change, withotu changing them yet
16:18:39 <heycam> ... we have a 3rd change in an ED for a while
16:18:39 <florian> no open issues: https://github.com/w3c/csswg-drafts/labels/css-contain-1... (full message at https://matrix.rivoal.net/_matrix/media/r0/download/rivoal.net/zZelGrIxxwxaJWwwGfouobbM)
16:18:43 <heycam> ... status of the spec is good. no open issues
16:18:50 <heycam> ... DoC all are resolved or deferred
16:18:56 <heycam> ... I wrote an implementation report for each of these 3 changes
16:19:04 <heycam> ... we have exhaustive tests, passing in at least 2 browsers, sometimes in 3
16:19:18 <heycam> ... I think we should republish this rec, mark these 3 changes as proposed changes, which will trigger AC review
16:19:38 <Rossen_> q?
16:19:39 <heycam> ... then we can ask the director (or his delegates) to get to an actual rec while the patent reviews etc. are going, horizontal review, etc.
16:19:47 <heycam> ... these are minute changes, so I don't think anything will come up
16:20:10 <heycam> ... asking for WG approval to republish css-contain-1 as a Rec with these 3 changes highlighted in it as proposed changes
16:20:27 <heycam> ... there is a level 2 of css-contain, and I have checked that they are in sync
16:20:58 <heycam> RESOLVED: Republish css-contain-1 as a Recommendation
16:21:22 <heycam> RESOLVED: ... with the 3 changes marked as proposed changes
16:21:40 <heycam> Topic: highlight pseudos and non-applicable properties
16:21:43 <heycam> github: https://github.com/w3c/csswg-drafts/issues/7591
16:22:39 <heycam> fantasai: look at the example in the issue
16:22:48 <heycam> ... it's showing a ::highlight with a text-shadow with an offset expressed as 1em
16:23:03 <heycam> ... there's a parent selection pseudo with a font-size:69px, and the actual element has a font-size:42px
16:23:13 <heycam> ... font-size does not apply to ::highlight, so the actual font is going to be 42px
16:23:19 <karlcow> karlcow has joined #css
16:23:37 <heycam> ... the question is, when we're computing the value of 1em, are we using the font-size assigned to the selection even though it doesn't apply, and cannot apply, or do we ignore that font-size and use the value from the originating element?
16:23:40 <dandclark> q+
16:23:44 <heycam> s/::highlight/::selection/
16:23:46 <karlcow> present+
16:23:54 <heycam> fantasai: implementations do various things. Blink uses the initial value, which is 16px
16:24:05 <heycam> ... the question is what do we want to do?
16:24:15 <kzms2> present+
16:24:19 <heycam> ... using the actual font-size would give the most expected results from the author perspective
16:24:24 <heycam> dandclark: I agree with that
16:24:25 <Rossen_> ack dandclark
16:24:33 <emilio> q+
16:24:34 <heycam> ... definitely seems the most intuiitive thing here, i.e. the font-size of the originating element
16:24:43 <heycam> ... anything else seems strange to me
16:24:54 <Rossen_> ack emilio
16:24:59 <heycam> emilio: we have precedent for this
16:24:59 <dholbert> dholbert has joined #css
16:25:09 <heycam> ... things like ::placeholder already ignore a bunch of properties, and they do so by ignoring the declarations
16:25:14 <heycam> ... so as if the font-size declaration wasn't there
16:25:21 <heycam> ... I htink that's what's being proposed here, and I think that's reasonable
16:25:42 <heycam> fantasai: proposed resolution is we use the actual, effective font-size (and font-family, etc.) here
16:25:51 <heycam> emilio: can we word it as declarations of not supported properties are ignored instead?
16:26:06 <heycam> fantasai: it inherits from the parent selection
16:26:11 <heycam> emilio: that's trickier then
16:26:18 <heycam> fantasai: we can say both things
16:26:30 <heycam> emilio: I think that's weird
16:26:37 <heycam> ... I'd rather keep it simple and ignore the declarations
16:26:49 <heycam> astearns: if we ignore the declarations, and just do the normal inheritance, even though the value is ignored, don't we get what we want?
16:26:52 <heycam> fantasai: you get the initial font-size
16:27:03 <heycam> emilio: or the root element's font-size
16:27:13 <heycam> ... weird to add another source of inputs here
16:27:24 <heycam> Rossen: if we don't do that what makes most sense?
16:27:36 <heycam> ... on one hand we have the default 16px
16:27:39 <heycam> ... that seems less useful
16:27:46 <heycam> astearns: don't understand why we get the initial font-size
16:27:51 <heycam> ... the pseudo is on an element that has a font-size
16:27:55 <heycam> fantasai: but it doesn't inherit from that element
16:28:05 <heycam> ... ::highlight inherits from the parent element's selection
16:28:24 <heycam> ... we rewired highlight inheritance like this
16:29:12 <heycam> Rossen: the intiial font-size, is that because you simply end up with the root size?
16:29:13 <heycam> fantasai: yes
16:29:42 <Rossen_> ack dbaron
16:29:45 <heycam> dbaron: I was just thinking about the desired behavior here
16:30:10 <heycam> ... if you have a selection with text-shadow that's got a 1em in it, and that selection crosses elements with different font sizes, do you actually expect that the shadow has a different offset or spread as the selection crosses those elements?
16:30:18 <heycam> fantasai: maybe, maybe not
16:30:22 <heycam> ... depends on what you were aiming for with the effect
16:30:31 <heycam> ... I think having it be consistent across them is not unreasonable
16:30:36 <heycam> Rossen: what do we do for outline?
16:30:38 <heycam> fantasai: that doesn't inherit
16:31:01 <heycam> dbaron: one of the other factors here is that a principle about selection styling is that you shouldn't get different results depending on where the selection starts
16:31:07 <JakeA> q+
16:31:31 <heycam> ... so if your selection starts further up ancestor, which has a different font-size, versus a narrow selection scoped to a descendant with a different font size, those descendants shouldn't render differently
16:31:37 <heycam> fantasai: I think both proposals follow that principle
16:31:41 <Rossen_> ack JakeA
16:31:49 <heycam> JakeA: is currentColor an issue here? for the same reason?
16:32:04 <heycam> fantasai: currentColor inherits as its own keyowrd, and resolves on each element
16:32:13 <heycam> ... for highlights it has some special behavior
16:32:38 <heycam> ... I think maybe it's just on the color property? it doesn't look as its parent, it looks at its originating element
16:32:49 <heycam> Rossen: I think following David's principle, that principle is satisfied
16:32:50 <CSSWG_LogBot> CSSWG_LogBot has joined #css
16:32:56 <heycam> ... from the user's PoV this is arguably what you want
16:33:07 <heycam> ... to Jake's point, if we model this on the same way color / currentColor works ...
16:33:18 <heycam> fantasai: color inherits from the parent selection, not the originating element
16:33:28 <heycam> ... currentColor on all other properties than color, looks at color
16:33:42 <heycam> ... normally color:currentColor is like inherit, but for highlights it takes the originating element's color
16:33:59 <heycam> ... so if you have a highlight where you're only doing say underlining, it gives you a way to "use the original color"
16:34:02 <heycam> ... rather than parent's color
16:34:18 <heycam> Rossen: so for em resolution
16:34:24 <heycam> ... seems like we could have the same behavior
16:34:30 <JakeA> q+
16:34:42 <fantasai> heycam: If you set font-size:inherit...
16:35:00 <fantasai> heycam: analog is, you're using the currentColor keyword on a property other than color, is the analogy is for having em values in some other property
16:35:16 <fantasai> heycam: if you used em values in the font-size property, that's more of an analog to using currentColor in color property
16:35:17 <Rossen_> ack JakeA
16:35:21 <heycam> JakeA: when you talk about the originating element of the highlight
16:35:28 <heycam> ... what happens in the case where the highlight spans multiple elements?
16:35:35 <heycam> fantasai: multiple pieces of highlight, each has an originating element
16:36:18 <heycam> ... if we consider dbaron's comment, making font relative values always resolve against the initial values seems to be most consistent with the principle
16:36:26 <heycam> Rossen: I'd argue from a user PoV that makes no sense
16:36:45 <heycam> ... [something about highlight sizes]
16:36:54 <heycam> fantasai: the size of the highlight doesn't change
16:37:03 <heycam> dbaron: I tend to be in favor of what Elika just proposed
16:37:09 <miriam> q+
16:37:10 <heycam> ... the alternative seems like it would be hard to implement
16:37:29 <fantasai> proposal was that, since having consistent resolution from 1em is not unreasonable in many cases, and is already implemented in Blink, then we should resolve on that
16:37:32 <heycam> ... and I don't think we've heard any good use cases for the alternative, i.e. do people really have demands for em offsetted text-shadow that varies on elements
16:37:50 <heycam> miriam: would it be closer to author intent to use root ems instead of browser default?
16:37:56 <heycam> emilio: that's the behavior you get when you ignore declarations
16:37:58 <Rossen_> ack miriam
16:38:01 <heycam> fantasai: I think the spec is a bit unclear on that
16:38:09 <heycam> ... so whatever we decide here is how we'll clarify it
16:38:48 <heycam> Rossen: hearing consensus forming around Elika's proposal, with using root ems intead of the initial value of font-size
16:38:50 <heycam> ... any other proposals?
16:39:18 <heycam> dandclark: should this be more general than font-size?
16:39:22 <heycam> ... lots of other properties that don't apply to highlights
16:39:36 <heycam> fantasai: we're applying it to all font properties, taken from the root
16:39:50 <heycam> ... all of the decalrations on pseudos that are defined not to apply are ignored
16:40:49 <heycam> fantasai: proposed resolution: declarations on highlight pseudos defined as not applied are ignored, and font properties are all taken from the root element
16:41:19 <heycam> RESOLVED: Properties that don't apply on highlight pseudos are ignored
16:41:59 <heycam> fantasai: I think we say that for the ::selection on the root element (and therefore inheriting down into other highlights), all of the font settings are taken from the root element
16:42:27 <heycam> RESOLVED: for the highlight pseudos on the root element, all of the font settings are taken from the element
16:43:04 <heycam> Topic: @image rule for manipulating images
16:43:07 <heycam> github: https://github.com/w3c/csswg-drafts/issues/6807
16:43:59 <heycam> TabAtkins: this is a request for feedback and possible WD, precised details are being discussed on the thread
16:44:06 <heycam> ... this is a request for a way to manipulate images directly in CSS
16:44:12 <heycam> ... right now you can do a handful of things directly in CSS
16:44:18 <heycam> ... certain repetitions with background properties
16:44:27 <GameMaker> GameMaker has joined #css
16:44:40 <heycam> ... but anything more complex, running a filter on it, opacity, etc. your only choice is to use a separate image, or to put it on a declarative element and then apply CSS properties to that element
16:44:57 <heycam> ... this is trying to split the different, and allow existing existing effecfts (transforms, filters), directly in a CSS image
16:45:08 <heycam> ... rough approach is an @image rule, which provides a doubel dashed name
16:45:26 <heycam> ... a bunch of descriptors, which takes a src image, then others which are copies of other CSS properites that do useful things
16:45:34 <heycam> ... currently only supporting things you can already do to elements
16:45:43 <heycam> ... once defined, you could use this image in CSS
16:45:50 <heycam> ... image(--foo)
16:46:05 <Rossen_> q?
16:46:08 <heycam> q+
16:46:24 <Rossen_> ack heycam
16:46:31 <fantasai> heycam: Alternative approach is to slam all of these filtering and transforms into the image() function itself
16:46:42 <fantasai> heycam: if you need to re-use that, put it all into a custom property
16:46:47 <fantasai> heycam: have you thought about that?
16:46:47 <heycam> TabAtkins: I don't believe there's a great reason to go one way or the other
16:46:58 <heycam> ... back in the day, using it in an image() function you'd need to repeat it
16:47:02 <heycam> ... but with variables it's not a huge deal now
16:47:33 <heycam> ... some bits of functionality like image layering have been discussed, but more widely as pulling in SVG's filter capabilities via nested at rules
16:47:38 <heycam> ... having them be consistent in approach would be nice
16:47:47 <heycam> ... but now that I bring that up, it could still be done using CSS functions
16:47:59 <heycam> ... it would be a matter of what we find more convenient to do, or more natural
16:48:05 <JakeA> q+
16:48:07 <heycam> ... don't think there's a huge way to go one way or the other
16:48:12 <Rossen_> ack dbaron
16:48:18 <heycam> dbaron: could you talk briefly about how sizing of these images works?
16:48:20 <heycam> ... looks like there's some sizing related properties in there
16:48:29 <heycam> ... transforms and filters which might have sizing implementations
16:48:33 <karlcow> karlcow has joined #css
16:48:34 <heycam> TabAtkins: you have a width/height property
16:48:40 <heycam> ... that's the natural width/heihgt of the produced image
16:48:44 <heycam> ... scaling etc. would be purely visual effects
16:48:51 <andreubotella> q+
16:48:55 <heycam> ... it would scale it within the bounds of the width/height that's already been provided
16:49:01 <Rossen_> ack JakeA
16:49:07 <heycam> JakeA: for blurring a low quality image as a placeholder
16:49:18 <heycam> ... that's difficult with filters now, because it blurs the edge as well
16:49:24 <heycam> ... here you want to recognize the edge and not blur the transparency into it
16:49:33 <heycam> ... so it works a bit more like backdrop-filter
16:49:40 <Rossen_> ack andreubotella
16:49:53 <heycam> andreubotella: could you use such an @image rule in the src property?
16:50:02 <heycam> ... if you already have declared an image, then you want to apply some further transformations to that?
16:50:30 <heycam> ... and for the current properties, it seems like you could apply a set of properties to multiple images
16:50:39 <heycam> TabAtkins: the exact answer to that depends on what we want to define
16:50:48 <heycam> ... being able to put a generated image in as the source of a new generated image is reasoanble
16:51:09 <ydaniv> q+
16:51:12 <heycam> ... whether that gets rasterized then transformed, as if it's an independent image, or these transformations are additively appended to the list of existing transformations in some intelligent fashion? no opinion
16:51:23 <heycam> ... both have pros/cons. simplicity on one side, understandability
16:51:31 <heycam> ... avoiding rasterization effects
16:51:37 <heycam> ... both seems potentially reasonable
16:51:42 <heycam> ... can discuss those
16:52:02 <heycam> andreubotella: thinking also maybe not having it rasterized, that might limit the properties we could add to @image rules
16:52:18 <heycam> TabAtkins: I think everythign we've discssed so far in the thread is compatible with just holding it as a scene graph
16:52:30 <heycam> ydaniv: might be some advantage to have this rasterized beforehand
16:52:34 <Rossen_> ack ydaniv
16:52:41 <heycam> ... if you're just setting the properties outside the at rule, you could have them animated
16:52:59 <heycam> ... then if you want to do further animations on the element, then have the browser apply all of these at the same time every frame, could be heavy for the browser to handle
16:53:08 <heycam> ... so maybe this could be some sort of performance boost
16:53:49 <heycam> ... another thing that might be way off, if you're thinking about syntax, having this for replaced images, object manipulation, that could be useful
16:54:08 <heycam> ... so not just for background-image, <image> values, but use the same manipulations on replaced elements like straight on an <img> element
16:54:30 <heycam> TabAtkins: right now you can take any replaced element and put properties on it
16:54:48 <heycam> ... but you want to be able to run these on the underlying image itself, and still be displayed in the bounds of the image element? so apply a rotate to the source image?
16:55:19 <heycam> ydaniv: I want to optimize for having the src already rasterized, then if I'm rotating the image outside, then the browser doesn't have to handle rasterizing every frame
16:55:29 <heycam> ... what you're saying is another use case which is also valuable
16:55:39 <Rossen_> ack dbaron
16:55:39 <Zakim> dbaron, you wanted to talk about ordering
16:55:48 <heycam> dbaron: Andreu's comment made me think about another set of questions about the ordering of these operations
16:56:01 <heycam> ... in CSS, a bunch of these things are properties where the order that they apply in is defined by our processing model
16:56:13 <heycam> ... the relative ordering we apply opactiy, filter, transform, etc. on a single element is defined by CSS's processing model
16:56:41 <heycam> ... one thought is that re being able to nest the output of one of these as the source of another, that's probably quite useful, since sometimes you want to apply these things in a differetn order than how CSS's processing model works
16:56:53 <heycam> TabAtkins: os the same descriptor multiple times in different fashions
16:56:55 <heycam> s/os/or/
16:57:25 <heycam> dbaron: maybe falling back to that processing model isn't the right thing here? for this rule, the graphical operations maybe shouldn't be order independent?
16:57:30 <heycam> ... so the order of the descriptors matters
16:57:41 <heycam> TabAtkins: if you have them in an order, that implies you should be able to repeat: rotate, blur, rotate
16:57:46 <heycam> ... first, object model issues
16:57:59 <heycam> ... also, that would run into our forward compat fallback ability
16:58:10 <heycam> ... where you can say something twice and ignore the first, unsupported value
16:58:18 <heycam> ... but I like the way you are thinking
16:58:25 <heycam> ... having this order be controllable is probably a great idea
16:58:30 <Rossen_> q?
16:58:31 <emilio> q+
16:58:41 <Rossen_> ack emilio
16:58:47 <heycam> emilio: that kind of issue disappears if you add the operations in the image() function
16:59:01 <heycam> TabAtkins: yes, it removes the fact taht ordering and repetition is ap roblem
16:59:09 <heycam> ... now support is an all or nothing for the entire graph
16:59:30 <heycam> ... on the other hand, if an image transform isn't supported, and you are trying to rely upon it, you probably do want the whole thing to fail
16:59:36 <heycam> ... so that is an argument in favor of a function
16:59:39 <heycam> q+
17:00:07 <emilio> heycam: I realized that there might be a semantic difference between image() and the at rule
17:00:09 <Rossen_> ack heycam
17:00:21 <emilio> ... each of those are a different image
17:01:10 <emilio> ... is there any situation where having the image defined in the at-rule lets you have a single place where you can do image manipulations, where with image() you'd need to apply the transform to all uses of the image() function
17:01:19 <emilio> ... it's probably not an issue, I don't think they can express different things
17:01:39 <emilio> TabAtkins: being able to say that one in an at-rule there's an efficiency arg to be made there
17:01:40 <heycam> TabAtkins: how to animate an at rule is an open question
17:01:47 <heycam> ... how to animate a function is already a reasonably solved problem
17:01:52 <heycam> ... match up lists, animate individual parameters
17:02:43 <heycam> TabAtkins: does the WG feel this is OK, or objectiosn to the approach in general?
17:02:55 <heycam> fantasai: my main concern is prioritization wrt other things we're doing
17:03:00 <heycam> ... other than that doesn't seem terrible
17:03:04 <heycam> Rossen: from a use case approach, it's fine
17:03:12 <heycam> fantasai: definitely needs a lot more work
17:03:18 <heycam> Rossen: that's like most other work we take on
17:03:21 <heycam> fantasai: this is not a small task
17:03:33 <heycam> Rossen: assuming Mia and others will be contributing to this?
17:03:36 <heycam> TabAtkins: I'm shepherding this
17:03:54 <andreubotella>  /s/Mia/Lea/
17:03:55 <heycam> Rossen: acknowledge this adds more work to the group, but I'm hearing support for the use case and approach
17:04:02 <heycam> ... so I'm personally OK with this
17:04:04 <fantasai> s/Mia/Lea/
17:04:18 <heycam> TabAtkins: do we want this added to images 5, or is it larger enough to be split out?
17:04:20 <heycam> fantasai: what else is in images 5?
17:04:23 <heycam> Rossen: almost nothing
17:04:39 <heycam> fantasai: current images is images-4. images-5 is just an ED, don't think there's anything even in it
17:04:50 <heycam> TabAtkins: just want to know if it should be merged into the totality of the images spec
17:04:58 <nigel> nigel has joined #css
17:05:37 <heycam> RESOLVED: Accept @image and add it to css-images-5
17:09:15 <TabAtkins> Topic: end
17:09:16 <dizhang> dizhang has joined #css
17:09:16 <nigel> nigel has joined #css
17:14:38 <PaulG> PaulG has joined #css
17:15:51 <nigel_> nigel_ has joined #css
17:20:11 <nigel_> nigel_ has joined #css
17:30:23 <andreubotella> andreubotella has joined #css
17:32:11 <fantasai> Topic: CSS-APA Joint Meeting
17:32:30 <chris> chris has joined #css
17:32:43 <khush_> khush_ has joined #css
17:32:45 <fantasai> scribenick: fantasai
17:32:48 <argyle> argyle has joined #css
17:32:54 <hober> present+
17:32:55 <Rossen_> Rossen_ has joined #css
17:32:59 <argyle> present+
17:33:02 <PaulG> present+
17:33:05 <chris> present+
17:33:07 <fantasai> Rossen_ does introductions
17:33:20 <khush> present+
17:33:23 <fantasai> and reminds everyone of requirements for testing and masking
17:33:59 <dholbert> present+
17:34:00 <fantasai> present+ Janina Saika, co-chair
17:34:03 <matatk> matatk has joined #css
17:34:11 <boris> present+
17:34:15 <matatk> present+
17:34:16 <Lionel_Wolberger> Lionel_Wolberger has joined #css
17:34:24 <Lionel_Wolberger> present+
17:34:48 <eeeps> eeeps has joined #css
17:35:04 <PaulG> Paul Grenier
17:35:06 <NeilS> NeilS has joined #css
17:35:07 <Lionel_Wolberger> Lionel Wolberger
17:35:11 <Lionel_Wolberger> Janina Sajka
17:35:17 <matatk> Matthew Atkinson
17:35:21 <matatk> present+
17:35:24 <fantasai> Elika J. Etemad
17:35:25 <matatk> present+ Janina
17:35:29 <fantasai> present+
17:35:33 <matatk> APA's agenda: https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2022#CSS_.26_APA_Joint_Meeting
17:35:36 <NeilS> present+
17:35:38 <florian> Florian Rivoal, Invited Expert
17:35:58 <fantasai> [Rossen reviews the agenda]
17:36:06 <dholbert> Daniel Holbert
17:36:20 <fantasai> Rossen_: Anything else to add?
17:36:34 <fantasai> Subtopic: CSS APA Liaison
17:36:47 <fantasai> Janina: Pleading with this group to help us out
17:37:01 <fantasai> ... Years ago were doing great with Amy
17:37:07 <fantasai> ... Tried on our end to find a new liaison
17:37:21 <fantasai> ... Many of you are from relatively large corporations, probably have some junior staff you want to develop into more effective participants
17:37:30 <dizhang> dizhang has joined #css
17:37:33 <fantasai> ... if you think they have interest in accessibility, we'll train them up for you
17:37:48 <fantasai> ... but we are desperate, having a formal liaison really makes this relationship effective
17:39:06 <fantasai> [discussion of possible liaisons]
17:39:18 <chris> q+
17:39:25 <fantasai> Subtopic: Contrast Ratio
17:39:32 <chris> github: https://github.com/w3c/csswg-drafts/issues/7730
17:39:35 <fantasai> matatk: not proposing to resolve all issues right now
17:39:55 <fantasai> ... wanted to use our F2F time to get background
17:40:04 <fantasai> ... what's the use case for this function?
17:40:07 <Rossen_> ack chris
17:40:08 <fantasai> chris: Dropped link to the issue
17:40:12 <nicole> nicole has joined #css
17:40:15 <fantasai> ... where I gave an introduction to what we want to do here
17:40:27 <fantasai> ... if you just have a single stylesheet, no variables, just light mode, don't need anything special
17:40:32 <fantasai> ... everything is constant
17:40:47 <fantasai> ... but if you have theming and customization, and stylesheets merged from multiple teams
17:40:51 <fantasai> ... it will work out for you
17:40:56 <fantasai> ... previously, this was all done by eye
17:41:04 <fantasai> ... they chose contrast by eye, threw through a checker to be sure
17:41:13 <argyle> also, user's bring preferences to the page: prefers-contrast (less, more, etc)
17:41:14 <fantasai> ... here, not necessarily have human intervention
17:41:17 <fantasai> ... but need to know that it will check out
17:41:39 <fantasai> matatk: I thought you as the author still have to give colors to choose from and isn't that deterministic
17:41:43 <fantasai> ... but you said it would be from variables
17:41:51 <fantasai> ... wouldn't you still have to know which custom properties would be applicable?
17:41:57 <fantasai> chris: yes, and the list that you give is in priority order
17:42:04 <fantasai> ... also one of the open issues is allowing that list to be empty
17:42:16 <fantasai> ... and if empty, it gives you a color: either white or black, whichever more contrasty
17:42:18 <iank_> note - something these lists colors are generated from a user provided image for example.
17:42:29 <fantasai> ... but if you want to pick a target contrast, then willl look for that
17:42:45 <fantasai> chris: other big issue open atm is WCAG2 has a contrast algorithm which gives a lot of false positives and false negatives
17:42:49 <fantasai> ... and we want to do btter
17:43:00 <fantasai> ... I've implemented a bunch of contrast algos in JS so ppl can play with it
17:43:04 <chris> https://colorjs.io/docs/contrast.html
17:43:15 <fantasai> matatk: As side project, I had to write a functio nthat gives white or black from bgcolor
17:43:18 <fantasai> ... so that's very helpful
17:43:27 <fantasai> ... we'll follow the discussions and offer what advice we can
17:43:58 <fantasai> janina: WCAG's color contrast rule is problematic in many ways
17:44:07 <fantasai> ... including that some ppl don't do well with very high contrast, as you noted
17:44:25 <fantasai> chris: It used to point to obsolete draft of sRGB, now it's updated
17:44:39 <fantasai> janina: Plan to be smarter in 3, but quite a ways out, so time to get it smarter
17:44:44 <fantasai> ... would be willing cooperators in that
17:45:00 <Rossen_> q?
17:45:31 <fantasai> Subtopic: Content Module
17:45:54 <fantasai> matatk: Adapt TF is working on, for decades, been through coda and aria and now become its own TF
17:46:08 <fantasai> ... what we're trying to do is to facilitate adaptations being made for pages to help ppl with cognitive and learning disabilities
17:46:20 <fantasai> ... as well as ppl who are busy, or have a migraine, or other temporary barrier
17:46:32 <fantasai> ... split and focus on different things, but some overlap with CSS to talk about
17:46:39 <fantasai> ... Adapt as a whole, got some transformative tech in there
17:46:56 <fantasai> ... but query we have specifically for you relates to potential overlap with what some of Adapt is doing and some things you can do with Media Queries
17:47:07 <fantasai> ... most important thing to say about Adapt is, it solves many problems, but all very similar
17:47:17 <fantasai> ... it attaches machine-readable metadata at the element level
17:47:19 <fantasai> ... to adapt
17:47:31 <fantasai> ... by adding a little bit of metadata, we can allow the machine to make a lot of enabling adaptations on the part of the user
17:47:46 <fantasai> ... I have a demo here, that we can use to discuss
17:47:52 <fantasai> [shares screen]
17:48:01 <fantasai> matatk: This is a page that is a distracting sign-up form
17:48:11 <fantasai> ... one thing aapt spec does is to simplify things for ppl easily distracting
17:48:18 <fantasai> ... for some ppl can be annoyance, for others can completely derail ppl
17:48:31 <fantasai> ... really critical, e.g. someone with dementia, sokmeone with a severe migraine
17:48:41 <fantasai> ... might need to pare this page down to be absolute core of what's required to sign up for this service
17:48:49 <fantasai> ... I've made this page as a dmo
17:49:09 <fantasai> ... got things like an animated logo, countdown timer
17:49:15 <fantasai> ... severa form fields to fill out, reset and submit
17:49:18 <fantasai> ... a marquee at the bottom
17:49:32 <fantasai> ... of course if you want to adapt this nowadays can use things liek prefers-reduced-motion
17:49:38 <fantasai> ... here the image and marquee stop moving
17:49:46 <Judy> Judy has joined #css
17:49:47 <fantasai> ... but maybe we want to go further than this
17:49:53 <fantasai> ... so attributes in the page allow filtering
17:49:58 <fantasai> ... one is to remove sensory distractions
17:50:03 <fantasai> ... and it's taken away the logo and the marquee
17:50:12 <fantasai> ... I can also say I only want things of medium or critical importance
17:50:17 <fantasai> ... and this case we lose some of the form fields
17:50:23 <fantasai> ... that weren't as important
17:50:38 <fantasai> ... if I say only critical things, now also lost the reset button, all I have is the heading the clock and two form fields and a submit form
17:50:44 <fantasai> ... example of what can be done with adapt
17:50:53 <fantasai> ... Question is should we be doing more of this with Media Queries?
17:50:58 <florian> q+
17:51:12 <fantasai> ... My feeling is that MQ are great for providing alternative content, but Adapt is also removing content that is distracting
17:51:19 <fantasai> florian: I think this is an interesting and related problem
17:51:20 <Rossen_> ack florian
17:51:30 <hober> q+
17:51:30 <fantasai> ... encourage you to think about whether author should provide all the alternatives
17:51:36 <fantasai> ... and let the UA make choices depending on context
17:51:49 <fantasai> ... or if you want the UA to tell the author what mode you're in, and make adaptations
17:52:01 <fantasai> florian: Let me give an example outside this field. Discussing whether to have MQ for network bandwidth
17:52:11 <fantasai> ... if it's too low, maybe want to swap in lower-resolution images
17:52:37 <fantasai> ... but suppose you enter a tunnel you end up switching to loading the lower-res images, then reload higher-res images
17:52:44 <fantasai> ... better to let UA make smart decisions
17:52:53 <PaulG> q+
17:52:54 <fantasai> florian: For this case, if you want UA to make smart dynamic choices, provide alternatives and let UA choose
17:53:05 <fantasai> ... if best for author to decide, then MQ is more appropriate
17:53:14 <Rossen_> ack hober
17:53:30 <fantasai> hober: My comment is similar vein, I was immediately reminded that many browsers have a feature called "reader mode" or something like that
17:53:42 <fantasai> ... where the user can make all the "junk" go away and read the content of the page
17:53:52 <fantasai> ... one of the reasons this works as a browser feature is that it's somewhat adversarial
17:53:59 <fantasai> ... not a feature that the website author is cooperating with
17:54:09 <fantasai> ... if you have some content that is ad-supported, ads on the Internet can be very distracting
17:54:12 <fantasai> ... images, sounds, etc.
17:54:27 <fantasai> ... but the page is not going to tell the browser that this is a distraction. They want to get paid
17:54:34 <dlibby> dlibby has joined #css
17:54:47 <fantasai> ... Florian noted on an important thing, on some level you're going to have to think of "remove the distractions" feature as something we do to the page, not something that the page wnats you to do
17:54:56 <fantasai> ... could be that there's both, maybe some amount of author opt-in to some of this
17:55:05 <fantasai> ... but what you're going to want is AT or something to impose this state on the page
17:55:06 <fantasai> ... without its cooperation
17:55:23 <fantasai> PaulG: 2 comments, first having the author provide hints for media queries
17:55:32 <fantasai> ... can work in a lot of contexts, especially where context is required
17:55:39 <fantasai> ... e.g. in investment banking, UA shouldn't be guessing what to show
17:55:58 <ydaniv> ydaniv has joined #css
17:56:00 <florian> s/switching to loading the lower-res images, then reload higher-res images/switching to loading the lower-res images even though the high-res images were already loaded, then reload higher-res images when you exit the tunnel/
17:56:05 <fantasai> ... Ad situation, have the agency to tip for service or to donate to links of our choice, if a site chose to mark their ads as optional and I chose to opt in, I'm helping to get paid
17:56:12 <fantasai> ... but prefers-less-captilism MQ
17:56:23 <fantasai> ... with MQ, fact that they apply to page and not individual components, I'm worried about that
17:56:34 <chris> +1 to prefers-less-capitalism
17:56:37 <florian> s/better to let UA make smart decisions/For such cases, better to let UA make smart decisions than expose a mode change to the author/
17:56:37 <fantasai> ... worried about extensibility in the future when society chances, user needs change, how long does it take to get MQ added to UAs
17:56:43 <fantasai> ... how long does it take to permeate to author use
17:56:48 <Rossen_> q?
17:56:48 <fantasai> ... is there another mechanism we should be looking at
17:56:59 <Rossen_> ack PaulG
17:57:03 <Rossen_> ack fantasai
17:57:11 <heycam> fantasai: if this is a sort of markup, where the UA chooses from alternatives, and show/hide content depending
17:57:16 <Rossen_> q+
17:57:21 <heycam> ... having standardaized markup is fine, but I think that makes sense to hook it up to a MQ
17:57:28 <heycam> ... UA styles could hook that up
17:57:39 <heycam> ... if you're choosing between alternatives based on user's preference, then as a MQ it makes most sense
17:57:49 <heycam> ... can be queried in JS
17:57:55 <heycam> ... any kind of adaptation can be made based on that
17:58:02 <heycam> ... the example of image loading Florian gave doesn't really apply here
17:58:05 <heycam> ... it's about time lag in that case
17:58:12 <heycam> ... not a factor here
17:58:25 <heycam> ... here, if you're switching modes you're want to switch modes
17:58:35 <heycam> ... I agree with Tess some amount of stuff will need to be handled by the UA itself
17:58:53 <florian> q?
17:59:02 <heycam> ... as far as how long it takes to add a MQ, if the user is somehow expressing a preference, and we need to expose it to the page, whether automatically based on metadata in thep age, or having a MQ, the browser has to do something to make that happen
17:59:07 <heycam> ... so once we have a framework for a MQ, adding values to it won't take long
17:59:20 <heycam> ... lastly, you are adding more information about the user, exposed to the page, no matter how you do this
17:59:24 <heycam> ... if you add/remove content, the page can know about
17:59:30 <heycam> ... if you have MQ, it can also see that
17:59:46 <heycam> ... there's privacy implications to exposing this, but the page will know regardless of which technique we use
17:59:54 <matatk> q?
18:00:06 <heycam> ... there's more fingreprinting surface, more complexity for the author. if it's too complex for the author they won't use it
18:00:11 <florian> q+
18:00:19 <fantasai> Rossen_: most of the things I wanted to mention already captured
18:00:22 <fantasai> ... demo page is great, thanks
18:00:36 <fantasai> ... I was hoping we can see an issue opened with CSSWG that we can consider at least simplification for MQ
18:00:49 <fantasai> ... can see something like prefers-simplification
18:00:59 <fantasai> ... and have authoring that helps identify what's critical medium and low
18:01:06 <fantasai> ... this is a great example where the ?? of the MQ can help
18:01:13 <fantasai> ... destruction is something we have discussed in the past
18:01:19 <fantasai> ... more to discuss in the TAG
18:01:24 <fantasai> s/destruction/distraction/
18:01:35 <fantasai> ... It's the most contentions, I don't know if possible to satisfy with MQ
18:01:43 <fantasai> ... but maybe open some issues
18:01:55 <andreubotella> andreubotella has joined #css
18:01:55 <fantasai> matatk: Can I show a 2-minute demo?
18:01:58 <Rossen_> ack Rossen
18:02:10 <Rossen_> ack florian
18:02:20 <fantasai> florian: I agree with fantasai the example I gave doesn't apply here, but you gave us a small sample of bigger project
18:02:35 <fantasai> ... is this a MQ, the weird scenario doesn't apply here, but that's a criteria I would use to think about it
18:02:42 <fantasai> ... but so far that wouldn't apply and media query seems appropriate
18:02:49 <fantasai> Rossen_: We have at this point crossed the halfway mark in our time
18:03:00 <Lionel_Wolberger> The simplification link, https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html
18:03:14 <GameMaker> GameMaker has joined #css
18:03:42 <fantasai> matatk: Problems that we're trying to solve are for many users helpful, and for some users absolutely critical
18:04:02 <fantasai> ... they aren't necessarily the issues that may be of highest priority if you look at content usability guidelines
18:04:08 <fantasai> ... because some of them are very bespoke to content involved
18:04:16 <fantasai> ... but issues we're trying to solve are the ones that are solveable by the machine
18:04:22 <fantasai> ... with just a little bit of metadata at the element level
18:04:31 <fantasai> ... so collection of problems that we're solving, and that's the technique we're using to solve them
18:04:42 <fantasai> Rossen_: when you say solved by the machine, can you define that for us?
18:04:49 <fantasai> matatk: We expect this would be a UA adaptation to the content
18:04:58 <fantasai> ... and by UA what we mean for the forseeable future, a browser extension
18:05:06 <fantasai> ... might be many browser etensions for different groups of users
18:05:08 <fantasai> ... because it varies a lot
18:05:21 <PaulG> user agent or assistive technology (AT)?
18:05:26 <fantasai> ... so really encourage anyone to make an extension to cover any bit of the spec, using any technique appropriate for their user
18:05:35 <fantasai> ... UA would be modifying the DOM on behalf of the user
18:05:41 <fantasai> ... because it's coded for a particular group
18:05:48 <fantasai> ... going off of markup that the author provides
18:05:52 <fantasai> ... to provide hints
18:05:53 <PaulG> q+
18:06:03 <PaulG> q-
18:06:07 <fantasai> matatk: Let me show this demo
18:06:29 <fantasai> PaulG: Clarify that matatk was saying UA, would be assistive technology. Doesn't ened to be in the AX tree
18:06:33 <fantasai> ... examples of plugins and extensions
18:06:44 <fantasai> ... this can be prototyped with markup, and help make a media query
18:07:04 <fantasai> matatk: Here's an exmaple, created by Lisa Sieman
18:07:16 <fantasai> ... it does have a button in the page, although if this was an extension, it would be in the browser UI
18:07:23 <fantasai> ... this is a clothese retailer with a contact form, many fields
18:07:39 <fantasai> ... navigation across top of page, lots of categories
18:07:48 <fantasai> ... when I press personalize page, get some visual preferences applied
18:07:54 <fantasai> ... slightly fewere categories
18:07:59 <fantasai> .. one fewer form field in the form
18:08:03 <fantasai> ... and then step down to even fewer
18:08:24 <fantasai> ... One of the things in our discussions is, some people say "I might not want this simplification, might want a different simplification"
18:08:36 <fantasai> ... e.g. Sports/Leisure rather than Men/Women
18:08:54 <fantasai> ... MVP doesn't handled, might have less control over how filtered but just does get filtered
18:09:03 <fantasai> ... want to make sure that filtering uses interest in the future
18:09:18 <fantasai> ... some sites have done demographic data, can alter markup based on info they know about the user
18:09:26 <fantasai> ... can do even with this markup
18:09:44 <fantasai> Rossen_: Next steps, so we have closure onthis issue
18:09:58 <fantasai> ... I encourage you to open issues and propose specific candidates for media queries
18:10:12 <fantasai> ... and then you have people here woul would help you reason about how that can progress through CSS
18:10:28 <fantasai> Subtopic: Work on Navigation
18:10:42 <fantasai> matatk: Context, I have a link to minutes from Sapporo 2015 TPAC
18:10:45 <matatk> https://www.w3.org/2015/10/30-apa-minutes.html
18:11:11 <fantasai> matatk: We saw mention of this in your new charter, work on navigation, wondering if it's a continuation of that conversation or something totally different?
18:11:34 <fantasai> matatk: It seemed to be discussing issues around DOM order vs visual order
18:11:43 <fantasai> ... controlling that through CSS
18:11:51 <fantasai> ... or is it about some new research on spatial navigation
18:12:12 <astearns> The charter may be referencing https://drafts.csswg.org/css-nav-1/
18:12:18 <chris> proposed new charter https://w3c.github.io/charter-drafts/2022/css-2022.html
18:12:24 <fantasai> astearns: I think charter might be referencing the spatial navigation draft
18:12:54 <heycam> there is also this paragraph:
18:12:54 <chris> "In addition to the above catch-all reference to horizontal review which includes accessibility review, this Working Group will work with the Accessible Platform Architectures Working Group to work on accessible navigation which needs to be addressed coherently across multiple modules, address accessibility issues related to the features of individual modules, and develop new CSS modules to address accessibility use cases where appropriate."
18:12:55 <heycam> > In addition to the above catch-all reference to horizontal review which includes accessibility review, this Working Group will work with the Accessible Platform Architectures Working Group to work on accessible navigation which needs to be addressed coherently across multiple modules, address accessibility issues related to the features of individual modules, and develop new CSS modules to address accessibility use cases where appropriate.
18:13:19 <fantasai> Rossen_: here's my 30s review of 2015 minutes interpretation
18:13:41 <fantasai> ... my recollection was that we had an extensive conversation which took place right before we introduced a lot of the order properties for Flexbox and Grid
18:13:51 <heycam> fantasai: must have been after, grid was published as CR
18:14:00 <fantasai> Rossen_: perhaps motivated by that
18:14:05 <fantasai> s/grid/flexbox
18:14:16 <fantasai> ... we have DOM that has an order, applying styles that change the order
18:14:29 <fantasai> ... whether tabbing or using AT to move spatially in the page, order is usually that of the DOM, and visual doesn't match the content
18:14:33 <fantasai> ... that was the basis of that conversation
18:14:50 <fantasai> ... at the time our position was that CSS has a strong recommendation for creating accessible content based on DOM and follows DOM order
18:14:55 <fantasai> ... fantasai has some good posts about this
18:14:58 <fantasai> ... and that was then
18:15:12 <fantasai> ... since then we've done some work on spatial navigation, which was motivated by other media such as screen navigation on TV
18:15:18 <fantasai> ... where you have a directional pad for input
18:15:28 <fantasai> ... and some effort to make that work in general, regardless of the page layout
18:15:48 <fantasai> ... These were the two efforts, and I think they're slightly separate
18:15:52 <fantasai> ... in terms of efforts we were chasin
18:15:55 <duga> duga has joined #css
18:16:00 <fantasai> ... but I wouldn't say they're mutually exclusive
18:16:01 <florian> q+
18:16:33 <fantasai> matatk: Things you've been working on, this ED is dated 17th of May last year, is it still active work?
18:16:40 <fantasai> florian: I'm editor of that document
18:16:43 <Rossen_> ack florian
18:16:48 <fantasai> ... it got to a reasonable degree of completeness, but it has since stalled
18:16:54 <fantasai> ... there hasn't been significant effort for quite some time
18:17:00 <fantasai> ... I still think it would be a good idea
18:17:06 <rachelandrew> q+
18:17:10 <fantasai> ... but given insufficent amount of attention, can't say it's an ongoing path forward atm
18:17:13 <matatk> q?
18:17:13 <fantasai> ... for now it is stalled
18:17:20 <matatk> q+
18:17:23 <Rossen_> ack rachelandrew
18:17:32 <fantasai> rachelandrew: Separately to that issue, there was a proposal that I raised
18:17:43 <fantasai> ... which was to create a way for authors to opt into the display order
18:17:51 <fantasai> ... a lot of interest from devs to do that
18:17:59 <fantasai> ... because although I think document order is generally what should be using
18:18:10 <fantasai> ... there are cases where, e.g. when content is rearranged by MQ
18:18:16 <fantasai> ... also have some layout methods that jumble the order
18:18:20 <fantasai> ... such as masonry
18:18:26 <fantasai> ... so a lot of discussion in that issue
18:18:39 <fantasai> ... This is definitely something that needs to be solved
18:18:45 <fantasai> ... authors want to do the right thing
18:18:49 <heycam> https://github.com/w3c/csswg-drafts/issues/7387
18:18:51 <fantasai> ... we've given them this ability, and saying don't use it,is not great
18:18:56 <fantasai> ... would really like to see this solved in a good
18:18:59 <fantasai> s/good/good way
18:19:00 <PaulG> "stalled" that's a shame. It seems like a great mechanism for authors to accommodate input development and a welcomed replacement for roving tab index keyboard handling JS.
18:19:05 <Rossen_> ack matatk
18:19:14 <fantasai> matatk: Thanks for that, Rachel
18:19:28 <fantasai> ... my question is, the work on spatial navigation was motivated by things like smart screens webTV etc
18:19:34 <fantasai> ... and as Rachel said, with new layouts
18:19:43 <fantasai> ... I'm wondering, given that the spatial navigation spec isn't a REC yet
18:19:52 <fantasai> ... what do you see devs doing in the wild to try to provide this, or not provided?
18:20:09 <fantasai> rachelandrew: I think that we're seeing people either not doing things that they would like to do for lots of users because of a11y issues
18:20:14 <fantasai> ... and others who are not caring and do terrible things
18:20:26 <fantasai> ... as you see more visual tools that allow drag-and-drop layouts, easy to do now with grid
18:20:35 <fantasai> ... those completely disconnect the author from the document, and will create situations like this
18:20:42 <fantasai> ... I just feel like this is an issue that we have to solve
18:20:49 <fantasai> ... not say "they should follow document order", I don't think that's realistic
18:21:01 <fantasai> ... at the moment ppl who want to do the right thing do not have good options
18:21:07 <fantasai> ... what's a good user experience?
18:21:11 <fantasai> ... creates problems for navigation
18:21:18 <fantasai> ... so I want to give ppl a good way to do this
18:21:21 <Rossen_> ack fantasai
18:21:32 <emilio> fantasai: I think we need to pursue both of these things
18:21:38 <emilio> ... they're not exclusive and both are needed
18:21:52 <heycam> fantasai: going through a linear order is a bit different
18:21:53 <emilio> ... spatial nav has different requirements from doc order
18:22:04 <emilio> ... we should accommodate both
18:22:05 <matatk> q+ Janina
18:22:22 <matatk> ack Janina
18:22:22 <Rossen_> ack j3m
18:22:22 <emilio> ... sometimes I want to navigate physically down, and sometimes I want to go to the next thing
18:22:26 <fantasai> Janina: Thanks for suggesting both are important, I agree
18:22:43 <fantasai> ... previous and  next as we have them in HTML, can be inadequate, and publishing as long has a more elaborate hierarchical model
18:22:50 <fantasai> ... easiest to illustrate if you consider a play
18:22:55 <fantasai> ... multiple acts, and in each act there are scenes
18:23:03 <fantasai> ... you may have to take a lot of steps to get in linear order
18:23:18 <fantasai> ... but if you can adjust your granularity, going to scene 3 in act 4
18:23:24 <matatk> q+
18:23:28 <fantasai> ... then you get there far more quickly
18:23:35 <Rossen_> q?
18:23:36 <fantasai> ... they've had that in publishing forever, came out of talking books
18:23:51 <fantasai> ... been effective in most cases, works very well
18:24:03 <fantasai> ... would be clever if we could have cookbooks that automatically readjust such as what's top level, what's next level, etc.
18:24:13 <fantasai> ... based on types of cuisine or whatever
18:24:34 <heycam> fantasai: I agree having a hierarchy would make that easier to manage
18:24:55 <PaulG> q+
18:25:02 <fantasai> Rossen_: This is handled by many ATs, can move by e.g. headings etc. But only works so long as document has good structure
18:25:04 <Rossen_> ack matatk
18:25:19 <fantasai> matatk: If you're not using AT, in the tranditional sense, and just a keyboard-only user
18:25:22 <fantasai> ... and there are many such users
18:25:26 <fantasai> ... then they do have a lot of work
18:25:36 <fantasai> ... keyboard-only users only have tab and scrollling and that's it
18:25:45 <fantasai> ... what Janina said about granularity of linear navigation
18:25:57 <fantasai> ... Remember an app where the developer had made hierarchical, tree-based order
18:26:16 <fantasai> ... initial navigation was across tab panesl, and then can enter into each panel and navigate through there
18:26:24 <fantasai> ... They had to take it out because it was unfamiliar and not documented well
18:26:31 <fantasai> ... it would be great to have a standard conventional mechanism for it
18:26:54 <fantasai> PaulG: Especially in light of what we were talking about before, of ripping out content based on user's request for less of it
18:27:03 <fantasai> ... this presents a difficult challenge for devs to get keyboard navigation correct
18:27:21 <fantasai> ... when predicted display is more complex, effect of both author's content and users preference
18:27:33 <fantasai> ... maybe dangling keyboard handlers with no next, or traps that appear out of nowhere
18:27:34 <Rossen_> ack PaulG
18:27:40 <fantasai> ... need to consider chances of authors really messing this up
18:27:51 <fantasai> ... so I think this spec is on its way and would like to get involved ot make sure we have those mechanisms for the future
18:28:01 <fantasai> ... and love to replace every intance of tabindex I have
18:28:36 <fantasai> Subtopic: :role() pseudo-class
18:28:51 <jcraig> scribe-
18:29:05 <jcraig> s/scribe-//
18:29:13 <fantasai> Rossen_: Can someone summarize this issue?
18:29:18 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/3596
18:30:03 <fantasai> matatk: Is this a shortcut for the attribute selector? Seems to be syntactic sugar
18:30:12 <fantasai> fremy: There are some differences, handles roles that are implied as well
18:30:21 <TabAtkins> Yeah, handling implicit roles is the big point
18:30:22 <fantasai> PaulG: Map to computed role from Chrome's implementation
18:30:34 <fantasai> fremy: could do it yourself with correct attribute, but simplified way
18:30:44 <fantasai> heycam: is computed role only a function of role and tag name, or more things?
18:31:07 <fantasai> matatk: Landmarks, I maintain an extension to navigate, and where they are in teh document determines what they are
18:31:16 <fantasai> ... e.g. if header/footer are scoped to page you have page header/footer
18:31:21 <fantasai> ... but inside an article, not the same landmarks
18:31:35 <fantasai> ... not that simple, so I can understand why if browser does the matching it would be useful
18:31:52 <fantasai> PaulG: What's the status of it?
18:32:20 <fantasai> Rossen_: There's a group discussing this with ARIA
18:32:47 <fantasai> TabAtkins: Several years back we resolved to add this, to expose computed roles to selectors
18:32:59 <fantasai> ... several years after that, I raised this issue saying that I was supposed to draft it
18:33:02 <fantasai> ... still haven't written it
18:33:10 <fantasai> ... if any concerns about it, please file issues/comments
18:33:19 <fantasai> ... otherwise this is just something that needs to be written by me at some point, because I signed up for it
18:33:30 <fantasai> Rossen_: With this, we are out of time
18:33:39 <PaulG> PaulG has left #css
18:33:40 <fantasai> Rossen_: thanks APA for joining us
18:33:50 <fantasai> Janina: Thanks for your hospitality
18:33:59 <fantasai> Rossen_: please do engage on the issues
18:34:04 <fantasai> ... we love to work with ou
18:34:12 <fantasai> ... if you find a liaison, would love to work with them
18:34:14 <fantasai> s/ou/you/
18:34:23 <fantasai> matatk: File issues is the theme for this week!
18:34:27 <fantasai> <br duration=10m>
18:35:44 <astearns> topic: break
18:36:14 <castastrophe> castastrophe has joined #css
18:40:13 <duga> duga has joined #css
18:40:48 <karlcow> karlcow has joined #css
18:41:20 <jcraig> re: :role() selector... I may have proposed it early on but we abandoned the idea when implementation discoveries made it apparent it would be way more effort that the benefit justified
18:41:27 <jcraig> My comment here: https://github.com/w3c/csswg-drafts/issues/3596#issuecomment-460135566
18:41:46 <jcraig> gist: It’s not impossible, but it’s quite a bit more than anyone was willing to commit to.
18:43:58 <CSSWG_LogBot> CSSWG_LogBot has joined #css
18:49:04 <fremy> ScribeNick: fremy
18:49:08 <Rossen_> Rossen_ has joined #css
18:49:21 <fremy> fantasai: TabAtkins can you project the test case?
18:49:27 <fremy> TabAtkins: yes
18:49:53 <fremy> fantasai: this page shows a scrollable box which is an inline-block
18:50:15 <Rossen_> Topic: Not clamping baseline position when scrollable overflow gives weird results
18:50:22 <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/7660
18:50:42 <fremy> fantasai: sorry, inline-flex not inline-block
18:50:56 <fremy> fantasai: the issue is that the text is bigger than the box itself
18:51:11 <fremy> fantasai: so, the reste of the text is aligned to a line that is beyond the box itself
18:51:18 <tante> tante has joined #css
18:51:20 <fremy> fantasai: which doesn't make much sense
18:51:29 <fremy> fantasai: the proposal is to clamp the baseline to the border box
18:51:30 <tantek> present+
18:51:53 <fremy> Rossen_: do we also do this in the other direction?
18:52:04 <fremy> fantasai: good point, we probably should do it in this direction as well
18:52:28 <fremy> asterns: what is the effect that this would do?
18:52:32 <florian> q+
18:52:38 <fremy> Rossen_: align "text" to the bottom of the scrollable box
18:52:51 <Rossen_> ack florian
18:52:56 <fremy> dbaron: this would be based based on the initial scroll position?
18:52:58 <matatk> matatk has joined #css
18:52:58 <fremy> fantasai: yes
18:53:07 <fremy> florian: what about overflow: clip?
18:53:14 <fremy> TabAtkins: probably the same?
18:53:20 <fremy> iank_: well
18:53:25 <emilio> q+
18:53:26 <andreubotella_> andreubotella_ has joined #css
18:53:44 <fremy> iank_: probably we don't want that because we resolved that overflow:clip should not have any effect on the layout
18:53:56 <emilio> q-
18:53:56 <fremy> iank_: there is already some margin clipping anyway
18:54:03 <fremy> dbaron: I agree, clip should not apply
18:54:06 <emilio> +1 to dbaron :)
18:54:07 <emeyer> q+
18:54:08 <fremy> emilio: I concur as well
18:54:24 <dizhang> dizhang has joined #css
18:54:25 <fremy> TabAtkins: currently, the reverse issue exists
18:54:25 <dbaron> s/clip should not apply/overflow:clip should not do anything different because overflow:clip shouldn't influence layout/
18:54:29 <Rossen_> ack emeyer
18:54:46 <heycam> q+
18:54:54 <fremy> rob: am I correct that the baseline can not be above or beyond the scrollable area?
18:54:59 <fremy> fantasai: yes, correct
18:55:08 <fremy> rob: then, sure, no objection
18:55:11 <fantasai> s/rob/emeyer/
18:55:12 <fantasai> s/rob/emeyer/
18:55:27 <Rossen_> q
18:55:31 <heycam> q-
18:55:45 <fremy> dholbert: the correct rendering would be that the border would align with the text
18:55:54 <fremy> dholbert: but we don't want to do that, right?
18:55:55 <iank_> q+
18:56:08 <fremy> Rossen_: yes, otherwise we would need to take a dependency on the font size etc...
18:56:22 <fremy> Rossen_: so, the proposed resolution is to clamp the baseline
18:56:27 <fremy> Rossen_: any other comment?
18:56:27 <dholbert> clarifying my question: I was asking if the border-top of the scrollable thing would align with the baseline of the text. And the answer was yes, it would
18:56:38 <dholbert> (in the "reverse scenario")
18:56:40 <fremy> iank_: can we keep last-baseline separated from this?
18:56:48 <fantasai> s/keep/keep inline-block/
18:56:52 <fremy> iank_: I don't want to change the margin behavior yet
18:56:53 <Rossen_> ack iank_
18:57:02 <fremy> TabAtkins: I'm fine with this for now
18:57:18 <fremy> Rossen_: any objection?
18:57:39 <fremy> RESOLVED: baselines of a scrollable container should be clamped to the scrollable area
18:57:52 <Rossen_> Topic: How to determine the last baseline of a flex container with different alignment groups.
18:57:59 <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/7660
18:58:34 <fremy> iank_: blink would like to implement last-baseline alignment
18:58:41 <fremy> iank_: (by blink I mean me)
18:58:54 <fremy> iank_: but how do we find out what is the last baseline is a question
18:59:13 <fremy> iank_: currently, anything that uses a baseline alignment should be counted in
18:59:20 <fremy> iank_: if none are, you fallback
18:59:28 <fremy> iank_: there are groups however
18:59:43 <fremy> iank_: some might be first-baseline aligned, some might be last-baseline aglined, etc...
18:59:53 <fremy> iank_: how do you choose? it's the question
19:00:04 <fremy> iank_: maybe TabAtkins can elaborate
19:00:19 <fremy> TabAtkins: I'm projecting the example on the screen
19:00:43 <fremy> fantasai: if we consider a flex container with multiple elements with baseline alignment
19:00:51 <fremy> fantasai: we want the baseline of these elements
19:01:06 <fremy> fantasai: but if you have last-baseline alignment only
19:01:15 <Rossen_> q?
19:01:18 <fremy> fantasai: should that count as the first baseline of that group?
19:01:22 <fremy> fantasai: or should we bail out?
19:01:34 <fremy> fantasai: and if you have both types of alignment in the first row
19:01:42 <fremy> fantasai: these might not align with each other
19:01:49 <fremy> fantasai: how do you pick in that case?
19:02:01 <fremy> dbaron: I would like to propose something
19:02:16 <dholbert> FWIW firefox's rendering changes when I inspect in devtools, so we've clearly got a bug here :)
19:02:23 <fremy> dbaron: maybe the solution is that if you look for a first baseline, first-baseline-aligned things should be used first
19:02:30 <fremy> dbaron: and vice versa for last baseline
19:02:36 <fremy> iank_: yes, I think most people agree with that
19:02:44 <Rossen_> ack dbaron
19:02:49 <fremy> iank_: an issue is what you do next
19:03:16 <fremy> fantasai: if a page has a navigation bar
19:03:22 <fremy> fantasai: and it's last-baseline aligned
19:03:27 <heycam> q+
19:03:33 <fremy> fantasai: if most items have one line, but one has two
19:03:42 <fremy> fantasai: if I align something with this, what behavior do we want?
19:03:59 <fremy> fantasai: we can either use the last-baseline that every item aligns to
19:04:11 <fremy> fantasai: or the first baseline of each of these items
19:04:23 <fremy> fantasai: I would posit that the shared baseline is a better guess for what the author might want
19:04:38 <fremy> iank_: to repeat that
19:04:46 <fremy> iank_: if we are trying to find the last baseline
19:04:54 <dbaron> I think what fantasai said seems reasonable as long as when there are *two* shared baselines, we pick the one being exported.
19:04:55 <chrishtr> Note: discussion not recorded to issue 7387 yet..
19:04:57 <fremy> iank_: we would pick the first baseline as the last baseline if that's all we got
19:05:13 <fremy> iank_: and if we don't even have that, then we fallback to the last baseline of the bottom item
19:05:14 <dholbert> q+
19:05:19 <fremy> fantasai: yes
19:05:22 <fremy> iank_: reasonable
19:05:34 <fremy> heycam: would not exporting a baseline be reasonaoble?
19:05:43 <fremy> fantasai: we will always do that
19:05:44 <Rossen_> ack heycam
19:05:55 <fremy> fantasai: but right now we synthetize one
19:05:59 <fremy> fantasai: that is rarely desirable
19:06:03 <fremy> heycam: isn't that enough?
19:06:17 <fremy> fantasai: it's better to use the other baseline, for the author
19:06:29 <fremy> iank_: the final fallback could be the first or last item
19:06:41 <fremy> iank_: I agree that the middle step is ok
19:06:57 <fremy> dholbert: I'm not sure we don't always the fallback
19:07:13 <dbaron> github: https://github.com/w3c/csswg-drafts/issues/7641
19:07:14 <fremy> dholbert: I'm worried that we could get a weird telescope effect
19:07:25 <heycam> s/telescope/stair-step/
19:07:26 <fremy> dholbert: things will be lined up
19:07:32 <fremy> dholbert: but in opposite directions
19:07:38 <fremy> dholbert: which might not look good, actually
19:07:46 <fremy> dholbert: the synthetic is at least "logical"
19:08:02 <fremy> fantasai: iank_ proposed to use the lower last baseline and the hightest first baseline etc...
19:08:35 <fremy> fantasai: but if you have five items that are 1, 2 or 3 lines tall; whether or not your item is at the top or the bottom, it won't look very reasonaoble
19:08:59 <fremy> fantasai: if you align with the shared baseline, the alignment will look reasonable I think
19:09:19 <fremy> dholbert: but if you are looking for a first baseline and there is none
19:09:19 <Rossen_> q?
19:09:42 <fremy> dholbert: I don't understand why the special handling is gonna make things substantially better
19:09:55 <fremy> fantasai: if you are aligning one line of text, it's more sensible
19:10:00 <Rossen_> ack dbaron
19:10:02 <Rossen_> ack dholbert
19:10:18 <fantasai> if you're asking for baseline alignment, you want to align to text, not to fall back to a box edge, if possible
19:10:26 <fremy> iank_: my comment is that if you are trying to find the last baseline, you could get the lowest in the first row
19:10:31 <fremy> iank_: this is kinda how tables work
19:10:41 <fremy> iank_: but the two solutions I most like
19:10:57 <fremy> iank_: is either use the first baseline item then use the fallback
19:11:08 <fremy> iank_: or fantasai's solution where there is a middle step
19:11:16 <fremy> iank_: both solutions look reasonable
19:11:20 <fremy> Rossen_: and if you had to pick?
19:11:26 <fremy> iank_: no strong opinion
19:11:42 <fremy> iank_: the first one is a bit simpler to implement because its has two levels only
19:12:15 <fremy> fantasai: if we are looking into multi-rows grid to align
19:12:38 <fremy> fantasai: if you don't have the middle step, you will get worse results
19:12:55 <florian> q+
19:12:59 <fremy> fantasai: because fewer things will align with each other
19:13:05 <dholbert> q+
19:13:07 <Rossen_> ack florian
19:13:12 <fremy> florian: flex items contain text
19:13:25 <fremy> florian: so it makes sense for them to have both
19:13:35 <fremy> florian: but the container only has one line
19:13:41 <dholbert> no, flex containers can have last-baseline as well as first-baseline aligned items
19:13:43 <dholbert> and can export both
19:13:45 <dholbert> (I think)
19:13:55 <fremy> florian: so I can't think of of any other relevant baseline is than the shared baseline
19:14:14 <fremy> iank_: you can look into it in two ways
19:14:29 <fremy> iank_: the question is that the fallback approach
19:14:47 <fremy> fantasai: in the issue, iank_ suggested also to look for the lowest or highest across all items
19:14:55 <fremy> fantasai: this would give even better results
19:15:06 <fremy> iank_: yes, this is another option I would accept
19:15:13 <fremy> iank_: I'm just worried a bit about the compat risk
19:15:19 <Rossen_> ack dholbert
19:15:52 <fremy> dholbert: when finding the first/last baseline, would what you described be the canonical algorithm?
19:15:54 <fremy> iank_: yes
19:16:05 <fremy> dholbert: then I would worry about compat too, I think
19:16:37 <fremy> dholbert: for the grid case, I agree that in most cases what fantasai proposes makes more sense
19:16:58 <fremy> dholbert: but when you have one flexbox with one item, which is a common case, which would be confusing I think
19:17:18 <fremy> dholbert: we could find the baseline of that first item
19:17:30 <fremy> iank_: it's an edge case
19:17:39 <fremy> iank_: you can get the correct behavior by doing nothing
19:17:48 <fremy> iank_: so, why would you do it if that's not what you want?
19:17:54 <fremy> iank_: I'm thus not very concerned
19:17:57 <Rossen_> ack dbaron
19:18:33 <fremy> dbaron: after listening to fantasai's explanation, I'm reasonably convinced that we want the fallback levels
19:18:47 <fremy> dbaron: because some things might need to be changed later in the design
19:19:08 <fremy> dbaron: otherwise, if you change things in one place, you have to change consistently, which might be difficult
19:19:25 <fremy> dbaron: the middle step enables to change only locally, and get things to work anyway
19:19:39 <fremy> iank_: seems like most people are aligning with fantasai's solution
19:19:45 <fremy> iank_: anyone would object to that?
19:20:02 <fremy> Rossen_: sounds like you will have to do the more complex implementation :)
19:20:11 <fremy> iank_: yes...
19:20:20 <fremy> Rossen_: ok, any objection?
19:21:07 <fremy> fantasai: proposed resolution: when taking the baseline of a row of item, we check a shared first baseline, then a shared last baseline, then the first baseline of the first item
19:21:12 <florian> +1
19:21:21 <fremy> fantasai: (everywhere we can get away with it without compat issues)
19:21:28 <antonp> antonp has joined #css
19:22:00 <dbaron> s/taking the baseline of a row of item/taking the first baseline of a row of items/
19:22:01 <fremy> iank_: the only additional warning is that you can have a first-baseline aligned thing in the first-baseline group, but that seems fine
19:22:10 <dbaron> (and vice-versa for the last baseline)
19:22:23 <fremy> Rossen_: ok, no objection,
19:22:36 <fremy> RESOLVED: when taking the baseline of a row of item, we check a shared first baseline, then a shared last baseline, then the first baseline of the first item
19:22:49 <Rossen_> Topic: How is the last-baseline of a multi-col determined?
19:22:56 <fremy> RESOLVED: (and vice-versa for the last baseline)
19:23:01 <matatk> matatk has joined #css
19:23:08 <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/7639
19:23:39 <fremy> iank_: for multicolumns elements, we currently take the baseline of the first column
19:23:52 <fremy> iank_: and implementations don't look for a last baseline
19:23:58 <fremy> iank_: maybe we should?
19:24:09 <fremy> iank_: but it's still an option not to, like we do today
19:24:17 <TabAtkins> q+
19:24:19 <fremy> iank_: we can take the last baseline of the first column
19:24:24 <fremy> iank_: or of the last column
19:24:31 <fremy> iank_: or the lowest of all the columns
19:24:52 <fremy> dbaron: exporting the baseline of a multicolumn sounds scary
19:25:00 <fremy> dbaron: especially if you have balancing going on
19:25:06 <dbaron> s/the baseline/the last baseline/
19:25:17 <fremy> iank_: if you use the last column and you balance, it will often work
19:25:31 <fremy> iank_: but without balancing, you can end up somewhere random in the height
19:25:34 <Rossen_> q?
19:25:38 <fremy> fantasai: that seems the worst indeed
19:25:45 <fremy> fantasai: I think the best would be the max
19:25:59 <fremy> TabAtkins: fantasai just said what I was about to say
19:26:16 <fantasai> s/the max/the max, and second best would be the last line of the first column/
19:26:26 <fremy> iank_: the only caveat is that we probably don't want to include spanned items
19:26:30 <fremy> fantasai: why not?
19:26:41 <fremy> fantasai: if sounds like an rare case, but why not?
19:26:49 <fremy> iank_: (nodding)
19:27:04 <fremy> fantasai: I think checking all columns is better
19:27:07 <rachelandrew> +1 to checking all columns
19:27:15 <fremy> fantasai: in case you have a large image that doesn't fit at the bottom of the first column
19:27:19 <fremy> iank_: I'm fine with that
19:27:43 <fremy> iank_: we have some compat constraints for inline-block
19:27:48 <fremy> iank_: but here it's ok
19:28:05 <fremy> fantasai: proposed resolution is to use the lowest last baseline of all columns
19:28:09 <fremy> Rossen_: any objection?
19:28:38 <fremy> RESOLVED: for multicolumns, use the lowest last baseline of all columns as its last baseline
19:28:40 <TabAtkins> ScribeNick:
19:28:43 <TabAtkins> ScribeNick: TabAtkins
19:28:50 <TabAtkins> Topic: last baseline of tables
19:28:58 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7655
19:29:22 <TabAtkins> iank_: Tables work by taking the first baseline from the first row in the larger table
19:29:30 <TabAtkins> iank_: Importantly, we skip captions, this is intentional
19:29:37 <TabAtkins> iank_: So how do we determine last baseline?
19:29:46 <TabAtkins> iank_: First relatively obvious bit is we probably want the last row
19:29:57 <TabAtkins> iank_: Given the reoslution we just had for flex and grid, we can probably do something similar
19:30:31 <TabAtkins> iank_: So if you've got a lot of baseline-aligned items, we'll take the first-baseline of those items and use it as the table's last baseline; toherwise we'll synthesize
19:30:54 <TabAtkins> fantasai: Alignment expands baseline alignment for tables, says align-content works on cells; "normal" looks at vertical-align, but you can use first/last baseline normally
19:30:59 <heycam> q+
19:31:03 <TabAtkins> fantasai: So probably just want to take literally the grid behavior and apply it here
19:31:06 <TabAtkins> iank_: Yeah, fine with that
19:31:13 <TabAtkins> iank_: Not implementing it yet, but seems fine
19:31:19 <TabAtkins> iank_: Important is to not consider captions
19:31:25 <TabAtkins> fantasai: agreed
19:31:33 <fremy> q+
19:31:38 <TabAtkins> iank_: (I'll show Firefox folks some cases for why caption should be ignored later)
19:31:38 <Rossen_> ack heycam
19:31:44 <TabAtkins> heycam: How do spanning cells impact this?
19:31:55 <TabAtkins> iank_: it gets a little complex
19:32:21 <TabAtkins> iank_: this wouldn't apply until impls support align-content; if something is spanning multiple rows, its first baseline currently only contributes to its first spanned row
19:32:49 <TabAtkins> iank_: And last-baseline, you can only get spanned cells affecting the last baseline if you support align-content:last-baseline
19:33:11 <TabAtkins> fantasai: So a spanned cell only affects first baseline alignment in its first row, and last baseline in its last row, and that's it
19:33:19 <Rossen_> ack fremy
19:33:22 <TabAtkins> fantasai: so it doesn't affect first-baseline alignmetn in its last row, etc
19:33:33 <TabAtkins> fremy: When you synthesize, do you include the table border?
19:33:55 <TabAtkins> iank_: TAbles always have a valid baseline - it's complicated - if there's a tbody, you ahve a baseline bc you synthesize it using the content edge of the first row
19:34:16 <TabAtkins> iank_: I think if you have captions but no body there's no exported baseline, so you'd synthesize from the table border
19:34:22 <TabAtkins> iank_: Need to do some investigation on our behavior
19:35:00 <TabAtkins> fantasai: proposed resolution: finding first/last baseline of a table cell works same as in grid
19:35:16 <TabAtkins> iank_: And last baseline of a table is taken from teh corret baseline-sharing group in the alst table row
19:35:21 <TabAtkins> Rossen_: objections?
19:35:37 <TabAtkins> RESOLVED: Table baselines match grid, per details above.
19:35:39 <fantasai> RESOLVED: Rowspanning cells particpate only in first baseline alignment of their first row, and last baseline alignment in the last row
19:35:46 <TabAtkins> fremy: Should I modify Tables?
19:35:55 <TabAtkins> fantasai: We might be able to do it generically in Align.
19:36:05 <TabAtkins> fantasai: If we can't we'll ping you.
19:36:08 <TabAtkins> Topic: end
19:36:15 <TabAtkins> <br dur=54min>
19:36:37 <dbaron> Topic: lunch break
19:38:00 <projector> projector has joined #css
19:38:30 <leaverou> leaverou has joined #css
19:39:00 <Rossen> Rossen has joined #css
19:39:31 <shans> shans has joined #css
19:40:01 <sylvaing> sylvaing has joined #css
19:45:05 <jacobcrypusa> jacobcrypusa has joined #css
19:49:59 <nigel> nigel has joined #css
19:51:53 <matatk> matatk has joined #css
19:54:20 <nigel> nigel has joined #css
19:56:08 <nigel> nigel has joined #css
20:00:18 <nigel> nigel has joined #css
20:03:59 <karlcow> karlcow has joined #css
20:12:48 <eeeps> eeeps has joined #css
20:13:10 <matatk> matatk has joined #css
20:29:45 <ydaniv> ydaniv has joined #css
20:30:36 <nigel> nigel has joined #css
20:33:02 <andreubotella> andreubotella has joined #css
20:33:25 <duga> duga has joined #css
20:33:28 <tantek> tantek has joined #css
20:33:53 <fremy> fremy has joined #css
20:34:08 <dizhang> dizhang has joined #css
20:34:16 <Rossen_> Rossen_ has joined #css
20:34:16 <TabAtkins> apologies, hamds full of sammich
20:34:24 <astearns> topic: [css-align-3] Baselines need to be defined on fieldsets.
20:34:35 <astearns> github: https://github.com/w3c/csswg-drafts/issues/7656
20:34:44 <emilio> ScribeNick: emilio
20:35:20 <emilio> iank_: fieldsets need their baseline defined
20:35:29 <emilio> ... they're special, have a <legend> on the border area
20:35:38 <emilio> ... and their contents are wrap in a box with arbitrary display type
20:35:40 <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10714
20:35:52 <emilio> iank_: implementations do wild things
20:36:03 <emilio> ... dgrogan has screenshots of what browsers do today
20:36:11 <emilio> ... my preference is to ignore the legend
20:36:17 <emilio> ... that's Chromium's behavior
20:36:19 <dlibby> dlibby has joined #css
20:36:24 <emilio> fantasai: I'd like to argue for Safari's behavior
20:36:33 <emilio> ... first baseline from legend, last from content
20:36:38 <emilio> Rossen_: why is that more sensible?
20:36:47 <emilio> fantasai: legend is the first bit of text that you see
20:36:54 <emilio> ... seems reasonable to align to it
20:36:58 <emilio> ... that should def. work
20:37:13 <fremy> +1 for aligning fieldsets with each other based on the legend
20:37:18 <emilio> ... not sure what the last baseline to be, but taking the last baseline of the content of the fieldset makes sense to me
20:37:26 <emilio> iank_: I think I disagree, <legend> is like table captions
20:37:37 <emilio> ... they have smaller font-size, they're not the main content of the fieldset
20:37:48 <emilio> ... first baseline should be actual content, that makes more sense to me
20:37:59 <emilio> fantasai: would be great if web designers would weigh in on this
20:38:26 <emilio> Rossen_: one potential use case might be aligning multiple fieldsets
20:38:42 <emilio> iank_: aligning to non-fieldset content is more common I think
20:38:53 <emilio> dbaron: I think I lean towards agreeing with iank_
20:39:00 <Rossen_> ack dbaron
20:39:02 <emilio> ... not that uncommon for fieldsets to lack a <legend>
20:39:17 <miriam> +1 Ian and David
20:39:18 <emilio> ... if we wanted to align to legend we'd need to define  what happens when there's no legend
20:39:21 <emilio> +1
20:39:25 <tantek> +1
20:39:26 <heycam> q+
20:39:33 <emilio> ... my sense is that it's common not to have one
20:39:43 <nigel> nigel has joined #css
20:39:45 <Rossen_> ack heycam
20:39:46 <emilio> iank_: if you're aligning fieldsets with and without legends it'd be weird
20:39:57 <emilio> heycam: agree with iank_ as well, legend is ancillary content like captions
20:40:07 <emilio> ... fieldset legend could also have multiple lines of text as well
20:40:07 <emeyer> q+
20:40:15 <Rossen_> ack emeyer
20:40:22 <emilio> emeyer: I'm looking at live dom viewer on irc
20:40:34 <emilio> ... I accept the argument that aligning to the legend is a bit dangerous
20:40:43 <emilio> ... I have the feeling that many fieldsets don't have legend
20:41:01 <emilio> ... but I do see situations for all three kinds of alignment. legend/first/last content
20:41:13 <emilio> ... if I had to pick one I'd choose first line of contents
20:41:23 <emilio> ... but I see use cases for the others
20:41:43 <emilio> ... there's cases where I might want to align to others
20:41:48 <emilio> ... I think both patterns would be common
20:42:11 <emilio> fantasai: when you want first line to align, is there case where the legends don't align?
20:42:13 <emilio> q+
20:42:30 <zcorpan> q+
20:42:31 <emilio> emeyer: I can't think of a reason, I'd want the legends to align with each other
20:42:32 <nigel> nigel has joined #css
20:42:45 <emilio> ... sometimes I want text outside to align with the legend
20:43:10 <emilio> iank_: if you want to align legends using top-alignment would work unless there's non-fieldset content
20:43:38 <emilio> emeyer: I probably would want the text outside to align with the first line of content rather than the legend
20:43:51 <emilio> iank_: we could also add a switch to allow you to align to a legend if that use case comes up
20:44:04 <emilio> fantasai: there's an issue to allow choosing baseline alignment box
20:44:20 <fantasai> https://github.com/w3c/csswg-drafts/issues/1339
20:44:27 <heycam> emilio: I was going to say something related what Ian said. we could add a switch but I'd also like to ignore the legend
20:44:32 <Rossen_> ack emilio
20:44:49 <heycam> ... if the use case for aligning to a legend comes up often, where you're aligning text outside the fieldset with the legend of the fieldset, which seems odd, we could look to allow that
20:44:52 <heycam> ... but seems farfetched
20:44:56 <heycam> ... for most cases top alignment should do
20:45:15 <Rossen_> ack zcorpan
20:45:23 <emilio> zcorpan: we discussed whether there's a case where legends wouldn't be align
20:45:39 <emilio> ... if you have a fieldset with one line of text and another when the legend is 2+ lines of text
20:45:45 <emilio> ... those wouldn't be necessarily align
20:45:49 <emilio> ... depending on what we decide
20:46:00 <emilio> ... maybe I misunderstood
20:46:07 <astearns> no, I had the same idea
20:46:19 <emilio> iank_: that's a similar problem if you try to align a fieldset with a legend and one without
20:46:45 <emilio> Rossen_: it sounds the obvious use case is that the first baseline of content needs to be available
20:46:56 <emilio> ... we need to resolve to have first-line baseline based on the content
20:47:11 <emilio> ... be available. The second question is whether we need to make the legend baseline available
20:47:38 <heycam> emilio: I would propose to try resolving the default be the baseline of the content
20:47:52 <heycam> ... if there are use cases that can't be solved without the baseline of the legend, work on what fantasai was talking about, choosing the baseline box
20:48:14 <emilio> Rossen_: seems to agree with the majority of the +1s and arguments made
20:48:33 <nigel_> nigel_ has joined #css
20:48:54 <zcorpan> +1
20:49:12 <emilio> Rossen_: fantasai, objections?
20:49:18 <emilio> fantasai: defer to emeyer and jensimmons
20:49:29 <emilio> s/fantasai, //
20:50:10 <emilio> emeyer: the proposed resolution is to default to first or last baseline of the content?
20:50:20 <emilio> emilio: both baselines first and last would be baseline of the content box
20:50:56 <emilio> emeyer: feels probably correct, I'll take al look at various cases to confirm it's not a bad idea, but seems like the best resolution
20:51:13 <emilio> RESOLVED: default first and last baselines to be the fieldset content's
20:52:02 <emilio> Topic: CSSStyleSheet.layer
20:52:26 <emilio> github:https://github.com/w3c/csswg-drafts/issues/7002
20:52:41 <emilio> miriam: we resolved on the main question, a CSStyleSheet.layer
20:52:53 <emilio> ... another question came up that fantasai and me weren't sure how to answer
20:53:03 <emilio> ... can the same sheet be imported in different layers
20:53:26 <emilio> ... is it guaranteed that different imports end up with different sheets or do we need to track all the different names?
20:53:27 <Rossen_> q?
20:53:27 <emilio> q+
20:53:39 <Rossen_> ack emilio
20:53:42 <heycam> emilio: the CSSOM guarantees each @import rule should be a different style sheet
20:53:44 <fantasai> emilio: The CSSOM guarantees that each @import rule should be a different style sheet
20:53:45 <heycam> ... so I think we're good
20:54:37 <emilio> RESOLVED: No change to the previous resolution
20:55:31 <heycam> emilio: Xiaocheng is talking about CSS Imports, not @import
20:55:49 <heycam> ... I don't know how CSS Modules behave, if they always create the same style sheet object, or multiple
20:55:53 <heycam> ... I was talking about @import rules
20:56:16 <heycam> ... presumably if Xiaocheng is asking, they must only create a single object
20:57:48 <dbaron> not sure if https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md is still accurate
20:57:54 <heycam> chrishtr: we should continue to research then get back to the issue
20:58:22 <heycam> dbaron: I have some memory of a discussion in a TAG review about whethehr they create separate objects, can't remember the conclusion
20:58:42 <dbaron> https://github.com/w3ctag/design-reviews/issues/405
20:59:08 <emilio> Rossen_: let's re-discuss when Xiaocheng is back
20:59:18 <emilio> Topic: querySelector and scoping
20:59:35 <emilio> github: https://github.com/w3c/csswg-drafts/issues/7709
21:00:00 <emilio> miriam: in the scope spec we tried to provide the at rule and also tried to provide that in selectors
21:00:21 <emilio> ... the reason was to use querySelector to return scoped results
21:00:30 <emilio> ... that ended up being difficult and raised many different issues
21:00:43 <emilio> ... syntax is easy to solve in @scope and harder in selector notations
21:00:52 <zcorpan> (I found https://html.spec.whatwg.org/multipage/webappapis.html#creating-a-css-module-script )
21:01:11 <emilio> ... is it worth to pursue that or can we add a second argument to qSA
21:01:15 <TabAtkins> q+
21:01:17 <emilio> ... and get rid of the selector notation
21:01:25 <Rossen_> ack TabAtkins
21:01:59 <emilio> TabAtkins: I think we should switch the second arg to an options bag
21:02:03 <TabAtkins> querySelector(".foo", {upper: Element, lower: Element} )
21:02:21 <jbroman> jbroman has joined #css
21:02:26 <emilio> q+
21:02:42 <heycam> emilio: I assume the way this would be implemented would be basically a post-processing of sorts
21:02:49 <miriam> q+
21:02:56 <heycam> ... you'd first match the selector, then if it matches, you check the scope. do we really need a querySelector API for that?
21:03:15 <heycam> ... it's like a filter on the querySelectorAll results
21:03:22 <heycam> miriam: I'm not sure I understand your proposal Tab
21:03:46 <heycam> emilio: I understand the proposal, but do we need to build this into qSA? can't you process the qSA results?
21:03:56 <heycam> miriam: if I'm reading Tab's proposal right, you're looking for a selector within a scope
21:04:01 <heycam> ... I'm trying to return a scoped fragment of tree
21:04:07 <heycam> ... which is a bit different from scoped selector
21:04:14 <heycam> ... so when you grab an element you get its descendants
21:04:25 <heycam> ... potentially with cutting off some lower boundaries
21:04:43 <emilio> TabAtkins: that's what you'd get if your selector was a star
21:04:49 <Rossen_> ack emilio
21:04:51 <Rossen_> ack miriam
21:04:59 <emilio> miriam: no, we're trying to return not a selector within a scope, but the scope
21:05:17 <emilio> TabAtkins: that sounds like a completely different thing
21:05:31 <emilio> miriam: doesn't qSA return the tree of elements?
21:05:41 <emilio> fantasai: no, only the list of matched elements
21:06:04 <emilio> fremy: are you trying to get something like get all the images inside a div but not inside a p
21:07:08 <emilio> TabAtkins: you can't do it with selectors reliably , you need upper and lower boundaries
21:07:27 <emilio> fremy: yeah but your proposal takes an element, it should ideally take selectors right?
21:07:32 <emilio> TabAtkins: it should take a list of elements
21:07:48 <fantasai> fantasai: Should accept a selector representing such elements
21:07:53 <heycam> emilio: I'm moderately sure qSA doesn't take a second argument
21:07:55 <heycam> TabAtkins: yes it does
21:08:07 <heycam> ... but it's the this value
21:08:15 <Rossen_> q
21:08:58 <emilio> TabAtkins: regardless of design discussions, question is is it ok to drop the scoping from selectors because we'll address the use case in some way by modifying qS?
21:09:00 <emilio> q+
21:09:09 <heycam> emilio: I think we should drop the selector syntax
21:09:20 <heycam> ... I'm pretty convinced you can achieve the scoping stuff with script right now
21:09:25 <heycam> ... even if it needs multiple qS calls
21:09:36 <Rossen_> ack emilio
21:09:41 <heycam> ... but if we need to add a more convenient way to do that, we can do that
21:09:45 <TabAtkins> Doing it in small amounts of code, correctly, is non-trivial.
21:09:49 <heycam> ... but I don't think we should force scoping into selectors just for this use case
21:09:59 <emilio> fremy: the only thing would be performance
21:10:03 <TabAtkins> Need to make sure the forbidden ancestor is between the element and the root (upper boundary); if it's *above* the root it doesn't matter.
21:10:19 <emilio> ... you can filter in JS but you can create wrappers for lots of nodes
21:10:23 <heycam> emilio: if you use closest, you don't create [...]
21:10:40 <emilio> TabAtkins: you can't use closest, it's non-trivial to do in script
21:10:54 <heycam> emilio: but I'm sure we can figure out a convenient way to do this if we need it
21:11:55 <zcorpan> https://dom.spec.whatwg.org/#dom-parentnode-queryselector
21:11:55 <emilio> TabAtkins: proposal is removing scoping from selectors, opening an issue in DOM for adding scoping API to qSA
21:12:16 <emilio> RESOLVED: Remove scoping from selectors
21:12:58 <emilio> Topic: scoping rules from @import
21:13:02 <emilio> Github: https://github.com/w3c/csswg-drafts/issues/7348
21:13:23 <emilio> miriam: similar to layer() in @import
21:13:38 <emilio> ... and upcoming layer in <link>
21:13:51 <emilio> ... there's a proposal to add scoping to a sheet when it's scoped
21:13:59 <emilio> ... proposal is to put the scoping condition in @scope
21:14:05 <emilio> ... and put it inside of a function
21:14:19 <emilio> ... so @import "url" scope(<root> to <lower>);
21:14:42 <emilio> ... we might want the same for html
21:14:58 <emilio> ... if you're only using scope you need double parens
21:15:06 <emilio> ... which is a bit ackward
21:16:04 <emilio> ... but proposal is to add the scope() function and maybe a shorthand for that awkward case
21:16:15 <emilio> q+
21:16:28 <heycam> emilio: this feels a bit more similar to @container or such, than @layer
21:16:43 <heycam> ... I feel it's a bit awkward. when would you want to scope a whole style sheet?
21:16:57 <Rossen_> ack emilio
21:16:57 <heycam> miriam: this would be particularly useful for systems that are currently modular / separate style sheets per component
21:17:07 <heycam> ... we could take those separate sheets, apply a scope as importing them
21:17:10 <heycam> emilio: could use shadow DOM
21:17:17 <heycam> miriam: other way is to wrap it in a file
21:17:23 <heycam> emilio: seems like a weird thing to have a shorthand for
21:17:31 <heycam> ... but if you say it's useful
21:18:53 <heycam> emilio: it feels weird in the sense it's depends on the DOM you're styling, rather than layer or media, where it's more about the style sheet itself and the environment
21:19:20 <heycam> miriam: I'll say people are going to do this. they have other methods to do it. I don't feel strongly we need this one, but it will keep coming up
21:19:24 <heycam> ... do we want to provide it as a shorthand?
21:19:27 <heycam> emilio: should we encourage it?
21:19:41 <heycam> ... if you want this kind of scoping for your whole style sheet, you may just want to use shadow DOM and drop the style sheet there
21:19:49 <heycam> miriam: scope is fairly different from shadow DOM
21:20:04 <heycam> ... you could make a fair argument that if the style sheet is meant to be scoped then it should be inside the style sheet
21:20:24 <heycam> ydaniv: it might not be your style sheet
21:21:00 <heycam> emilio: I get wanting to use teh style sheet only when I'm printing, or to put it in this layer, but I want to scope this whole style sheet, since it depends on what selectors you're scoping it to
21:21:05 <heycam> chrishtr: seems like it's the same as @scope
21:21:08 <heycam> ... it's just for a whole file
21:21:11 <heycam> ... that could be convenient
21:21:32 <heycam> ... if we accept the general usefulness of scoping, which I think it is, we should provide primitives to make that easier
21:21:40 <heycam> ... this seems like a natural extension to that
21:21:45 <heycam> emilio: you could make the same argument for container
21:22:05 <heycam> emilio: to me, @scope and @container are more similar than @scope and @media
21:22:09 <heycam> ydaniv: it's more like @layer
21:22:11 <heycam> emilio: do you think so?
21:22:16 <heycam> ... @layer doesn't change whether something matches or not
21:22:28 <heycam> chrishtr: it's scoping to different subtrees
21:22:31 <heycam> emilio: not objecting
21:23:01 <emilio> RESOLVED: add scope() to @import syntax
21:23:50 <emilio> topic: Proximity of siblings
21:23:53 <emilio> github: https://github.com/w3c/csswg-drafts/issues/7233
21:24:04 <emilio> miriam: original request framed it as sibling scopes
21:24:31 <emilio> ... but when we dug they cared about proximity of siblings in the cascade
21:24:52 <emilio> ... we have this for descendants where proximity affects the weight in the cascade
21:25:02 <emilio> ... this wanted to account for siblings
21:25:18 <emilio> ... seems we could do something like that with different syntax
21:26:11 <nigel> nigel has joined #css
21:26:12 <emilio> TabAtkins: I don't think how we'd account for this in `@scope`
21:26:16 <zcorpan> h1 ~~ p or h1 ++ p
21:26:25 <emilio> s/think/know
21:26:36 <emilio> TabAtkins: but the use case is great and the combinator syntax is great
21:26:44 <emilio> ... doesn't matter which syntax
21:27:03 <emilio> zcorpan: proposal are ~~ or ++
21:27:06 <emilio> q+
21:27:38 <ydaniv> +1 for snakes
21:27:42 <tantek> +1 for snakes
21:27:45 <emilio> TabAtkins: I don't care about which one but we should make it work in @scope
21:27:55 <heycam> emilio: I argue for snakes
21:27:55 <tantek> since ++ already means something in other languages :)
21:27:56 <Rossen_> ack emilio
21:28:02 <fantasai> +1 tantek
21:28:06 <heycam> emilio: snake already involves all the siblings
21:28:09 <heycam> ... while plus doesn't
21:28:10 <fantasai> s/+1 tantek/tantek++/
21:28:15 <heycam> ... so it feels more logical
21:28:34 <zcorpan> mushroom ~~ muchroom
21:29:02 <nigel_> nigel_ has joined #css
21:30:02 <emilio> TabAtkins: Currently child one is based on child rather than descendant combo, so would be more consistent with +
21:30:23 <emilio> fantasai: I agree with tab that ++ is more analogous but I also prefer the snakes
21:30:58 <zcorpan> 🐍
21:31:23 <fantasai> Rossen_: Imagine you're on a plane...
21:31:45 <TabAtkins> Hm, thinking using `to sibling` keyword in @scope would work
21:32:30 <emilio> miriam: proposal is adding ~~ as a sibling combinator that prefers closer siblings
21:32:43 <heycam> emilio: after Tab's argument I prefer the pluses, but I don't mind either way
21:33:06 <emilio> RESOLVED: ~~ is a sibling combinator that prefers closer siblings
21:33:09 <karlcow> karlcow has joined #css
21:33:26 <emilio> topic: :stylesheet
21:33:37 <emilio> github: https://github.com/w3c/csswg-drafts/issues/7349
21:34:23 <emilio> miriam: this is about stylesheets in the dom and scoping
21:34:30 <eeeps> eeeps has joined #css
21:34:42 <emilio> ... idea is to use `:stylesheet` / `:stylesheet-parent` to select stuff inside this scope
21:34:52 <emilio> ... that would allow you to scope the stylesheet
21:35:02 <emilio> ... most usecases prefer the stylesheet parent
21:35:18 <emilio> ... I don't have strong use cases for any
21:35:19 <CSSWG_LogBot> CSSWG_LogBot has joined #css
21:35:20 <fremy> huge +1
21:35:31 <emilio> fantasai: is there any use case other than implementing <style scoped>?
21:35:34 <emilio> miriam: no
21:35:39 <emilio> fantasai: then how about doing that?
21:35:55 <emilio> miriam: problem is backwards compat
21:36:25 <heycam> q+
21:36:40 <emilio> ... if scope is not recognized it's applied unscoped
21:36:50 <emilio> fantasai: can we use empty @scope rule for this?
21:36:54 <emilio> miriam: I like it
21:37:07 <emilio> ... we'd be setting aside being able to select the stylesheet's sibling
21:37:21 <Rossen_> ack heycam
21:37:39 <emilio> heycam: 2 things, does @scope nest? What would it mean if you would use @scope without a selector, would it be sensible?
21:38:09 <heycam> emilio: it would have sensible behavior
21:38:19 <heycam> ... the rule wouldn't apply, you would apply both filters
21:38:41 <emilio> heycam: second point is that there are stylesheets without nodes (constructable stylesheets)
21:38:53 <emilio> ... so we'd need to decide what it does
21:39:06 <heycam> emilio: it could also do nothing. just not match.
21:39:23 <heycam> fremy: this is in @scope
21:39:28 <heycam> emilio: so it would always match
21:39:50 <heycam> emilio: is <style scoped> really not possible?
21:39:54 <heycam> ... layers have the same issue
21:39:58 <heycam> ... you use layers
21:40:14 <heycam> miriam: if we get the media attribute extended to support supports(), then the media attribute can fail, and stop the style sheet from being applied
21:40:21 <heycam> ... you could use that along with the new attribute
21:40:28 <heycam> ... that's the proposal for layers and scope attributes
21:40:53 <heycam> emilio: I don't think any engine keeps around the DOM node deep enough, it could be done
21:41:04 <heycam> miriam: it has a bit less flexibility than what Tab was suggesting, where you could still apply a lower boundary
21:41:14 <heycam> ... while letting the upper boundary be applied by the position of the style sheet
21:41:37 <heycam> ... since lower boundaries is a bit part of what scoping provides, that might be a reason to go with the change to the @scope rule
21:41:52 <heycam> emilio: if I had to choose between :stylesheet and @scope, I'd go for @scope
21:42:27 <heycam> chrishtr: for the bottom or the top of the scope?
21:42:43 <emilio> miriam: the top, if you use no selector it'd use the parent of the <style> / <style> element as the scope root
21:43:14 <emilio> fantasai: if your <link> is in your <head> it doesn't accomplish very much
21:43:31 <emilio> chrishtr: what about constructable stylesheets?
21:43:35 <fantasai> s/it does/the stylesheet does/
21:44:03 <emilio> heycam: you need to define it but I think it logically shouldn't scope to anything
21:44:24 <emilio> chrishtr: could you add a `scope` property to the stylesheet to be able to scope a constructable stylesheet?
21:44:29 <emilio> heycam: yeah that should be doable
21:44:58 <dbaron> (leaving meeting now, probably back around 5pm)
21:45:20 <emilio> miriam: do we want links in <head> to also style the whole doc?
21:45:32 <emilio> fantasai: I don't think you want to do that, it'd just end up not styling anything
21:45:41 <fantasai> s/anything/much of anything/
21:46:46 <emilio> RESOLVED: @scope without selector scopes to the parent of the owner node, or the containing tree if there's no owner node
21:47:33 <emilio> topic: lower boundaries
21:47:42 <emilio> github: https://github.com/w3c/csswg-drafts/issues/6577
21:48:29 <emilio> miriam: with the lower boundary selector as part of the scope, there's a question of whether they're part or not of the scope
21:48:44 <emilio> ... there's use cases for both, initially we spec'd as inclusive
21:49:07 <emilio> ... so lower boundaries are part of the scope
21:49:14 <fantasai> https://github.com/w3c/csswg-drafts/issues/6577#issuecomment-1021035991
21:49:18 <emilio> ... exclusive allows to include explicitly with `> *`
21:49:36 <emilio> ... we want to add a keyword to `@scope`
21:49:47 <TabAtkins> q+
21:49:50 <emilio> ... to say whether you want the boundaries included
21:49:51 <flackr> q+
21:50:00 <Rossen_> ack TabAtkins
21:50:04 <emilio> TabAtkins: I'm fine with the kw
21:50:11 <emilio> ... but I think exclusive is better default
21:50:25 <emilio> ... also it's trivial to turn exclusive into inclusive
21:50:41 <Rossen_> ack flackr
21:50:43 <emilio> flackr: tab covered what I was going to say
21:50:48 <florian> q+
21:50:53 <emilio> ... exclusive is a little bit more ergonomic
21:51:00 <Rossen_> ack florian
21:51:07 <emilio> florian: does `> *` work if there's no child?
21:51:24 <emilio> TabAtkins: if no element matches the lower bound nothing gets excluded which is what you want
21:51:40 <emilio> miriam: I guess main argument to have it a keyword is readability, is it clear?
21:51:51 <emilio> TabAtkins: I think it does what it says and says what it does
21:52:06 <emilio> ... inclusive / exclusive ranges are a perennial source of confusion in every context
21:52:36 <emilio> fantasai: we can always add a keyword if we want to
21:53:18 <emilio> miriam: So proposal is make exclusive the default and add an example to the spec on how to do inclusive right?
21:53:33 <emilio> fantasai: yes, is default for upper bound inclusive?
21:53:34 <TabAtkins> they're both inclusive, the lower bound just includes elements in the forbid list ^_^
21:53:48 <emilio> miriam: yeah, and no use cases for exclusive
21:54:10 <emilio> RESOLVED: make exclusive lower boundaries the default and add an example to the spec on how to do inclusive
21:54:14 <karlcow> karlcow has joined #css
21:54:35 <emilio> miriam: aside, I want people to look at how proximity affects cascade priority
21:54:45 <emilio> ... not to discuss today
21:54:51 <miriam> https://github.com/w3c/csswg-drafts/issues/6790
21:55:24 <astearns> topic: break
22:08:16 <jenniferS> jenniferS has joined #css
22:29:30 <nigel> nigel has joined #css
22:31:45 <andreubotella> andreubotella has joined #css
22:33:08 <Rossen_> Rossen_ has joined #css
22:33:09 <heycam> Scribe: Cameron
22:33:13 <heycam> ScribeNick: heycam
22:33:28 <heycam> Topic: Change content-size suggestion to min-intrinsic instead of min-content?
22:33:31 <heycam> github: https://github.com/w3c/csswg-drafts/issues/6794
22:33:54 <jondavis> jondavis has joined #css
22:34:12 <heycam> dgrogan: this is about how the automatic minimum sizing for flex items works with items that have an aspect-ratio
22:34:17 <heycam> ... non-replaced items with an aspect-ratio
22:34:19 <karlcow> karlcow has joined #css
22:34:30 <heycam> ... Elika summarized it nicely
22:34:33 <eeeps> eeeps has joined #css
22:34:54 <heycam> ... ultimately it's a conflict between when an aspect-ratio item, would overflow the container, do we want to destroy the aspect-ratio and let flex's shrinking properties override it
22:35:05 <heycam> ... or preserve the aspect-ratio, with potentially some overflow
22:35:08 <dgrogan> https://jsfiddle.net/dgrogan/zcL7qs2v/5
22:35:11 <dizhang> dizhang has joined #css
22:35:32 <heycam> dgrogan: I would argue that we want to preserve the aspect-ratio, in part because authors seem to want their aspect-ratios preserved
22:35:54 <heycam> ... I just looked on Stack Overflow, I looked at the first 10-15 aspect ratio questions, mostly they're about flex destroying their aspect-ratio
22:36:06 <heycam> ... if they want it destroyed because they don't want overflow, they can specify min-width:0
22:36:12 <heycam> ... this issue is only about what we want in the default case
22:36:28 <Rossen_> ack fantasai
22:36:45 <heycam> fantasai: the initial value of min-width is auto, to prevent overflow when the author wasn't expecting the screen to be as narrow as it is
22:37:03 <heycam> ... the case here is the flex item is shrinkable, and is in a container that's smaller than its aspect-ratio derived size, but larger than its min-content width
22:37:24 <heycam> ... do we want it to shrink right down to the min-intrinsic size?
22:37:45 <heycam> ... setting min-width to 0 is more extreme, it shrinks to the point where the item no longer overlfows the container, but the item's contents overflows the item
22:37:46 <CSSWG_LogBot> CSSWG_LogBot has joined #css
22:37:49 <heycam> ... it prevents one kind of overflow but causes another
22:38:12 <heycam> ... if authors don't want a box to shrink below its specified size, whether it's specified through width or aspect-ratio, they shouldn't be having the box be a shrinkable flex item
22:38:29 <heycam> ... the purpose of min-width is a safety mechanism.  preferred size is expressed through the width property
22:38:56 <heycam> dgrogan: I don't follow the argument about min-width no being the way to set a preferred size
22:39:16 <heycam> fantasai: if your preferred size is something with an aspect-ratio, and you set it width width/height, then min-width is a stopgap to prevent bad cases of overflow
22:39:32 <heycam> ... the aspect-ratio breaking, it might not look the way you wanted, but we're trying to optimize for the case being usable
22:39:32 <CSSWG_LogBot> CSSWG_LogBot has joined #css
22:39:45 <heycam> ... not to make your design look perfect, which is what width expresses
22:40:16 <heycam> dgrogan: I see what you're saying. I can take the other way symmetrically, specifying the preferred main size through the aspect-ratio and the height
22:40:31 <heycam> ... when we let the author set an aspect-ratio and a cross size, we're kind of promising that we'll respect that, they went out of their way to set that
22:40:46 <heycam> fantasai: same when the author says width:100px, but we break that when the item is shrinkable. since you've asked it to be shrinkable
22:40:55 <heycam> ... don't think aspect-ratio is less of a constraint than width
22:41:03 <heycam> dgrogan: authors seem to really hate when their aspect-ratios are broken
22:41:17 <heycam> ... I don't think it's obvious that aspect-ratio is the same strength as width
22:41:35 <heycam> ... it's not clear they're setting something as flimsy as a width, when they set aspect-ratio
22:41:54 <heycam> IanK: I think more opinions might be good from the author side of things
22:42:18 <heycam> dholbert: I'd question analagous situations. are there other cases where you set an aspect-ratio, and you stretch in both driections, like a grid cell?
22:42:30 <heycam> fantasai: when you set width/height on an element we ignore aspect-ratio completely
22:42:45 <heycam> IanK: the trick with flexbox is that it has a strong explicit stretch in the cross axis, by default
22:43:00 <miriam> q+
22:43:12 <Rossen_> ack miriam
22:43:20 <heycam> miriam: I can see use cases where I want it to shrink, and others where not
22:43:33 <heycam> ... how easy is it for the author to specify that?
22:43:44 <tantek> tantek has joined #css
22:43:45 <heycam> ... wondering if adding flex:0 is clear
22:43:52 <heycam> fantasai: that would cause it not to shrink. initial value allows shrinking but not growing
22:44:16 <heycam> miriam: I'm wondering if we were going with the other default, what would be the counter author solution to say, allow shrinking?
22:44:24 <heycam> IanK: flex:0 will still allow shrinking
22:44:28 <heycam> dholbert: flex:none is what you want
22:44:30 <heycam> fantasai: they're the same
22:44:31 <heycam> IanK: no
22:44:38 <heycam> fantasai: initial value is "1 0"
22:45:04 <heycam> dgrogan: I think we all agree on flex:none
22:45:13 <heycam> ... if we go with the opposite default, you'd have to go out of your way to say min-width:0
22:45:22 <heycam> dholbert: min-width:0 would cause more overflow than the opposite
22:45:23 <TabAtkins> Right, `flex: 0` is equivalent to `flex: 0 1 0px`
22:45:32 <heycam> ... it doesn't precisely undo it. that would allow things to compress to 0.
22:45:45 <heycam> dholbert: min-content or min-instrinsic
22:45:50 <heycam> IanK: min-content would do the right thing
22:45:53 <heycam> fantasai: it's not quite exactly that
22:46:06 <heycam> ... min-content will win
22:46:28 <heycam> ... auto minimum size, because it's trying to be a non-intrusive safety mechanism, if you have some explicit size on it, it'll take the minimum of that and the min-content size
22:46:34 <heycam> ... so you can't get the auto behavior by setting min-content
22:46:45 <heycam> miriam: I don't have an immediate sense of which one I want more often
22:46:47 <heycam> ... flex:none seems the simpler fix though
22:46:53 <heycam> fantasai: it also resolves to 0 if you're a scroll container
22:47:05 <heycam> ... there's a lot of magic in min-width:auto, to make it weaker than other author expressed constraints
22:47:21 <heycam> ... it's always trying to find what's the smallest size to prevent overflow and also not interfere with other constraints
22:47:36 <heycam> dgrogan: glad you brought up min-width:auto magic
22:48:09 <heycam> ... one proposal in the bug, from Ian in March, is redefining min-content for non-replaced aspect-ratio items to incorporate the auto min width from the aspect-ratio in css-sizing-4
22:48:19 <heycam> ... if we did that, we'd end up with the asepct-ratio preserving behavior in this case
22:48:49 <heycam> ... but it would do so in a way that would 1. a lot of magic would go away, min-width:auto becomse simpler to spec, and 2. it becomes easier to implement, and the auto min width for aspect-ratio items totally ignoring flexboxes also gets easier to implement
22:49:04 <heycam> ... in the 2 years this has been specced, it's been really hard to implement
22:49:10 <heycam> ... Ian has a big test case that shows some of this
22:49:31 <heycam> ... I think based on my knowledge of Blink/WebKit/Gecko, if we did Ian's proposal, implementation becomes simpler, and we'd be way more likely to get interop
22:49:47 <heycam> ... if we stuck with the magic in auto min-width, we're not going to get interop on a lot of this for a long time
22:49:49 <heycam> ... if ever
22:50:02 <heycam> ... we've all had a really hard time implementing this, and got lots of bug reports
22:50:45 <heycam> Rossen: becoming a bit more pragmatic, rather than chasing spec purity
22:51:02 <heycam> ... can we do that moving forward? if we can, do we have enough buy in from implementors?
22:51:14 <heycam> dholbert: what's Ian's proposal?
22:51:50 <heycam> Ian: effectively, instead of having a separate min intrinsic and min content size, you incorporate the min-width:auto behavior in min-content
22:52:04 <heycam> ... currently, we're the only implementation that explicitly created a separate min intrinsic size
22:52:28 <heycam> ... and effectively, that would disappear, and when you're calculating min-content for the box, you also apply the min-width:auto logic on top of the aspec-ratio logic
22:52:45 <heycam> fantasai: not following. we explicitly wanted to say min-width:auto would break aspect-ratio
22:52:51 <heycam> ... having min-height break but not min-width ...
22:53:03 <heycam> IanK: min-width:auto would still encompass this, it just wouldn't shrink
22:53:09 <heycam> dgrogan: I think Safari does this today
22:53:17 <heycam> Ian: Safari's min-content implementation basically does this already
22:53:55 <heycam> ... in some of the complicated test cases, Safari kind of does what I'm suggesting
22:54:04 <heycam> dgrogan: but we all have many bugs in this area
22:54:16 <heycam> Ian: engines also struggle with width:100% and width stretch being different
22:54:30 <karlcow> karlcow has joined #css
22:54:57 <heycam> Rossen: what's the proposal here?
22:55:03 <hyojin> hyojin has joined #css
22:55:07 <fantasai> https://jsfiddle.net/dgrogan/zcL7qs2v/5
22:55:12 <fantasai> https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1218597495
22:55:18 <heycam> fantasai: we walked through a bunch of cases ^
22:55:38 <heycam> Ian: I also wanted to note, we can't change replaced elements. they have to stay at min-content
22:55:44 <fantasai> https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1220038900
22:55:48 <heycam> ... there's too much of the web that relies on them preserving aspect-ratio
22:55:52 <fantasai> latest proposal from me and TabAtkins ^
22:56:02 <heycam> ... we accidentally broke this recently and got bug reports quickly
22:56:13 <heycam> ... can't shrink replaced elements below their min-content size
22:56:28 <heycam> dgrogan: I think your point Ian is that if we can't change replaced elements, they currently do what non-replaced elements currently do
22:56:45 <heycam> Ian: replaced elements will always pass through their aspect-ratio, and we can't change that
22:57:14 <heycam> dgrogan: so, incorporate the current min-width:auto magic into the min-content algorithm itself
22:57:15 <CSSWG_LogBot> CSSWG_LogBot has joined #css
22:57:33 <heycam> ... the min-width for these aspect-ratio items would be largest of their min intrinsic width, or their aspect-ratio derived width
22:57:45 <heycam> fantasai: Tab and I don't really like the idea of incorporating min-width:auto into min-content definition
22:57:48 <heycam> ... because it really should be the other way around
22:57:58 <duga> duga has joined #css
22:58:18 <heycam> ... if you set width:min-content, you're proposing that the resolution of that min-content value to a concrete value, looks at the min-width value, and if it is auto, incorporates some extra magic
22:58:22 <heycam> ... if it's not auto, does not have magic
22:58:31 <heycam> ... but if you set min-width:min-content, it cannot depend on the min-width property itself
22:58:41 <heycam> ... so the min-content keyword means two different things, depending on where you set it
22:58:55 <heycam> ... we think this should be more consistent, and independent of what sizing property you set it on
22:59:01 <heycam> ... whether it's on width or min-width, its used value is the same
22:59:19 <heycam> Ian: we already look at the width properties in the min-content algorithm. there's already a bunch of compressibility stuff, special table stuff
22:59:28 <heycam> ... this is fine from an engineering point of view
22:59:45 <heycam> dholbert: I'm a bit confused about that stating of the propsoal
22:59:58 <heycam> ... it sounds like we're talking about what should happen when you have an element with an asepct-ratio that's forced to shrink
23:00:12 <heycam> ... sounds like that's talking about what the magic is behind min-width:auto. not about how it gets incorporated
23:00:26 <heycam> fantasai: the compressibility stuff affects the min-content contribution, which is not hte same as the min-content size
23:00:34 <heycam> dgrogan: I think Ian's saying it's fine from an implementation PoV
23:01:00 <heycam> dgrogan: I think of this as how the min-content:auto magic is incorporated
23:01:07 <heycam> dholbert: min-width:auto resolves to come length
23:01:09 <heycam> s/min-content/min-width/
23:01:19 <heycam> ... sounds like the proposal is to resolve it to a different length
23:01:25 <heycam> ... that takes into account the aspect-ratio more eagerly
23:01:45 <heycam> dgrogan: I'm not talking about the min-content alg more eagerly taking it into account
23:01:57 <heycam> ... right now, it ignores min intrinsic size and only looks at aspect-ratio
23:02:04 <heycam> ... so if anything this proposal is to do it less eagerly
23:02:18 <heycam> Ian: we also look at asepct-ratio for the min intrinsci size, because we transfer through the max height and min height
23:02:26 <heycam> ... and that affects the min intrinsic size
23:02:48 <heycam> ... min-intrisc and min-content are almost always the same
23:03:15 <heycam> Rossen: still not seeing something we can resolve on
23:03:41 <heycam> ... sentiment here is clear, but I still don't see what to resolve to move forward, that satisifies implementability and the developer point
23:04:12 <heycam> ... Elika's pointing out another part of the issue, that articulates what we should and can do for replaced elements, and for non-replaced elements the explanation here still doesn't give enough specifiy that suggests a change
23:04:17 <fantasai> https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1220038900
23:04:24 <heycam> fantasai: we are suggesting several specific changes
23:04:47 <heycam> fantasai: Tab and I are saying it shouldn't be considering aspect-ratio
23:05:02 <heycam> ... when we originally wrote the text for min-width:auto, there wasn't aspect-ratio on anything excpet replaced elements
23:05:14 <heycam> ... in that context, it doesn't make sense to incorporate aspect-ratio
23:05:28 <heycam> ... so we really meant min-intrinsic size despite not having that term yet
23:05:43 <Rossen_> a/developer point/developer pain/
23:06:00 <heycam> ... [the other two points are there in the link above]
23:06:15 <heycam> fantasai: in flex/grid when you have a transferred size, it's different in grid the transferred size takes precedence
23:06:21 <heycam> ... but in flex it takes the min of the two
23:06:33 <heycam> ... it seems that would probably not be a good idea for compat, given where implementations are right now
23:06:45 <heycam> Ian: that's something we can resolve on. for replaced elements, for compat, we need to keep it as min-content
23:07:01 <heycam> fantasai: I'd phrase that as "use the transferred size suggestion in preference to the content size suggestion, where that exists, for a replaced element
23:07:07 <eeeps> eeeps has joined #css
23:07:36 <heycam> Ian: for us they're basically equivalent
23:07:45 <heycam> ... when do they differ?
23:07:54 <heycam> fantasai: because the content size suggestions do not take aspect-ratio into account
23:08:04 <heycam> ... if it did, then there wouldn't have been a transferred size suggestion in the first place
23:08:15 <heycam> Ian: this is flex box's content size suggestion, not min-content size we use elsewhere
23:09:10 <heycam> RESOLVED: use the transferred size suggestion in preference to the content size suggestion, where that exists, for replaced elements
23:09:33 <heycam> fantasai: there was a comment in the thread about how transferring the max size from the opposite axis didn't make much sense
23:09:37 <heycam> dgrogan: in the content size suggestion?
23:09:40 <heycam> fantasai: for non-replaced
23:09:50 <heycam> ... right now we transfer a max size constraint from the opposite axis to clamp the min in this axis
23:09:53 <heycam> ... that probably doesn't make sense
23:10:24 <heycam> dgrogan: we still have a fundamental disagreement about the main point
23:10:39 <heycam> ... I just want to fall back, all 3 engines tried and we're in the place where we don't have much interop
23:11:04 <heycam> ... the suggestion of incorporating hte auto min width into the min-content calculation, it's not great, but it's practical, pretty sure all engines can do it easily, and we'd get interop way easier
23:11:20 <heycam> chrishtr: you also said impl difficulty and web compat prevented you from implementing the altnerative?
23:11:27 <heycam> Rossen: no that's for replaced elements
23:11:30 <heycam> dgrogan: it's related
23:11:39 <heycam> ... we're talking about changing the rules. and one of them would've changed replaced, but we can't do that
23:11:48 <heycam> chrishtr: so we special case replaced elements, for compat
23:12:05 <heycam> dholbert: to be fair, non-replaced elements do have a meaningful smaller min width
23:12:45 <heycam> Ian: I'd still like to hear from more web devs about what they expect of the default
23:12:51 <heycam> ... and how they'd work around that
23:12:57 <heycam> ... heard from Miriam
23:13:14 <heycam> dgrogan: it's not just implementation. if we resolve on Ian's March proposal, it becomes easier to implement, and we think it doesn't break user expectations
23:13:19 <heycam> ... Adam Argyle weighed in on that
23:13:45 <heycam> miriam: I have use cases that I'd want to go either way, so more important to me is that I have the tools to get non-defautl behavior when I need it
23:13:58 <heycam> ... flex:none, to say "preserve my aspect-ratio" worked for me
23:14:08 <heycam> ... if there's a similar swtich from the other side, then it'd work for me too
23:14:12 <heycam> fantasai: but there isn't one from the other side
23:14:22 <heycam> ... flex:none is the thing to use to prevent it from going below its minimum size
23:14:31 <heycam> chrishtr: do we need something for the other case?
23:14:34 <heycam> fantasai: that's what min-width:auto is for
23:15:14 <heycam> chrishtr: is there some other way to get this use case that Miriam says is legit?
23:15:25 <heycam> dgrogan: I don't really understand why some fixe value of min-width wouldn't work well
23:15:33 <heycam> ... even if it doesn't cover all cases, I think it'd be close enough
23:15:45 <heycam> ... don't understand why min-width is not enough
23:15:50 <heycam> miriam: it might be for my cases, would have to look more
23:15:55 <heycam> fantasai: would point out that it's a strong constraint
23:16:05 <heycam> ... if you put min-width:min-content that's winning over all other size constraints
23:16:11 <heycam> ... min-width:auto is a weak constraint
23:16:18 <heycam> ... everything else will win over it
23:16:45 <heycam> ... so if you want to set some kind of minimum, you want it to be a weaker one than other constraints? like max-width? you can't do that with min-content, because that will win over everything else
23:16:52 <heycam> dgrogan: you can do min-width:10px
23:16:59 <heycam> fantasai: is an arbitrary length value what you want?
23:17:03 <heycam> ... or something based on the content?
23:17:10 <heycam> dgrogan: I don't know where we go from here
23:17:36 <heycam> miriam: would also say that the fact it's not flexing to grow ... would it maintain the aspect-ratio?
23:17:46 <heycam> ... I'd expected it to do the same thing growing as shrinking
23:17:52 <heycam> ... if flex-grow:1, it will trash the aspect-ratio
23:18:03 <heycam> s/...if flex/Ian: if flex/
23:18:06 <heycam> miriam: I'd expect them to work the same way
23:18:20 <heycam> Ian: the problem we get into is that flex-shrink being 1 everywhere is ...
23:18:26 <heycam> fantasai: being the default is what's throwing people for a loop
23:18:36 <heycam> ... if they also set width:100px on it and notice that shrinks but doesnt grow, that's consistent
23:18:45 <heycam> ... whatever width you have preferred, it will shrink but not grow, by default, in flex
23:19:05 <heycam> Rossen: still not hearing a concrete path forward here
23:19:14 <heycam> ... I think this would benefit from some whiteboarding
23:20:45 <heycam> Topic: Intrinsic Main Size algo has errors
23:20:46 <heycam> github: https://github.com/w3c/csswg-drafts/issues/7189
23:20:52 <heycam> TabAtkins: this one should be easier
23:21:06 <heycam> ... we noticed an error, discovered what it was, talked it over with David, fixed it to his satisfaction
23:21:20 <fantasai> https://github.com/w3c/csswg-drafts/commit/d452a10a921391dc6b6a96e7be97218692c1de53
23:21:25 <heycam> ... we asked for a review few weeks ago, if no comments, we can go ahead and accept it
23:21:47 <heycam> fantasai: this is already folded into the spec
23:21:53 <heycam> dholbert: I haven't had a chance to look
23:22:05 <heycam> ... I could take a quick look offline. but I suspect it's fine.
23:22:49 <heycam> Ian: we are still implementing this. don't know what the compat fallout will be
23:22:58 <heycam> ... but we need to try to work out what that looks like
23:23:25 <heycam> ... this is just a bit hairy because we've all had the same intrinsic sizing alg for a while
23:23:35 <heycam> RESOLVED: Accept changes, close the issue
23:23:53 <heycam> Topic: column wrap intrinsic size algorithm can make inline min-content > max-content
23:23:55 <heycam> github: https://github.com/w3c/csswg-drafts/issues/6777
23:24:11 <heycam> dgrogan: this one is similar to the last one
23:24:19 <fantasai> https://github.com/w3c/csswg-drafts/issues/6777
23:24:26 <fantasai> proposal: https://github.com/w3c/csswg-drafts/issues/6777#issuecomment-1220003107
23:24:30 <heycam> ... there have been spec proposal, but fantasai made a good proposal, implemented it not shipped, but it works well
23:24:34 <TabAtkins> summary at https://github.com/w3c/csswg-drafts/issues/6777#issuecomment-1220003107
23:24:56 <heycam> ... from calculating the min-content width of a column wrapped flexbox, instead of laying out all the items at their min-content width and then taking the result and calling that hte min-content width
23:24:58 <heycam> ... we'll just ignore wrapping
23:25:11 <heycam> ... so the min-content width of a column wrapped flexbox will be the same as a non-wrapped flexbox
23:25:33 <heycam> ... downside will be is there can be some overflow if the column wrapped flexbox has a definite height specified, such that the items need to wrap, but now they can't
23:25:45 <heycam> ... also point out this proposal is what all browsers implement today
23:25:45 <heycam> ... so it seems fine
23:25:46 <heycam> dholbert: seems fine to me
23:25:51 <heycam> fantasai: that's for min0content sizes
23:26:07 <heycam> ... guarantees even if you have overflow columns, the width of the box will be as wide as the widest column
23:26:15 <heycam> ... trickier is max-content size, where there's no real good answer
23:26:34 <heycam> ... proposal is to lay out each item at its max-content size, then try to build the columsn, then try to wrap a box around that set of columns
23:26:53 <heycam> ... mostly that should be a box that can size its contents exactly, but if the author used %age sizing there'd be cyclic effects
23:27:18 <heycam> s/min0content/min-content/
23:27:34 <heycam> dgrogan: what fantasai just proposed is already specced
23:28:20 <heycam> RESOLVED: Accept the proposal in the issue
23:28:45 <heycam> Topic: https://github.com/w3c/csswg-drafts/issues/7714
23:28:49 <heycam> Topic: overflow clip on SVG elements and flex layout
23:28:52 <heycam> github: https://github.com/w3c/csswg-drafts/issues/7714
23:29:11 <heycam> khush: this concerns how the min width / min-height auto is computed for a flex child
23:29:25 <heycam> ... spec says that if an element is a scroll container, the min-width/height will be 0
23:29:31 <heycam> ... but if not a scroll container, then it's content based min size
23:29:51 <heycam> ... the two cases where it's not a scroll container, is if overflow is clip/hidden
23:30:19 <heycam> ... previous change made replaced elements [...]
23:30:28 <heycam> ... SVG has for a long time had `overflow: hidden` in the UA style sheet
23:30:36 <heycam> ... now we're setting overflow:clip, it causes this layout behavior
23:30:46 <heycam> ... before, min-width/height would be 0
23:30:52 <heycam> ... but now it's computing to the content based min size
23:31:03 <heycam> Ian: we got many bugs
23:31:11 <heycam> khush: fun part is that was accidentally rolled out to stable channel
23:31:23 <heycam> ... have to keep this behavior for compat
23:31:45 <heycam> ... options are to first add min-width/height:0 to the UA style sheet, which when combined with overlfow:clip gives you the preivous behavior
23:31:46 <heycam> ... but now we have different compat problems
23:32:07 <heycam> ... second option is to special case it
23:32:20 <heycam> ... either in the layout computation spot. clip behaves this way except for SVG
23:32:47 <heycam> ... other option is that we don't set the overflow:clip in the UA style sheet only for SVG, and at layout time the previous behavior continues to apply, but at paint time we use it as if it's clip
23:33:00 <heycam> ... it'd have to be a used value time thing
23:33:00 <emilio> q+
23:33:08 <heycam> ... used value would be different in paint time
23:33:34 <heycam> fantasai: maybe should've gone over #7144 first
23:33:34 <Github> https://github.com/w3c/csswg-drafts/issues/7144 : [css-images-4][css-overflow-3] How do `object-overflow` and `object-view-box` interact with `overflow` and `overflow-clip-margin`?
23:33:53 <heycam> dholbert: I'm fond of the third option, keeping overflow:hidden SVG. is there a reason we need to change SVG?
23:33:56 <heycam> Ian: mainly for consistency
23:34:00 <heycam> ... we didn't perceive the compat risk
23:34:03 <fantasai> +1 to keeping overflow:hidden on svg
23:34:26 <heycam> ... only weird quirk is that at layout time, when we're looking at overflow, pretend overflow means clip at paint time
23:34:30 <heycam> ... at paint time
23:34:38 <heycam> s/layout time/paint time/
23:34:47 <heycam> dholbert: where is that used value magic? already exists?
23:34:55 <heycam> ... seems orthogonal to this
23:35:01 <heycam> fantasai: maybe we should switch to 7144
23:35:08 <Rossen_> ack emilio
23:35:16 <heycam> emilio: I have a question. overflow:clip by default on SVG, it changes the sizing behavior
23:35:24 <heycam> Ian: so min-content sizes
23:35:27 <heycam> ... auto min size will be 0
23:35:40 <heycam> emilio: if I load the test case in the first comment, and set overflow:clip/hidden, I don't see any layout change
23:35:58 <heycam> khush: flex layout was implemented first, so where it's supposed to check is this a scroll container or not, it looks at overflow value
23:36:11 <heycam> ... assumes it's not a scroll container only if overlfow:visible, but we are also now checking for clip
23:36:21 <heycam> ... this is a change in the process of landing
23:36:28 <heycam> emilio: right now SVG is not a scroll container
23:36:33 <heycam> Ian: but it does have overflow:hidden
23:36:39 <heycam> emilio: right now that decision is based on scrollable overflow
23:36:45 <heycam> Ian: computed overflow property value
23:36:57 <heycam> emilio: and you are changing that?
23:37:08 <heycam> ... but you want SVG to keep behaving the same way?
23:37:24 <heycam> Ian: the flexbox auto min size thing likely needs to say look at the computed value of overflow, rather than "scroll container"
23:37:33 <heycam> ... could make that narrower
23:37:45 <heycam> ... it becomes a used value, after layout thing
23:37:49 <heycam> emilio: I'm still confused
23:38:01 <heycam> ... I see a different if I set overflow:visible on the SVG, but not if I set overflow:clip
23:38:07 <heycam> Ian: we currently don't support overflow:clip
23:38:10 <heycam> dholbert: in Firefox I see a difference
23:38:15 <heycam> Ian: but that's not the compat concern
23:38:18 <dholbert> (If I add `overflow:clip` to https://github.com/w3c/csswg-drafts/issues/7714#issue-1366802020 , then the green thing gets wider)
23:38:20 <heycam> ... overflow visible/clip should behave the same
23:38:31 <heycam> ... but we changed the UA style sheet from hidden to clip, and that broke things
23:38:35 <heycam> emilio: maybe not change the UA style sheet?
23:38:45 <heycam> ... since it doesn't create a scroll container either
23:38:55 <heycam> Ian: at layout time you use the computed value of overflow, like we do right now
23:39:06 <heycam> ... to determine if we apply the auto min size
23:39:13 <heycam> ... and at paint time, we convert this to a used value of overflow:cip
23:39:20 <heycam> emilio: but that's basically what happens now?
23:39:32 <heycam> Ian: differences are overflow clip margin will start to apply
23:39:51 <heycam> khush: in terms of the changes in the UA sheet, we can skip setting overflow:clip, but we still need the overflow clip margin box for it to work with these elements
23:39:56 <nigel> nigel has joined #css
23:40:09 <heycam> khush: overflow-clip: margin-box
23:40:20 <heycam> ... so we'll skip setting overflow:clip, leave it as hidden
23:40:27 <heycam> emilio: proposed solution only changes the UA sheet?
23:41:01 <heycam> emilio: do we need to add magic to make overflow:hidden to behave like overflow:clip for SVG, rather than letting authors do it?
23:41:29 <heycam> Ian: we had a resolution that overflow:hidden would behave as overflow:clip
23:41:34 <heycam> ... it basically behaves like that anyway
23:41:37 <heycam> ... this is harmonizing
23:41:45 <heycam> emilio: bit unfortunatey
23:41:49 <heycam> s/unfortunatey/unfortunate/
23:42:03 <heycam> Ian: the coercion would apply to all the replaced elements, not just SVG
23:42:08 <heycam> ... if they're overflow:hidden
23:42:12 <heycam> emilio: as long as you're a replaced element
23:42:27 <nigel_> nigel_ has joined #css
23:42:31 <heycam> ... you don't get weird cases where there's only clip on one axis
23:42:37 <heycam> ... as long as this is well tested
23:42:39 <heycam> khush: I promise!
23:43:05 <heycam> dholbert: the thing where you check the computed value for flex layout purposes, I think that already matches what we already do internally, and it's what the spec used to say
23:43:12 <heycam> ... it results to 0 if overflow is hidden/scroll/auto
23:43:17 <heycam> ... but the spec now says scroll container
23:43:45 <heycam> ... so we might want to consider reverting that, and explicitly defer to computed overflow value
23:43:49 <heycam> Ian: I think I'd prefer that
23:44:30 <heycam> ... in summary, part 1: in the UA style sheet, we keep `svg { overflow: hidden; }`. part 2: in the flex spec, for auto min sizing, instead of saying scroll container, we read the computed overflow property value
23:44:48 <heycam> ... part 3: which may already be specced, is overflow:hidden on replaced elements gets coerced to overflow:clip at paint time
23:45:03 <heycam> dholbert: you can't do scrollTop on an <img>
23:45:12 <plh> plh has joined #css
23:45:14 <heycam> khush: part 3 was resolved in #7144
23:45:14 <Github> https://github.com/w3c/csswg-drafts/issues/7144 : [css-images-4][css-overflow-3] How do `object-overflow` and `object-view-box` interact with `overflow` and `overflow-clip-margin`?
23:45:35 <fantasai> +1
23:45:48 <heycam> khush: one other thing, for SVG, we're still keeping overflow-clip-margin in the UA sheet
23:46:22 <heycam> RESOLVED: in the UA style sheet, we keep `svg { overflow: hidden; }`
23:46:27 <heycam> RESOLVED: in the flex spec, for auto min sizing, instead of saying scroll container, we read the computed overflow property value
23:46:34 <heycam> RESOLVED: overflow:hidden on replaced elements gets coerced to overflow:clip at paint time
23:47:21 <heycam> <br dur="13m">
23:47:22 <dbaron> Topic: break
23:56:45 <nigel> nigel has joined #css