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.
<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.
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
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.
> 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...
<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 {...}'?
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).
It's treating the symptom rather than the cause.
The solution is not to use tailwind in the first place.
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.
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!
Which is valid but also this article idea seems to make the rounds every two weeks
Browsers create ANY tag with at least one dash as a *Custom Element*
They come in TWO flavours, and since they ARE HTMLElement, can be used for layout AND styling with CSS.
The official names are:
► UNdefined Custom Elements (the article calls these "CSS Web Components")
- shadowDOM optional with Declarative ShadowDOM
- shadowDOM optional
- A new Element, or an UPGRADED existing UNdefined Custom Element
### Good to know about UNDEFINED Custom Elements:
* Absolutely NO JavaScript required, it is only HTML and CSS
* This is STANDARD behaviour in all browsers for nearly a DECADE now: Chrome (2016) Safari (2017) FireFox (2018)
* The W3C HTML Validator accepts ALL <tag-name> Custom Elements with a dash as HTMLElement. It does not accept <tagname> (no dash), those are HTMLUnknownElement
* Custom Elements do not inherit the standard [hidden] behaviour; so you have to add that behaviour yourself in your stylesheet.
* Same for DIVs display:block. You have to set the display property on these Custom Elements yourself. (You will forget this 20 times, then you never make the mistake again)
* The :defined pseudo selector targets standard HTML tags and JavaScript defined Custom Elements
* Thus :not(:defined) targets the UNdefined Custom Elements; again... they are still valid HTMLElement so CSS applies like any element
* <you-are-not-bound-to-one-dash>
* Declarative ShadowDOM <template shadowrootmode="open"> creates the same UNdefined Custom Elements WITH a shadowDOM
* The Custom Elements JavaScript API upgrades UNdefined Custom Elements TO defined Custom Elements.
* You can't UNdefine defined Custom Elements
* You can't REMOVE a set shadowRoot
* for now, only Safari supports multiple custom element registries (duplicating Custom Element names)
----
Why?
► Try to find that closing </div> in a long HTML page. </tag-name> is always just there.
► Built a UI that doesn't FOUC, and UPGRADE it lazy-loaded with more logic and interactivity... you can not do this with technologies that CREATE HTML AFTER DOM was parsed.
Custom Elements/Web Components ARE HTML; Frameworks CREATE HTML
We will forever call Custom Elements: Web Components, and vice versa...