Discussion: style override

[dvoytenko]

Related issues: #7.

A reusable component may need to set a style that it wants to be overridable. For instance,

function MyComponent({style, ...rest}) {
  return <div role="" style={{outline: '1px solid blue', ...style}} {...rest}></div>
}

Structurally it may be important for the component to have an outline. At the same time, provided it's substituted safely, it should be overridable. The example above allows override by passing the style prop. But that would only work with inline styling. A styled-components, for instance, would be unable to override it because it works via stylesheet.

Some possible options:

1. Try again to find a safe way to deploy stylesheets for components and use the predefined classes, e.g. className={${props.className || ''} amp-component}. So far, however, we didn't find a non-fragile way to deploy stylesheets.
2. Cancel default styles. E.g. <AmpComponent disableDefaultStyles>. This is a very rough flag however. The user may want to override only some of the styles.
3. Cancel style-by-style. E.g. <AmpComponent className="myclass" style={{outline: ''}}>. This will work, but a bit cryptic and also fragile. E.g. for now styles may use outline and tomorrow decide to switch to outline-color. CSS is smart enough to override it all. But style map may or may not work well for this. And even then, this is not very ergonomic. Basically, the component user must cancel the same styles on every use.

[caroqliu]

In @ampproject/wg-ui-and-a11y past discussions, we have often preferred some way to do (2). The underlying principle is that for every component that comes with default functionally crucial and visually enhancing styles, the visually enhancing styles should follow an "all or none" opt-in model. The reasoning is publishers should not rely on some combination of our styles and their styles to achieve the look on the page -- if so, we become locked into our non-critical styling because changes to these will break publishers in unanticipated ways.

This is one of the points discussed in the CSS in Bento AMP document.

[dvoytenko]

In this case, we may also need to reclassify all styles into two categories: "essential structure" vs "pure styling". E.g. if an element must have overflow:hidden, it's not the same if it also recommends outline: 1px. Removing a structural style will likely break the component in some major ways.

[caroqliu]

Yes that's right, the document linked earlier discusses this:

As an additional point of reference, default styles tend to either be (1) functionally crucial or (2) visually enhancing. The former generally make the component "work", configuring DOM structure i.e. positionality of the element or the laying out of its children. The latter generally make the component "pretty", identifying a common visual language across components that shouldn't require additional styling on the publisher's part by default.

There is currently no way of distinguishing between the two types of default styles within our codebase other than ideologically, and in the past this has created obstacles for making changes to styles in AMP. In general this has been due to the assumption that publishers who use custom styles rely on the exact intersection between AMP's default styles and their custom styles to produce the experience on their page.

In this regard, establishing a styling heuristic in Bento not only addresses an unresolved technical challenge but also offers an opportunity to deviate from the existing pattern by defining a clear boundary between default and custom styles going forward.

[dvoytenko]

Do we have an issue on wg-bento that lists the document and some key points from it? If not, could we create it and link it here?

[caroqliu]

Created #15

[dvoytenko]

Related Web proposal: w3c/csswg-drafts#3890