Problem/Motivation
I was working now with css clip-paths and it all works well, untill it goes to production. In the combined css `clip-path: url('#clip-cloud')` is then rewritten to `clip-path: url('/themes/my-theme/css/#clip-cloud')`, which breaks the svg reference.
Steps to reproduce
Use any theme css file with a svg id refference: `clip-path: url('#clip-cloud')`
Proposed resolution
I would say, best would be, if I could mark some parts of a css file to not be rewritten... Alternatively, `url(#whatever)` should NOT be rewritten. It's probably safe, but might lead in cases i don't know to an error.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Comments
Comment #2
akozoriz commentedComment #3
mherchelHaven't tested this, but maybe try to add
{ minified: true }to the CSS file within your library.Comment #4
brobert7 commentedI've verified that I'm seeing the same behavior - my
clip-path: url(#something)gets rewritten to a relative link and breaks the SVG reference.Adding
{ preprocess: false }to the stylesheet reference in the THEME.libraries.yml file DOES work, but{ minified: true }DOES NOT.Comment #5
danlew commentedI've just run into this on core 10.0.7.
Turning off the aggregation stops the problem, but is definitely a workaround, not a fix.
The original suggestion of testing the path to see if it starts with `#` seems like a sensible idea. I can't think of any reason for that not working? Can anyone smarter than me think of any reason that would fall over?
Comment #6
danielehrenhofer commentedThe problem also exists on core 10.1.x-dev.
The workaround described here, switching off aggregation, still solves the problem.
Comment #7
mkalkbrennerComment #8
smustgrave commentedAs a bug can we get a test case showing this problem?
Comment #9
mkalkbrennerI just can see the issue on our website that some "parts" of SVGs embedded in CSS are missing. The patch in #7 fixes this issue and the SVGs are "completely visible" again.
I can't tell if the fix suggested in the issue description here is correct for all use-cases, but it fixes our issue. So I shared the patch here as a beginning.
I would leave the addition of tests to someone who has better knowledge about SVG and who can judge if the suggested patch might cause other issues instead of just solving the clip-path issue.
Comment #10
heykarthikwithuHi @smustgrave, in regards to
Below is the test case shows the problem.
Log for reference:
Here's code within import3.css
Thanks :)
Comment #11
smustgrave commentedCan we add the test case to the patch.
Comment #12
heykarthikwithuHi @smustgrave, in regards to
Attached the patch file with test case & inter diff changes.
Log for reference:
Thanks :)
Comment #13
smustgrave commentedThanks but you don't need to post the output of the test passing, that's shown by the patch.
Typically uploading a test-only patch would be good though.
But ran the test locally. and got
Failed asserting that two strings are equal.
Expected: 'div{clip-path:url('#clip-cloud');}\n
Actual: 'div{clip-path:url(generated-relative-url:core/tests/Drupal/Tests/Core/Asset/css_test_files/#clip-cloud);}\n
So the test appears to be covering
Good job!
Comment #14
catchDo we have or need coverage for when the URL is relative but contains a
#?Comment #15
heykarthikwithuHi @catch I see, we don't need coverage for this scenario.
I have checked locally with below scenario
div{clip-path:url('#clip-cloud');}div{clip-path:url('/abc/#clip-cloud');}I have noticed, bug described in the issue summary will not show up with the case of relative url, like
clip-path: url('/abc/#clip-cloud');So, we don't need coverage for this scenario.
Comment #16
catch@heykarthikwithu it's not the question of whether there's a bug now, it's adding test coverage to show that there isn't and preventing one being introduced in the future. I think that just adding an extra bit of CSS to the test file and assertion would be enough.
Comment #17
heykarthikwithu@catch,
sure.. here's the patch.
Comment #18
catchYeah that looks good!
Comment #21
catchCommitted/pushed to 11.x and cherry-picked to 10.1.x, thanks!