--- title: "Discussion on \"3 Examples of the TAC Methodology In Action\" | Hashnode" description: "Discussion on \"3 Examples of the TAC Methodology In Action\". In this post, we're going to build three components, each of which demonstrates how to follow different parts of the TAC CSS methodology.\nIf you haven't read about the TAC CSS methodology you can still follow along, but to fully understand some of th..." url: "https://hashnode.com/posts/3-examples-of-the-tac-methodology-in-action/64e2f9273231053d14b04246" --- [Feed](https://hashnode.com/feed) / Discussion # [3 Examples of the TAC Methodology In Action](https://jordanbrennan.hashnode.dev/3-examples-of-the-tac-methodology-in-action?utm_source=hashnode&utm_medium=feed) 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... Aug 21, 2023 · 9 min read · jordanbrennan.hashnode.dev Updated Aug 23, 2023 Read the article - [#html5](https://hashnode.com/tag/html5) - [#css](https://hashnode.com/tag/css) - [#javascript](https://hashnode.com/tag/javascript) - [#web-development](https://hashnode.com/tag/web-development) ## Written by [Jordan Brennan](https://hashnode.com/@jfbrennan) @jfbrennan · Tulsa [View profile](https://hashnode.com/@jfbrennan) Frontend engineer ## Responses 2 Markdown supported · ⌘↵ to post [Kurt Rank](https://hashnode.com/@kurtrank) [Oct 14, 2024](https://hashnode.com/posts/3-examples-of-the-tac-methodology-in-action/64e2f9273231053d14b04246/comment/670d1ccfcad5385d9672afee) 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. [Jordan Brennan](https://hashnode.com/@jfbrennan) [Jan 17, 2025](https://hashnode.com/posts/3-examples-of-the-tac-methodology-in-action/64e2f9273231053d14b04246/comment/670d1ccfcad5385d9672afee#reply-6789efe3680861c2ae97014c) 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 `` because slots are for Web Components and `` 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. [Kurt Rank](https://hashnode.com/@kurtrank) [Oct 14, 2024](https://hashnode.com/posts/3-examples-of-the-tac-methodology-in-action/64e2f9273231053d14b04246/comment/670d1aebf4e47b739a871f13) 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 `
` 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 `` and then not need the inner `
`? What if someone wants to have a `` but to show a blog excerpt where it may make sense to use `
`? 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 `