Closed dvdherron closed 1 year ago
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.
@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?
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.
Trying to think through this from a structural perspective, because it feels like we might have a higher-level issue to solve.
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:
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:
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.
@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.
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.
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 @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?
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).
Description
Steps to test/reproduce
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.