Comment by CafeRacer

2 days ago

I spent days building this little perfect dropdown select thing, that is a hundreds lines of code and even more docs explaining what the hell is going on. Someone wasted the same amount of time before me. Someone else spent a lot of time before them. And so on.

I wish we have had more browser native implementations including some notion of virtual lists so the browser would not choke when rendering a lot of content.

---

Eventually, this would be same as border-radius. It will get implemented and we'll forget about that forever.

9 comments

CafeRacer

Reply
nine_k  2 days ago

I thought the promise of Web Components was also about this: make a control once, make it styleable, let everyone reuse it.

I wonder why is this not happening widely.

  • bastawhiz  2 days ago

    It's not surprising, really: web components suck for having highly-customizable inputs.

    1. You get HTML attributes to pass data in, or JavaScript properties. If you're in React, you'd just use a React component and skip web components. If you're in vanilla HTML, you can't just write HTML, you have to build the component with the DOM.

    2. There's no real standard to making web components look the way you want them to. You can't just use CSS (you have to have the shadow root "adopt" the styles). Your point of "make it styleable" is actually one of web components' biggest weaknesses (IMO).

    3. Web components are globally registered. React/Vue/Svelte/etc. components are objects that you use. You end up with a mess of making sure you registered all of the components you want before you use them (and not registering the ones you don't use) and hope no two packages you like use the same name.

  • troupo  2 days ago

    Because web components themselves break even in the expected situations? And need 20+ new spec to make them work? And because they are neither low level enough nor high level enough to be useful for the use case you described?

  • JimDabell  2 days ago

    Web components are pretty terrible, and do not work as you would expect them to. Take this, for example

        <some-element>
        <input type="text">
    </some-element>

    So <some-element> is a web component that adds extra features to the input. So it constructs a shadow DOM, puts the <input> into it, styles the input appropriately, etc. And before the web component finishes loading, or if it fails, or if web components aren’t supported in some way, it still works like a normal <input>.

    Now take this:

        <some-element>
        <textarea>…</textarea>
    </some-element>

    Same thing. You’ve got a normal <textarea>, and the web component adds its extra stuff.

    Now take this:

        <some-element>
        <select>
            <option>…</option>
        </select>
    </some-element>

    Same thing, right? Nope! This doesn’t work! Web components can only style their immediate children. So the first web component can style the <input> element, the second web component can style the <textarea> element, and the third web component can style the <select> element… but it can’t style the <option> element.

    Web components are full of all of these random footguns.

    • rafram  1 day ago

      > Web components can only style their immediate children.

      This isn’t true at all. You’re doing something incorrect when creating your shadow root or adding your styles. (“Web components” aren’t really a thing - it’s a marketing term for a set of technologies - so I assume that you’re talking about custom elements with shadow roots here.)

      2 replies →