I'm a big web components guy, but calling these web components is a massive stretch of the word component.
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.
That just adds HTML bloat to the page, something people with a singular focus on eliminating JavaScript often forget to worry about. Too many HTML elements can slow the page to a crawl.
Use classes:
<a class="button" href="">Learn more</a>
They're meant for this, lighter weight, and highly optimized.
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.)
> 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.
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"
Author of the blog post here! Since this blog post, I put this idea to practice on the VS Code website (https://code.visualstudio.com/) to create all the interactive graphics on the homepage. Which is a slightly different use case than what I described in the post, but cool and effective none-the-less.
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).
I have flitered with this in the past and an important note that you are missing from the post, that this type of custom element should only replace divs and spans. These new elements will have no meaning to the document outline or for accessibility.
I like that the author came to the idea by cross pollination via web components.
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.
The reason fixing ads from the inside won’t work is that they are designed to disrupt. An ad that ruins your scrolling for three seconds is preferable to one that ruins your scrolling for 2.5 seconds. All ads are designed to wreck the environment that they are in, to create a space for irrationality to enter.
I'm not a fan of these custom elements. Unless you do something really interactive, dynamic and reusable (an element with complex behavior), I don't think it's worth to use them. The SEO / accessibility becomes more challenging. Also, worth to noting, web components require JS, so they are not pure "CSS" web components. Web components are useful for isolation, when used with shadow DOM.
Using custom elements as the article suggests doesn't require JavaScript, so they are "pure" HTML and CSS (though whether they count as "web components" is up to you). More to the point, all of the technologies that the term "web components" includes — custom elements, <template> tags, shadow DOM — can be used without JavaScript.
<div> and <span> are semantically neutral, so I'm not sure what SEO and accessibility challenges custom elements would introduce?
Why not use CSS without the custom element? From this post I don't see the benefit of using <swim-lanes> over <section class="swim-lanes"> for example.
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" />
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:
That just adds HTML bloat to the page, something people with a singular focus on eliminating JavaScript often forget to worry about. Too many HTML elements can slow the page to a crawl.Use classes:
They're meant for this, lighter weight, and highly optimized.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.
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...
> 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.
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.
<div> and <span> are semantically neutral, so I'm not sure what SEO and accessibility challenges custom elements would introduce?
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" />