You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Browser: Safari 11.1.2 (and probably other versions)
Operating System: OSx El Capitan (and probably other versions)
Checklist
Is this an issue with code?: [Yes]
Is this an issue with documentation?: [No]
Have you reproduced this in other browsers?: [No]
Have you checked for updates?: [Yes]
Have you checked for similar open issues?: [Yes]
Please describe your issue in as much detail as possible:
First, context:
In Safari, if the 'base' tag is used, any SVGs that use url(), for example to point to a gradient within the 'defs' tag of the same svg code, show as black (see here, or here)... the whole SVG shows as black.
This is because the 'base' tag changes the relative url and so the url call fails.
I was having this problem, but removed the base tag and it was fixed.
Now, velocity:
I am getting a variation of this bug, tied to velocity transformations, without 'base' tag present.
I am dynamically prepending, fading, rotating and removing SVGs on the page.
In several moments of this transformations, the SVGs turn black, and back to showing the right gradient, then back to black, etc.
Before I try to reproduce the code in a fiddle, I have one main suspect, which is how I target and remove elements within the complete call, because when an element is removed, another one, or several, usually turns to black:
Velocity V1 is completely unsupported now - can you try again with V2. If that still does it then it might be a Safari bug (especially if it doesn't happen in other browsers).
That specific bit of the docs is just explaining that it passes the this value you're passing to Velocity back as arguments, just not wrapped in a jQuery object any more (ie, it's just an array). Velocity V1 does keep hold of elements in memory longer than strictly necessary, but once they're detached from the DOM that won't actually make any difference.
Btw, if you're sure of the exact DOM structure of the SVG then .parent() is fine - but (having edited SVGs by hand for many years) you'd probably be better to do something like .closest("g,.rotating") or similar.
Your system information
Checklist
Please describe your issue in as much detail as possible:
First, context:
In Safari, if the 'base' tag is used, any SVGs that use url(), for example to point to a gradient within the 'defs' tag of the same svg code, show as black (see here, or here)... the whole SVG shows as black.
This is because the 'base' tag changes the relative url and so the url call fails.
I was having this problem, but removed the base tag and it was fixed.
Now, velocity:
I am getting a variation of this bug, tied to velocity transformations, without 'base' tag present.
I am dynamically prepending, fading, rotating and removing SVGs on the page.
In several moments of this transformations, the SVGs turn black, and back to showing the right gradient, then back to black, etc.
Before I try to reproduce the code in a fiddle, I have one main suspect, which is how I target and remove elements within the complete call, because when an element is removed, another one, or several, usually turns to black:
Could it be that velocity is doing something akin to what 'base' does within that complete call?
Documentation says:
Although I am not sure to fully understand what that implies, it sounds as it could be related to this problem.
Thank you
Steps for reproducing this issue (code):
not yet
JSFiddle example showing issue in action (code):
not yet
The text was updated successfully, but these errors were encountered: