Lit: a library for building fast, lightweight web components

I had lit in a project at work and not having to deal with it anymore is just great. We already have another heavier component framework to do the actual application stuff anyway, so having two just because somebody wanted to optimize their resume was such a drag.

It all looked nice in theory, but one thing shadow DOM makes worse is A11y, because element ids are now scoped and all the missing describe-by, label-for for things that should link to other side of the fence are a massive pain in the ass.

Big part of it is just skill issue on our part of course.

Shadow DOM is optional in Lit - you can just disable it on a per-component basis.

causes a bunch of things to no longer work though - slots, style encapsulation, ...

And that's the biggest problem with Shadow DOM (and most web component specs): you can't chose the good parts. Style encapsulation is useful, slots are useful, Shadow DOM is just all around bad, having a crazy amount of edge cases and broken behaviours [1].

Can you use style encapsulation and slots without Shadow DOM? Why can't you? I only need the horse, not the horse, and the cart, and the driver, and all the cargo in the cart.

You can't because people pushing all this stuff forward never ever stopped to think whether this was a good idea, and never ever talked to anyone outside of their own group.

[1] I will keep quoting this report by Web Components Working Group to death:

--- start quote --

It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.

...

Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. While there are ways to develop these UIs by orchestrating the relationships between elements of synthesizing the passing of content across a shadow boundary, these practices generally position accessible development out of reach for most developers, both at component creation and component consumption time.

...

Selection does not work across or within shadow roots. This makes fully-featured rich-text editors impossible to implement with web components. Some of the web's most popular editors have issues that are blocked on this functionality.

--- end quote ---