I'm trying to debug why this piece of animating SVG isn't working in Firefox.
Test case & code here: http://jsbin.com/AYICOwE/18/edit
I'm changing the stroke-dasharray attribute on a <path>-element inside of an inline <svg> graphic, to progressively draw a dashed line. Since I don't want the path to show before I animate it, I set the stroke-attribute to none initially (have also tried to set it to a transparent color), and then re-set it when the animation runs.
The progressive drawing of the dashes works everywhere when the line initially has a visible stroke, but as soon as it doesn't, Firefox doesn't show anything at all. When the line is initially shown, I can still animate it, hide it (by setting stroke to none) and show it again etc.
Toggling CSS properties in the inspector (causing the element to repaint) afterwards snaps it into view.
Browser bug, or something I'm doing wrong/stupidly? Workaround ideas?
Related
I want to animate an SVG path to 2 different states. For this, I've created a triangle path, with 2 example animations, which I trigger through Javascript.
These animations only have the "to" attribute because the intention is to animate the path from whatever state is in to any other desired state (the final animation will have 10+ states).
You can see a working example here: http://codepen.io/anon/pen/dxvlt
The problem is that, at least in Chrome, if you click Animation1, then Animation2, then back to Animation1 it works fine. However, right after that, animations stop working, or only one of them works. I believe the animation is triggered, but it's not being drawn. This problem does not happen in Firefox, and I've read that Webkit and Blink have numerous SVG bugs.
Do you know a workaround to make it draw correctly on Chrome as well?
I'm using absolute positioning to move a VERY large SVG img around inside another div element. I've set up a jsFiddle as a demo:
http://jsfiddle.net/wEBnE/6
This works fine in all browsers except (you guessed it) IE. Click the button in the jsFiddle a few times. It increases the top position 3 times until it goes beyond -84245px - then the image stops moving. The css property still increases, but the visible element remains in the same position.
As far as I can tell, this only happens with an img tag. I have other div elements that work fine like this.
Am I correct in thinking it must be some sort of built-in IE maximum setting and is there a way to override this behaviour?
Thanks
I GOT THE SOLUTION: Using a div with background instead of the img tag works like a charm.(But it would be nice to know why did this happen, so if you have an idea feel free to comment.)
I have a kinda strange problem. I have a png image on my site, resize from 280x280 px to 40x40px (in the CSS it's 40 x auto). The problem is that the image appears pixelated on the edges, but when I change it to an other picture with a jQuery click event (same size, just colored) it appears nicely width sharp edges. If I change the order and display the colored version first, and then change it, the colored one appears pixelated. So somehow the changing affects the image I guess, but when I click on it again to change it back it's pixelated again. I tried to add the img with jQuery, no effect. Has anybody seen something like this before? Any ideas? This happens in Firefox. In IE, the pic is pixelated in both states. In chrome it works fine.
UPDATE:
This is how it looks before click:
After click:
UPDATE 2:
I thought I found a workaround, but I just found half a workaround... So I made a gif image of the first png. I display that first, then on the click event, I switch between the two png-s, and they look good. But of course, the gif on the first load has the same issue. If I change it on document.ready the png becomes pixelated...
I currently have a DIV with an image and 2 children, like so:
<div id="main">
<div id="left"></div>
<div id="right"></div>
<img ... />
</div>
I'm applying a 3D transform to #main like so:
'transform':'perspective(800px) rotateX(0deg) rotateY(60deg)';
Here's the CSS I have for left/right:
#left, #right {width:50%;height:100%;position:absolute;z-index:999999;}
#right {right:0;}
Clicking on either left or right will navigate to the prev/next image.
I also have some fade hover events setup on the left/right containers. It works good works well in all browsers when the rotation degrees are 0.
However, whenever I apply a rotateX or rotateY it has some odd positioning problems in Opera and Chrome only.
All other browsers seem to handle the events of the left/right divs relative to the 3D transform just fine. However in Opera and Chrome, the transforms seem to mess with the triggering of the mouseenter,mouseleave and click events of the left/right divs.
To make this even more strange, it will only happen on one of the child elements. Whatever side of #main is positioned farther away in 3D space presents problems. The DIV that is closest to the viewer will still hover just fine.
I've also added borders and colors to each DIV, and it isn't an actual positioning issue. Both DIVs show up perfectly.
Here's a screenshot. The white border is applied to #main.
Inside #main you can see the 2 left/right DIVs. The problematic one (pushed farther back in space) has a white gradient. I've applied a purple border to each one. The foreground one in bright green works perfectly.
Any suggestions would be awesome. Works in everything except Opera and Chrome.
Thanks!
Ok, so finally figured this out and will hopefully help others.
When working in 3D space certain browsers will correctly intersect/clip other elements. Safari is one of these browsers. When rotating an element in 3D space like in the screenshot above, the actual #main is intersecting with the background element. The correct way a browser should handle this is by clipping off the part that goes "into" the element behind it. However, the majority of browsers do not show clipping and will instead show the transformed element (although it's intersecting another element) like in the screenshot above. Safari, however correctly handles this and would clip off the part of #main where it intersects the background.
For whatever reason, Chrome and Opera still show #main when clipping occurs, however any events that are bound to the transformed element will not be fired because you're hovering over the background element, and not the element that has been transformed.
All other browsers that don't clip transformed elements will fire events on those transformed elements.
The solution is to adjust the Z axis of the transformed element.
I have a small web-app I'm developing for myself.
When I click the add button, it calls some .load functions to return the error message and the updated table.
However, it causes the gradients to look like this (look around the error message and to the top left/right of the table):
The gradient is set to the background of the containing div (The grey one inside the green one). The jQuery loads in a single <p> for the message and a <table> for the table.
I can't see why this would happen to the gradient, as it works fine on the initial page load (before jQuery updates it).
Is there anyway to force the background to 'refresh'? It fixes itself if you inspect element or change to a different tab then back to this one.
With the limited information provided, I would assume it is less an issue with the "background gradient" and more an issue of the elements in the foreground having an opaque and/or colored background being overlaid on top of the background gradient.
Have you styled the <p> in question to have a transparent background, or is there a background color being applied to it (either directly or inherently)?
Please provide more info (the CSS and a bit of HTML) for the problem for a better answer.