- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Sep 2024 22:41:51 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo] more clearly define which pseudo-elements are tree-abiding or part-like`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Related: https://github.com/w3c/csswg-drafts/pull/10839/files<br> <dholbert> dbaron: we introduced this concept of ::part-like pseudo-elements<br> <dholbert> dbaron: there's a few different ways to think about it; I like to think it's a pseudo-element where underneath there's actually an element. So you can do most things with it<br> <dholbert> dbaron: ::part lets you use a pseudo element that was part of the shadow tree<br> <dholbert> dbaron: we're adding another way to do for form-controls that's similar<br> <dholbert> dbaron: we've added tree-abiding pseudo elements. they support a smaller set of things. General assumption: we can make a tree out of them<br> <dholbert> dbaron: they're not things like ::selection that cross the tree in random ways<br> <dholbert> dbaron: they're like ::before which lives in the tree at this place, and it has clearly-defined before/after siblings<br> <dholbert> dbaron: we have a lot of pseudo-elements in different specs. We need to be sure the ones that should be defined as ::part-like are defined that way, and same for tree-abiding, and we should say which ones aren't those things too<br> <dholbert> dbaron: I tried to make a list of which pseudo-elements go in each bucket<br> <emilio> q+<br> <dholbert> dbaron: I'd like other folks to take a look, especially the ones that I put question marks next to<br> <dholbert> dbaron: this is in the last comment in the issue, https://github.com/w3c/csswg-drafts/issues/10794#issuecomment-2379912294<br> <Rossen6> ack fantasai<br> <dholbert> fantasai: there are multiple categories of pseudo-elements. we should be sure the names for the categories are reasonable<br> <dholbert> fantasai: "tree-abiding" seems reasonable. we have some that are restricted in terms of which properties they can take (e.g. ::before vs ::marker)<br> <dholbert> fantasai: "tree-abiding and takes any property", "tree-abiding but restricted", and "part-like" -- are those the 3 categories?<br> <dholbert> dbaron: we've already allowed pseudo elements to have hand-written restrictions<br> <dholbert> dbaron: everything not in the ::part-like bucket has some restrictions hand-written at its definition<br> <dholbert> dbaron: there are also a bunch of general rules about how selectors combine, more than about what properties are used<br> <dholbert> dbaron: ::part-like pseudo elements do allow any properties, but the more interesting part is about how you can combine selectors<br> <dholbert> dbaron: anything that's not part-like has custom prose saying which properties are allowed<br> <kbabbitt> q+<br> <Rossen6> ack emilio<br> <flackr> w.r.t. having a known location in the tree, see https://drafts.csswg.org/css-animations-2/#animation-composite-order<br> <dholbert> emilio: I think your list is pretty reasonable. I don't think all the tree-abiding pseudos support the content property<br> <dholbert> dbaron: that was me reading the spec, not checking reality<br> <dholbert> dbaron: I looked through all the specs for things that reference those definitions<br> <dholbert> dbaron: in reality support for the content property does not match the spec<br> <dholbert> emilio: ::backdrop might not be implemented as an element in all engines... as a box, in all engines?<br> <dholbert> fantasai: that's how it should be defined. There's no reason for it to have an element backing...<br> <dholbert> emilio: not sure if all impls make it an element. if they don't make it an element, I'm not sure it should be tree-abiding?<br> <andreubotella> q+<br> <dholbert> fantasai: it does fit in the tree. stuff that's not tree-abiding is stuff that crosses element boundaries. ::first-letter, ::first-line, all that stuff<br> <kbabbitt> q-<br> <dholbert> emilio: ::cue might be ::part-like<br> <dholbert> emilio: and also [...]<br> <dholbert> emilio: for now we can go with -- if an engine doesn't implement it as a part, we can consider it not-part-like, and we can sort out more later<br> <dholbert> emilio: my other intuition for part-like vs. not is whether there's an actual dom element behind it, that isn't created by layout<br> <dholbert> emilio: (::before and ::after and ::marker are special)<br> <dholbert> emilio: but generally, my list would match yours, except for maybe ::backdrop and ::cue<br> <Rossen6> ack andreubotella<br> <emilio> perhaps ::placeholder could be part-like<br> <emilio> Once we define how `<input>` is laid out<br> <emilio> One of these days ;)<br> <dholbert> andreubotella: you could think of ??? as selecting something in the flattened element tree, tree-abiding as selecting something in the box tree<br> <kbabbitt> s/???/part-like/<br> <dholbert> andreubotella: do these pseudo-elements have some particular distinction? does it make sense to group them in this way, depending on what they select into?<br> <jarhar> q?<br> <dholbert> andreubotella: first and last select into the fragment tree, and nth-fragment also<br> <kbabbitt> s/first and last/::first-line and ::nth-fragment()/<br> <dholbert> andreubotella: does it make sense to treat these as a separate category? or are the restrictions on those similar enough to the groups you've defined already?<br> <dholbert> dbaron: It may well make sense to describe that as a category<br> <dholbert> dbaron: I'm not aware of any common definition, so I'm hesitant to define spec terms if we don't have a reason to do so<br> <dholbert> dbaron: but the classification makes some sense<br> <jarhar> q+<br> <kbabbitt> I think dbaron's list makes sense for the selectors that I understand<br> <dholbert> dbaron: might be premature to take a resolution on this one. but I'd encourage discussion on the issue<br> <Rossen6> ack jarhar<br> <dholbert> jarhar: for the classification question/concepts: hopefully this is related... On Mon or Tues at a joint meeting, I brought up whether new pseudo elements for customizable select should be before-like or part-like<br> <dholbert> jarhar: there weren't spec concepts for this but it's important for implementation<br> <dholbert> jarhar: if I want to make it part-like, I need to wire it to shadow tree, real element in the tree, etc<br> <dholbert> jarhar: would be useful to have some kind of distinction for implementors, to help steer impl strategies<br> <dholbert> jarhar: (on new pseudos)<br> <emilio> q+<br> <dholbert> emilio: that's the main distinction. tree-abiding may encompass other things that are like generated content<br> <dholbert> emilio: we want to make part-like be things that have an element behind, unrelated to the styling of the parent<br> <dholbert> emilio: that's how a lot of the form-control shadow trees are implemented<br> <Rossen6> ack emilio<br> <dholbert> emilio: I'm pretty sure gecko/webkit have same kinds of assumptions about generated content. It'd be kinda hard to support a lot of these pseudo-classes on before/after<br> <dholbert> emilio: depending on how we decide to make a pseudo-element work, you need to take one approach or the other to implmeent it<br> <dholbert> fantasai: could you implement a tree-abiding as a part-like pseudo-element?<br> <dholbert> emilio: you could, it'd be more restricted<br> <dholbert> emilio: if you have an actual DOM element, you can implement a part-like and tree-abiding pseudo-element<br> <dholbert> fantasai: you can't implement a part-like pseudo without an actual element backing it, without a lot of work<br> <dholbert> fantasai: ...<br> <dholbert> emilio: that's how placeholder is implemented in webkit and blink<br> <fantasai> s/.../but you could implement tree-abiding as a part-like pseudo-element with some disabled features/<br> <dholbert> emilio: we could change how gecko works to work that way too<br> <dholbert> emilio: but that's not great if we don't define what tree it is and what it works<br> <dholbert> Rossen6: let's move on<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10794#issuecomment-2380241579 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 September 2024 22:41:52 UTC