Re: [csswg-drafts] [selectors-4] Add pseudo-class to establish before-change style for css-transitions on new elements. (#8174)

> There was discussion in [#8174 (comment)](https://github.com/w3c/csswg-drafts/issues/8174#issuecomment-1379224022) about pseudo-class versus pseudo-element, but I didn't feel that that discussion came to much of a conclusion, and I think I probably lean towards a pseudo-element rather than a pseudo-class (which is where I thought that previous discussion was leaning).
> 
> I fully admit that this has some aspects of either -- it's unlike a pseudo-element in that it matches the same _thing_ as the element -- but it does so at a different _time_ (for a somewhat interesting definition of "time").
> 
> I think the restrictions proposed above look a lot like the restrictions that we would put on a pseudo-element, and are quite unusual for a pseudo-class. In particular, the "only does something on the subject of the selector" really makes it feel quite like a pseudo-element.

Yes, I agree.

One concern for me is that resolving on matching `:initial` inside `:is()` if all selectors in the list matches `:initial` in all branches, is that we are resolving specifically for `:initial` what is a general problem for pseudo elements if we chose to use a pseudo element instead.

You could similarly say that pseudo elements could be supported in :is() if all arguments select the same pseudo element:

`:is(.a::before, .b::before)` can match, but not `:is(.a, .b::before)` for instance.

For CSS Nesting, we currently do not allow (because of :is):

```
::before {}
  div& {}
}
```

Same limitation would apply to an `::initial` pseudo element, which is also what my proposed :is/:where restriction does.

> I also think as a pseudo-class people might reasonably expect it to work when applied to something other than the subject. As a pseudo-class, I think that `div:initial p` is conceptually the same as `div p:initial` -- it would seem that both should affect the before-change style of a p that is a descendant of a div -- since the before-change style of the p inherits from the before-change style of its ancestor (etc.). I think that these selectors really seem to do the same thing perhaps argues for it being a pseudo-element -- although as noted above that particular situation is different from the existing pseudo-classes and pseudo-elements since it's a difference of "time" rather than object identity.

I don't find it intuitive that `div:initial p` matches `:initial` when computing initial styles for `<p>` since it is matching the compound that is matching the `<div>` element.

> There's also a rather significant substantive difference between a pseudo-class and a pseudo-element in terms of cascading. For example compare this situation:
> 
> ```css
> :any-link { color: blue; transition: color 1s; }
> :any-link#signature { color: green; }     /* overrides :link:initial */
> :any-link:initial { color: purple; }      /* does not affect transition of #signature */
> ```
> 
> with this situation:
> 
> ```css
> :any-link { color: blue; transition: color 1s; }
> :any-link#signature { color: green; }     /* does not override :link:initial */
> :any-link::initial { color: purple; }     /* affects transitions of all links, including #signature */
> ```

Is that because the pseudo element would cascade separately?

How would that mix with the non-::initial styles. Would you need to repeat all the styles that do not differ between ::initial and not, or do you apply the pseudo element styles on top of the other styles somehow?

> I'm not sure which cascading setup is preferable, but they're definitely different, and my intuition is that I prefer the pseudo-element version since I think of before-change style as different (even if it's different in "time" rather than object identity).


-- 
GitHub Notification of comment by lilles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8174#issuecomment-1451493539 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 2 March 2023 08:39:22 UTC