Open JohnPixle opened 2 years ago
mghenciu
commented
2 years ago Definitely we need to look into this, @JohnPixle . From what I understand, and just to confirm: we are aiming for Color Variables more, not necessarily hard coded colors, right? This is especially important with FSE themes, where there are multiple styles available.
For Legacy themes, I think not a lot of them have the idea of having multiple Color Palettes, so hard coded should be fine (if vars are not possible).
HardeepAsrani
commented
2 years ago This might be done better with a Color Pallette rather than trying to inherit colors, like we can't possible inherit link color into an element, as there's no one variable for link color and we can't simply make CSS inherit color of a link to non <a> elements. This is where a simple Color Pallette for starts can help, nothing complex, just something that works within the default of Otter blocks.
JohnPixle
commented
2 years ago @HardeepAsrani I understand, but on the other hand we don't want to lose the graceful inheritance of Otter patterns across different themes. So far, Otter patterns are being previewed (and inserted) inheriting most of the styles of the active theme.
The Color variables can be a very simple set of colors indeed, and they can include:
Text color: color that will be inherited on all text and borders of Otter blocks
Accent color: Color that will be inherited in Buttons, links and other elements (progress bars etc)
Inverted bg: Will be used as background in "inverted" (dark) patterns.
Inverted text: text and border color for elements in "dark" patterns.
Light bg: a light color that will be used on block surfaces, cards etc.
We can discuss in the meeting tomorrow some more details on how this can work, but we should keep in mind the theme inheritance as well.
So for example, if the user sets a blank value for the Otter Text Color in the palette, then the text color from the theme must be inherited. I understand we cannot do this for ALL variables, but for Text and Accent colors I believe we should establish a theme-friendly fallback.
JohnPixle
commented
1 year ago Following up on this, we agree to start with the bare minimum amount of colors, and cover just our most basic needs?
Accent Color: accent colors in some widgets where currently we use hardcoded values (e.g. progress bar)
These two below will be used in Patterns (but we should register them in Otter) Inverted bg: For when/ where we use a dark / inverted background color on an area Inverted text: Text used on inverted backgrounds (e.g. white text on black background. )
The rest styles can be inherited by the themes, no need to provide color vars for: Text color Site bg Button/ link color
Let me know what you think! I can wrap up some basic mockups, or update the existing ones. I think this can be enough for starting and test the waters gradually before doing any major overhauls. We can always expand to more color variables in the future, of a reason comes up.
JohnPixle
commented
1 year ago Linking this: https://github.com/Codeinwp/otter-internals/issues/21 where we will adjust/update the UI
JohnPixle
commented
1 year ago In an attempt to set this in motion slowly, I am proposing a summarised and step-by-step plan to implement the color variables. Related Figma.
[ ] Create a variable for Accent color with the value of #ED6F57
[ ] Progress bar block
The default accent color for the progress bar is hardcoded to #6adcfa
Let's set it to accent color.
Also, the lighter (empty part) of the progress bar can be 15% of the accent color
#3878ff
Let's set it to accent color
The (lighter) empty half of the counter appears to be an opacity of the above value (i may be wrong).
Can we set this to 15% of the accent color?
#ED6F57. Let's set this to accent colorWe'll need a way to test and customise the accent color. For starters, let's just add a "Color Palette" panel at the Otter sidebar, which will include only the accent color. We can add more colors there in the future.
Let me know your thoughts!
Following up to the recent discussions we had recently about better defaults in the context of color, here are some notes regarding current issues with blocks and inline color styles.
Progress bar block
The default accent color for the progress bar is hardcoded to
#6adcfaWe need to use the theme's accent / link color if possible for this. For the gray (empty part) it would be great if we can have the link color on a 5-10% opacityCircle counter block
The stroke color of the counter is also set as
#3878ffThe other (lighter) empty half of the counter appears to be an opacity of the above value (i may be wrong). In any case it would be good if these can inherit the theme's accent / link color.For the empty part of the counter, we can have a 5-10% opacity of the link color.
Review Block buttons
The buttons in the review block should also inherit the theme's default button styles. Curently they are assigned the value of
#ED6F57. The button text also appears underlined in the frontend, if there is something we can do about it it would be great.Contact form buttons
The form buttons should also inherit theme default button styles.
Flip box button
Same applies for the button style of the Flip box. It should ideally default to the theme's button styles.
Plugin Card button and accent colors
Let's follow the same approach for the plugin card as well. There are inline colors of
#4550aeso it woulc be great to inherit the theme's accent / link colors.Additionally, there is an issue with the font families for this block. I see the serif font is not related to the theme styles at all. Can we have all the text styles inherit the theme's family?
Countdown block border color
By default, the border color of the countdowns has a
#000color assigned. By default, we want this to inherit the theme's Text color.Let me know if the above make sense, and if you spot any other element that may have inline styles applied on it, feel free to add it in the list.
cc @Soare-Robert-Daniel @HardeepAsrani @mghenciu