Interesting choice to ignore autocomplete=off. I am not sure how I feel about that.

https://groups.google.com/a/chromium.org/forum/#!msg/chromiu...

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.

Google Search. The search form has autocomplete=off so that it can be replaced with Google Suggest.

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!

Sometimes when dealing with high security you have to input a nonce. Autocomplete would be a nuisance.

Credit card number fields?

My browser can type my credit card information faster than I can.

Honestly, `autocomplete=off` is an unwelcome attempt to try to save me from myself.

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.

They intend for that to be stored. http://www.chromium.org/developers/using-requestautocomplete

The change that they're making to Chrome only affects password fields.

+1 and even more importantly CVV fields.

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.

Oh god, please no. I like using that to force Chrome not to remember form values in single-page web apps. :(

Click and read. It's for password fields only.

> PSA: Ignoring autocomplete='off' by default for password fields

1M times THIS.

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 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.

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...

A lot of the world still uses shared devices, and disabling this setting smacks a bit of arrogance, to 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.

Didn't Safari just remove this feature in 10.9.2?

Safari in 10.9.2 ignores autocomplete=off. The preference was removed since it's no longer of any use.

Ah, that makes more sense.

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:

http://paulstamatiou.com/photos/carmel-monterey/

I believe the element that you're looking for is <picture>, which will be shipping with a future version of Chrome.

http://picture.responsiveimages.org/#examples

Ah right, thanks. I had been thinking that picture and srcset were competing.

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.

[1] http://picture.responsiveimages.org/#examples

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.

Maybe this http://foundation.zurb.com/docs/components/interchange.html when <picture> isn't supported?

I'd also be interested to know if it would use the 2x version if I zoom in the page 200% on a non-HiDPI machine.

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.

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.

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.

Mozilla intends to implement srcset/picture, but it hasn't landed yet. Relevant bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=870021 https://bugzilla.mozilla.org/show_bug.cgi?id=870022

I hope the development tools get some love, since they're completely borked in the last couple of releases.

Yes - what the heck happened there?

Still waiting for proper WebGL support without having to force it.

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.

http://www.theverge.com/2014/2/27/5453572/the-vergecast-113

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.

Have you tested the same video Incognito?