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
{{ message }}
This repository has been archived by the owner on Nov 16, 2021. It is now read-only.
We need to style components and make them usable with minimal effort for AMP Web Components, as well as standalone React deployment. That means that the styling has to be very flexible. Specifically, the following styling approaches have to work:
Classical className + stylesheet. E.g. <AmpCarousel className="mycarousel">.
E.g., AmpCarousel.css. This limits our distribution options. There are numerous ways to include a stylesheet in an application, but there's no one "standard" way. Asking users to do this manually is error prone. It's also easy to collide with stylesheets on selector specificity.
Use CSS-in-JS
There are several popular frameworks for this (GoogleForCreators/web-stories-wp#111). But it'd be hard for us to pick an option here, since it can easily conflict with the solution used by the host application.
Inline styles.
E.g.
<div style={{position: 'relative'}}>...</div>
This will increase markup and makes code messy. However, it's also the safest way that's compatible with most of other approaches.
One negative: there's no way to support a number of CSS features using inline styles. Such as:
:after{} and :before{}. We'd have to accomplish this through nesting.
:focus{} and :hover{}. Just can't do anything here. Arguably, however, this is a rare need for our style of components. We could deploy a separate stylesheet for AMP specifically to "enhance" a few features and document how to do so for React.
:nth-child. We'd have to run the math manually. This might be more idiomatic from React point of view anyway.
Removing complexity of inline style declarations
The <div style={{...}}> get very messy. We can move all such styles into a separate constants file. E.g.
import {CAROUSEL_STYLE} from './style.js';
return <div style={CAROUSEL_STYLE}>...</div>;
Where style.js is:
const CAROUSEL_STYLE = {
position: 'relative',
}
Ideally, we could even jump one way further and allow specifying styles in CSS format as style.css (with obvious restrictions). E.g.:
carousel {
position: relative;
}
This style.css would be run through PostCSS and then transformed into style.css.js file with the constants.
This could lend itself to lots of optimizations. In some environments (AMP), we could even rewrite components to use a shared shadow stylesheets using such declarations.
The text was updated successfully, but these errors were encountered:
We need to style components and make them usable with minimal effort for AMP Web Components, as well as standalone React deployment. That means that the styling has to be very flexible. Specifically, the following styling approaches have to work:
className
+ stylesheet. E.g.<AmpCarousel className="mycarousel">
.<AmpCarousel style={{position: 'fixed'}}>
Approaches
Publish component's stylesheet
E.g.,
AmpCarousel.css
. This limits our distribution options. There are numerous ways to include a stylesheet in an application, but there's no one "standard" way. Asking users to do this manually is error prone. It's also easy to collide with stylesheets on selector specificity.Use CSS-in-JS
There are several popular frameworks for this (GoogleForCreators/web-stories-wp#111). But it'd be hard for us to pick an option here, since it can easily conflict with the solution used by the host application.
Inline styles.
E.g.
This will increase markup and makes code messy. However, it's also the safest way that's compatible with most of other approaches.
One negative: there's no way to support a number of CSS features using inline styles. Such as:
:after{}
and:before{}
. We'd have to accomplish this through nesting.:focus{}
and:hover{}
. Just can't do anything here. Arguably, however, this is a rare need for our style of components. We could deploy a separate stylesheet for AMP specifically to "enhance" a few features and document how to do so for React.:nth-child
. We'd have to run the math manually. This might be more idiomatic from React point of view anyway.Removing complexity of inline style declarations
The
<div style={{...}}>
get very messy. We can move all such styles into a separate constants file. E.g.Where
style.js
is:Ideally, we could even jump one way further and allow specifying styles in CSS format as
style.css
(with obvious restrictions). E.g.:This
style.css
would be run through PostCSS and then transformed intostyle.css.js
file with the constants.This could lend itself to lots of optimizations. In some environments (AMP), we could even rewrite components to use a shared shadow stylesheets using such declarations.
The text was updated successfully, but these errors were encountered: