[Bug] Herman preview styles overriden by custom styles

[dvdherron]

Description

• Fixes styles for code examples being overriden by site custom styles.
• Limits the amount of Herman color custom properties generated for color previews.

Steps to test/reproduce

• To see a live version of the conflicts, see the color previews on this OddSite PR using the latest version of Herman.
• the font sizes are too big and the some of the Herman styles for code examples are being overrwritten by custom styles from OddSite. Please explain how to best reproduce the issue and/or test the changes locally (including the pages/URLs/views/states to review).

Show me

Color previews now only contain two generated custom properties: --herman-brand-blue and --herman-brand-pink:

Previously we were generating custom properties for all Herman colors:

Old:

Provide screenshots/animated gifs/videos if necessary.

[netlify[bot]]

✅ Deploy Preview for herman-staging ready!

Name	Link
🔨 Latest commit	e9a8ccfa3ea36d6a564f2c678b81a2cdb9278693
🔍 Latest deploy log	https://app.netlify.com/sites/herman-staging/deploys/637d457ea80c020008281723
😎 Deploy Preview	https://deploy-preview-390--herman-staging.netlify.app/configuration
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[dvdherron]

Bug: Herman color preview styles are easily overridden by site custom styles.

[dvdherron]

@mirisuzanne @stacyk

I think what I have done here so far will prevent the font-size of Herman color swatches being overriden by custom sites. This selector is overriding padding, color, and background properties set in Herman though.

Ideas for the best approach to set values in Herman that won't be overriden by this? Or should this be adjusted on OddSite?

[stacyk]

Ideas for the best approach to set values in Herman that won't be overriden by this? Or should this be adjusted on OddSite?

Is there anyway we can automatically add a class or attribute to these inline code snippets on OddSite? If not, maybe we can be a little more specific on OddSite and add a class (or use something like the h-entry class). I think this is more of an OddSite specificity issue.

[mirisuzanne]

Trying to think through this from a structural perspective, because it feels like we might have a higher-level issue to solve.

• There are some places where we only want Herman styles, and we need basically all Herman styles: e.g. most of the generated pages/documentation that is not in a nested iframe.
• Then there are some places where we only want project styles, and we need basically all project styles: e.g. rendering sassdoc examples.

Those should both work ok with the current setup. The outer pages get only the full Herman stylesheet, and the example iframes get only the custom CSS set by the project. Is that right?

So then this issue is specifically about design-token previews (colors, fonts, sizes) which require:

• access to custom properties from the documented-project
• visualizations provided by Herman

And the issue is that both Herman and the documented-project are supplying more styles than necessary in those previews, right? We're getting the full custom CSS from the project (which can interfere with our previews), and maybe we're also passing in more Herman styles than we need for the previews? A few thoughts, which we could try some or all of:

• Split out Herman 'iframe styles' into individual stylesheets for each preview type, so there's less Herman code involved
• Ask projects for a second custom stylesheet, with only design tokens in it, so there's less project code interfering with previews
• Use cascade layers to ensure that Herman preview styles take precedence in selector conflicts. This doesn't solve the issue for properties we haven't set, but maybe using all:revert in a few places would do it?

What we really want here is 'scoping' to keep the the project styles from even accidentally selecting parts of our previews. First thought was shadow-DOM with custom components, but I'm not sure that would actually solve the problem?

Whatever we do here, shouldn't require making changes to OddSite styles in order to resolve the conflicts. It should be on Herman to make sure this all works right.

[mirisuzanne]

@dvdherron @stacyk - I just chatted with @jgerigmeyer about this on our 1:1 call. We think it might be possible to auto-generate a version of the project CSS file that is stripped down to only include custom-properties. That would remove the issue of project styles interfering with preview styles. We'd still want to add these prefixes to Herman custom properties, to avoid naming conflicts in the tokens themselves.

[jgerigmeyer]

We think it might be possible to auto-generate a version of the project CSS file that is stripped down to only include custom-properties.

@dvdherron I can throw together a proof-of-concept for how this might work, if that'd be useful.

[dvdherron]

We think it might be possible to auto-generate a version of the project CSS file that is stripped down to only include custom-properties.

@dvdherron I can throw together a proof-of-concept for how this might work, if that'd be useful.

@jgerigmeyer That would be super useful 🙏🏽

[dvdherron]

@dvdherron @stacyk - I just chatted with @jgerigmeyer about this on our 1:1 call. We think it might be possible to auto-generate a version of the project CSS file that is stripped down to only include custom-properties. That would remove the issue of project styles interfering with preview styles. We'd still want to add these prefixes to Herman custom properties, to avoid naming conflicts in the tokens themselves.

Ok, I'm guessing this would be all of the custom properties that we generate with Accoutrement (sizes/ratios, colors)? Or all custom properties in a project?

This probably means something like the focus styling example wouldn't work or would have to be made in a different way?

[jgerigmeyer]

Ok, I'm guessing this would be all of the custom properties that we generate with Accoutrement (sizes/ratios, colors)? Or all custom properties in a project?

Just all custom properties provided by the project CSS itself.

This probably means something like the focus styling example wouldn't work or would have to be made in a different way?

We would only use this stripped-down version for the iframes that have Herman styles and only need custom properties from the project itself: fonts, ratios, scales, and colors. @example iframes would continue to get the full set of project styles (and no Herman styles -- so no risk of conflict).