> To many HTML elements can slow the page to a crawl.

You can read the entirety of War and Peace in a single HTML file: https://standardebooks.org/ebooks/leo-tolstoy/war-and-peace/...

A marketing page, SaaS app landing, etc., will not even begin to approach that size, whether or not you add an extra wrapper around your <a>s.

HTML elements can style themselves now using the @scope rule. (It's Baseline Newly Available.) Unlike the "style" attribute, @scope blocks can include @media and other @ rules. You can't get more self-contained than this.

    <swim-lane>
        <style>
            @scope {
                background: pink;
                b {
                    background: lightblue
                }
                @media (max-width: 650px) {
                    /* Mobile responsive styles */
                }
            }
        </style>
        something <b>cool</b>
    </swim-lane>

    @scope (swim-lane) { /* ... */ }

Shadow DOM is awful. Nobody should be using it for anything, ever. (It's required for putting child-element "slots" in custom elements, and so nobody should use those, either.) Shadow DOM is like an iframe in your page; styles can't escape the shadow root and they can't get into the shadow root, either. IDs are scoped in shadow roots, too, so the aria-labelledby attribute can't get in or out, either.

@scope is the right abstraction: parent styles can cascade in, but the component's styles won't escape the element, giving you all of the (limited) performance advantages of Shadow DOM with none of the drawbacks.

There's a lot of contradictions in this comment.

> it's self-contained: it brings along its own dependencies, whether that's JavaScript, templates, CSS

> Also, don't do this [...] That just adds HTML bloat to the page, something people with a singular focus on eliminating JavaScript often forget to worry about. To many HTML elements can slow the page to a crawl.

A static JS-less page can handle a lot of HTML elements - "HTML bloat" isn't really a thing unless those HTML elements come with performance-impacting behaviour. Which "self-contained" web-components "bringing along their own dependencies" absolutely will.

> shouldn't require an external framework

If you're "bringing along your own dependencies" & you don't have any external framework to manage those dependencies, you're effectively loading each component instance as a kind of "statically linked" entity, whereby those links are in-memory. That's going to bloat your page enormously in all but the simplest of applications.

I might toss it out there that upcoming changes to attr() [0] as well as typed properties [1] will add some interesting features. Being able to provide a value that's subbed into a stylesheet from the HTML itself is neat.

You can try to get by with auto-generated selectors for every possible value today, ([background="#FFFFFF"]{background: #FFFFFF}[background="#FFFFFE"]{background: #FFFFFE}...) but just mapping attributes to styles 1:1 does begin to feel like a very lightweight component.

(Note... I'm not convinced this is a great idea... but it could be interesting to mess around with.)

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...

I disagree on the number of elements actually approaching problematic territory, but agree this just isn’t something you can’t do already without web components

According to the dictionary, the word component means "a part or element of a larger whole" which I think goes to the opposite direction of "self contained"