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

21–30 of 473 posts

Re: Chrome breaks the Web

#21

Post by LoSboccacc »

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…

that change in particular broke most of two factor authenticated bank pages X:

Re: Chrome breaks the Web

#22

Post by falcolas »

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?

Because browsers can and do lie? Often to get around such "serving the right version" logic.

Or the "Browse the web faster and more securely, try (Chrome|Edge)" crap?

Re: Chrome breaks the Web

#23

Post by falcolas »

deno wrote: post #7
pvdebbe wrote: post #5

Earlier quoted context omitted.

Except that Firefox LTS and other minority browsers suffer. I already use a couple sites that disregard all old Firefox compatibilities and use JS that break things up

How does this affect Firefox LTS? It doesn’t.

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

Re: Chrome breaks the Web

#24

Post by acobster »

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?

Are you referring to user agents? Serving different code based on user agent is considered bad practice, and would be a maintenance nightmare. Not to mention, serving different JavaScript would make it more difficult to reason about what is running client-side. Plus, user agents are neither canonical nor necessarily even reliable sources of information about the browser.

Re: Chrome breaks the Web

#25

Post by breakingcups »

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?

Because it's bad behaviour to rely on browser user agents instead of feature detection. It's what led to IE-only sites and is currently leading to Chrome-only sites.

Re: Chrome breaks the Web

#26

Post by chii »

Klathmon wrote: post #16

To be honest as a user, I'm glad they made this change, even though as a developer it might be a pain in the ass for a day or 2. Scrolling on the mobile web sucked for a long time. Yes, updating the default broke many things, but the scope of that breakage was fairly limited in the grand scheme of things (like the author said, sliders, maps, touch-and-draggable things like lists are the biggest impacted, stuff like "…

> "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 flu - to get better one must get sick first if you've been infected.

Re: Chrome breaks the Web

#27

Post by nsebban »

stupidcar wrote: post #14
ipedrazas wrote: post #2

> Google wasn’t concerned about your websites at all. It was more concerned about its own product performance Why I'm not surprised?

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.

Re: Chrome breaks the Web

#28

Post by reificator »

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?

1. Because every browser pretends to be each other and so the UA is worthless: https://webaim.org/blog/user-agent-string-history/

2. Because you're not going to update your detection every time a new version comes out, meaning that new browsers that support the features you need are still going to get served the wrong version of your site.

3. Because there are more browsers than you can count.

4. Because for non-syntax related features, feature detection on the client is usually pretty simple.

5. Because the UA is trivial to spoof.

Re: Chrome breaks the Web

#29

Post by nevir »

bad_user wrote: post #19
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…

They can afford to do this due to their market share. This is precisely why I refuse to use Chrome. I use Firefox and would do so even if it were an inferior browser, plus at this point in time and for my usage patterns Firefox really is superior.

Firefox (and IE) did the same thing for autocomplete=off, with the same rationale.

https://bugzilla.mozilla.org/show_bug.cgi?id=956906

Re: Chrome breaks the Web

#30

Post by masklinn »

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

> Another way of phrasing it: Google is putting users first, ahead of developers.

For the most part, Google is putting its developers ahead of your developers. They could have e.g. jitted scroll handlers to bail out of passive, but did not, and instead broke all active scroll listeners.

> The vast majority of times scroll listening is used, a passive listener is the correct implementation and just wasn't available when the code was written.

And once again minorities get to visit the mass grave through no fault of their own.

Post reply on HN