Replies: 4 comments
-
|
That's a really interesting idea, I like it! I think we'd have to try it out with a few components to know whether it works for us. Is the advantage that it has over I'm not sure I understand the difference between |
Beta Was this translation helpful? Give feedback.
-
🎉 Thanks! Agreed. Let me know if you can think of any use cases for this.
No. If anything
With |
Beta Was this translation helpful? Give feedback.
-
What about: label {
font-size: 8px;
}
I'm not sure I understand the mechanics of this, but probably best for us to discuss separate from this issue. |
Beta Was this translation helpful? Give feedback.
-
|
Sadly not, since the <label>
<input type="text" className={className} />
</label>@emotion/core takes the styles you define as template literals, serialises them and generates CSS. It targets the CSS at an auto-generated class that it assigns to the appropriate element. Then in the DOM, it adds the CSS to a style tag and adds that style tag to the bottom of the head. In most cases, we're composing a list of serialised styles and passing it to a component. @emotion/core smooshes the serialised styles together into a single block of CSS. The styles are smooshed based on the order in which they are passed, with later styles overriding earlier ones. Allowing @emotion/core to manage all styling is preferred because it gives us better guarantees over the cascade. If we use @emotion/core to generate some styles and use className to manage others, we can't guarantee the order in which style properties appear in the head, so we have to use I might not be explaining clearly, and some of these details are not 100% clear to me either, so I'll be happy to discuss further if you wanna hangout |
Beta Was this translation helpful? Give feedback.
-
In an effort to maximise the usefulness of components, we support consumers customising styles. We do this for two reasons:
Currently there are a number of ways to customise styles of components:
Theming
Source allows consumers to create their colour theme for a component. This is a first class approach to customisation.
cssOverrides
Users of
@emotion/corecan pass additional styles to thecssOverridesprop. This is more idiomatic to@emotion/core, but it's a bit clunky as the overrides get applied to a single element that is part of the component.If a consumer wishes to override the styles of a different element, they must try and target it using sibling or descendant selectors. Some elements are not stylable in this way, so the approach is limited.
className
Source allow consumers to pass classes to the
classNameprop. This is more idiomatic to React. Depending on the order in which style elements are added to the DOM (and@emotion/coreis very keen to get styles at the bottom of the<head>), styles that use classes passed in this way may need!importantdeclarations.Like with
cssOverrides, if a consumer wishes to override the styles of a different element, they must try and target it using sibling or descendant selectors. Some elements are not stylable in this way, so the approach is limited.Request for comments
I'm considering a new API that works similar to the
cssOverridesproperty but instead of receiving a singleSerializedStylesobject, it receives a map of SerializedStyles, expressed as a Map or a plain JS object:We would need to document which elements are stylable, and how to reach them using keys in the map.
I'll be happy to hear opinions on this, or thoughts about limitations or difficulties with this approach. If anyone has any other suggestions, please add them below.
Thanks so much for reading!
Beta Was this translation helpful? Give feedback.
All reactions