Edit: the reason for avoiding this in the past was name-spacing. But the standard says you can use a hyphen and then you're OK, native elements won't ever use a `-`.
Edit 2: also it's great because it works fine with CSS selectors too. Write stuff like `<image-container>` in plain HTML docs and it's fine.
Edit 3: but also `<albums>` tags and etc which won't be adopted into the HTML standard soon work too if they don't conflict with element names, and the rare case that they might be adopted in the future as an element name can be resolved with a simple text search/replace.
Edit 4: This all really has little to do with javascript, but you can use `querySelector` and `querySelectorAll` with any of these made up names the same as any native name too.
It's very nice to write. I used and liked vue for a little while when it was needed(?) but modern HTML fills that gap.
Quoth the standard: "The use of HTMLElement instead of HTMLUnknownElement in the case of valid custom element names is done to ensure that any potential future upgrades only cause a linear transition of the element's prototype chain, from HTMLElement to a subclass, instead of a lateral one, from HTMLUnknownElement to an unrelated subclass."
You can customize it using the Custom Element API: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
I agree the need for everything to be a react app by default has gotten out of control. But I think if you’re a startup with unknown future needs it’s hard to ignore the flexibility and power of something like react. If you know you’re just making a CRUD app and good old fashioned form POSTs will do then it’s beautiful to have that speed and the lightweight pages.
That being said, if you read through that post and were intrigued, you might also like custom web components: https://web.dev/articles/custom-elements-v1
It's a simple way to add more to your "made up" HTML tags. So you could have a tag called <my-code>, for example, that automatically has a copy button and syntax highlights the code.
That's the premise behind Lit (using the custom elements api)! I've been using it to build out a project recently and it's quite good, simpler to reason about than the current state of React imo.
It started at google and now is part of OpenJS.
It does! <https://lit.dev/docs/components/shadow-dom/>
By default, Lit renders into shadow DOM. This carries benefits like encapsulation (including the style encapsulation you mention). If you prefer global styles, you can render into light DOM instead with that one-line switch.
However, shadow DOM is required for slotting (composing) components, so typically what I'd recommend for theming is leveraging the array option of each component's styles:
static styles = [themeStyles, componentStyles]
protected createRenderRoot() {
return this;
}
While you can easily turn rendering to shadow DOM off on a per-component basis, that removes the ability to use slots. It only really works for leaf nodes.
Pulling a stylesheet into every component is actually not bad though. Adopted stylesheets allow you to share the same stylesheet instance across all shadow roots, so it's quite fast.
Even if this custom element trick didn't work, I don't see why one would need to count divs (at least if you control the markup, but if not then made-up tags aren't an option anyway). The article even mentions using class names as an option.
So yeah, I guess what wasn't obvious from my statement of gratitude was that I appreciate knowing that there is a more concise way of keeping track - even without CSS styling. If I make up tags, they will just inherit default styling but to my eye I can be clear about where things are closed, and where to insert things later. I was talking about the manual editing (in vim, as I mentioned), rather than any dynamic query selectors. Make more sense?
> <article-header>
> <article-quote>
> <quote-body>
Not the best example, because in this case, you could just use real HTML tags instead
<article>
<header>
<blockquote>
<p> <div class=article>
<div class=article-header>
<div class=article-quote>
<div class=quote-body>
... a bunch more HTML ...
</div>
</div>
</div>
</div>
<article>
<header>
<blockquote>
<p class=quote-body>
... a bunch more HTML ...
</p>
</blockquote>
</header>
</article>Although be sure to avoid too many :has(:nth-child(n of complex selector)) in case of frequent DOM updates.
As a side note, I’ve been going through all the HTML elements slowly to learn the fundamentals, and it turns out that lots of elements are just a <div> or <span>, with different default styles and default ARIA things.
And a <div> is just a <span> with display block…
This and TFA both help me to realize HTML is pretty darn simple.
It's a bit more subtle than that. HTML5 defines "Content Models", two of which are 'Phasing Content' and 'Flow Content'. Phasing Content can only contain text and text-like tags (em, strong, bold) whereas Flow Content can contain anything.
Technically <span> is defined as accepting Phrasing Content and <div> accepts Flow Content. Changing this with CSS doesn't change the content model.
Although browsers are very forgiving so it all works anyways and this is very in the deep end, I can't think of the last time I've consciously thought of this stuff.
https://html.spec.whatwg.org/#the-span-element
If there's no native semantic tag that fits my purposes, I'd much rather stick to a div or span as appropriate, and identify it with one (or more) classes. That's what classes are for, and always have been for.
Support for custom HTML elements seems more appropriate for things like polyfills for actual official elements, or possibly more complicated things like UX widgets that really make sense conceptually as an interactive object, not just CSS formatting.
Using custom element names as a general practice to replace CSS classes for regular formatting just feels like it creates confusion rather than creating clarity.
<div class=expander>
<button aria-expanded=false>Expand</button>
<!-- Some other stuff here -->
</div>
for (const expander of document.querySelectorAll('.expander')) {
const btn = expander.querySelector('button');
btn.addEventListener('click', () => {
btn.ariaExpanded = 'true';
});
}
Custom elements solve exactly this problem. You can now do:
<expander-elem>
<button aria-expanded=false>Expand</button>
<!-- Some other stuff here -->
</expander-elem>
customElements.define('expander-elem', class extends HTMLElement {
connectedCallback() {
const btn = this.querySelector('button');
btn.addEventListener('click', () => {
btn.ariaExpanded = 'true';
});
}
});
I didn't know you could just make up tags, but I figured I'd give it a shot, and with a bit of jquery glue and playing with visibility settings, I was able to fix browsers and bring back the glorious blinking. I was surprised you could just do that; I would have assumed that the types of tags are final.
I thought about open sourcing it, but it was seriously like ten lines of code and I suspect that there are dozens of things that did the same thing I did.
On the one hand I kind of want to use any random tag and have it work.
On the other hand ...
<div class=main-article> # or <div class="main-article">
versus
<main-article>
I understand that it is not the same semantically, but I am using div tags and p tags a LOT. I avoid the new HTML tags for more semantic meaning as this adds cognitive load to my brain. I'd rather confine myself to div and p tags though - it is just easier. And I use proper ids to infer additional information; it is not the same, but I kind of want to keep my HTML simple too. So I don't want to add 500 new custom HTML tags really. Even though I think having this as a FEATURE, can be useful.
HTML5 Shiv was needed, with added history https://www.paulirish.com/2011/the-history-of-the-html5-shiv... (2011)
macintux•1h ago
http://www.badgers-in-foil.co.uk/projects/docbook-css/