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

141–150 of 473 posts

Re: Chrome breaks the Web

#141

Post by eknkc »

Sir_Cmpwn wrote: post #41
eknkc wrote: post #13

Earlier quoted context omitted.

Great idea. Why stop there? I say let's make "if" conditions randomly work on false values 1/1000th of the time. That will teach them.

You're being sarcastic, but this is a great idea. Let's do it.

Hahah I was but since you put it this way I thought what would happen and it would be glorious.

But you know whats gonna happen right? Someone will create a “jqif” library that will run same if 10 times (maybe throw in a transpiler) or whatever then we’ll have 10 times slower javascript that fails with 1/10^11 chance.

Js is here to stay unfortunately.

Re: Chrome breaks the Web

#142

Post by yoodenvranx »

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.

> A user that will close your website when scrolling is messed with.

Exactly, I stopped using https://news.google.com because of its strange scrolling behavior on my phone.

Re: Chrome breaks the Web

#143

Post by gkya »

saas_co_de wrote: post #84
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…

> does assumption on how things "should" be (in a highly subjective way) They claim they are making these decisions based on user data which I have no reason to doubt. > and breaks the web. Breaks crap websites that are broken already from performance and usability perspective. I personally think this is exactly what is needed to make the web better as a whole. Individual developers working for individual companies a…

It's not onto Google or someone else to decide good or bad coding practices, and implement this sort of precautions breaking standards.

Re: Chrome breaks the Web

#144

Post by diiiimaaaa »

I've seen similar posts when Apple announced that there won't be Flash on mobile Safari. And I agree with Chrome team decision to force passive on document level listeners.

Also, note that not many people complained about "blocking video/audio autoplay on mobile browsers", because it's good for users.

BUT:

- Passive event listener detection is horrible and it baffles me that they start thinking about proper way only now.

- The announcement of this breaking change was quite silent. Chrome has so many influencers on social media, but almost no one shared/explained this change properly.

Re: Chrome breaks the Web

#145

Post by ravenstine »

emodendroket wrote: post #104
chii wrote: post #26

Earlier quoted context omitted.

> "polyfill" that reverted the change that site owners could use as a stop-gap until they could properly update their apps to work correctly then the site owners would just use the polyfill indefinitely, since it now works again. THe more expensive option of rewriting to conform is not going to give return on investment. This is why breaking a bad thing is needed - the suffering has to happen. It's like getting the f…

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

Re: Chrome breaks the Web

#146

Post by quotemstr »

Without commenting on the "intervention" itself: why change the signature of addEventListener? It would have been trivial to add a new addEventListenerEx API with a redefined final parameter, and this alternative approach would have made feature detection trivial.

Re: Chrome breaks the Web

#147

Post by Daycrawler »

saas_co_de wrote: post #84
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…

> does assumption on how things "should" be (in a highly subjective way) They claim they are making these decisions based on user data which I have no reason to doubt. > and breaks the web. Breaks crap websites that are broken already from performance and usability perspective. I personally think this is exactly what is needed to make the web better as a whole. Individual developers working for individual companies a…

Most of those examples seem "good" because they prevent nasty behavior. This is conformance to the lowest usage, just like the FBI tries to argue against encryption because bad guys are using it too.

Re: Chrome breaks the Web

#148

Post by ivanhoe »

saas_co_de wrote: post #84
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…

> does assumption on how things "should" be (in a highly subjective way) They claim they are making these decisions based on user data which I have no reason to doubt. > and breaks the web. Breaks crap websites that are broken already from performance and usability perspective. I personally think this is exactly what is needed to make the web better as a whole. Individual developers working for individual companies a…

There are valid arguments for both sides, but instead of forcing this upon everyone, Chrome team could have added it as a config option. Set the defaults for autocomplete anyway you like, and then let the user change the behaviour only on some sites. Or if you don't wish to pollute the settings with this, extract this behaviour into an extension and let the people choose if it bothers them enough to go and install it.

Re: Chrome breaks the Web

#149

Post by gkya »

digi_owl wrote: post #115
CydeWeys wrote: post #107

Earlier quoted context omitted.

There are several other first-class browsers that you have a choice of if you don't like Chrome. The same was not true during IE's era of dominance. Also, do you agree, in general terms, that sometimes changes can be good whereas other times changes can be bad?

Most of those are rebranded chromium. The only big ones that are independent are Safari (since Google forked Webkit to create Blink), Firefox, and IE/Edge. And the impression i have is that Safari is lagging, Mozilla is directionless and struggling to keep Firefox relevant, and MS is, well, MS. Ever since Opera folded and made their browser a Chromium clone, only Mozilla have been carrying the banner for standard cor…

Quantum is a great improvement to Firefox. I'm running 57.0b14 ATM (normally I'm quite conservative with anything except Emacs) and quite pleased. The performance improvements are quite noticable. Though I do wish they created a more user-extensible browser, a bit a la Emacs.

Re: Chrome breaks the Web

#150

Post by falcolas »

deno wrote: post #51
falcolas wrote: post #23

Earlier quoted context omitted.

Devs frequently assume "Chrome", because that's what they use. So, passing an unexpected argument to addEventListener will break LTS releases.

This has nothing to do with making event listeners passive by default. If you don’t do feature detection then of course your website will not be backwards compatible. If you care about backward compatibility there exists a polyfill for this functionality.

In saying that "Devs assume Chrome", I'm asserting that they do not do feature detection.

However, that does not absolve Chrome of breaking backwards compatibility, workaround or not. Tossing the responsibility of dealing with their breaking changes back on the developer (with little notice) is what caused this article in the first place.

Post reply on HN