On: Chrome 56 will mark HTTP pages with password field...

[throwaway6845]

Countdown until a JS extension that takes a normal <input> field and uses &bull; characters to make it look like a password field without tripping Chrome's detector...

[dawnerd → throwaway6845]

Can we just ban inputs being manipulated on input? It's really annoying for custom implemented types like phone numbers that do the '(___) ___-____'. Half the time it seems they break if you mess up.

[tomschlick → dawnerd]

I'd be in favor of banning input manipulation but adding custom fields like phone which would accept regex formatters.

[lucideer → tomschlick]

Browsers already support that. Good look convincing managers/clients/designers that they're sufficient on their own though.

The real problem is UI. Most of these plugins are changing the UI of forms to something that looks fancier (and more consistent) than the defaults.

[dawnerd → lucideer]

There really does need to be a better way to style inputs. It's all over the place now. Hell, just making `type=search` look the same across browsers isn't as straight forward as it should be.

[wongarsu → lucideer]

Yeah, but if you want something slighlty different that isn't solved by one of the existing input field types you would be completely out of luck. And even if what you need is in the HTML spec you might be out of luck. Firefox is only adding support for date inputs sometime this year (my estimate) [1].

1: https://wiki.mozilla.org/TPE_DOM/Date_time_input_types#Roadm...

[MarkMc → throwaway6845]

Then another countdown until normal input fields over HTTP are marked as insecure by Chrome.