Mateusz Burzyński

> This is an interesting point. Out of curiosity, wouldn't shipping unminified builds just bounce the issue to our consumer's build? No, it shouldn't because your unminified code should roughly...

I've created a PR that might allow you to workaround this issue: https://github.com/emotion-js/emotion/pull/2867

I recommend using `React.HTMLAttributes` over `React.HTMLProps` because this is a type of props for `` element. I'm not exactly sure in what context `HTMLProps` should be used.

I've created a quick PR for this: https://github.com/emotion-js/emotion/pull/2297 but I don't have time to test this properly (nor in any codebase nor by creating new type tests in this repo)....

> I tested styled-components for the same case, it seems generating extra class name to maintain the relationship instead of breaking it. Yes, they introduce extra class names to accommodate...

Creating those relationships in CSS makes styling **less** predictable and also might break our composition patterns. When we write this: ```js [fooStyles, { color: 'hotpink' }] ``` the expectation is...

I agree this could be documented - documentation PRs are always welcome.

You can totally use arrays like this: ```jsx ``` So there is no need for a dedicated helper for composition (nor in Emotion, not in the userland).

@ali-garajian I don't see any practical difference here. In fact - the latter reads better to me because you have the condition first so it reads like "if this is...

This is a byproduct of our `compat` plugin - however, this matches the behavior of Emotion 10 for all pseudo-selectors. I'd like to remove this `compat` plugin in the next...