Live data from Hacker News

Chrome breaks the Web

tonsky.me

61–70 of 473 posts

Re: Chrome breaks the Web

#61
post #35
post #9

> they made all top-level event listeners passive by default. They call it “an intervention”. This is my very problem with Chrome/Chromium right now. The Chrome team does assumption on how things "should" be (in a highly subjective way) and breaks the web. Another example: they decided to ignore the value of `autocomplete` attributes on ` ` tags [1], because: > The tricky part here is that somewhere along the journey…

The problem is that some sites decided to use autocomplete=off to impose their feeling about password managers on users and make them more difficult to use. It's the same reason I have to turn off clipboard events because some sites think it's okay to block copy/paste.

Password managers use browsers plugins, and as such can modify pages before they render as much as they like.

Re: Chrome breaks the Web

#62
post #50
post #35

Earlier quoted context omitted.

The problem is that some sites decided to use autocomplete=off to impose their feeling about password managers on users and make them more difficult to use. It's the same reason I have to turn off clipboard events because some sites think it's okay to block copy/paste.

How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions (e.g. 6-8 characters, must include digits, upper- and lowercase letters, and special characters but no quotation marks or any known SQL keywords)? The right thing to do is to bring the issue up with whoever is running the website. If they decide not to act on it because they think they know security/UX b…

The market should sort it out is deeply naive wishful thinking. Numerous sites block copy/paste, block password managers from functioning well, still have password rules from the Pleistocene let alone the most recent NIST recommendations. And those companies are worth more today than 10 years ago. So no, it really doesn't get sorted out. To the market, this is a detail it simply doesn't care about.

Re: Chrome breaks the Web

#63
post #50
post #35

Earlier quoted context omitted.

The problem is that some sites decided to use autocomplete=off to impose their feeling about password managers on users and make them more difficult to use. It's the same reason I have to turn off clipboard events because some sites think it's okay to block copy/paste.

How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions (e.g. 6-8 characters, must include digits, upper- and lowercase letters, and special characters but no quotation marks or any known SQL keywords)? The right thing to do is to bring the issue up with whoever is running the website. If they decide not to act on it because they think they know security/UX b…

"How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions (e.g. 6-8 characters, must include digits, upper- and lowercase letters, and special characters but no quotation marks or any known SQL keywords)?"

If the Chrome team could figure out a way to force all of those sites to change their password restrictions through a Chrome update, they probably would.

Re: Chrome breaks the Web

#64

I side with Google on this one. IMO we should be breaking JavaScript more often, especially in the name of performance, to make people use less JS and simpler JS on their websites.

You know who is a big user of JS? Who is using more, and more complex JS on their websites?

Google.

Google is also the pusher of some of the WebAPIs that will give browsers more access to your system (e.g. WebUSB [1])

Do you think Google is breaking JS to make themselves using less JS?

[1]: https://wicg.github.io/webusb/

Re: Chrome breaks the Web

#65
post #61
post #35

Earlier quoted context omitted.

The problem is that some sites decided to use autocomplete=off to impose their feeling about password managers on users and make them more difficult to use. It's the same reason I have to turn off clipboard events because some sites think it's okay to block copy/paste.

Password managers use browsers plugins, and as such can modify pages before they render as much as they like.

Only if you use the plugin and the password manager identifies fields correctly.

Re: Chrome breaks the Web

#66
post #10

> Turned out, Google wasn’t concerned about your websites at all. It was more concerned about its own product performance, Google Chrome Mobile. As a web developer, I see this attitude a lot and it annoys me immensely. Another way of phrasing it: Google is putting users first, ahead of developers. This is as it should be. "your" website exists to serve users, if you're doing a bad job at it then maybe it's an opportu…

that's a load of bollocks. if google wants a better web, he needs to work toward better standards. implementing a vendor specific api by fiat with broken detection is what fucked the web in the first place! same with apple - "now we'll ignore user-scalable=no and screw every responsive webapp out there" instead of user punishing badly behaved application, vendor are indiscriminately breaking well behaved apps whether…

> same with apple - "now we'll ignore user-scalable=no and screw every responsive webapp out there"

Maybe because 90% of responsive webapps would be better implemented as standard html websites which would improve performance and help preserving battery.

Re: Chrome breaks the Web

#67
post #35
post #9

> they made all top-level event listeners passive by default. They call it “an intervention”. This is my very problem with Chrome/Chromium right now. The Chrome team does assumption on how things "should" be (in a highly subjective way) and breaks the web. Another example: they decided to ignore the value of `autocomplete` attributes on ` ` tags [1], because: > The tricky part here is that somewhere along the journey…

The problem is that some sites decided to use autocomplete=off to impose their feeling about password managers on users and make them more difficult to use. It's the same reason I have to turn off clipboard events because some sites think it's okay to block copy/paste.

So the question becomes what's less bad: for website developers to break their own site, or for Chrome to break other people's site.

I'm all for empowering browsers to override abusive behaviour from websites, but using bad defaults and breaking innocent websites as a result is not the solution.

Re: Chrome breaks the Web

#68
post #27

Earlier quoted context omitted.

No, Google were concerned about your websites. Your mobile websites which are so heavily overloaded with JS that basic interactions like scrolling don’t work. Complaining that Google “broke the web”, when mobile developers have been making it slowly unusable—and unused—for years is pretty hypocritical. All the feature detection and backwards compatible changes in the world won’t help developers when their entire user…

Excellent point. Hopefully someday a "lean webpages" movement appears.

It's here and it's basically the brutalism of the web, see Craigslist or the Drudge Report, or just look at Hacker News. These are not "web 2.0" designed but they are easy to use and well organized.

Re: Chrome breaks the Web

#69
post #10

> Turned out, Google wasn’t concerned about your websites at all. It was more concerned about its own product performance, Google Chrome Mobile. As a web developer, I see this attitude a lot and it annoys me immensely. Another way of phrasing it: Google is putting users first, ahead of developers. This is as it should be. "your" website exists to serve users, if you're doing a bad job at it then maybe it's an opportu…

I can appreciate this outlook, but I still worry about "just wasn't available when the code was written". Code rot is very real for websites, and I worry that in the quest to do things 'right' Chrome is undervaluing the incremental harm done by every change. I don't think this action broke the web, but I'm wary of the idea that breaking changes can be casually blamed on the people who didn't update fast enough. Chang…

> there ought to be an open discussion about timeframes and impact before a change happens

There was. In fact, there's a whole GitHub project dedicated to discussing proposed interventions like these: https://github.com/WICG/interventions

All interventions also get posted on the blink-dev mailing list before they are implemented: https://groups.google.com/a/chromium.org/forum/#!forum/blink...

Re: Chrome breaks the Web

#70
post #58
post #50

Earlier quoted context omitted.

How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions (e.g. 6-8 characters, must include digits, upper- and lowercase letters, and special characters but no quotation marks or any known SQL keywords)? The right thing to do is to bring the issue up with whoever is running the website. If they decide not to act on it because they think they know security/UX b…

> How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions The difference is that disabling of "autocomplete" is a user interface issue, and can be addressed by the browser I use. The problem of ridiculous password restrictions is not usually something that can be controlled by the client. I like the idea of convincing IT to change crazy password policies, but…

I'm all for allowing the user to control whether autocomplete is or isn't respected. But the browser breaking web standards to force certain choices on the user is about the worst possible way to go about this.
Post reply on HN