gradients, clipPaths and masks inside svg:symbol aren't rendered
Categories
(Core :: SVG, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | fixed |
People
(Reporter: takenspc, Assigned: emilio)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060918 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060918 Minefield/3.0a1 gradients inside svg:symbol aren't rendered. gradients outside svg:symbol are rendered. Reproducible: Always Steps to Reproduce: 1.Open a svg file which has gradient(s) inside svg:symbol aren't rendered. 2. 3. Actual Results: gradient(s) are not rendered. Expected Results: gradient(s) are rendered.
Reporter | ||
Comment 1•17 years ago
|
||
4 rects shuld have same gradient.
Comment 2•17 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060920 Minefield/3.0a1 Confirmed.
![]() |
||
Comment 3•17 years ago
|
||
Why would you put the gradient _inside_ the symbol? The elements in the symbol are probably cloned into a shadow tree, in which case you're increasing memory use (and there are going to be multiple shadow elements with the same ID).
Reporter | ||
Comment 4•17 years ago
|
||
(In reply to comment #3) > Why would you put the gradient _inside_ the symbol? Adobe Illustrator 12.0.1, SVG Export Plug-In exports svg files which include the gradient inside the symbol. For example, http://spreadfirefox.jp/foxkeh/downloads/parts/tail01.svg another examples at http://spreadfirefox.jp/foxkeh/downloads/parts/ # A mascot in those pages is Foxkeh, a mascot of Firefox brought by Mozilla Japan.
Comment 6•14 years ago
|
||
#3 jwatt asks "Why would you put the gradient _inside_ the symbol?" one reason is authoring tool user interface. beyond hand coding... ie unless a number of icons are saved as a set at one time, each will have the gradients, then when the icons are agglomerated, there is much duplication: http://www.openicon.org/icon-ark/freedesktop/gnome/devices.svgz
Updated•14 years ago
|
For the SVG-edit project, I'm working on arbitrary SVG importing. The idea is to insert a <symbol> element with the data, so multiple copies can be made using <use>. This bug means that import files with gradients will thus appear filled in black when using Firefox. As a workaround I was going to put the imported <svg> in a <defs>, then have the <use> elements refer to that, but unfortunately Adobe Illustrator incorrectly displays an image like this (it does fine with <symbol>). A bug on their part, certainly, but it forces me to decide whether to support Firefox or Illustrator. Considering how <symbol> is very very similar to <svg> elements (in which this bug does not occur), I find it hard to imagine that this bug would be hard to fix.
Comment 9•12 years ago
|
||
Just FYI: The Foxkeh assets, including the broken tail SVG files in comment 4, have been moved to http://www.foxkeh.com/downloads/parts/
Comment 10•12 years ago
|
||
A similar problem occurs when we have overlapping IDs and the first occurrence is within a hidden group. This crops up in Santa's Workshop and results in the snowflakes, trees and elves appearing partially or wholly black: http://ie.microsoft.com/testdrive/Performance/SantasWorkshop/Default.xhtml The attached test case is a simplified version of what's happening in Santa's Workshop. I suspect the root cause is the same as this bug. Namely, if a gradient first appears in a context that isn't rendered we seem to refuse to render it from there on. The fact that Illustrator is exporting this sort of arrangement raises the importance of this bug as does its use in Santa's Workshop.
Comment 11•12 years ago
|
||
The display:none is a different issue, bug 376027 tracks that.
Updated•12 years ago
|
Comment hidden (advocacy) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (advocacy) |
Comment hidden (off-topic) |
Comment hidden (obsolete) |
Updated•7 years ago
|
Comment 25•3 years ago
|
||
(In reply to Kirby from comment #15)
(In reply to Brian Birtles (:birtles) from comment #14)
Kirby, please keep comments to those which help fix the bug. For progress
updates, please follow bug 376027. My previous patch for that bug also fixed
this bug (since they have the same root cause) but was unfortunately
rejected due to questions raised about the validity of the spec. I have
investigated an alternative approach and written it out in detail so that
another contributor can implement it. If no one else is available I will try
to implement it soon.Brian: I am sorry my previous message came out sounding so angry and
frustrated. I wish you the best of luck in finding a solution to this
problem— know that I am continuing to monitor it with fingers-crossed.
Hey Kirby, I was experiencing this exact issue...in 2020. Good news is that there seems to be a workaround, here's a code pen that some created which illustrates the technique: https://codepen.io/RwwL/pen/GgaGgV.
Long story short, you need to define the clip paths outside of the symbol, once you've done that you should be able to reference that symbol with the use
element. Not ideal, but definitely let me still use symbols for my icon sprites! Hopefully this is helpful for your use case
Comment 26•3 years ago
|
||
Update on the bug reproducing:
This SVG file will be proper rendered in the last version of Chrome, IE (exept Firefox):
<svg id="custom-shape" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 50 50">
<symbol viewBox="0 0 50 50" id="sun">
<defs>
<radialGradient id="grad1" >
<stop stop-color="#EFDC75" offset="0%" />
<stop stop-color="#B6A01A" offset="100%" />
</radialGradient>
</defs>
<circle cx="25" cy="25" r="25" fill="url(#grad1)" />
</symbol>
<use xlink:href="#sun" x="0" y="0" width="50" />
</svg>
For this moment the solution is to use defs outside a symbol:
<svg id="custom-shape" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 50 50">
<defs>
<radialGradient id="grad1" >
<stop stop-color="#EFDC75" offset="0%" />
<stop stop-color="#B6A01A" offset="100%" />
</radialGradient>
</defs>
<symbol viewBox="0 0 50 50" id="sun">
<circle cx="25" cy="25" r="25" fill="url(#grad1)" />
</symbol>
<use xlink:href="#sun" x="0" y="0" width="50" />
</svg>
For dynamically created SVG I add symbols with their design incapsulated. For Firefox I need adittionally manage common <defs>. I think it is not convinient.
Please, pay attention on this bug.
Assignee | ||
Comment 27•3 years ago
|
||
I think this should be easy to fix, actually.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 28•3 years ago
|
||
Other UAs allow this, and it seems in the general consensus of
https://github.com/w3c/webcomponents/issues/179.
This matches WebKit's behavior. Blink, for some reason shows red on the
test-case, probably because they're not doing quite this, but they
manage to render masks inside the display: none symbol element or such.
Comment 29•3 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8efff752175e Allow IDTracker to look up elements in <svg:use> shadow trees. r=smaug
Comment 30•3 years ago
|
||
bugherder |
Description
•