#5027 - Theme wizard: Inconsistencies with generated themes
-
By PDStig
- Added
- 3 views
| Identifier | #5027 |
|---|---|
| Issue type | Minor issue (breaks specific functionality) |
| Title | Theme wizard: Inconsistencies with generated themes |
| Status | Completed |
| Tags |
Roadmap: v11 (custom) |
| Handling member | PDStig |
| Addon | General / Uncategorised |
| Description | There are a few areas to check into when generating a new theme using the theme wizard in v11:
* New themes seem to set their own settings in theme.ini that are not congruent with the default theme, e.g. using regular icons instead of monochrome, disabling the homepage banner, etc. Perhaps these should be "advanced" settings on the theme wizard screen that an admin can define? * Theme wizard also seems to modify the default theme's theme.ini after creating a new theme from it. * Generating a theme using HSV shift creates a dark background (looks like a permanent overlay is activated, but I don't think there is). * Light / bright colors are not properly contrasted: - links and menu items are barely visible - button text remains white against the bright background color when it should be black. - Table header text not properly contrasted (still white instead of black) - Borders are barely visible * Dark mode needs heavy work: Lots of areas where text or icons are too dark * CSS breaks / does not load correctly for white and black seeded themes. |
| Steps to reproduce | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
Second item: Not true
This is not conditional to seed. Also, it usually resolves itself after the first page load (except for previews which re-generate on every page load).
>> All other bullets in this issue are resolved, although there may still be a few hidden colour contrast issues in themes.
---
Added new themewizard equation: contrast. This outputs a new colour given the provided contrast ratio (the HSV value and saturation are adjusted until the contrast ratio is met or both value and saturation reached their min/max allowed).
Example use: {$THEMEWIZARD_COLOR,#ffffff,seed_contrast_medium,100% (seed contrast 4.5)} [outputs a new color that has a contrast ratio of up to 4.5 compared to the seed colour]
---
Added {$THEME_COLOUR_IS_BRIGHT,colour} Tempcode symbol. Returns 1 if the luminance of the specified colour is 0.5 or higher, else returns 0. Can be used to determine when to use white versus black text. For example:
/*{+START,IF,{$THEME_COLOUR_IS_BRIGHT,{$GET,button_primary}}}*/
.btn-primary img.icon {
/* When the buttons are bright, we do not want their icons to be white after-all */
filter: none !important;
}
/*{+END}*/
This makes the icons on the primary buttons black when the button colour is bright.
Black seems to be less visible against the seed background than white was, so I thought this was a bug. However, when I calculated the black / white color contrasts, black came out at 5.31 whereas white was 3.95. So technically, the theme wizard was correct in choosing black according to WCAG standards despite it looking less visible to me personally.
May want to review this more. Maybe the WCAG algorithm is flawed.
Edit: The WCAG 2.0 standard is indeed flawed. WCAG 3.0 / APCA is much more accurate.
Additional note, while what I said above about WCAG 2.1 is true and that I still recommend WCAG 3.0 / APCA, a good PHP implementation is not yet available. So I'm using luminance instead of contrast ratio to determine black versus white text.