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 was archived by the owner on Jun 5, 2023. It is now read-only.
Some aspects of our theming system could use some streamlining to make it both easier to use and more flexible.
Issues:
Button colours are currently global and separate from both Theme Sections and Color Blocks. They're simpler than a Theme Section, and slightly more complex than a Color Block (giving separate control over text and background colour). In a way, they're an escape hatch I introduced because neither concept was fitting 100%.
Neither Color Blocks nor Buttons can be customised per Theme Section. Since Buttons are global, they may clash with some of the colours set for a theme section. Ironically, the negative example in the Storybook theming explainer can still easily happen in base5-ui. There needs to be a theme-level escape hatch for that.
Theme Sections often share similar variables. Especially the fields links, highlight, textDimStrength, shadeStrength, and lineStrength are often the same across multiple Theme Sections.
Approach:
Allow specifying a default Theme Section sections.default which will be extended when variables are missing from any other section
Move default Color Blocks from globals.colorBlocks into sections.default.colorBlocks; then allow overriding them in other sections
Allow defining Color Blocks in more detail. Currently, they extend a Theme Section named colorBlock, replacing its text, links, and background fields, without precise control over how that's done. It should be possible to instead of assigning a simple colour string, assign an object that overrides the default Theme Section (e.g. instead of positive: 'green', allow positive: {text: '#fff', background: 'green'}). Again, missing fields would be taken from the default.
With the aforementioned update, buttons could then be turned from special global variables to simple Color Blocks, e.g. button-default, button-primary, and button-important.
Implementation:
All of this needs to be done in a backwards-compatible way, we can't break existing themes
Investigate whether the colorBlock section we're currently using is still necessary when we introduce a default Theme Section The colorBlock section has been removed in the meantime ✅
Some aspects of our theming system could use some streamlining to make it both easier to use and more flexible.
Issues:
links,highlight,textDimStrength,shadeStrength, andlineStrengthare often the same across multiple Theme Sections.Approach:
sections.defaultwhich will be extended when variables are missing from any other sectionglobals.colorBlocksintosections.default.colorBlocks; then allow overriding them in other sectionsCurrently, they extend a Theme Section namedIt should be possible to instead of assigning a simple colour string, assign an object that overrides the default Theme Section (e.g. instead ofcolorBlock, replacing itstext,links, andbackgroundfields, without precise control over how that's done.positive: 'green', allowpositive: {text: '#fff', background: 'green'}). Again, missing fields would be taken from the default.button-default,button-primary, andbutton-important.Implementation:
Investigate whether theThecolorBlocksection we're currently using is still necessary when we introduce adefaultTheme SectioncolorBlocksection has been removed in the meantime ✅