If the file specified on an SVG <image> element is not found then the results are unpredictable. In Firefox, I get no indication and no error. In Chrome, I get some default box-shaped scenery image.
Is there a way to provide an alternative image, such as a nice error marker? I have seen solutions for a similar issue in HTML that involve the attribute:
onerror="this.onerror=null; this.src='Default.jpg'"
But this does not work in my SVG (even after changing src to href). I have also seen a cheat where using an additional src attribute provides a fallback for normal the href (see SVG Fallbacks) but it seemed to rely on a quirk of the implementation within the browser and no longer works (at least not in Firefox).
I'm looking for a method that works at least in Firefox, Chrome, and Edge.
You want
this.href.baseVal='Default.jpg'
Due to SVG's support for SMIL
Related
My problem is that the svg based map does not seem in Firefox.
Chrome, Edge, Opera is OK, only Firefox doesn't.
The site is: http://2018.tvep.hu/tagletszam-alakulasa.html
I appreciate any help! Thanks: Laszlo Varga
The filter inner-shadow is invalid because the first feComposite references an undefined offset-blur as its in2. Firefox is, as usual and rightfully, more strict and doesn't just ignore the problematic input. Removing the in2="offset-blur" makes it work because it will then automatically use the result of the previous filter (from the SVG 1.1 spec):
If no value is provided and this is a subsequent filter primitive, then this filter primitive will use the result from the previous filter primitive as its input.
Adding result="offset-blur" to the feOffset above it would achive the same.
The attributte "srcset" which was working with polyfill, until chrome 33 is not working anymore in the version 34. As you can see in this link http://jimbobsquarepants.github.io/srcset-polyfill/ if you access using chrome 34 the imagem that shows is the mobile one, because chrome is not reading the srcset, but if you open in a different browse it'll show the desktop image. Any ideas why this is happening?
This happens since the polyfill has feature detection for the srcset attribute:
var srcsetSupported = "srcset" in document.createElement("img");
In Chrom(e|ium) 34 this test yields "true", but in reality the srcset attribute seems to not be supported. So neither a native implementation nor the polyfill handles the attribute.
Edit:
The problem is that Chrome 34 supports the srcset attribute, but only partially: The src is only chosen depending on the device-pixel-ratio (the x setting), but ignores the viewport (w and h settings).
Edit 2:
More research and asking around led me to this:
There are two specifications of the srcset attribute.
The first one includes the possibility to define the maximal viewport width and height for which to use for an image.
The second one (can't find a good link) only allows to define a maximal device-pixel-ratio for which to use an image. To switch images depending on the viewport width, a <picture>-tag will be used, with <source>-elements allowing full media queries to specify when to use which.
Chromium implements the second version of the srcset attribute, but not yet the picture tag.
Here are some discussions about this (Thanks to Mat Marquis to point me to those):
Mozilla
Blink (Chrome)
Workarounds
Use a polyfill that supports the <picture>-tag together with the limited srcset (I don't know one). This will probably be more future-proof (but will probably need adaptions from time to time, the standard has not stabilized yet).
Switch off feature detection in the current polyfill and always use it. This will probably break sometime in the future.
Firefox under version 28 has an issue where a path with a stroke-dashoffset property will render differently depending on the stroke-width amount. There is a known fix which is to divide stroke-dashoffset with stroke-width, but applying this across the board will mean other browsers will now display incorrectly.
https://bugzilla.mozilla.org/show_bug.cgi?id=661812
The quickest solution I can think of is is simply check for browser type and version number, but generally this seems to be regarded as a bad idea. Does anyone know a way to test the result without going down this route?
I have put together a Codepen which allows you to change the width of an animated offset, and a toggle for the fix so you can see for yourselves in different browsers. http://codepen.io/MattyBalaam/full/lGJkc
Very large images will not render in Google Chrome (although the scrollbars will still behave as if the image is present). The same images will often render just fine in other browsers.
Here are two sample images. If you're using Google Chrome, you won't see the long red bar:
Short Blue
http://i.stack.imgur.com/ApGfg.png
Long Red
http://i.stack.imgur.com/J2eRf.png
As you can see, the browser thinks the longer image is there, but it simply doesn't render. The image format doesn't seem to matter either: I've tried both PNGs and JPEGs. I've also tested this on two different machines running different operating systems (Windows and OSX). This is obviously a bug, but can anyone think of a workaround that would force Chrome to render large images?
Not that anyone cares or is even looking at this post, but I did find an odd workaround. The problem seems to be with the way Chrome handles zooming. If you set the zoom property to 98.6% and lower or 102.6% and higher, the image will render (setting the zoom property to any value between 98.6% and 102.6% will cause the rendering to fail). Note that the zoom property is not officially defined in CSS, so some browsers may ignore it (which is a good thing in this case since this is a browser-specific hack). As long as you don't mind the image being resized slightly, I suppose this may be the best fix.
In short, the following code produces the desired result, as shown here:
<img style="zoom:98.6%" src="http://i.stack.imgur.com/J2eRf.png">
Update:
Actually, this is a good opportunity to kill two birds with one stone. As screens move to higher resolutions (e.g. the Apple Retina display), web developers will want to start serving up images that are twice as large and then scaling them down by 50%, as suggested here. So, instead of using the zoom property as suggested above, you could simply double the size of the image and render it at half the size:
<img style="width:50%;height:50%;" src="http://i.stack.imgur.com/J2eRf.png">
Not only will this solve your rendering problem in Chrome, but it will make the image look nice and crisp on the next generation of high-resolution displays.
I am using three.js to do some online interactive modelling of geology, and have been creating image URI using the Canvas Element (output would be: data:image/png;base64,).
The image creation works fine in Chrome,Firefox, and Safari, but using the images in three.js as a texture doesn't show up in Firefox.
The simplest demonstration I can show is by changing one line of a three.js example, to substitue an image URL for a dataURI, and use that as a texture.
http://visiblegeology.com/renderingProblem/
This works fine for me in Chrome and Safari, but just doesn't show up in Firefox.
I was wondering if anyone had any advice, work-arounds, or thoughts.
Thanks for any help,
Rowan
I've checked using a regular img tag. It works that way in Firefox. So the problem would seem to be the combination of three.js and the data uri.
This example by mrdoob doesn't work in Firefox either: http://mrdoob.github.com/three.js/examples/webgl_particles_shapes.html
A few suggestions:
check if you are using the latest three code.
try removing the final equals sign of the data uri. It is used for padding and may not be necessary.
try disabling your add ons one by one, as they may interfere as well