Needs work
Project:
Drupal core
Version:
main
Component:
Umami demo
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
13 Mar 2023 at 18:36 UTC
Updated:
20 Oct 2023 at 12:02 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #3
markconroy commentedI've converted as much as I can to using variables. I've left some hard coded values as they are "special numbers" and only available in one or two places in the CSS.
I'd like to get this much merged if we could as it's a huge improvement and we can see if we can amend the designs a little bit in a follow up to rationalise some of the magic numbers values.
Comment #4
smustgrave commentedBuild error
But will keep an eye out as this looks good to me.
Comment #5
markconroy commentedIt's probably a fair failure. My copy/replace changed values in the /css/class directory. Maybe we should leave that directory alone.
Comment #6
markconroy commentedComment #7
aziza_a commentedBuild error - command failed
Comment #8
spokjeWas just passing by and was amazed why our spellchecker cspell not only didn't know the word "grey", but also outright forbids it's usage.
Then I found #3155258: Use American English spelling of "gray".
Comment #9
markconroy commented@Spokje good find, but crazy we can't actually use it even in a variable name.
Comment #10
spokjeMumbles something about crazy Yankees
Fully agreed, but that's the way it is :)
Comment #11
smustgrave commentedClose!
profiles/demo_umami/themes/umami/css/components/forms/buttons.css
45:16 ✖ Unexpected unknown function "-var" function-no-unknown
51:33 ✖ Unexpected unknown function "-var" function-no-unknown
Comment #12
markconroy commentedComment #13
smustgrave commentedLooks good!
Comment #15
gauravvvv commentedEverything seems good only minor miss. In the
core/profiles/demo_umami/themes/umami/css/components/blocks/disclaimer/disclaimer.cssfile, margin-left variable should be--spacing-smallerComment #16
smustgrave commentedThanks.
Comment #17
nod_Seems like the svg changes are not working as intended. Some of those files are loaded as background images and (at least on FF) the color is not picked up properly.
Comment #18
nod_Comment #19
nod_Maybe using a fallback in the svg files would do the trick.
Comment #20
Harish1688 commentedHi nod,
as per comment #17, if we used the SVG files as background images and use the variables to fill the svg icon color. it's not working (it's because they not get the variable source).
1. solution - working
we can redeclare the variable in the SVG file, working fine.
2. solution - working (looks more better, it's variables control generic way)
we can call the variables css file in the SVG file, working fine.
Comment #21
Harish1688 commentedComment #22
Harish1688 commentedComment #23
Harish1688 commented2. solution - working (looks more better, it's variables control generic way)
Comment #24
markconroy commentedThanks @Harish1688 for working on this.
I've added a new commit to remove all the Adobe Illustrator classes from our SVGs. I hadn't realised they were still there to be honest, and should not be. They are too generic and if used inline
.cls-1in one SVG will override.cls-1in another SVG if they are on the same page.All the SVGs are now using the same approach of having their fill colour set via a CSS hex value.
Comment #25
Harish1688 commentedHi markconroy,
Thanks for this point, but instead of fill the hard value in the fill=" " attribute, we may declare the variables here to like .
In that case we will not face any css
.cls-1classes conflict issues on generic approach. and variables also can be used.Comment #26
markconroy commentedThere's 2 issues with that:
1. We need to go through every CSS value in each SVG, which could be tricky (only the SVGs exported via Illustrator have this .cls-1 issue, which is why this only showed up in 2 SVGs)
2. When I tried to add
fill="var(--color-primary)to SVGs last night, the variable wasn't picked up (perhaps because these SVGs are used as background images rather than inline.Let's get this MR merged with the current approach and we can file a follow-up issue to look at the SVGs more closely later.
Comment #27
Harish1688 commentedHi markconroy,
1. We need to go through every CSS value in each SVG, which could be tricky -- we could do it, this way only, because SVG called as background image so css will not here. (masking css property not a proper solution here )
2. When I tried to add fill="var(--color-primary) to SVGs last night, the variable wasn't picked up (perhaps because these SVGs are used as background images rather than inline. -- you need to call the variables source in SVG file mention in comment #25
<link xmlns="http://www.w3.org/1999/xhtml" rel="stylesheet" href="../../css/variables.css" type="text/css"/>Comment #28
markconroy commentedI don't want to do that. if we do that, then we might as well just hardcode the variables like my latest commit does. Or else we are declaring a variable definition repeatedly, and using it just once in each file.
Again, let's get what we have merged as it's a great improvement, and let's talk about the SVGs in a follow up issue if we need to.
Comment #29
smustgrave commentedOpened #3357143: Discuss SVG for Umami Theme could use more details though.
Comment #31
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #33
snig commentedI adjusted the MR to align with the recent updates from version 10.1.x. Since there's a dedicated ticket for managing SVG colors, we should address it there to allow the main ticket to proceed with merging.
Given our theme's transition to an SDC structure, it's crucial to accelerate the migration to CSS variables to minimize potential conflicts down the line. Let's update the status to "needs review" to facilitate this process.
@smustgrave, I'm uncertain whether we should initiate an 11.x branch
Comment #34
smustgrave commentedAnswer is yes. Code has to go into 11.x first and can be backported.
Comment #35
smustgrave commentedComment #37
snig commentedComment #38
snig commented