15:54:50 <RRSAgent> RRSAgent has joined #css
15:54:55 <RRSAgent> logging to https://www.w3.org/2026/04/22-css-irc
15:54:55 <Zakim> RRSAgent, make logs Public
15:54:56 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:58:02 <SebastianZ> SebastianZ has joined #css
15:59:59 <kizu> kizu has joined #css
16:00:02 <dshin-moz> dshin-moz has joined #css
16:00:06 <dshin-moz> present+
16:00:10 <kizu> present+
16:00:30 <sakhapov> sakhapov has joined #css
16:00:53 <alisonmaher> alisonmaher has joined #css
16:00:53 <SebastianZ> present+
16:00:56 <alisonmaher> present+
16:01:02 <github-bot> github-bot has joined #css
16:01:04 <jBreiland> jBreiland has joined #css
16:01:09 <oSamDavis> oSamDavis has joined #css
16:01:14 <javierct> javierct has joined #css
16:01:17 <hoch> hoch has joined #css
16:01:26 <hoch> present+
16:01:27 <jBreiland> present+
16:01:32 <rachelandrew> present+
16:01:32 <javierct> present+
16:01:58 <davidjmarland> davidjmarland has joined #css
16:02:04 <JoshT> JoshT has joined #css
16:02:21 <davidjmarland> present+
16:02:23 <JoshT> present+
16:02:27 <ChrisL> present+
16:02:31 <lea> lea has joined #css
16:02:43 <alisonmaher> alisonmaher has joined #css
16:02:47 <romain> romain has joined #css
16:02:52 <romain> present+
16:02:53 <JohnJansen> present+
16:03:11 <schenney> schenney has joined #css
16:03:16 <lea> present+
16:03:18 <schenney> present+
16:03:20 <alisonmaher3> alisonmaher3 has joined #css
16:03:25 <JoshT> github-bot, topic https://github.com/w3c/csswg-drafts/issues/13804
16:03:25 <github-bot> Topic: [css-pseudo] Add ::backdrop and ::view-transitions to the CSSPseudoElement's allowed pseudo-elements list
16:03:25 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13804
16:03:27 <jfkthame> jfkthame has joined #css
16:03:32 <jfkthame> present+
16:03:37 <flackr> present+
16:03:53 <JoshT> sakhapov: now have the pseudo element JS interface
16:03:59 <JoshT> ... biggest useful thing would be events
16:04:10 <JoshT> ... click on some pseudo element in the target
16:04:30 <JoshT> ... pseudo elements supports before and after. could add ::backdrop and ::view-transitions as well
16:04:30 <PaulG> PaulG has joined #css
16:04:35 <PaulG> present+
16:05:00 <JoshT> ... example for ::backdrop would be when you have modal open and you want to click outside of window, people currently have to do geometry intersection stuff
16:05:16 <JoshT> ... with this, you just check if the click target was the pseudo element
16:05:19 <flackr> q+
16:05:33 <alisonmaher3> alisonmaher3 has left #css
16:05:35 <JoshT> ... for ::v-t, bramus shows if you have an ongoing v-t, you can intercept to start a new one
16:05:45 <smfr> smfr has joined #css
16:05:55 <JoshT> ... for scroll-marker and scroll-buttons, you could target them
16:06:21 <JoshT> ... proposal is to follow Rob's suggestion to add all tree abiding elements to pseudo element interface
16:06:41 <JoshT> flackr: given that proposal, that sounds good. we know strong use case for the scroll pseudos
16:06:49 <bramus> +1 on tree-abiding
16:06:53 <JoshT> ... tree abiding elements have well established way of working
16:07:07 <emilio> q+
16:07:31 <JoshT> astearns: makes sense. am I right that there's no back compat issues or problems from if engines are scattered in their support. they don't need to support all tree abiding pseudos all at once?
16:07:45 <JoshT> flackr: you get the event anyway. this is about if the target is a pseudo
16:08:00 <JoshT> ... for unsupported, you just have no target but still see the event
16:08:20 <JoshT> astearns: so at that point, you don't know if it's lack of support or just whether the event didn't hit the pseudo
16:08:21 <kizu> kizu has joined #css
16:08:27 <astearns> ack emilio
16:08:28 <JoshT> flackr: that's the situation today
16:08:30 <astearns> ack flackr
16:08:43 <JoshT> emilio: did we figure out how in out events behave with pseudos?
16:08:49 <JoshT> ... do you get a mouse event?
16:08:57 <JoshT> sakhapov: we decided to disable for now
16:09:05 <JoshT> flackr: they don't cause boundary events
16:09:14 <JoshT> ... you just say this event is targetted to the pseudo
16:09:29 <JoshT> emilio: so you cannot observe whether ???
16:09:51 <JoshT> ... concern is whether all tree abiding elements doesn't include non standard stuff
16:10:10 <JoshT> ... presumably it would include ::-webkit-, which could cause compat problems
16:10:24 <JoshT> ... there are some details about layout of other tree abiding elements, but maybe that's ok
16:10:46 <JoshT> ... concerned about people building custom effects for inputs that only work on -webkit- pseudos
16:11:01 <JoshT> flackr: i'd support adding a condition for only standard pseudos
16:11:21 <JoshT> sakhapov: considered adding select, but I will raise a new issue
16:11:35 <JoshT> emilio: for pseudos that represent multiple things, it's tricker
16:11:42 <sgill> sgill has joined #css
16:11:55 <JoshT> ... these aren't part of the resolution because they're real elements
16:12:14 <JoshT> sakhapov: maybe I can get a specific list of what we have and if no one objects, we can accept
16:12:29 <JoshT> astearns: a list instead of the general tree abiding elements solution?
16:12:40 <JoshT> sakhapov: maybe not? we can go with the general solution
16:13:10 <JoshT> astearns: my preference is the standard tree abiding pseudos with some examples like '::part included because it's an element' etc
16:13:40 <JoshT> PROPOSED: use the CSSPseudo interface for all standardised tree-abiding pseudo elements
16:13:49 <ChrisL> q+ to check this is for selectors-5, right?
16:14:05 <bkardell> bkardell has joined #css
16:14:06 <JoshT> ChrisL: this is for selectors-5, not 4, right?
16:14:14 <JoshT> sakhapov: this is in pseudo elements 4
16:14:15 <bkardell> present+
16:14:25 <JoshT> RESOLVED: use the CSSPseudoElements interface for all standardised tree-abiding pseudo elements
16:14:50 <JoshT> github-bot, topic https://github.com/w3c/csswg-drafts/issues/13697
16:14:50 <github-bot> Topic: [css-gaps-1] `overlap-join` with `between` rule visibility
16:14:50 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13697
16:15:48 <JoshT> javierct: [shares screen]
16:15:59 <JoshT> ... we have resolved on overlap-join to join decorations
16:16:28 <JoshT> ... then in f2f, we talked about what happens with unjoined ones. do we want to extend them across empty cells?
16:16:39 <JoshT> ... how exactly we're not sure, so we want to resolve on them today
16:16:51 <JoshT> ... we want to only join segments that we want to join
16:17:24 <JoshT> ... suggestion was: currently we have edge and interior points. instead, we could do 'does this point have a crossing decoration - something to join with - or not?'
16:17:28 <miriam> present+
16:17:31 <JoshT> ... we think this is the way forward
16:17:46 <JoshT> ... so 'does this end point meet an intersection or not?'
16:18:04 <JoshT> ... edge endpoints still don't have anything to join, so the author could still set a different behaviour
16:18:16 <JoshT> ... we might want to control them separately, still
16:18:57 <JoshT> ... question is 'edge' and 'interior' names don't make sense any more. Kevin asked on social media. 'cap' and 'junction' or 'open' and 'close'
16:19:04 <JoshT> s/close/closed/
16:19:24 <JoshT> ... our current behaviour is still preserved, but we can deal with the cases discussed in the f2f
16:19:41 <JoshT> astearns: suggestion is to choose between these two names?
16:19:56 <JoshT> javierct: we resolved on trimming the ones with no intersection to join with
16:20:14 <JoshT> ... proposal for that is this behaviour to move from edge/interior to some other distinction
16:20:27 <JoshT> ... we want to know if that's the correct way to solve this problem. and then work out the names
16:20:44 <kizu> kizu has joined #css
16:20:53 <JoshT> astearns: so for first part, do we continue with previous edge/interior distinction, or go with 'is there a junction or not'? options?
16:21:27 <JoshT> ... it makes sense to me. I'm concerned if people will say 'I want to treat the non existent junctions at the edge separately to interior ones'
16:21:44 <JoshT> javierct: that's something we considered. we don't have use cases to treat them differently
16:21:58 <JoshT> astearns: i would be happy to change it to the proposal
16:22:19 <JoshT> ... no other opinions. shall we resolve?
16:22:30 <emeyer> emeyer has joined #css
16:22:44 <JoshT> RESOLVED: go with new approach about whether there is a junction to handle or not
16:23:01 <JoshT> astearns: any opinions on name options? or additional options?
16:23:14 <bramus> junction seems fine
16:23:28 <JoshT> ... i prefer junction rather than open or closed is that it seems more direct
16:23:30 <hoch> +1 for junction
16:23:32 <JoshT> q+
16:23:38 <emeyer> +1 to junction (if we’re not going to use intersection)
16:23:55 <bramus> scribe+
16:23:58 <SebastianZ> For what it's worth, I agree with astearns.
16:24:00 <bkardell> junction seems pretty good
16:24:04 <astearns> ack JoshT
16:24:10 <bramus> JoshT: fan of junction, not sure what cap means
16:24:13 <kurt> kurt has joined #css
16:24:14 <davidjmarland> same
16:24:41 <bramus> javierct: look at diagrams here. cap is somewhat abstract I guess … would not know what it means in terms of english … like top or cap
16:25:04 <fantasai> fantasai has joined #css
16:25:05 <emeyer> +1
16:25:08 <astearns> ack ChrisL
16:25:08 <Zakim> ChrisL, you wanted to check this is for selectors-5, right?
16:25:09 <emeyer> q+
16:25:18 <bramus> … it is a bit abstract. the cap/junction was the most voted one in the bsky thread by kbabbitt
16:25:26 <bramus> … people were leaning towards it
16:25:27 <hoch> q+
16:25:36 <bramus> … one could make similar args about open/closed
16:25:55 <bramus> … could look at it as  ?? but agree with astearns that junction makes more sense
16:26:01 <bramus> JoshT: definitely agree with junction
16:26:20 <bramus> … in British English we might call cap a “dead end” more or “cul de sac”
16:26:24 <davidjmarland> short?
16:26:25 <PaulG> terminator?
16:26:35 <bkardell> oooh terminator
16:26:36 <emeyer> q-
16:26:52 <astearns> ack hoch
16:27:02 <rachelandrew> I thought terminator as well
16:27:10 <bramus> hoch: part of the origin of cap was from the CSS Propertye for svgs: stroke-line-cap
16:27:16 <emeyer> I was going to make the same point about SVG terminology.
16:27:21 <bramus> … so there is precedent fo rindicating this dangling line
16:27:22 <hoch> q-
16:27:25 <bramus> JoshT: makes sense
16:27:27 <bramus> +1
16:27:34 <JohnJansen> I thought "end cap" which I have on the end of my garden hose to prevent leaking...
16:27:57 <JoshT> astearns: shall we resolve on option A for now and leave it open for later bikeshedding?
16:28:16 <JoshT> PROPOSED: option A for naming, use 'junction' and 'cap'
16:28:33 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/22-css-minutes.html fantasai
16:28:42 <bkardell> I like terminator
16:28:56 <JoshT> RESOLVED: option A for naming, use 'junction' and 'cap'
16:29:33 <JoshT> astearns: in the write up, I think it should be called in option A put 'start' and 'end' values at the end of all of the longhands
16:29:34 <bramus> +1
16:29:44 <SebastianZ> +1
16:29:47 <davidjmarland> +1
16:29:54 <jBreiland> +1
16:30:01 <JoshT> github-bot, topic https://github.com/w3c/csswg-drafts/issues/13754
16:30:01 <github-bot> Topic: [css-gaps-1] Dropping decorations for suppressed gaps
16:30:01 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13754
16:30:01 <emeyer> +1
16:31:05 <JoshT> oSamDavis: issue was about assigning 13663, we resolved to add linear assignment
16:31:16 <JoshT> ... we've come back with some investigations
16:31:32 <JoshT> ... question of whether to ????, we want to drop in that case, but we don't want to drop by ?????
16:31:53 <JoshT> ... on the issue, we have a couple of examples why it would be confusing if done by default
16:32:09 <JoshT> ... although it could be common for authors to want to drop
16:32:14 <JoshT> ... we thought about other cases to drop
16:32:41 <JoshT> ... supressed gaps for fragmentation
16:32:55 <JoshT> ... we resolved to suppress the gaps when they coincide with fragment breaks
16:33:14 <JoshT> ... we want to drop decorations to match behaviour of printing when you want to preserve the pattern
16:33:39 <JoshT> ... for collapsed tracks in grid, we said assignment happens after tracks have collapsed
16:34:04 <JoshT> ... all in all, our proposal is number 1, we want to drop in flex but not by default. 2, we want to drop decorations that follow fragment breaks
16:34:17 <JoshT> ... and 3, we don't want to drop track collapse in grid
16:34:47 <JoshT> astearns: for 1, i understand that for multiline flex containers, we will not drop by default
16:35:01 <JoshT> ... but we want the option to drop between lines in a flex layout
16:35:06 <JoshT> ... seems reasonable
16:35:28 <JoshT> fantasai: probably the best way to know if we got the right call is to ship it and see who complains
16:35:31 <miriam> q+
16:35:40 <JoshT> astearns: that does increase compat risk, but edge case
16:36:01 <JoshT> miriam: i'm not sure if I understood your clarification. we're not suppressing at the wrap point?
16:36:25 <JoshT> fantasai: if you have a repeating one, then the pattern continues. you won't draw the decoration at the end because you skip it
16:36:51 <JoshT> oSamDavis: for role visibility items, we could have the drop on items that keep setting the same decorations
16:37:08 <JoshT> astearns: i also had miriam's confusion
16:37:32 <JoshT> ... we are not dropping the decoration. we are only changing how the decoration pattern is applied to exisiting gaps
16:37:56 <JoshT> fantasai: the alt proposal is assigning into that non-existing gap and therefore not drawing one of the items in the pack
16:38:18 <JoshT> astearns: let's not talk about dropping a decoration but applying the pattern to multiline flex containers
16:38:26 <fantasai> s/pack/list
16:38:52 <JoshT> PROPOSED: The gap decoration pattern is applied to the actual gaps that exist in a multiline flex layout
16:39:07 <JoshT> RESOLVED: The gap decoration pattern is applied to the actual gaps that exist in a multiline flex layout
16:39:26 <JoshT> astearns: given that way of expressing the 1st option, what is the second resolution about frag?
16:39:35 <astearns> ack miriam
16:39:46 <JoshT> oSamDavis: suppressed gaps, we apply the decoration to suppressed gaps
16:39:59 <JoshT> astearns: suppressed gaps are just those gaps that would fall on a frag boundary?
16:40:07 <JoshT> oSamDavis: yes so the pattern is preseved
16:40:24 <JoshT> astearns: for a fragmented flex layout, we assign gap decorations to ?????
16:40:32 <JoshT> oSamDavis: yes but to ????????
16:40:52 <astearns> s/????????/grid as well
16:41:06 <JoshT> fantasai: this relates to previous resolution. I think for that one, there's arguments in both directions. for this one, an author is going to notice when the gap gets out of sync
16:41:20 <JoshT> ... the proposed resolution makes sense. otherwise people will get things they don't expect
16:41:28 <fantasai> s/is going/is not going/
16:41:49 <JoshT> astearns: here we're talking about multiline frag breaks
16:42:09 <JoshT> PROPOSED: gaps that fall on an external fragmentation boundary consume a decoration from the pattern
16:42:32 <fantasai> +1
16:42:38 <JoshT> RESOLVED: gaps that fall on an external fragmentation boundary consume a decoration from the pattern
16:42:53 <JoshT> astearns: for track collapsing in grid?
16:43:30 <JoshT> oSamDavis: apply gap decorations to actual gaps in grid
16:43:46 <JoshT> ... it's what we resolved on in previous issue. just clarifying it's no change
16:44:02 <JoshT> astearns: is it clear that the resolutions we just took do not contradict the previous resolution
16:44:06 <JoshT> oSamDavis: yes
16:44:10 <JoshT> astearns: then we should be OK
16:44:25 <JoshT> fantasai: so if the gap is collapsed away, we pretend it's not there for gap decorations?
16:44:33 <JoshT> oSamDavis: yes
16:44:35 <JohnJansen> I do think it's important to clarify that this new resolution does not impact the previous resolution.
16:44:55 <JoshT> astearns: if it's clear that these new resolutions don't contradict, it can be an editorial point in the spec and we can move on
16:45:17 <JoshT> JohnJansen: i liked that we clarified that it does not contradict
16:45:25 <JoshT> astearns: it's in the minutes now so we can move on
16:45:46 <JoshT> github-bot, topic https://github.com/w3c/csswg-drafts/issues/3216
16:45:46 <github-bot> Topic: [css-selectors] Standardise `:⁠(‑moz‑)first‑node` and `:⁠(‑moz‑)last‑node`
16:45:46 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/3216
16:46:12 <JoshT> SebastianZ: the request to standardised -moz-first-node and -last-node has come up already
16:46:28 <JoshT> ... they select elements but also count the text nodes
16:46:47 <JoshT> ... say you want to style an element that should be the first node in a parent element, you would use these
16:47:17 <JoshT> ... there are some use cases in the issue. most common was related to styling icons and emojis differently depending on whether inside text or standalone
16:47:27 <JoshT> ... can we standardise these?
16:47:35 <JoshT> ... emilio wanted to remove them from Gecko
16:47:38 <emilio> q+
16:47:40 <JoshT> ... it seems they're slow
16:47:51 <JoshT> ... there are a few compelling cases to standardise
16:47:59 <astearns> ack fantasai
16:48:21 <astearns> ack emilio
16:48:25 <JoshT> ... my proposal was to extend the exisiting first-child and last-child classes to be functional and have attributes for whether to only select elements or also non-whitespace text
16:48:40 <JoshT> emilio: i am not sure if these selectors are the best way for these use cases
16:48:53 <JoshT> ... they were only implementing for supporting quirks mode stuff
16:49:04 <kizu> q+
16:49:06 <JoshT> ... we should change them to use something else because they are not defined
16:49:12 <JoshT> ... it's weird to care about nodes in CSS
16:49:24 <JoshT> ... I suppose column empty is a precedent
16:49:38 <astearns> q+
16:49:41 <JoshT> ... i think making the pseudo classes functional is weird. first-node would work as well
16:50:03 <JoshT> SebastianZ: :first-node would not work, because you're not selecting as a node. you want to select the element based on --
16:50:15 <JoshT> emilio: but for the emoji case, it's only the emoji that you want
16:50:18 <JoshT> SebastianZ: yeah
16:50:33 <astearns> ack kizu
16:50:49 <JoshT> kizu: this is something I have use cases for typography or styling buttons that could have text and other elements
16:51:01 <JoshT> ... often you want to check if the first thing is an element or something else
16:51:04 <emilio> q+
16:51:12 <JoshT> ... with icons you can add a margin. if it's just text, you can't do anything
16:51:23 <JoshT> ... same with anything where we generate boxes
16:51:39 <JoshT> ... these elements get styles based on how we do layouts, but you can't style them any other way externally
16:51:49 <JoshT> ... maybe there are other use cases for those
16:52:06 <JoshT> ... for functional notation, don't mind too much
16:52:25 <JoshT> ... for node, there are different notions for what it means in HTML and CSS
16:52:35 <JoshT> ... in CSS, the nodes are bundled up into one thing
16:52:52 <lea> q?
16:52:55 <lea> q+
16:52:57 <JoshT> ... and if you're in a whitespace context, you might want to know if something is between the beginning of an element and something inside
16:53:02 <astearns> ack fantasai
16:53:11 <JoshT> fantasai: +1 to kizu comments about what is a node
16:53:18 <JoshT> ... maybe not the right name
16:53:37 <JoshT> ... for functional pseudo class idea, clashes with the functional notation for nth-child
16:53:45 <JoshT> ... they should have a matching syntax
16:54:13 <JoshT> ... and for some use cases about preceding content in the parent, is it the first content in a fragmentation context like a line.
16:54:31 <JoshT> ... if it's at the beginning but it's on the second line, then this selector can't help you
16:54:44 <JoshT> astearns: I'm a little worried about the child node distinction
16:55:05 <JoshT> ... it's not immediately clear to me that I want to select this text that's not an element so I need to use first-node
16:55:26 <JoshT> ... the functional version seems worse because then you've got to say 'don't select a child'
16:55:55 <astearns> ack emilio
16:55:58 <astearns> ack astearns
16:56:01 <JoshT> ... if mozilla is considering removing these and other engines aren't implementing because it doesnt fit their priorities, i want to understand implementor interest
16:56:24 <JoshT> emilio: these selectors as implemented are mostly useful for block contexts
16:56:48 <JoshT> ... cases where whitespace is not relevant at block boundaries
16:57:07 <JoshT> ... the HTML target implements some quirks and they don't do the best job at it
16:57:35 <JoshT> ... styling the anon wrappers for grid and flex box seems doable
16:57:45 <JoshT> ... there are more questions like what kizu asked
16:57:50 <JoshT> ... as defined, they feel hacky
16:57:51 <JoshT> +1
16:57:56 <kizu> Random idea: `p:with-text(:first-child)` or something — a wrapping functional selector that modifies what selectors inside consider “children” to be, so any …-child will start counting the text nodes as well, etc.
16:58:19 <JoshT> ... if we were to implement these in the last ten years, they wouldn't have been exposed to content to begin with
16:58:28 <emeyer> emeyer has left #css
16:58:31 <JoshT> ... they accomplish the use cases in a hacky way
16:58:41 <JoshT> ... I don't feel standardising them is the best path
16:58:55 <JoshT> ... they are an easy thing to implement even if they're not fast, but they feel weird
16:59:08 <JoshT> SebastianZ: i want to note there is a difference in use cases
16:59:25 <JoshT> ... ones that select the element based on whether there's text nodes, and one is the text nodes themselves
16:59:36 <JoshT> ... we're just talking about styling the elements
17:00:05 <JoshT> emilio: if you have a span, and you have [space] svg [space], you might care about the whitespace but it doesn't seem relevant
17:00:17 <JoshT> ... these are the first non-whitespace text nodes
17:00:37 <JoshT> ... they are not what you want. they only make sense when you apply on things that are not block boundaries
17:00:56 <JoshT> astearns: out of time. we should continue discussing in the issue.
17:01:10 <JoshT> Topic: end
17:02:59 <astearns> zakim, end meeting
17:02:59 <Zakim> As of this point the attendees have been dshin-moz, kizu, SebastianZ, alisonmaher, hoch, jBreiland, rachelandrew, javierct, davidjmarland, JoshT, ChrisL, romain, JohnJansen, lea,
17:02:59 <Zakim> ... schenney, jfkthame, flackr, PaulG, bramus, bkardell, miriam
17:02:59 <Zakim> RRSAgent, please draft minutes v2
17:03:00 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/22-css-minutes.html Zakim
17:03:06 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:03:06 <Zakim> Zakim has left #css
17:14:41 <emeyer> emeyer has joined #css
17:35:04 <JohnJansen8> JohnJansen8 has joined #css
17:49:12 <NaN> NaN has joined #css
20:31:47 <antonp> antonp has joined #css
20:57:43 <TabAtkins> TabAtkins has joined #css