Im not sure what you're referring to, they seem pretty straightforward to me. Cr...

troupo · 2025-06-28T09:58:37 1751104717

You mean other than the 20+ web specs they added to platform (often to "fix" problems that they themselves introduced and/or that no one else has)? https://w3c.github.io/webcomponents-cg/2022.html (this list appeared after half a dozen or more specs had already been rammed through)

Or that their mere existence infects nearly every spec in existence delaying and needlessly complicating actual useful specs like Scoped CSS?

_benton · 2025-06-28T10:35:42 1751106942

I don't think it's surprising that a feature like web components would require new specs, isn't that how standard web features work?

troupo · 2025-06-28T21:46:04 1751147164

Usually a new feature:

- doesn't require 20+ web specs

- doesn't forget and then scramble to fix the most basic expected functionality like form participation

- doesn't pollute the space so badly that actual useful specs like Scoped CSS are delayed for years because now they have to deal with all the web coponent shenanigans

- hopefully doesn't take 15 years to barely do what others have been doing since time immemorial

JimDabell · 2025-06-28T15:24:43 1751124283

Let’s take this example:

    <!DOCTYPE html>
    <title>Example</title>
    <cool-dog>
        <template shadowrootmode="open">
            <style>
                :host {
                    display: block;
                    font-family: system-ui;
                    margin: auto;
                    width: fit-content;
                }
                ::slotted(img) {
                    border-radius: 1em;
                }
            </style>
            <slot></slot>
        </template>
        <img
            src="https://placedog.net/512/342?random"
            width="512"
            height="342"
            alt="A dog"
        >
        <p>Check out this cool dog!</p>
    </cool-dog>
    <script>
        customElements.define(
            "cool-dog",
            class extends HTMLElement {},
        );
    </script>

First off, what’s with the pointless JavaScript? There’s no need for imperative code here. All web components have a dash in the name; this can be inferred. But even if you want it to be explicit, this could be done with markup not imperative code. But no, it doesn’t work without the pointless JavaScript ritual.

Now, I’ve noticed that since the text is a caption for the image, I should actually use <figure> and <figcaption>. So let’s do that:

    <!DOCTYPE html>
    <title>Example</title>
    <cool-dog>
        <template shadowrootmode="open">
            <style>
                :host {
                    display: block;
                    font-family: system-ui;
                    margin: auto;
                    width: fit-content;
                }
                ::slotted(img) {
                    border-radius: 1em;
                }
            </style>
            <slot></slot>
        </template>
        <figure>
            <img
                src="https://placedog.net/512/342?random"
                width="512"
                height="342"
                alt="A dog"
            >
            <figcaption>Check out this cool dog!</figcaption>
        </figure>
    </cool-dog>
    <script>
        customElements.define(
            "cool-dog",
            class extends HTMLElement {},
        );
    </script>

Wait a sec! The nice round corners on the image have turned into ugly square ones. Why is that?

It’s because web components can’t style anything other than their direct children. You can style the <img> when it’s a direct child of the web component, but as soon as you need anything more complex than an entirely flat hierarchy, you run into problems. Even if it’s something as simple as wrapping an <img> in a <figure> to associate it with a <figcaption>.

What’s the “official” way of getting things like this done when you bring it up with the people working on the specs? Make a custom property to fake the real one and then set a global style that listens to the fake property to set it on the real one:

    <!DOCTYPE html>
    <title>Example</title>
    <style>
        img {
            border-radius: var(--border-radius);
        }
    </style>
    <cool-dog>
        <template shadowrootmode="open">
            <style>
                :host {
                    display: block;
                    font-family: system-ui;
                    margin: auto;
                    width: fit-content;
                    --border-radius: 1em;
                }
            </style>
            <slot></slot>
        </template>
        <figure>
            <img
                src="https://placedog.net/512/342?random"
                width="512"
                height="342"
                alt="A dog"
            >
            <figcaption>Check out this cool dog!</figcaption>
        </figure>
    </cool-dog>
    <script>
        customElements.define(
            "cool-dog",
            class extends HTMLElement {},
        );
    </script>

Now let’s say I want to put a second <cool-dog> element on the page. What does that look like? You define the template once and then just use <cool-dog> a bunch of times? That would be the obvious thing to do, right? Since it’s a template?

Nope. Every instance of the web component needs its own <template>. The best you can do is write some JavaScript to copy the template into each one.

The developer ergonomics of this stuff is terrible. It’s full of weird limitations and footguns.

throwitaway1123 · 2025-06-28T17:46:53 1751132813

> First off, what’s with the pointless JavaScript? There’s no need for imperative code here.

Exactly, I'm not sure why you've included the JS. The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively. To quote web.dev "This gives us the benefits of Shadow DOM's encapsulation and slot projection in static HTML. No JavaScript is needed to produce the entire tree, including the Shadow Root." [1]

[1] https://web.dev/articles/declarative-shadow-dom#how_to_build....

troupo · 2025-06-28T21:47:50 1751147270

> The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively.

It's a pipe dream that doesn't work in practice. Because on its own declarative shadow dom is useless.

throwitaway1123 · 2025-06-28T22:10:21 1751148621

You clearly have an axe to grind, and I'm not particularly interested in proselytizing. If you don't find the Declarative Shadow DOM useful, that's fine!

The example I was responding to was using the Declarative Shadow DOM. My comment was intended to point out the simple fact that the imperative component definition the author was complaining about is superfluous, meaning you can safely remove that entire script from the example.

_benton · 2025-06-29T15:28:33 1751210913

I'm so fascinated by the few people online who show up to anything web component related just to flame and complain. It's always the same things too.

DSD is useful for SSRing web components, which allows them to render and work without JS. But honestly, I don't get the obsession with doing stuff without JS, it's part of the html/css/js trifecta.