Live data from Hacker News

Chrome breaks the Web

tonsky.me

221–230 of 473 posts

Re: Chrome breaks the Web

#221
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…

Regulatory compliance. I've worked on applications that had to go to great lengths to get the target browser platform to not do something like auto-complete authentication credentials. Philosophically-speaking some Web Platform developers think that it's more secure for the browser to autofill credentials from a keychain so that users can use better passwords and not be burdened with remember N-pseudo-random characte…

> Regulatory compliance. I've worked on applications that had to go to great lengths to get the target browser platform to not do something like auto-complete authentication credentials.

If I had a penny for every time I've heard this excuse for really terrible unsafe practices just to find out that the developer deliberately misinterprets it to make its job easier... it be rather rich now.

Re: Chrome breaks the Web

#222
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…

The web is the only platform aside from perhaps some assembly languages that is that stable and that ubiquitous. Websites have always been a "write and forget" deal; there never was supposed to be any feedback loop of developers fixing breaking changes. This is why old websites from 1998 still work in your browser. This is why there are piles and piles of cruft within browsers and web standards for making sure old be…

> This is why old websites from 1998 still work in your browser.

Unless their navigation interface used a Java applet.

Re: Chrome breaks the Web

#223
post #195

Earlier quoted context omitted.

The web is the only platform aside from perhaps some assembly languages that is that stable and that ubiquitous. Websites have always been a "write and forget" deal; there never was supposed to be any feedback loop of developers fixing breaking changes. This is why old websites from 1998 still work in your browser. This is why there are piles and piles of cruft within browsers and web standards for making sure old be…

> This is why old websites from 1998 still work in your browser. They won't if they use a tag, for example. The problem is that if we freeze the entire web and demand 100% backwards compatibility, we also can't ever move forwards. This scroll event change is a positive in 99% of cases - should a web site built in 1998 really hold that back? There's no absolute in "putting users first" there - you're either putting th…

> we also can't ever move forwards.

There is a thing called Forward Compatibility. Not everything old has to die to move forward.

On our OpenGL 4.x videocards still run OpenGL 1.x. And no, fixed function pipeline of 1.x isn't anything like the modern shader pipeline. (Sidenote: many cards that were designed in the 3.x era and nVidia backported 4.x support into their older cards which is amazing to me.)

>Maybe it wouldn't be the worst thing in the world to introduce an "archival" mode in a browser.

Internet Explorer already did that.

Re: Chrome breaks the Web

#224
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…

> Individual developers working for individual companies are rarely if ever thinking about the good of their users, except in a very narrow profit motivated sense

But the megacorp Google is acting all altruistic and not at all abusing it monopoly powers?

Give me a break.

Re: Chrome breaks the Web

#225
post #78

> As a user, I certainly do not care about “being part of moving the web forward aggressively”. Why should I? I like my stuff working, not broken. Actually, I do want to be part of websites being faster, and I don't care about the functionality that is being broken. Performance isn't a secondary concern - if it's bad, the site is unusable from my point of view. Your shitty scrolljacking site breaks the web, Chrome is…

But his shitty scrolljacking doesn't break the web, at most his own website. Google probably broke a lot of website _except_ its own.

This is a change to how Chrome deals with sites that use onScroll. In their current state, most of these are broken as far as I'm concerned. Chrome's changes will partially fix a lot of these sites, at the cost of breaking some that aren't currently broken. That is a win for the user.

My only problem with this change is that developers can still override the default and cancel scroll events. The handful of legitimate use cases this enables aren't worth the cost of letting shitty designers abuse it.

Re: Chrome breaks the Web

#226
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…

[deleted]

Re: Chrome breaks the Web

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

Not all users have a choice to leave a website.

If a Chrome update breaks the governmental website that relied on some "never used" feature and the user can no longer, say, apply to unemployment insurance, real people would be getting affected in very real ways.

We wanted technology to part of peoples lives, now it is, we have to own up to the responsibility.

Re: Chrome breaks the Web

#228
post #213

Earlier quoted context omitted.

There is a rule against breaking APIs, there is no rule against making a website that is better than another one. So by your logic it's ok for you to kill and rob a rich person and redistribute all the money because, hey, at the end of the day it's a better user experience for everyone else and if you don't do it someone else might. EDIT: By the way, browsers are in the business of providing a platform. Platforms sho…

> There is a rule against breaking APIs What rule? Is it that the 11th commandment? How about my rule: Users are more important than API backwards compatibility (because, in the end, we are serving users, not developers.). It's simple really: killing a person to enhance user experience is morally wrong. Forcing, in very rare cases (by my own experience), some developers to make a 1 line change so that in effect almos…

If they plan on making breaking APIs changes whenever they feel like their data suggest it's ok, they should clearly say so. But like openly, on the front of the chrome web page: "We care about you, the user, and will break the platform for the developers whenever we think it's necessary to improve your experience".

> It's simple really: killing a person to enhance user experience is morally wrong

Well for me it's morally wrong to break APIs, if you don't agree I hope to never touch anything you ever make.

This is not about caring about the users, it's about doing it without pissing on the developers heads.

By the way, I was not even affected by this, but I know that if we let this slide it will just get worse and worse. As if the web was a nice platform to develop on to start with...

Re: Chrome breaks the Web

#229
post #195

Earlier quoted context omitted.

> This is why old websites from 1998 still work in your browser. They won't if they use a tag, for example. The problem is that if we freeze the entire web and demand 100% backwards compatibility, we also can't ever move forwards. This scroll event change is a positive in 99% of cases - should a web site built in 1998 really hold that back? There's no absolute in "putting users first" there - you're either putting th…

> we also can't ever move forwards. There is a thing called Forward Compatibility. Not everything old has to die to move forward. On our OpenGL 4.x videocards still run OpenGL 1.x. And no, fixed function pipeline of 1.x isn't anything like the modern shader pipeline. (Sidenote: many cards that were designed in the 3.x era and nVidia backported 4.x support into their older cards which is amazing to me.) >Maybe it woul…

> Not everything old has to die to move forward.

But we're talking about a very specific example, where the best option for the vast majority of users was to change default behaviour. There is no "passive event listener still implements active event listener API" equivalent here. You have to make a choice.

Re: Chrome breaks the Web

#230

Earlier quoted context omitted.

Aren't cookies a web standard? I can assure you that Safari's policies w.r.t. cookies "break" a lot of website functionality, and quite intentionally so. You may not like that functionality, but the website marketers like it and have spent lots of time implementing it. So - what's ok to break, and what isn't? In the end, it's a judgement call on the browser developer. I like what another person said here - the browse…

> So - what's ok to break, and what isn't? I'd say, for a start, achieving consensus before breaking is ideal. If the attempt to achieve consensus fails, at least I can see they tried (or I can disagree). Hopefully in the future users can use their leverage to make it not a judgement call on the browser developer, but a judgement call by the community of users. The myriad of features in browsers, however, makes it a…

They do have a consensus about these things among their users. Virtually no one wants their password manager to not work or for third-party marketers to be able to track them more easily.

The people who disagree are third-parties who want to impose their own preferences on Chrome's users. Their opinions should not be taken into account because they are not Chrome's users.

Post reply on HN