Does this only work for device resolution needs - ie, load an @2x version in the same image width/height for 2x hi dpi displays? Versus progressively download larger images the more the user widens the display. I actually care a bit less about loading huge images for 4k or other 'retina' displays than I do just showing a 1000px image instead of a 500px (note, not a 1000px image in a 500px container for high dpi needs) image when the user expands the window, etc.
currently very hackily checking browser width (and keeping in mind of image is used in a grid or just a full-width image on its own) to rewrite all data-src when the page loads and before lazy loading has kicked in (to prevent double image downloading) on my photoblog:
They're complementary. <picture> uses subset of original srcset spec to meet the "resolution switching" use case - e.g. see Example 1 [1]. If you want to select an asset based on viewport width, then you'd either use "sizes" attribute on picture, or a combination of srcset + sources + sizes.
This behavior is not defined by the spec / left to the UA. At the moment, I don't believe either WebKit or Blink implementation will swap the image on (desktop) zoom.
The srcset attribute by itself can't do what you ask; it only lets you specify multiple resolutions of an image, all (intended to be) the same size.
But wait for implementation to finish, and you'll be able to use the sizes='' attribute on the <img>, or the full <picture> deal, and that'll give you more control, letting you load a smaller image if the image would take up less space.
Since I upgraded to Chrome 33, some Flash videos don't work anymore. The screen is just black there, and there's no sound either. Are they aware of this bug? It could be Adobe's fault, but Flash is updated in Chrome only through Chrome, so then it's their fault, too.
For example, the live video here isn't working right now in Chrome, and when I right click, it says "movie not loaded". It works in Firefox.
Recently I can't get any browser to reliably render flash content without the browser crashing or blacking out. It's a coin flip whether a video is going to show or not. The irony is that IE 11 has been the most consistent of all things.
I love it! So many companies have made it a massive pain to use password managers, and thus unique, random and strong passwords for individual sites, all in the name of "security," using that property.
I wish all browsers/password managers would ignore it.
I do get their logic. And it is just for password fields, which is good - I've used autocomplete=off before when making a custom autocomplete solution on the page.
This seems like it could be inconvenient for web applications that use <input type=password> in a non-login context. Imagine that you've got a web interface that can be used to configure usernames and passwords for something completely separate (say, for email accounts). Trying to autofill that form with credentials from the management interface, or saving usernames/passwords entered into that form, would be unexpected and undesirable.
i have a web app that has multiple password fields on the same page / domain. especially on config/admin pages. this is gonna break many things for me.
I use Safari solely because of this reason. It would cost me too much time to remember/retype all of my passwords, especially if it is a intranet type application that demands a password seemingly time I get a link and won't stay logged in for a reasonable time.
I've yet to find a time when autocomplete has been disabled that I've not wanted to slap the web designer. Most every one has been on some sort of common address form. My browser knows my address. I don't want to type it. You'll get better results from my browser than from me typing, always.
I always thought of `autocomplete=off` to guard shared computers. I've turned it off for CC fields but the intention is that if you're on a shared computer the security outweighs the browser remembering something such as a credit card number.
I don't believe people type values into a form realizing at the moment that the browser is saving it for future uses.
It's still useful to control unwanted autocomplete behavior. With Chrome, for example, if you have a form with fields name "name" and "state", even if they have zero to do with a personal name or state of residency, users still get their normal autocomplete in "name". When you select a name, if that autocomplete entry has address information attached, Chrome helpfully fills in "state" with "CA". Even if "CA" makes zero sense for that field.
Almost all other times, though, I'm with you: slap them!
Yeah, so for example, Google (or anyone with a warrant) can recover saved passwords if the user signed in to Chrome (strongly encouraged) but did not set up a sync password (buried in settings).
It's awful if websites disable password saving. But I think that it's not good that Chrom is ignoring this attribute: Now some webpages will start tactics like renaming their fields every time.
I always disabled autocomplete=off via bookmarklets, now for the annoying pages that create workarounds yet more tools are needed to save passwords...
Does anybody know if this responsive image thing also works in Firefox and are there any polyfills for IE? Would look strange if images only look crisp and detailed in Chrome.
This is great news, but what I'd really love to see is the Chrome team focus on their memory footprint. Chrome < 20 used to run great on my 2GB ultrabook, now Firefox is my only option. Chromium on my Raspberry Pi can barely handle 1 open tab, while Firefox can handle several before the system starts to thrash.
If Google was smart, they create a group like Firefox's memshrink to get this situation under control.
44 comments
[ 2.9 ms ] story [ 107 ms ] threadcurrently very hackily checking browser width (and keeping in mind of image is used in a grid or just a full-width image on its own) to rewrite all data-src when the page loads and before lazy loading has kicked in (to prevent double image downloading) on my photoblog:
http://paulstamatiou.com/photos/carmel-monterey/
http://picture.responsiveimages.org/#examples
[1] http://picture.responsiveimages.org/#examples
But wait for implementation to finish, and you'll be able to use the sizes='' attribute on the <img>, or the full <picture> deal, and that'll give you more control, letting you load a smaller image if the image would take up less space.
For example, the live video here isn't working right now in Chrome, and when I right click, it says "movie not loaded". It works in Firefox.
http://www.theverge.com/2014/2/27/5453572/the-vergecast-113
https://groups.google.com/a/chromium.org/forum/#!msg/chromiu...
I wish all browsers/password managers would ignore it.
Honestly, `autocomplete=off` is an unwelcome attempt to try to save me from myself.
I don't believe people type values into a form realizing at the moment that the browser is saving it for future uses.
Almost all other times, though, I'm with you: slap them!
> PSA: Ignoring autocomplete='off' by default for password fields
https://bugzilla.mozilla.org/show_bug.cgi?id=870021 https://bugzilla.mozilla.org/show_bug.cgi?id=870022
If Google was smart, they create a group like Firefox's memshrink to get this situation under control.