Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SVGs turn to black in Safari during transformations, akin to a bug with <base> tag #899

Open
plagasul opened this issue Nov 26, 2018 · 2 comments

Comments

@plagasul
Copy link

Your system information

  • VelocityJS version: VelocityJS.org (1.5.2) / VelocityJS.org jQuery Shim (1.0.1)
  • 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:

$('.rotating:eq(1)').find('path').velocity(
    {opacity: 0},
    {
        duration: 2000,
	queue: false,
	complete: function(elements) { 
	     $.each(elements, function(i,v){
	         $(v).parent().remove();
	     })
         }
    }
);

Could it be that velocity is doing something akin to what 'base' does within that complete call?

Documentation says:

"The callback is passed the entire raw DOM (not jQuery) element array as both its context and its first argument."

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

@Rycochet
Copy link
Collaborator

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.

@plagasul
Copy link
Author

plagasul commented Dec 2, 2018

Thank you,
I'll be back with updates and or a jsfiddle as requested.
velocity v2 I understand is in beta
thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants