- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Sep 2024 22:14:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-shadow-parts] are rules for which pseudo-classes and pseudo-elements work after ::part() parse-time or match-time?`, and agreed to the following: * `RESOLVED: reject these invalid selectors at parse time` <details><summary>The full IRC log of that discussion</summary> <dholbert> dbaron: I filed a series of pseudo-element issues. this first one was a case where spec was written after impls/tests were written<br> <dholbert> dbaron: impls are interoperable and disagree with spec<br> <dholbert> dbaron: spec says some pseudo elements / classes work after ::part<br> <dholbert> dbaron: but all of them are supposed to be syntactically allowed at parse time, and the ones that don't work just don't match<br> <dholbert> dbaron: but impls reject at parse time the ones that don't work<br> <dholbert> dbaron: TabAtkins prefers what the spec says<br> <dholbert> dbaron: TabAtkins thinks parse-time selector restrictions haven't been very successful and we shouldn't add more of them<br> <TabAtkins> +1<br> <dholbert> dbaron: counterargument: it's already implemented across 3 engines, so changing impls might have some level of risk<br> <keithamus> q+<br> <dholbert> dbaron: Also, it's more consistent with other pseudo-elements<br> <florian> q+<br> <dholbert> dbaron: other pseudos that don't do anything are invalid at parse time<br> <emilio> q+<br> <dholbert> dbaron: [gives an example with two ::before elements]<br> <dholbert> dbaron: my inclination is to do easy thing and change spec to match the impls + tests<br> <lea> q+ to ask, it sounds like there's a clear upside to doing the validation at match time. What's the downside?<br> <dholbert> dbaron: this is widely tested in WPTs. We could just change the spec and say we've got it already implemented and tested<br> <kbabbitt> s/two ::before elements/::before::before selector, which is invalid/<br> <dholbert> dbaron: I'd like us to do that, or to hear a convincing argument in the other direction<br> <Rossen6> ack keithamus<br> <dholbert> ???: another benefit is that impls can highlight this in devtools<br> <lea> We can address that head-on by providing a method to test whether selectors are valid<br> <dbaron> s/???/keithamus/<br> <dholbert> keithamus: that's another argument for the parse-time restriction<br> <Rossen6> ack florian<br> <dholbert> florian: people who put tests in WPTs are welcome to change the spec & file spec bugs<br> <dholbert> florian: we should generally be more careful about this<br> <dholbert> dbaron: in this particular case, the tests were mostly testing other things. They were testing the rules for what wasn't allowed, and they didn't realize that there was stuff about it being a parse-time restriction<br> <dholbert> florian: there's a significant difference between things that are currently invalid are strongly expected to stay invalid forever, vs. if it may someday change<br> <dholbert> florian: if we treat a selector as a parse-time error and we want to make it valid in the future, that'll be painful<br> <dholbert> florian: But if we know these are going to be invalid forever, I have an easier time agreeing with your position<br> <Rossen6> ack emilio<br> <dholbert> emilio: I think parse-time is generally better; it works better with @supports<br> <dholbert> emilio: (and CSS.supports, etc)<br> <astearns> +1 to emilio and keithamus<br> <dholbert> emilio: I was going to also argue that impl-wise it's better not to have to deal with sort-of valid states, but we have to deal with that with nesting anyways<br> <dholbert> emilio: but yeah, @supports makes parse-time checking very valuable<br> <dholbert> emilio: if you want match-time restriction, you can use :is or :where<br> <dholbert> emilio: given we have a way of doing both things, I lean towards fixing the spec to match reality<br> <dholbert> florian: I'd be more ??? if we had selector invalidation at each ??? [agreeing I think]<br> <dholbert> dbaron: given the later issues I want to discuss, there might be a few strange cases of restrictions where we want to relax in the future<br> <dholbert> dbaron: but in most cases the restrictions are solid because it just doesn't make sense<br> <dholbert> lea: it sounds like there are upsides & downsides<br> <Rossen6> ack lea<br> <Zakim> lea, you wanted to ask, it sounds like there's a clear upside to doing the validation at match time. What's the downside?<br> <florian> s/I'd be more ???/I'd be more comfortable with the proposal<br> <dholbert> lea: sounds like arguments for parse-time checking are for testing if something's supported<br> <kbabbitt> q+<br> <dholbert> lea: is there a way we could add a way to check for if something is valid that would account for this case, and if we can, are there remaining arguments?<br> <florian> s/ if we had selector invalidation at each ???/ if we had selector error recovery at each comma, but especially given the availability of :is and :where, I think that's fine.<br> <Rossen6> ack kbabbitt<br> <dholbert> kbabbitt: does document.querySelector throw on an invalid selector, and that could be used to check for validity?<br> <dholbert> lea: only throws at parse time<br> <dholbert> lea: all our tools right now check for validity at parse-time<br> <dholbert> kbabbitt: you're looking for a way to check whether a selector that's valid at parse time is valid when used?<br> <dholbert> lea: sort of, yes<br> <dholbert> dbaron: we just listed 3 different ways for checking whether selectors are valid, and they're all the parse-time version<br> <dholbert> dbaron: it'd be confusing to add another way that checks at a different time<br> <dholbert> lea: who was arguing for making it invalid at match time?<br> <dholbert> [various]: Tab<br> <dholbert> dbaron: TabAtkins is OK either way but would prefer match time<br> <dholbert> Rossen6: we're leaning towards fixing the spec & going with parse time<br> <Rossen6> q?<br> <dholbert> Rossen6: objections?<br> <dholbert> RESOLVED: reject these invalid selectors at parse time<br> <dholbert> (fixing the spec to match reality)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10786#issuecomment-2380205005 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:14:14 UTC