Kurt Rank

Oct 14, 2024

These are really great examples. I am a big fan of everything you've written about TAC, I am certainly inspired. I am incorporating this philosophy where possible on the things I work on. One potential issue I have come across is by not using classes you lose the flexibility to use different builtin elements for the main component wrapper. For example using an <article> for a card. I wonder if it makes sense to use custom attributes in more cases instead of a separate tag (like your ord button example -- as you can also apply it to a tags if someone wants a big call to action link). I've also been considering the discussion on registered custom attributes as an alternative to builtin extends with is="".

In the site-header example, would it instead make sense to do <x-siteheader role="header"> and then not need the inner <header>? What if someone wants to have a <x-card> but to show a blog excerpt where it may make sense to use <article>? I suppose you can nest it like article > x-card.

I am not sure what the right mix of custom tags, slots, attributes, classes, etc. is in some cases, when trying to build a library that may be used in ways I am not expecting. I don't want to confuse people either by having some components be tags, others as attributes or classes but I guess as long as it's clearly documented. Maybe I'm overthinking it, and if a <footer> or whatever is needed then it can just be nested. Or maybe I am still a bit too much in the mindset of how I used to build things with BEM haha

Thanks Kurt!

Let me clarify the most important thing first:

I am not sure what the right mix of custom tags, slots, attributes, classes, etc. is in some cases

and

I don't want to confuse people either by having some components be tags, others as attributes or classes

In all cases TAC says components MUST be defined with tags. Remember, the T is for tags. Tag comes first. Button starts with <button>, table starts with <table>, dialog starts with <dialog>, icon starts with <x-icon>, badge starts with <x-badge>.

So, as you've seen already a button would then of course start with <button>. Then your different kinds of buttons would be specified through an attribute. In all my years of doing this I've seen such an attribute named ord (ordinal, which has strong semantics if using "primary", "secondary", "tertiary" language) or kind or variant.

In the case of the site header example, I would agree <x-siteheader role="header"> is probably like the ideal application of the TAC methodology, but WCAG strongly discourages the use of roles (or any ARIA feature) whenever you're able to use the equivalent HTML feature. So in the case of a site header component defining a custom tag like x-siteheader and then defining its relationship with a child <header> I think is technically a bit more correct according to WCAG. But again, I would agree <x-siteheader role="header"> is better :)

Same goes for your x-card example: <x-card role="article"> seems great, but technically not the best way according to WCAG. Your second approach with a plain <article> and <x-card> inside I think is great too. Let article be an article, which is just a block-level element like div but with better semantics, then get the card styles and features from your actual card component.

One more example that might help: dialog. In one of the design systems that I've built we started with the raw <dialog> element (of course!) and simply styled it according to the company design language. In addition to just the plain dialog tag, we defined a slot for the dialog's basic close button (the [ X ] button positioned to the top-right corner) and a kind attribute that is used to set the dialog as a "drawer" which makes the dialog slide in and out like other similar drawer components. We also defined a rule for an optional <header> child that gets some minor styling and improves structure and semantics and similarly a <footer> which we said was required for the dialog's action button(s), like cancel and/or save buttons.

Hopefully that demonstrates how the component is always defined with a tag, then using the power of HTML primitives like attributes, slots, and parent and child and sibling relationships we can come up with some very capable components with really good API!

Search Hashnode