In Safari all is well, in Firefox, the svg is not the correct size and when I transform it, it disappears. I'm running Safari Mac 5.1.7 and Firefox Mac 15.0.
The code was created with d3 but I've just supplied the html.
Now you see it: http://bl.ocks.org/3531350
Now you don't: http://bl.ocks.org/3531267 (edited so it works now)
I imagine I have made a foolish mistake somewhere but I just can't see it!
I can see the svg at the bottom of the grey area if I add height and width attributes of 100% to the outer svg element. They do really need to be there if you are using svg embedded in html. I suspect Safari will require width/height in embedded svg at some point.
Related
I'm using D3 v4 to achieve the zoom functionality and everything works perfectly on FireFox, Chrome browsers.
Quite different behavior with Safari browser (my version is Version 10.0.1 (12602.2.14.0.7)). Wheel zoom works for g element and doesn't work for svg element. Note: that dbClick zoom works for svg element.
I've created simple fiddle example where tried to reproduce the issue.
If you try wheel zoom over red rect - it will work, outside of rect - not work, but works for other browsers.
I was looking for official examples like https://bl.ocks.org/mbostock/db6b4335bf1662b413e7968910104f0f where everything works and I could not find a problem with my example...
Here is a zones where zoom works (madness is that left and top zone in the svg has working zoom):
I got answer from mbostock:
PROBLEM:
As shown in the https://jsfiddle.net/vbabenko/5shshq97/7/ , this is a Safari bug (or if you like, an alternative interpretation of the specification). Safari does not dispatch wheel events to the SVG when there is no SVG content under the pointer; the events get sent to whatever is underneath the SVG element (the body in this case). In contrast other browsers dispatch wheel events to the SVG element anywhere inside its bounding rect.
SOLUTION:
If you want the SVG to receive the event on all browsers, you must put some content in the SVG to capture the wheel event. Here is a fixed test case: https://bl.ocks.org/mbostock/9e3fed7a5904991e7973a87628d9f84d
ORIGINAL DISCUSSION:
https://github.com/d3/d3/issues/3035
On this page http://bit.ly/202URGh, when I click on Book Size (Second row icons) and then click on Book type (First row icons), the image collapses into the other div.
I have added clearfix, but that seems to have had no effect. This seems to be a problem only in Safari on Mac. Other browsers work fine.
Can someone help. My problem is compounded because I don't have a Mac to test.
I understood the source of the problem. Issue was because I was trying to get the height of image dynamically. Safari (and webkit based browsers) do not seem to support dynamic height computation. Jquery was returning the height as zero and hence the div was collapsing.
In my html document, there are some tiles with two pictures (one jpg as a background and one png with transparency as a foreground) and with a hover effect:
On the current tile which you are hovering, the image gets zoomed where your mouse is and the front image gets moved away from the cursor.
While moving the cursor only horizontally, all vertical pictures are animated too and the other way round.
Here is an example with all html, javascript and css:
http://jsfiddle.net/Lmcn0sxw/6/
The effect is working (with a few bugs, but that's not important).
The animations are easily added with javascript and transform3d where item is the current tile with the class .item.
Variables like topRatioFron are calculated from the current mouse position relative to the current tile.
item.find('.front').css('transform', 'translate3d(0,' + topRatioFront + 'px,0)');
item.find('.back').css('transform', 'translate3d(0,' + topRatioBack + 'px,0)');
There are some variations which you can see in the jsfiddle javascript code.
The main tile gets animated with a matrix3d effect:
self.find(itemClass).css(
'transform',
'matrix3d(1,0,0.00,' + leftRatio + ',0.00,1,0.00,' + topRatio + ',0,0,1,0,0,0,0,1)'
);
In the Google Chrome Browser on Linux Mint, it works perfectly. On Google Chrome on Windows, it works too. In Mozilla Firefox, it's not as perfect as in Google Chrome, but it's okay.
The actual problem
A friend opened this site on a Mac with Safari, and all animations were really laggy (it looked like it was shaking). Another friend opened this on a Mac in the Chrome browser, and it was shaking too, but this time not in Safari.
How can I test or find out what this is causing? It can't be the performance of the computer they used, because this site with the same effect is working perfectly in ALL browsers, regardless of the operating system.
What I tried
First, I used translate instead of translate3d (I read that the latter is faster), but It didn't help.
I later added a function called requestAnimationFrame which can help rendering animations. The result was the same.
The second problem
On Safari (I tried it with v8.0.7), the matrix3d transform works, but all other transforms don't work, not on the current tile and not on the others, but CanIUse tells me that transform3d is supported by Safari 8. When I inspect the item with the matrix3d transform, I can see it in the DOM tree being updated, but all of the elements from .back or .front, I can't see the transform3d added, and I have no idea how to fix this.
I believe that this is the cause of your lag - offset = self.offset().
On each frame you query the DOM, which forces it to render the layout, and cause the stuttering.
Instead read the offset once before the animations start.
You can also add to each element will-change: transform before the animation start.
Take a look at http://jsfiddle.net/EyrRD/. I use D3.js library to animate SVG rectangle by changing its width:
rect.transition().duration(2000).delay(500).ease("cubic-out").attr("width", 500);
Everything works fine in other browsers, but in Firefox animation suddenly stops when rectangle width reaches 300px. Actually it doesn't matter what is the destination width (>=300), it always stops at 300px. Is that really a bug? If so, how to overcome this? An by the way, is D3.js the best tool for this kind of SVG animations?
You need to set the width of the SVG:
var svg = d3.select("body").append("svg").attr("width", 1000);
In Firefox and maybe other browsers you need to set a width and height for the svg:svg element. It is a Firefox bug, here is my related SO answer.
I'm trying to draw a css resized image in a canvas (I'm using mootools, but it really doesn't matter):
var width = $('canvas').get('width');
var height = $('canvas').get('height');
$('image').set({ 'width': width, 'height': height });
$('canvas').getContext('2d').drawImage($('image'), 0, 0, width, height);
Everything works fine in firefox, but not on webkit.
The image in FF is drawn with the browser interpolation (which is good), but on webkit it's not interpolated.
Here's the fiddle
http://jsfiddle.net/a2co/KyhEE/
Anyone knows how can I solve the problem?
thanks
edit:
i added an image to quickly show what i want to do.
Unfortunately this may be discrepant between browsers for some time, since the spec says that the spec doesn't care:
This specification does not define the algorithm to use when scaling the image, if necessary.
But hold on a minute: The canvas representation of your fiddle in Firefox, Webkit, Chrome and IE9 are all consistent. The only inconsistent piece that I see is how webkit scales the <img>. Here's Firefox 10, IE9 and Chrome 19 (from top to bottom):
WebKit (both chrome and Safari) is the odd one out here, and its not a Canvas thing. The <img> alone in WebKit looks different, all of the canvases look the same!
Chrome (possibly webkit) has been changing their anti-aliasing madly these past few months (very evident if you use the developer channel of chrome because it will often be broken in some way with respect to canvas drawing)
Anyway do you see something different here? Nothing looks out of the ordinary.
Edit: There's a webkit CSS property: image-rendering: -webkit-optimize-contrast which allows the image to look just as bad as the Canvas. This leads me to believe that how the Canvas looks on WebKit is an honest bug. In other words, in WebKit, its as if image-rendering: -webkit-optimize-contrast is always on for canvases, with no way to turn it off.