You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current Emotion-based override system is powerful, but it has a few downsides:
no syntax highlighting or validation unless you use Emotion's object-based CSS and you install its types, or use specific IDEs (e.g. Intellij Idea Ultimate) with Emotion's css`...` string template.
no obvious mapping between overrides and DOM elements, which complicates prototyping and debugging from the browser.
no easy way to style children from a parent override: one must either use CSS variables to pass data between the two overrides, or rely on the precise DOM structure (which we may change at any time).
One way to solve these issues would be to add classes to every element that uses overrides.
One foreseeable pitfall to this approach would be that class-based CSS overrides may conflict with emotion-generated CSS. In those cases, some specificity hacks may be required.
The text was updated successfully, but these errors were encountered:
The current Emotion-based override system is powerful, but it has a few downsides:
One way to solve these issues would be to add classes to every element that uses overrides.
One foreseeable pitfall to this approach would be that class-based CSS overrides may conflict with emotion-generated CSS. In those cases, some specificity hacks may be required.
The text was updated successfully, but these errors were encountered: