Has the thing you are doing ever worked? I mean, if you were to use actual inline svg document then I think it would just work, but I doubt you are doing that. But if you just use an svg image using say, list-style-image or background-image, then I don’t think currentcolor inside the svg has ever worked.
The way colors are forwarded from the embedding document (in gecko) to the svg is bit of a hack. The svg icon needs to have certain attribute value in its definition: example: ... AND the element using this svg icon needs to declare that such forwarding is needed using css .thing { -moz-context-properties: fill, fill-opacity } AND then setting the fill color like .thing { fill: currentColor }.
And you need to set svg.context-properties.content.enabled if the svg file you are using is not loaded using chrome:// or resource:// uri.
If you do that setup then you can totally make them use currentColor from the embedding document. This hackery might not be required anymore when/if css link params is implemented.
Has the thing you are doing ever worked? I mean, if you were to use actual inline svg document then I think it would just work, but I doubt you are doing that. But if you just use an svg image using say, list-style-image or background-image, then I don’t think
currentcolorinside the svg has ever worked.The way colors are forwarded from the embedding document (in gecko) to the svg is bit of a hack. The svg icon needs to have certain attribute value in its definition: example:
...AND the element using this svg icon needs to declare that such forwarding is needed using css.thing { -moz-context-properties: fill, fill-opacity }AND then setting the fill color like.thing { fill: currentColor }.And you need to set
svg.context-properties.content.enabledif the svg file you are using is not loaded usingchrome://orresource://uri.If you do that setup then you can totally make them use currentColor from the embedding document. This hackery might not be required anymore when/if css link params is implemented.