mix-blend-mode not working as expected when applied to svg elements inside of transformed <g> tags.
Categories
(Core :: SVG, defect)
Tracking
()
People
(Reporter: petterssonalbin, Unassigned)
References
Details
Attachments
(1 file)
675 bytes,
image/svg+xml
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0
Steps to reproduce:
Create an SVG file. Add an element with some color, for example a square covering the entire area with fill set to blue.
Then define an svg element inside of a transformed <g> tag and give the element a class or id.
Then style that component using a <style> tag, and set it's mix-blend-mode to multiply and its fill color to a gray color.
<?xml version="1.0" encoding="UTF-8"?>
<svg width="100" height="100" version="1.1" viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
<style>
.mix-mult {
fill: #bbbbbb;
mix-blend-mode: multiply;
}
</style>
<!-- Background -->
<rect width="100%" height="100%" fill="blue" />
<!-- Top Right -->
<g transform="translate(50 0)">
<rect width="50%" height="50%" class="mix-mult" />
</g>
</svg>
The same issue seems to arise with some additional (all?) blend modes. The same issue also seems to arise no matter which transforms are applied to the surrounding <g> tag, as long as it is transformed.
I'll attach a file which shows the issue. It renders as expected on both Chrome and Opera.
Actual results:
The element (in this particular example the element with its class set to mix-mult) is rendered as gray.
Expected results:
The element (in this particular example the element with its class set to mix-mult) should have been multiplied with the background, in this case resulting in a darker shade of blue.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::SVG' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•3 years ago
|
||
Thanks for the bug report.
Looks likely to be the same core issue as bug 1379524. (The testcase there involves an animation instead of a transform, but per bug 1379524 comment 1, setting a transform (or will-change:transform
) triggers the same issue, which seems to be what the testcase here is doing.)
Description
•