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

151–160 of 473 posts

Re: Chrome breaks the Web

#151

Post by gkya »

Spivak wrote: post #35
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…

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 does autocomplete=off affect password managers?

Re: Chrome breaks the Web

#152

Post by francasso »

Jesus Christ, to think there are people in this thread defending what the assholes in the Chrome team did is unbelievable. You make breaking changes opt-in, that is API design 101. Linus should take over Chrome development.

Re: Chrome breaks the Web

#153

Post by Klathmon »

ksk wrote: post #135
Klathmon wrote: post #121

Earlier quoted context omitted.

I explained this in my first comment, but I'm also basing it on my own testing in february when this came out, as well as from user feedback for years from users of mobile safari which has done this for quite a long time and it has greatly improved the scrolling performance in their browser.

But how does this apply to the majority of users as you suggest? As a user, I'd like the website to keep working. I don't agree with simply breaking working websites via a top-down dictatorial approach.

Because in my personal case a majority of users would take smoother scrolling over a small UI bug that doesn't impact the usability of the application which is fixable in a few hours at most.

Because any websites that need this "blocking events" functionality can opt-in to it quite easily.

Because as I explained in my first comment, the breakages didn't affect that many websites, and the sites it did affect were mostly just small UI bugs that didn't impact usability.

Yes, some sites were impacted and broken, but they were the extreme minority, and even if you accounted for all of the users of all of those sites I'd be willing to bet that it doesn't come anywhere close to being a "majority" of web users. Hell I'd wager that it's not even close to 1% of web users that were negatively impacted by this change in any way.

Re: Chrome breaks the Web

#154

Post by TheAceOfHearts »

Spivak wrote: post #35
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…

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.

I especially hate websites that think it's ever reasonable to disable pasting into inputs! Luckily in most cases you can just right-click -> Inspect Element -> $0.value = 'paste'.

You can also copy text with right-click -> Inspect Element -> copy($0.innerText). Although you'd use $0.value for an input or textarea.

Re: Chrome breaks the Web

#155

Post by leeoniya »

bluetwo wrote: post #124
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 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.

Re: Chrome breaks the Web

#156

Post by adrianmonk »

dotdi wrote: post #32

Dear developer, I hate you[1] when you interfere with scrolling. Yes, some people do it right and so on. You are not one of them. Please. Stop. Yours, A user that will close your website when scrolling is messed with. --- [1] not OP, but the average developer, which, under time pressure and without many resources, cannot test all desktop/phone and browser combinations. Assuming they even care.

Yeah, not a web dev myself, but this seems kind of like a new tag: very rarely makes for a better user experience, but tempting for sites to use.

Unfortunately, browsers have a long history of giving sites the power to do things I probably don't want, like opening new windows, moving windows to the back, opening alerts that are implemented as modal dialogs (which block all tabs, even unrelated ones), and disabling context menus.

I guess they are trying to provide a rich set of capabilities to allow web devs to make neat things, but from my perspective as an end user, they're all about could, not about should.

Re: Chrome breaks the Web

#157

Post by emodendroket »

dhimes wrote: post #116
emodendroket wrote: post #102

Earlier quoted context omitted.

> Every update of chrome erases their password manager entries. That has not been my experience.

I wonder what the difference is? It's been going on for years. https://superuser.com/questions/926902/google-chrome-loses-d...

Have they enabled the Cloud password sync thing?

Re: Chrome breaks the Web

#158

Post by LoSboccacc »

Spivak wrote: post #83
LoSboccacc wrote: post #18

Earlier quoted context omitted.

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…

Fine, I'll call out that it's good. I mean honestly you should have seen the writing on the wall with user-scalable: it inhibited the user from doing something they wanted to do, it hurt accessibility, it made websites imperceptibly inconsistent, and there isn't a good way of asking the user if they would like to disable zoom.

Shut the W3C down, call Mozilla, close the Acid pages, now Spivak calls out what's good for the web.

You know what's good for the web? Standards. Standards that are thoughtful and consistent.

Re: Chrome breaks the Web

#159

Post by emodendroket »

ravenstine wrote: post #145
emodendroket wrote: post #104

Earlier quoted context omitted.

Except that millions of sites will not ever be fixed; they'll just be broken indefinitely.

Possibly, but if they are that useful to users, those sites either need to be maintained or forked. Your argument could have just as easily been used to argue for Adobe Flash support(OK it's still sort of around, but it's nearly irrelevant at this point).

I am not going to go so far as to say breaking backward compatibility is never the right way to go, but "those sites either need to be maintained or forked" is not what is likely to happen; rather instead they'll just say "you have to use such-and-such a browser at such-and-such a version" and lock it in that way for a long time. Consider how big a business it was (is?) to have VMs specifically to keep running Web apps in IE6.

Re: Chrome breaks the Web

#160

Post by mediumdeviation »

mathias wrote: post #134

> Which means you can’t practically use the new form without feature detection. That does not follow. `{ capture: true }` works in both, since it’s an object, and thus truthy. There’s no need for feature detection in the case you describe. Sadly, that’s the whole premise of this article. It’s only a problem if you want `capture: false` combined with other options — since you’d need to pass in an object, that would be…

In older browsers, useCapture is NOT an optional parameter, and in most cases you do NOT want to use event capture instead of event bubbling. There's no trivial way to support addEventListener(event, handler, { passive: true }) on both new and old browsers without that really ugly feature detection code in the article.
Post reply on HN