– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

<JoshT> github-bot, topic w3c/csswg-drafts#13804

[css-pseudo] Add ::backdrop and ::view-transitions to the CSSPseudoElement's allowed pseudo-elements list

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#13804

<JoshT> sakhapov: now have the pseudo element JS interface

<JoshT> ... biggest useful thing would be events

<JoshT> ... click on some pseudo element in the target

<JoshT> ... pseudo elements supports before and after. could add ::backdrop and ::view-transitions as well

<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

<JoshT> ... with this, you just check if the click target was the pseudo element

<JoshT> ... for ::v-t, bramus shows if you have an ongoing v-t, you can intercept to start a new one

<JoshT> ... for scroll-marker and scroll-buttons, you could target them

<JoshT> ... proposal is to follow Rob's suggestion to add all tree abiding elements to pseudo element interface

<JoshT> flackr: given that proposal, that sounds good. we know strong use case for the scroll pseudos

<bramus> +1 on tree-abiding

<JoshT> ... tree abiding elements have well established way of working

<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?

<JoshT> flackr: you get the event anyway. this is about if the target is a pseudo

<JoshT> ... for unsupported, you just have no target but still see the event

<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

<JoshT> flackr: that's the situation today

<JoshT> emilio: did we figure out how in out events behave with pseudos?

<JoshT> ... do you get a mouse event?

<JoshT> sakhapov: we decided to disable for now

<JoshT> flackr: they don't cause boundary events

<JoshT> ... you just say this event is targetted to the pseudo

<JoshT> emilio: so you cannot observe whether ???

<JoshT> ... concern is whether all tree abiding elements doesn't include non standard stuff

<JoshT> ... presumably it would include ::-webkit-, which could cause compat problems

<JoshT> ... there are some details about layout of other tree abiding elements, but maybe that's ok

<JoshT> ... concerned about people building custom effects for inputs that only work on -webkit- pseudos

<JoshT> flackr: i'd support adding a condition for only standard pseudos

<JoshT> sakhapov: considered adding select, but I will raise a new issue

<JoshT> emilio: for pseudos that represent multiple things, it's tricker

<JoshT> ... these aren't part of the resolution because they're real elements

<JoshT> sakhapov: maybe I can get a specific list of what we have and if no one objects, we can accept

<JoshT> astearns: a list instead of the general tree abiding elements solution?

<JoshT> sakhapov: maybe not? we can go with the general solution

<JoshT> astearns: my preference is the standard tree abiding pseudos with some examples like '::part included because it's an element' etc

<JoshT> PROPOSED: use the CSSPseudo interface for all standardised tree-abiding pseudo elements

<JoshT> ChrisL: this is for selectors-5, not 4, right?

<JoshT> sakhapov: this is in pseudo elements 4

RESOLUTION: use the CSSPseudoElements interface for all standardised tree-abiding pseudo elements

<JoshT> github-bot, topic w3c/csswg-drafts#13697

[css-gaps-1] `overlap-join` with `between` rule visibility

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#13697

<JoshT> javierct: [shares screen]

<JoshT> ... we have resolved on overlap-join to join decorations

<JoshT> ... then in f2f, we talked about what happens with unjoined ones. do we want to extend them across empty cells?

<JoshT> ... how exactly we're not sure, so we want to resolve on them today

<JoshT> ... we want to only join segments that we want to join

<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?'

<JoshT> ... we think this is the way forward

<JoshT> ... so 'does this end point meet an intersection or not?'

<JoshT> ... edge endpoints still don't have anything to join, so the author could still set a different behaviour

<JoshT> ... we might want to control them separately, still

<JoshT> ... question is 'edge' and 'interior' names don't make sense any more. Kevin asked on social media. 'cap' and 'junction' or 'open' and 'closed'

<JoshT> ... our current behaviour is still preserved, but we can deal with the cases discussed in the f2f

<JoshT> astearns: suggestion is to choose between these two names?

<JoshT> javierct: we resolved on trimming the ones with no intersection to join with

<JoshT> ... proposal for that is this behaviour to move from edge/interior to some other distinction

<JoshT> ... we want to know if that's the correct way to solve this problem. and then work out the names

<JoshT> astearns: so for first part, do we continue with previous edge/interior distinction, or go with 'is there a junction or not'? options?

<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'

<JoshT> javierct: that's something we considered. we don't have use cases to treat them differently

<JoshT> astearns: i would be happy to change it to the proposal

<JoshT> ... no other opinions. shall we resolve?

RESOLUTION: go with new approach about whether there is a junction to handle or not

