Hacker News Reader

Comment by crazygringo | Hacker News Reader

But there's no real reason to, and it just adds confusion around which elements are semantic -- bringing formatting, functionality, meaning to screen readers and search engines, etc. -- vs which are custom and therefore carry no semantic meaning.

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.

View on HN

So, the article doesn't discuss this, but there's actually a really good reason to make up and use custom elements: the browser can hydrate their dynamic behaviour automatically. For example, suppose you have:

    <div class=expander>
      <button aria-expanded=false>Expand</button>
      <!-- Some other stuff here -->
    </div>

And you have some JS that handles the expander's behaviour:

    for (const expander of document.querySelectorAll('.expander')) {
      const btn = expander.querySelector('button');

      btn.addEventListener('click', () => {
        btn.ariaExpanded = 'true';
      });
    }

This will work fine for `.expander` divs that are already in the page when the event handler is set up. But suppose you dynamically load new expander divs, what then? Your event handler is not going to retroactively set up their click listeners too.

Custom elements solve exactly this problem. You can now do:

    <expander-elem>
      <button aria-expanded=false>Expand</button>
      <!-- Some other stuff here -->
    </expander-elem>

And then set up the listener:

    customElements.define('expander-elem', class extends HTMLElement {
      connectedCallback() {
        const btn = this.querySelector('button');

        btn.addEventListener('click', () => {
          btn.ariaExpanded = 'true';
        });
      }
    });

And the browser will ensure that it always sets up the listeners for all of the expanders, no matter whether they are loaded on the page initially or dynamically injected later. Without this you would have had to jump through a bunch of hoops to ensure it. This solves the problem elegantly.

Beware that connectedCallback runs _every time_ a custom element is added to the dom. So you should make sure to only add event listeners once by tracking internally if the element was already initialized.

Thanks, that's good to know. In some contexts I don't think a custom element is ever added to the DOM more than once, eg in htmx I am responding with HTML markup which is then injected into the page and then just kept there, possibly 'forever' or at least until it is replaced by some new markup from a new response.

Yes, the hydration behavior of custom elements is nice. You don’t even need to do anything special with JS bundle loading.

Simply render your <element> (server-side is fine) and whenever the JavaScript downloads and executes your custom elements will mount and do their thing.

this.querySelector will return nothing when you define this Web Component before (light)DOM is parsed, because the connectedCallback fires on the opening tag.

Above code will only work when the Web Component is defined after DOM has parsed; using "defer" or "import" makes your JS file execute after DOM is parsed, you "fixed" the problem without understanding what happened.

I blogged about this long time ago: https://dev.to/dannyengelman/web-component-developers-do-not...

Well, that's why I include JS files at the bottom of my HTML body, to make sure to avoid exactly this problem: https://github.com/yawaramin/dream-html-ui/blob/92f2dfc51b75...

One drawback.

► execute <script> at bottom of file

► execute <script defer>

Both do the same; they execute script after DOM was parsed. When your JS creates GUI you now have to battle FOUCs.

► "import" loads your script async

so it _could_ load before _all_ DOM has parsed... but 9999 out of 10000 scenarios it won't

That's why my JS doesn't create the GUI, it just attaches event handlers to the GUI rendered on the server. Check the link I posted above...

That's good to know, and I even did say that custom UX widgets are a case where custom tag names makes more sense conceptually.

I'm really just pushing back on the idea of using them for CSS formatting purposes of general text and layout instead of classes.

> no real reason

Doing this for syntax highlighting on https://janetdocs.org/ shrank the homepage's .html from from 51kb to 24kb, or 8kb to 6kb compressed (at the time).

Why would it create confusion? Because you're not familiar with it? Things change..

Because there are so many native elements to keep track of now.

If you see an unfamiliar tag that has a reasonably simple name, you simply don't know if it's native or for formatting.

That's confusing. It's taking two categories of things and mixing them so you can't tell them apart.

There's a very clear rule for it: if it contains a dash it's a custom element

That rule doesn't work in reverse. If there's no dash it could be either.

So now you've got to try to enforce some practice of using hyphens in all tag names that used to be class names, even if they're a single word that has no place for a hyphen?

It's getting even more confusing now, you see? Not less.

Just use classes. That's what they're there for.

Only native elements can be a single word, you can't create a custom elements without a dash.

Let's be clear: this whole conversation isn't about custom elements. This is about formatting. Not web components.

You just use it (single word) and style it (CSS) and it works. You don't have to "create" anything.

So nothing's stopping anyone from using single-word elements. There's another comment here defending exactly that:

https://news.ycombinator.com/item?id=46418090

But it's bad practice. Just use classes. It's literally what they are designed for.

Aha fair enough, but yeah browsers often allow invalid HTML to just work. But that doesn't mean that the valid usage is somehow flawed. I can understand that the dash can be a bit of a weird rule if you're new to HTML. But I think it's an elegant way to allow users to create custom tags and have readable compact semantic HTML.

But yeah I also do see the confusion part, if a person new to HTML sees these custom tags being used it might think it can create one too and not realize it must contain a dash, and it would still work. So yeah in that sense, indeed it's confusing if you're unfamiliar with it.

But having multiple </div></div></div> at the end of a large block of HTML is also confusing, often resulting in closing too many / too few divs. Having </nav-item></nav-bar></main-header> is much better. So yeah it has it's pros and cons I guess.

Reply on news.ycombinator.com