Re: [w3ctag/design-reviews] [WebComponents] Custom state pseudo class (#428)

@karlhorky thanks for the hint, but reading through that, this is my outcome:

  * it wasn't clear who would benefit from this or how, and this feature is shipping after more than person claimed it will be beneficial only (or mostly) for shadow root elements, which is a pity
  * differently from `el.attachShadow(...)`, the `el.attachInternals()` works only in certain conditions, creating conflicts with the fact that DOM APIs work with DOM nodes, period.
  * specs shipping questioning only Googlers don't represent well what the Web/JS ecosystem needs; I've been advocating Custom Elements (or anything DOM native, for what it matters) for dunno how many years, and I've learned about this proposal literally just today. Now, I'm not saying *I* should be involved in these discussions, but it would be awesome if specs would ask real-world DOM API users before landing on the browser, as it's clear to me this one in particular solves maybe one (imho edge) case, leaving everything else surpassed by frameworks land ... meaning, this spec won't likely convince anyone "_we improved the DOM with states_"
  * last, but not least, it looks like we're not learning by early shipping stuff nobody can use, and this spec looks like yet another example to point at

I know none of these points are your direct fault, but I also believe it's already too late to reconsider this proposal.

- - -

@annevk  about that ... 

> The CSS engine can inspect the element's states token list's token set directly.

It was silly/stupid of me thinking the JS would've played a role in the CSS side, but here is my quick feedback on the matter:

  * the documentation is currently misleading, as it looks like you need to expose a getter to communicate the state of a specific item to CSS (and of course, CSS wouldn't care about such getter, but it's not clear in the current reasoning/documentation regarding this proposal)
  * my proposal would make state handling more useful for all elements, not just shadow root, accepting already more kind of states, not just boolean (yep/nope) states, as classes, or attributes, including data attributes, do that already everywhere, without polyfills, and without Shadow DOM

Thanks anyway for the clarification, it made instant sense as soon as I've read it, yet please consider above points to maybe improve the current documentation, or specification, sate.

Best Regards.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/428#issuecomment-565617087