<JoshT> astearns: any opinions on name options? or additional options?

junction seems fine

<JoshT> ... i prefer junction rather than open or closed is that it seems more direct

<hoch> +1 for junction

<emeyer> +1 to junction (if we’re not going to use intersection)

<SebastianZ> For what it's worth, I agree with astearns.

<bkardell> junction seems pretty good

JoshT: fan of junction, not sure what cap means

<davidjmarland> same

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

<emeyer> +1

<Zakim> ChrisL, you wanted to check this is for selectors-5, right?

javierct: it is a bit abstract. the cap/junction was the most voted one in the bsky thread by kbabbitt
… people were leaning towards it
… one could make similar args about open/closed
… could look at it as ?? but agree with astearns that junction makes more sense

JoshT: definitely agree with junction
… in British English we might call cap a “dead end” more or “cul de sac”

<davidjmarland> short?

<PaulG> terminator?

<bkardell> oooh terminator

<rachelandrew> I thought terminator as well

hoch: part of the origin of cap was from the CSS Propertye for svgs: stroke-line-cap

<emeyer> I was going to make the same point about SVG terminology.

hoch: so there is precedent fo rindicating this dangling line

JoshT: makes sense

<bramus> +1

<JohnJansen> I thought "end cap" which I have on the end of my garden hose to prevent leaking...

<JoshT> astearns: shall we resolve on option A for now and leave it open for later bikeshedding?

<JoshT> PROPOSED: option A for naming, use 'junction' and 'cap'

<bkardell> I like terminator

RESOLUTION: option A for naming, use 'junction' and 'cap'

<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

<bramus> +1

<SebastianZ> +1

<davidjmarland> +1

<jBreiland> +1

<JoshT> github-bot, topic w3c/csswg-drafts#13754

[css-gaps-1] Dropping decorations for suppressed gaps

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#13754

<emeyer> +1

<JoshT> oSamDavis: issue was about assigning 13663, we resolved to add linear assignment

<JoshT> ... we've come back with some investigations

<JoshT> ... question of whether to ????, we want to drop in that case, but we don't want to drop by ?????

<JoshT> ... on the issue, we have a couple of examples why it would be confusing if done by default

<JoshT> ... although it could be common for authors to want to drop

<JoshT> ... we thought about other cases to drop

<JoshT> ... supressed gaps for fragmentation

<JoshT> ... we resolved to suppress the gaps when they coincide with fragment breaks

<JoshT> ... we want to drop decorations to match behaviour of printing when you want to preserve the pattern

<JoshT> ... for collapsed tracks in grid, we said assignment happens after tracks have collapsed

<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

<JoshT> ... and 3, we don't want to drop track collapse in grid

<JoshT> astearns: for 1, i understand that for multiline flex containers, we will not drop by default

<JoshT> ... but we want the option to drop between lines in a flex layout

<JoshT> ... seems reasonable

<JoshT> fantasai: probably the best way to know if we got the right call is to ship it and see who complains

<JoshT> astearns: that does increase compat risk, but edge case

<JoshT> miriam: i'm not sure if I understood your clarification. we're not suppressing at the wrap point?

<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

<JoshT> oSamDavis: for role visibility items, we could have the drop on items that keep setting the same decorations

<JoshT> astearns: i also had miriam's confusion

<JoshT> ... we are not dropping the decoration. we are only changing how the decoration pattern is applied to exisiting gaps

<JoshT> fantasai: the alt proposal is assigning into that non-existing gap and therefore not drawing one of the items in the list

<JoshT> astearns: let's not talk about dropping a decoration but applying the pattern to multiline flex containers

<JoshT> PROPOSED: The gap decoration pattern is applied to the actual gaps that exist in a multiline flex layout

RESOLUTION: The gap decoration pattern is applied to the actual gaps that exist in a multiline flex layout

<JoshT> astearns: given that way of expressing the 1st option, what is the second resolution about frag?

<JoshT> oSamDavis: suppressed gaps, we apply the decoration to suppressed gaps

<JoshT> astearns: suppressed gaps are just those gaps that would fall on a frag boundary?

<JoshT> oSamDavis: yes so the pattern is preseved

<JoshT> astearns: for a fragmented flex layout, we assign gap decorations to ?????

<JoshT> oSamDavis: yes but to grid as well

<JoshT> fantasai: this relates to previous resolution. I think for that one, there's arguments in both directions. for this one, an author is not going to notice when the gap gets out of sync

<JoshT> ... the proposed resolution makes sense. otherwise people will get things they don't expect

<JoshT> astearns: here we're talking about multiline frag breaks

