Discussion on "3 Examples of the TAC Methodology In Action"

Jordan Brennan · 2023-08-21T05:41:59.463Z

In this post, we're going to build three components, each of which demonstrates how to follow different parts of the TAC CSS methodology. If you haven't read about the TAC CSS methodology you can still follow along, but to fully understand some of th...

One other question: I notice in your modal dialog example you use slot. Is there ever a situation where it makes sense to use part instead of slot? Without a shadow DOM both of those won't do anything functionally but can be used for style selectors. I feel that slot makes sense for a lot of cases where you want to treat the inner content as optional or something that an author wants to place as a child of your custom element, but part makes sense if you have a nested element that is a "required" child element that isn't really considered as content being placed in the component.

I guess the downside is that styling would be confusing as you would do [part="something"] instead of ::part(something) like you would do with a real shadow DOM. I wonder if shadow DOM will be more widespread now that it can be declarative, albeit without shared templates yet.

Good question. Parts are elements that originate in the Web Component whereas slots are elements provided or "slotted in" by the developer (or by the app or however you want to think of it). In the case of the dialog, I want the developer to be able to provide the close button themself and wire up whatever logic or event handlers make sense for this particular dialog. They provided the button, I only defined a place for it to go, that's a slot.

However, there's some nuance here in the case of dialog, isn't there?

I technically probably shouldn't go for a slot in <dialog> because slots are for Web Components and <dialog> is a native element. I could just say "put a button in the dialog and wire it up", but that's just not enough for a good design system. I need to control a few details about that button, so I need some way of defining an API for it. Slots work well for this, so that's what I did. (there's some nuanced details that explain why, but too tired to type it all out right now) Although I'm using slots in a way that's not exactly technically correct. But then again the spec doesn't say not it and it works well for a number of reasons so I do it.

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

3 Examples of the TAC Methodology In Action

Responses2