- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 22 Apr 2026 17:01:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-selectors] Standardise `:(‑moz‑)first‑node` and `:(‑moz‑)last‑node` ``. <details><summary>The full IRC log of that discussion</summary> <JoshT> SebastianZ: the request to standardised -moz-first-node and -last-node has come up already<br> <JoshT> ... they select elements but also count the text nodes<br> <JoshT> ... say you want to style an element that should be the first node in a parent element, you would use these<br> <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<br> <JoshT> ... can we standardise these?<br> <JoshT> ... emilio wanted to remove them from Gecko<br> <emilio> q+<br> <JoshT> ... it seems they're slow<br> <JoshT> ... there are a few compelling cases to standardise<br> <astearns> ack fantasai<br> <astearns> ack emilio<br> <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<br> <JoshT> emilio: i am not sure if these selectors are the best way for these use cases<br> <JoshT> ... they were only implementing for supporting quirks mode stuff<br> <kizu> q+<br> <JoshT> ... we should change them to use something else because they are not defined<br> <JoshT> ... it's weird to care about nodes in CSS<br> <JoshT> ... I suppose column empty is a precedent<br> <astearns> q+<br> <JoshT> ... i think making the pseudo classes functional is weird. first-node would work as well<br> <JoshT> SebastianZ: :first-node would not work, because you're not selecting as a node. you want to select the element based on --<br> <JoshT> emilio: but for the emoji case, it's only the emoji that you want<br> <JoshT> SebastianZ: yeah<br> <astearns> ack kizu<br> <JoshT> kizu: this is something I have use cases for typography or styling buttons that could have text and other elements<br> <JoshT> ... often you want to check if the first thing is an element or something else<br> <emilio> q+<br> <JoshT> ... with icons you can add a margin. if it's just text, you can't do anything<br> <JoshT> ... same with anything where we generate boxes<br> <JoshT> ... these elements get styles based on how we do layouts, but you can't style them any other way externally<br> <JoshT> ... maybe there are other use cases for those<br> <JoshT> ... for functional notation, don't mind too much<br> <JoshT> ... for node, there are different notions for what it means in HTML and CSS<br> <JoshT> ... in CSS, the nodes are bundled up into one thing<br> <lea> q?<br> <lea> q+<br> <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<br> <astearns> ack fantasai<br> <JoshT> fantasai: +1 to kizu comments about what is a node<br> <JoshT> ... maybe not the right name<br> <JoshT> ... for functional pseudo class idea, clashes with the functional notation for nth-child<br> <JoshT> ... they should have a matching syntax<br> <JoshT> ... and for some use cases about preceding content in the parent, is it the first content in a fragmentation context like a line.<br> <JoshT> ... if it's at the beginning but it's on the second line, then this selector can't help you<br> <JoshT> astearns: I'm a little worried about the child node distinction<br> <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<br> <JoshT> ... the functional version seems worse because then you've got to say 'don't select a child'<br> <astearns> ack emilio<br> <astearns> ack astearns<br> <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<br> <JoshT> emilio: these selectors as implemented are mostly useful for block contexts<br> <JoshT> ... cases where whitespace is not relevant at block boundaries<br> <JoshT> ... the HTML target implements some quirks and they don't do the best job at it<br> <JoshT> ... styling the anon wrappers for grid and flex box seems doable<br> <JoshT> ... there are more questions like what kizu asked<br> <JoshT> ... as defined, they feel hacky<br> <JoshT> +1<br> <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.<br> <JoshT> ... if we were to implement these in the last ten years, they wouldn't have been exposed to content to begin with<br> <JoshT> ... they accomplish the use cases in a hacky way<br> <JoshT> ... I don't feel standardising them is the best path<br> <JoshT> ... they are an easy thing to implement even if they're not fast, but they feel weird<br> <JoshT> SebastianZ: i want to note there is a difference in use cases<br> <JoshT> ... ones that select the element based on whether there's text nodes, and one is the text nodes themselves<br> <JoshT> ... we're just talking about styling the elements<br> <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<br> <JoshT> ... these are the first non-whitespace text nodes<br> <JoshT> ... they are not what you want. they only make sense when you apply on things that are not block boundaries<br> <JoshT> astearns: out of time. we should continue discussing in the issue.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3216#issuecomment-4298280570 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 April 2026 17:01:19 UTC