---
title: "Comment by Kurt Rank on \"3 Examples of the TAC Methodology In Action\" | Hashnode"
description: "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"
url: "https://hashnode.com/posts/3-examples-of-the-tac-methodology-in-action/64e2f9273231053d14b04246/comment/670d1ccfcad5385d9672afee"
---

[Discussion](https://hashnode.com/posts/3-examples-of-the-tac-methodology-in-action/64e2f9273231053d14b04246)

Comment [3 Examples of the TAC Methodology In Action](https://hashnode.com/posts/3-examples-of-the-tac-methodology-in-action/64e2f9273231053d14b04246)

[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 `<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.