<JoshT> PROPOSED: gaps that fall on an external fragmentation boundary consume a decoration from the pattern

<fantasai> +1

RESOLUTION: gaps that fall on an external fragmentation boundary consume a decoration from the pattern

<JoshT> astearns: for track collapsing in grid?

<JoshT> oSamDavis: apply gap decorations to actual gaps in grid

<JoshT> ... it's what we resolved on in previous issue. just clarifying it's no change

<JoshT> astearns: is it clear that the resolutions we just took do not contradict the previous resolution

<JoshT> oSamDavis: yes

<JoshT> astearns: then we should be OK

<JoshT> fantasai: so if the gap is collapsed away, we pretend it's not there for gap decorations?

<JoshT> oSamDavis: yes

<JohnJansen> I do think it's important to clarify that this new resolution does not impact the previous resolution.

<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

<JoshT> JohnJansen: i liked that we clarified that it does not contradict

<JoshT> astearns: it's in the minutes now so we can move on

<JoshT> github-bot, topic w3c/csswg-drafts#3216

[css-selectors] Standardise `:⁠(‑moz‑)first‑node` and `:⁠(‑moz‑)last‑node`

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#3216

<JoshT> SebastianZ: the request to standardised -moz-first-node and -last-node has come up already

<JoshT> ... they select elements but also count the text nodes

<JoshT> ... say you want to style an element that should be the first node in a parent element, you would use these

<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

<JoshT> ... can we standardise these?

<JoshT> ... emilio wanted to remove them from Gecko

<JoshT> ... it seems they're slow

<JoshT> ... there are a few compelling cases to standardise

<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

<JoshT> emilio: i am not sure if these selectors are the best way for these use cases

<JoshT> ... they were only implementing for supporting quirks mode stuff

<JoshT> ... we should change them to use something else because they are not defined

<JoshT> ... it's weird to care about nodes in CSS

<JoshT> ... I suppose column empty is a precedent

<JoshT> ... i think making the pseudo classes functional is weird. first-node would work as well

<JoshT> SebastianZ: :first-node would not work, because you're not selecting as a node. you want to select the element based on --

<JoshT> emilio: but for the emoji case, it's only the emoji that you want

<JoshT> SebastianZ: yeah

<JoshT> kizu: this is something I have use cases for typography or styling buttons that could have text and other elements

<JoshT> ... often you want to check if the first thing is an element or something else

<JoshT> ... with icons you can add a margin. if it's just text, you can't do anything

<JoshT> ... same with anything where we generate boxes

<JoshT> ... these elements get styles based on how we do layouts, but you can't style them any other way externally

<JoshT> ... maybe there are other use cases for those

<JoshT> ... for functional notation, don't mind too much

<JoshT> ... for node, there are different notions for what it means in HTML and CSS

<JoshT> ... in CSS, the nodes are bundled up into one thing

<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

<JoshT> fantasai: +1 to kizu comments about what is a node

<JoshT> ... maybe not the right name

<JoshT> ... for functional pseudo class idea, clashes with the functional notation for nth-child

<JoshT> ... they should have a matching syntax

<JoshT> ... and for some use cases about preceding content in the parent, is it the first content in a fragmentation context like a line.

<JoshT> ... if it's at the beginning but it's on the second line, then this selector can't help you

<JoshT> astearns: I'm a little worried about the child node distinction

<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

<JoshT> ... the functional version seems worse because then you've got to say 'don't select a child'

<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

<JoshT> emilio: these selectors as implemented are mostly useful for block contexts

<JoshT> ... cases where whitespace is not relevant at block boundaries

<JoshT> ... the HTML target implements some quirks and they don't do the best job at it

<JoshT> ... styling the anon wrappers for grid and flex box seems doable

<JoshT> ... there are more questions like what kizu asked

<JoshT> ... as defined, they feel hacky

<JoshT> +1

<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.

<JoshT> ... if we were to implement these in the last ten years, they wouldn't have been exposed to content to begin with

<JoshT> ... they accomplish the use cases in a hacky way

<JoshT> ... I don't feel standardising them is the best path

<JoshT> ... they are an easy thing to implement even if they're not fast, but they feel weird

<JoshT> SebastianZ: i want to note there is a difference in use cases

<JoshT> ... ones that select the element based on whether there's text nodes, and one is the text nodes themselves

<JoshT> ... we're just talking about styling the elements

<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

<JoshT> ... these are the first non-whitespace text nodes

<JoshT> ... they are not what you want. they only make sense when you apply on things that are not block boundaries

<JoshT> astearns: out of time. we should continue discussing in the issue.

end