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.
Arguably, that would be misuse of the semantic meaning of "section." While <section> is nearly as generic as <div>, they should always have a heading of their own. The author's <swim-lane> already has a nested <section> with its own <h2>, but the <swim-lane> itself doesn't get (or need) its own even-higher heading.
And since that would drive us to <div>, I don't see any value in <div class="swim-lanes"> over <swim-lanes>.
It is unfortunate that you cannot simply move a block of HTML elsewhere where the context is otherwise perfectly suitable but expected heading level is different[0].
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.
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" />
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:
"Clean" is the biggest lie in software development. It's an aesthetic opinion dressed up as objective fact. You think components are clean, someone else thinks classes are clean, and neither of you are wrong, except for believing that "clean" is a property of the code and not something entirely in your own mind.
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.
Arguably, that would be misuse of the semantic meaning of "section." While <section> is nearly as generic as <div>, they should always have a heading of their own. The author's <swim-lane> already has a nested <section> with its own <h2>, but the <swim-lane> itself doesn't get (or need) its own even-higher heading.
And since that would drive us to <div>, I don't see any value in <div class="swim-lanes"> over <swim-lanes>.
It is unfortunate that you cannot simply move a block of HTML elsewhere where the context is otherwise perfectly suitable but expected heading level is different[0].
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/...
Web components come with additional complexity, heavy use of custom element definitions are more complicated to manage.
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.
1 reply →
If you're not actually getting anything semantically useful out of the element, then you may as well use a custom element.
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.
A handful of benefits:
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" />
> Specificity
: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 replies →
"Clean" is the biggest lie in software development. It's an aesthetic opinion dressed up as objective fact. You think components are clean, someone else thinks classes are clean, and neither of you are wrong, except for believing that "clean" is a property of the code and not something entirely in your own mind.
1 reply →