Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome breaks the Web

tonsky.me

Post reply on HN
Print view View original

371–380 of 473 posts

Re: Chrome breaks the Web

#371

Post by walterstucco »

comatose wrote: post #340
nashashmi wrote: post #326

Earlier quoted context omitted.

Adblock is opt-in. If the browser misbehaves because of an extension, the browser nor website is to be blamed. Chrome cannot decide on a whim that old websites should be broken. It is not how the web moves forward. Take for example Firefox that kept breaking extensions with every update, now they have few compatible extensions.

it's a little reductio ad absurdum but what about defaulting to popup blocking? blink? marquee? It's not the same thing but maybe worth considering when defending web author's intent being ignored.

> what about defaulting to popup blocking?

that's a misbehaviour of the browser, not the developers

The browsers were designed for viewing a single page at time

popup blocking is fixing a browsers misbehaviour, as much as fixing a car that when you hit the brake accelerates

Re: Chrome breaks the Web

#372

Post by wmeredith »

KeitIG wrote: 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…

I am the Director of UX for a CRM SaaS product. The ignoring of web standards (like autocomplete flags) is misguided and totally obnoxious. Chrome is terrible about stuff like this. It drives me crazy.

Re: Chrome breaks the Web

#373

Post by Manishearth »

pawelk wrote: post #305
Manishearth wrote: post #161

Earlier quoted context omitted.

I'm one of the folks who pushed for autocomplete=off to be disabled for password fields because of abuse. Basically, browsers obeyed autocomplete=off to shut off password managers; and sites used this to shut off password managers for "idk lol security" reasons. This isn't what the autocomplete attribute was for in the first place; password managers have a different workflow and saving a password is prompted to the u…

> "idk lol security" reasons. I hereby confess to being guilty of adding autocomplete="off" to a login form, because the client's corporate IT only cared about ticking all the boxes on a security conformance report. We have tried to fight this and some other rules (e.g. log the user out after 20mins), because this was quite a simple website, but the rules were strict like it was online banking at the very least. Now…

> because the client's corporate IT only cared about ticking all the boxes on a security conformance report.

Yeah, I'm aware it used to be in conformance stuff (and probably still is in many cases). Super annoying when that happens :)

Re: Chrome breaks the Web

#374

Post by 013a »

walterstucco wrote: post #370
013a wrote: post #359

Earlier quoted context omitted.

Choosing to use Chrome is also opt-in. Its the same concept. Its not ideal , but it is what it is.

developers cannot opt-in

They also can't opt-in to adblock or noscript or me choosing to run Netscape version 4. Developers fundamentally do not get a say on what I choose to run on my system; at best the only control they have is saying "nope we aren't even going to try to run on whatever you've got" but even that isn't a guarantee.

Re: Chrome breaks the Web

#375

Post by alexssung »

JoshTriplett wrote: post #335
alexssung wrote: post #272

Earlier quoted context omitted.

The difference between autocomplete=off and the rest of your examples is that there are actually positive UX use cases for disabling autocomplete on certain inputs (e.g. when you are an admin editing existing users)

Ad blockers have false positives as well. And there's a use case for blocking the user from closing the tab (onbeforeunload), such as prompting them to save/submit what they're working on. But for all of those, the browser is still in control and the question is what provides the most benefit for the user . So, along the same lines, it may make sense to improve the UI for autocompleting users, or for hinting about th…

Ad blockers are extensions to browsers.

And I would actually argue that blocking before closing the tab should be a decision up to the developer, not the browser.

Re: Chrome breaks the Web

#376

Post by scott_karana »

lallysingh wrote: post #17

I don't get this feature detection problem. The browser identifies itself in the request. Why not serve the right version at the beginning?

In addition to the UA spoofing others mention, there's also forward conpatibility.

If your app holds a mini "caniuse.com" UA-feature mapping, you have to keep it up to date infinitely forward in time, or new browsers won't work (think Brave/etc)

Better to detect features directly, and reward anyone who implements them, rather than just hardcode the present incumbents.

Re: Chrome breaks the Web

#377

Post by xupybd »

KeitIG wrote: 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…

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

And that is how IE used to operate. I think this is something we're going to have to deal with for a long time.

Re: Chrome breaks the Web

#378

Post by jimktrains2 »

leeoniya wrote: post #155
bluetwo wrote: post #124

Earlier quoted context omitted.

I haven't run into this issue but the autocomplete=off thing annoys the cr@p out of me. If you have a simple web app that has an administrator mode for editing accounts, you should be able to turn off autocomplete so your password doesn't automatically get filled in for users that you edit. It's that simple.

this is such an obvious use case, they basically threw a ton of web-apps/crms under the bus.

While I dislike this behavior of chrome, you should never be able to set a users password.

Re: Chrome breaks the Web

#379

Post by DannyBee »

matt_kantor wrote: post #86

First of all I 100% wholeheartedly agree with the message of this post. However I have a minor quibble: > Chrome broke half of user websites, the ones that were relying on touch/scroll events being cancellable Either I badly misunderstood or the author is asserting that 50% of all websites rely on touch/scroll events being cancellable. That's inflated by at least 100x. Exaggeration is doing no favors here; the rest o…

"Either I badly misunderstood or the author is asserting that 50% of all websites rely on touch/scroll events being cancellable. That's inflated by at least 100x. Exaggeration is doing no favors here; the rest of the article is pretty rational despite it being clear that the author is pissed off, but this one sentence undermines it. " The funniest part of this sentence is that it cites no source. Meanwhile, Google claims very clearly that they analyzed websites and determined pretty much nothing would break.

Given the internet did not break that day, i'm going to go with "They were probably right".

Especially since, unlike this website, they have the crawl data to know.

Re: Chrome breaks the Web

#380

Post by winkeltripel »

Tyr42 wrote: post #358
pas wrote: post #290

Earlier quoted context omitted.

Users don't use thousands of sites. If a site misbehaves and users want autofill on it, they should be able to override autocomplete=off for that site. Google could even make an extension for this to allow users to gather and share a list of sites that behave in a user unfriendly way. But of course, it was much easier to fuck up half of the Web. Public choice and mandates are great for things that require cooperation…

> If a site misbehaves and users want autofill on it, they should be able to override autocomplete=off for that site. How? What do you imagine?

We don't need to imagine. Lots of sites abused autofill in order to prevent password management. That's why autocomplete=off gets stomped.
Post reply on HN