What do you mean by targetable? The only thing that should be modifying the styles of MyComponent is itself. Any necessary changes should be exposed through the component's public API. Because of this, whether the styles live inside the component itself or in an adjacent css file doesn't matter.

What he means by naming one off elements is that within MyComponent there are multiple native elements that may need to be styled.

Maybe I don't understand your concept of reuse well, but I certainly don't think all components can just be slapped into the flow of an arbitrary parent container and have the right positioning and styling for free, and if you have to target those off of emergent behavior (i.e. Tailwind classes making it look some way), you are doing something very error-prone.

I also don't think it makes sense to imply the component's creator can know all possible circumstances it will be rendered in and can therefore make an insightful API to control these things. Instead, we can target the fact that CSS is a public API to control styling choices, and expose the classic handle into that API...

I disagree that you commonly need to style component internals from the outside. But when you do, exposing html class name injection points works fine. By no means should you be writing css to target a component's internals from outside of the component's own css file. That leads to a mess and is the opposite of reusable. The HTML structure of a component is private.

> I disagree that you commonly need to style component internals from the outside

Can you say more? For example, if any use case for it exists - which you seem to agree - surely you can see anyone inside such a use case would prefer to have this for free.

For example, I built a nice declarative form using React. I reuse my own Input fields and such. To control their spacing, I target their classNames for some occasions, like "MyLibraryInput" etc.. To be clear, this className belongs to the top level parent of that HTML structure and no styles of the type I described interact with the private HTML of that component, which I am surprised I have to state given that you are responding to a comment stating "I certainly don't think all components can just be slapped into the flow of an arbitrary parent container and have the right positioning and styling for free" and "we can target the fact that CSS is a public API" for single elements because that's quite exactly what it is...

> exposing html class name injection points works fine

So, after all this about how this use case is invalid, you just argue that someone who needs to do this type of thing should have to make extra wiring for no reason? I mean, certainly it functions, but it's a completely unnecessary step to force consumers to go thru. I do not understand this perspective at all.

The class names inside MyLibraryInput are, even at its top level, private implementation details. To control spacing of them in a form, you should add additional class names to their root, via a public API that allows adding class names, or by styling their parent as a flex box or similar, or by having a spacing control in its API. You should not be targeting them through CSS at all.

It's not extra wiring for no reason, it's extra wiring to ensure maintainability. When you style children via css like `#parent .child` you are making it difficult to understand where and why styles are being applied. Any parent at any level of nesting could overwrite the styles of any child, potentially conflicting with other ancestor overwrites. And as the internals of the component change, all these overwrites may stop working correctly. By making the class name injection points explicit, even if it's just the root, you are avoiding this problem of "where did all these styles on my input come from??" and "what is going to break if I change this class name?"