1. Specificity - swim-line.buttons vs .swin-lines.buttons vs .buttons.swim-lanes. 2. Future pathing - Maybe you don't need a Web Component today, but you might need one tomorrow. 3. Cleaner - <swim-lane /> is just better than <div class="swim-lane" />
:where() gives you zero specificity.
> Future pathing
Sounds like premature optimization. And I say this as someone who has been using custom elements and web components in production since 2016. In fact one of my products offers WCs for our customers:
https://docs.wavekit.app/web-components-wavekit-audio/
> Cleaner
Debatable. Personally I find it cleaner to simply rely on CSS to solve something rather a combination of CSS, JS, and some custom markup.
2. One person's "premature optimization" is someone else's "this was literally something I dealt with this week."
3. This method relies on CSS and HTML, just as any other styling solution would.
And since that would drive us to <div>, I don't see any value in <div class="swim-lanes"> over <swim-lanes>.
It’s more than just an aesthetic preference
But if you’re not really using web components it’s harmless but it’s a bit odd and pointless.
Section-relative headings were briefly part of the spec but quickly got removed. As it stands, I would not consider any block of HTML with an <hX> element portable.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Also by using a custom element instead of a class, you're saying this isn't anything else other than what I say it is.
It's not a <section class="swim-lanes">, it's not a <form class="swim-lanes">, it's not a <blockquote class="swim-lanes">, it's a <swim-lanes>.
If you make something only a class, people end up misusing it in odd places.
The word "component" has to mean something ultimately, and to me the defining feature of a web component is that it's self-contained: it brings along its own dependencies, whether that's JavaScript, templates, CSS, etc. Web components shouldn't require an external framework or external CSS (except for customization by the user) - those things should be implementation details depended on directly by the component.
This here is just CSS using tag names for selectors. The element is doing nothing on its own.
Which is fine! It's just not web components.
edit: Also, don't do this:
<link-button>
<a href="">Learn more</a>
</link-button>
Use classes:
<a class="button" href="">Learn more</a>
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.
Marketing is in the end a way of trying to get people to listen, even if you have nothing substantial to say (or if you have something to say, potentially multiply the effect of that message). That means you have to invent a lot of packaging and fluff surrounding the thing you want to sell to change peoples impression independent of the actual substance they will encounter.
This to me is entirely backwards. If you want people to listen focus on your content, then make sure it is presented in a way that serves that content. And if we are talking about text, that is really, really small in terms of data and people will be happy if they can access it quickly and without 10 popups in their face.
Not that I accuse any person in this thread of towing that line, but the web as of today seems to be 99% of unneeded crap, with a tiny sprinkle of irrelevant content.
> 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.
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...
<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.
Counterpoint: Shadow DOM is great. People should be using it more. It's the only DOM primitive that allows for interoperable composition. Without it you're at the mercy of frameworks for being able to compose container components out of internal structure and external children.
Sort by negative sentiment; Shadow DOM is at the top of the list, the most hated feature in Web Components. You can read the comments, too, and they're almost all negative, and 100% correct.
"Accessibility nightmare"
"always hard to comprehend, and it doesn't get easier with time"
"most components don't need it"
"The big issue is you need some better way to some better way to incorporate styling from outside the shadow dom"
> It's the only DOM primitive that allows for interoperable composition.
There is no DOM primitive that allows for interoperable composition with fine-grained reactivity. Your framework offers fine-grained reactivity (Virtual DOM for React/Preact, signals for Angular, runes for Svelte, etc.) and any component that contains another component has to coordinate with it.
As a result, you can only mix-and-match container components between frameworks with different reactivity workflows by giving up on fine-grained reactivity, blowing away the internals when you cross boundaries between frameworks. (And Shadow DOM makes it harder, not easier, to coordinate workflows between frameworks.)
Shadow DOM sucks at the only thing it's supposed to be for. Please, listen to the wisdom of the crowd here.
Yet, for actual web components, I entirely agree with you.
This just isn't true - composition and reactivity are completely orthogonal concerns.
Any reactivity system can manage DOM outside of the component, including nodes that are projected into slots. The component's internal DOM is managed by the component using whatever reactivity system it desires.
There are major applications built this way. They make have a React outer shell using vdom and Lit custom elements using lit-html for their shadow contents.
On top of those basics you can also have cross-shadow interoperable fine-grained reactivity with primitives like signals. You can pass signals around, down the tree, across subtrees, and have different reactivity systems use those signals to update the DOM.
If the child component had been a React component instead, the children would have participated in the virtual DOM, and React could do a minimal DOM update when it was done.
React can't even see the shadow contents of Lit elements, so React just has to update the light DOM and let Lit take over from there.
(Same applies to Vue, Angular, Svelte, Solid, etc. Each framework has a reactivity system, and you have to integrate with it to get its benefits.)
React's vdom without shadow DOM passes props to components, which all return one big vdom tree, and then there's one big reconciliation. React used with shadow DOM evaluates smaller vdom trees per shadow root, and does more, but smaller reconciliations. It's the same O(n) work.
But in reality it's often much _better_ with shadow roots because the common WC base classes like Lit's ReactiveElement all do change detection on a per-property basis. So you only regenerate vdom trees for components with changed props, and with slots that doesn't include children. So if children of a component change, but props don't, the component doesn't need to re-render. You can do something similar by hand with memo, but that doesn't handle children separately. The compiler will, of course, fix everything.
Every other reactivity system works fine across shadow boundaries. Even the super-fine grained ones like Solid. The only issue with signals-based libraries like Solid is that they pass signals around instead of values, so to get true no-re-rendering behavior with web components you have to do that to, which means picking a signals library, which means less interoperability. The TC39 signals proposal points to a future where you can do that interoperably too.
I love custom elements. For non React.js apps I use them to create islands of reactivity. With Vue each custom element becomes a mini app, and can be easily lazy loaded for example. Due to how Vue 3 works, it’s even easy to share state & routing between them when required.
They should really move the most worthwhile features of shadow dom into custom elements: slots and the template shadow-roots, and associated forms are actually nice.
It’s all the extra stuff, like styling issues, that make it a pain in the behind
For slots to work you need a container for the slots that the slotted elements do not belong to, and whose slots are separated from other slot containers. Otherwise you can't make an unambiguous relationship between element and slot. This is why a shadow root is a separate tree.
But, if you do that, what happens to the original `<super-row-header>` element that the user provided? Maybe you'd want to delete it…? But how can you tell the difference between the user removing the `<row-header>` and the custom element removing it in the course of its work?
What you'd need is for `<row-header>` to somehow exist and not exist at the same time. Which is to say, you'd have one version of the DOM (the Light DOM) where the slot element exists, and another version of the DOM (the Shadow DOM) where the `<row-header>` element doesn't exist, and the transformed content exists instead.
It's clever, I guess, but the drawbacks far outweigh the benefits.
Client-side components inherently require JS anyway, so just use your favorite JS framework. Frameworks can't really interoperate while preserving fine-grained reactivity (in fact, Shadow DOM makes that harder), so, just pick a framework and use it.
<div> and <span> are semantically neutral, so I'm not sure what SEO and accessibility challenges custom elements would introduce?
> "shadow DOM — can be used without JavaScript" Yes, shadow DOM can be used without JS, but I was talking about web components.
> "I'm not sure what SEO and accessibility challenges custom elements would introduce?" If you replace standard elements (such as 'p', 'a', 'button', etc) with custom ones it can hurt SEO and accessibility. There are very few reasons to use custom element names and attributes if they are not full web components.
What's the point of using selector 'link-button[size="large"] a {...}' when you could do the same with '.link-button.large a {...}'?
Not necessarily. CSS alone can allow for a lot of useful complex behaviour. You can customise how something renders (or not) or is interactable based on parent elements, sibling elements, css variables, or other state.
> For example, you can't define a reusable 'host-element' tag and expect some additional elements (or some behavior) to automatically appear inside it each time your html includes or you create <host-element> ... </host-element>.
Actually you can, using <template> and <slot> elements. No JS required.
> What's the point of using selector 'link-button[size="large"] a {...}' when you could do the same with '.link-button.large a {...}'?
This is really two questions:
1. What's the point of using <link-button> instead of a link-button class?
2. What's the point of using a size="large" attribute instead of a "large" class?
To answer 1:
Classes end up being misused compared to custom elements. When you make a custom element (in this example "<link-button>"), you're explicitly saying this is a <link-button>. It is not a <blockquote class="link-button">, it is not a <form class="link-button> and it is most certainly not a <picture class="link-button>. It is a <link-button>.
Also with what was stated above, you can use <link-button> to declare default internal elements (using <template> and <slot>) without using js to say what should be inside a link-button.
To answer 2:
Because you should make impossible states impossible (or at the very least present impossible states as impossible). Size is a state, it could be small, large or any other list of predefined values. If you use classes then you can end up with something like <link-element class="small large">. If you use attributes, you end up with something like <link-button size="small"> or <link-button size="large"> but not <link-button size="small" size="large"> (since that's illegal in html and duplicated attributes are ignored).
Plus you're already using attributes for interactive aria roles (or you should be).
So with a basic collapsible menu:
<nav role="navigation">
<a href="#">home</a>
<button id="navbar-toggle" aria-expanded="false" aria-controls="navbar-menu">Menu</button>
<ul id="navbar-menu">
<li><a href="#">Login/Logout</a></li>
<li><a href="#">Feedback</a></li>
<li><a href="#">Other links...</a></li>
</ul>
You use css to style the menu being open or not with: `#navbar-toggle[aria-expanded=true] ~ #navbar-menu` and not something inaccessible like: `.navbar-menu.navbar-menu-open`.
It's treating the symptom rather than the cause.
The solution is not to use tailwind in the first place.
What woud have been a soup of `div` elements with various class names are now more meaningfully named elements like `<top-bar>`, `<chat-container>`, etc. that were mixed and remixed to create all the graphics.
Also no issues regarding performance that we've seen up to this point, which makes sense; browsers are very good and fast at rendering HTML elements (native or custom).
However, it's basically describing the "modifiers" part of BEM, which is a pattern that emerged from structuring CSS. Neither custom element or attributes are needed, even though they might feel different.
If you like that kind of pattern to structure CSS, then combining it with custom CSS properties (often called "variables", example: --block-spacing: 2rem) makes it even more modular. These properties follow the cascade rule.
Which is valid but also this article idea seems to make the rounds every two weeks
Most "frameworks" are the wrong tool because they assume that the markup and design (HTML/CSS) won't change as much as the functionality (JS) when it's exactly the opposite situation.
All the consistency needs to be concentrated in the JS without the baggage of any particular HTML/CSS in mind.
The only aspects of a framework you should want are a flexible way to register event listeners onto the elements, and organizing the styles and callbacks.
In practice, this ends up looking like a static HTML file that is not up to the developers how to organize apart from the usage of CSS classes because it will be audited by many non-devs, a Sass build derived from design guidelines with some alt classes to contain the mess when people change their minds, and some very robust JS that you're gonna have to write almost entirely from scratch.
I still don't get why this scares some people off though. You won't ever need to (re)write that much JS. Every new page design is just remapping existing functionality to the new HTML IDs, and maybe every now and then adding new functionality. Most of your time will be spent in CSS which just plain makes sense!