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.
Related
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
I'm building a new app with this great tool and i have a question to solve.
What is the best way to handle imnage size for multiple scren and multiple devices.
Apple = retina and non-retina
Android = ldpi, mdpi, hdpi, xhdpi, xxhdpi and tablets (all this with multiple screen resolution)
BlackBerry10 = one resolution (but not equal to the others)
WindowsPhone8 = one resolution (but not equal to the others)
For this case, what is the best way ?
Use SVG images (Optimizacion, perfomance, size of app) ??
Dedicate CSS tags for device pixel ratio (CSS Image Replacement) (the designer can kill me :smile: lol ) see the list http://bjango.com/articles/min-device-pixel-ratio/
CSS Sprite sheet
Another way
Before the decision, think in what is the best to apply in all devices.
Thanks in advance
There really isn't a single way to do this since each implementation of an image will require a different approach depending on its purpose. SVGs are great but not everything works as an SVG.
Media queries will be your ally.
See this: supporting multiple resolution and density of images in phonegap
and this for an alternate approach: Angular.js data-bind background images using media queries
There are also some nice polyfills for the html5 picture element which you might find useful.
See: https://github.com/scottjehl/picturefill
...and its angularjs directive implementation https://github.com/tinacious/angular-picturefill
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
All in the title.
I want to do whatever will be fastest.... I would think that 5 CSS generated circles would load faster than having to load an external image, whether its a sprite or not... but I'm looking for somebody who's more educated to offer an opinion!
The circles (to scale, presently generated with CSS):
http://puu.sh/3VZHO.png
First to answer your question as to which is faster... The CSS solution is quicker. But why?
The first reason CSS is faster is because of HTTP Requests.
Every time you have, let's call it an object, that object has to be loaded from the server. To do this the browser must send an HTTP request to the server for said file, the server has to check if you have permissions to access said file, if you do, it retrieves it's location, and sends it back to the browser. This happens multiple times and takes hundredths of a second to perform. Seems pretty quick, but the more of these you have to perform the slower your site will become.
CSS is fastest because the CSS for those 5 circles is contained inside one file style.css
The multi-circle image sprite is slower than CSS because now, not only does the server have to send you style sheet for the rest of the site, it also has to send the your image sprite. Think of this as ordering a quantity of 2 of the exact same thing from amazon from the same seller. Amazon will package both items into one big box because its cheaper. Where ever possible you want to piggy back things like this because it's "cheaper" on load times.
As a further explanation, if you were to load the 5 circles all as separate graphics, 5 individual jpgs/pngs/gifs etc. This would take EVEN longer because it would have to perform 6 HTTP Request as opposed to 2, or even 1 (the css solution).
The second reason CSS is faster is because of shear file-size.
Let's assume the CSS for your circles has 8 lines of CSS code for each circle, that's 40 total lines. That represents just bytes of information compared a couple kilo bytes. To put that better into perspective you are talking 100-400 bytes compared to 4,000-8,000 bytes.
The clear winner? CSS
Other Considerations
That said... There are other factors which should weight in on your decision. Not all browsers support border-radius. See this link for details on what does support border-radius: Can I Use
Since IE8 and below does not support border-radius anyone using IE8 or earlier will render your circles as boxes instead. You can help this along by using something like Modernizr to fill in some of those gaps. But now, even if you use a build of Modernizr that helps only border-radius, you've added 7+kb of data and an extra HTTP Request with this file, which sort of defeats your purpose. That is of course unless there are other things you can use Modernizr for other than border-radius, or if you have a lot more utilizing border-radius than just those 5 circles. Suddenly the extra data and HTTP request can be easily justified.
Ultimately your decision should be based on your target audience. What browser are they most likely to be using, if they are mostly using IE9+, Chrome, Firefox etc. Then go for it. If a significant number of your visitors are IE8 and below you should consider providing a fallback. For example using that image sprite for IE8 and below only.
It all depends also in your needs.
I think the border-radius is not rendered correctly in old IE versions, so...maybe the image sprite is the best solution. But I repeat it all depends. Maybe your clients are in a place where internet is slow (css is best) or maybe they won't update their IE and are stuck in IE6 or 7 (sprites).
You could use both, using one stylesheet for IE with sprites and one for css border-radius.
Check the paint times via the chrome dev tools.
Should give you a good idea.
B
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.