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

211–220 of 473 posts

Re: Chrome breaks the Web

#211

Post by jarym »

ko27 wrote: post #179
jarym wrote: post #73

It really feels like the Chrome developers have forgotten that they're providing a platform and not an in-house Google service. It happens very often - developers with experience building apps don't always manage to build tools for other developers very well. They focus too much on the end-user and disregard their platform developers too much. The balance needs to be somewhere but I doubt they have it in the right pl…

> The balance needs to be somewhere It might be a controversial opinion, but I think that the balance should always lean closer to the user's side, not developer's.

I agree with you on 'lean'. But say I'm building a web-app that accesses medical records and I don't want sensitive fields being auto-completed by a browser.

Forcing autocomplete in this instance does a dis-service to both users and developers.

Re: Chrome breaks the Web

#212

Post by styfle »

Did anyone's website or web app break because of this change in Chrome 56?

I ask because the article lists a couple things that could break such as drag 'n drop but I have not noticed anything breaking in my experience.

Re: Chrome breaks the Web

#213

Post by ko27 »

francasso wrote: post #204
ko27 wrote: post #186

Earlier quoted context omitted.

> If a website doesn't opt in their users will migrate to another one that offers the same content with a better user experience Can't you see how this logic also applies in Chrome's case: everybody would switch to another browser that does passive listeners by default because it's a better user experience. What's bothering me is that people like you think they are entitled to not maintain your active web apps on bro…

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 almost all pages will have jitter-free scrolling is a worthy exchange.

> By the way, browsers are in the business of providing a platform

YES!!! That's the main point of it. They serve (and thus get payed by) users first, developers second.

> Platforms should be stable. If they plan on not doing that they should say so. Guess how many developers will stop supporting chrome the day after that.

They did more than say, the just did it. So let me guess have many web developers will stop developing for Chrome now? uhmmm ..., zero?

Re: Chrome breaks the Web

#214

Post by daanlo »

ghostly_s wrote: post #208
edoceo wrote: post #139

Earlier quoted context omitted.

Dude, autocomplete=off should just work. Chrome does the WRONG THING. Spec says what to do, living spec says what to do - Chrome does whatever they want. It's BS. It breaks the web. Then chrome Devs say to use autocomplete=something-stupid to get the specification behaviour of 'off' WTF is that?! Donate to Firefox. Chrome is the new IE

> Dude, autocomplete=off should just work. Chrome does the WRONG THING. Screw you. I've probably encountered 'autocomplete=off' thousands of times in my browsing history, and maybe 1% of the time was it being used for something that wasn't user-hostile. I don't care what the spec says, I care about what's good for users. If the spec writers aren't willing to embrace that, vendors will ignore it.

A website is owned by someone. If they decide that in their shop they want to have a carpet floor it is up to users not to visit that shop (if they don't like that), but not up to adidas to turn the floor into tarmac, because that works better for their shoes...

Re: Chrome breaks the Web

#215

Post by chimeracoder »

nevir wrote: post #29
bad_user wrote: post #19

Earlier quoted context omitted.

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

To be clear, it appears that Chrome disables autocomplete=off for all fields and forms, not just for password fields. The linked ticket is about password fields in Firefox specifically.

Re: Chrome breaks the Web

#216

Post by [deleted] »

francasso wrote: post #204
ko27 wrote: post #186

Earlier quoted context omitted.

> If a website doesn't opt in their users will migrate to another one that offers the same content with a better user experience Can't you see how this logic also applies in Chrome's case: everybody would switch to another browser that does passive listeners by default because it's a better user experience. What's bothering me is that people like you think they are entitled to not maintain your active web apps on bro…

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…

[deleted]

Re: Chrome breaks the Web

#217

Post by explodingcamera »

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…

There's a lot of confusion about autofill. Specifically for these user management interfaces etc. autocomplete="new-password" was introduced and as far as I know is supported in widely used browsers.

Re: Chrome breaks the Web

#218

Post by TheCoelacanth »

daanlo wrote: post #214
ghostly_s wrote: post #208

Earlier quoted context omitted.

> Dude, autocomplete=off should just work. Chrome does the WRONG THING. Screw you. I've probably encountered 'autocomplete=off' thousands of times in my browsing history, and maybe 1% of the time was it being used for something that wasn't user-hostile. I don't care what the spec says, I care about what's good for users. If the spec writers aren't willing to embrace that, vendors will ignore it.

A website is owned by someone. If they decide that in their shop they want to have a carpet floor it is up to users not to visit that shop (if they don't like that), but not up to adidas to turn the floor into tarmac, because that works better for their shoes...

The browser is owned by the user. If the user wants it to autocomplete a field, then it should autocomplete the field.

Re: Chrome breaks the Web

#219

Post by katastic »

Manishearth wrote: post #180
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…

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…

>The web is the only platform aside from perhaps some assembly languages that is that stable and that ubiquitous.

The first part I agree with. The second, I don't understand.

.NET and Java are way more universal than assembly language unless you really split hairs and pretend "any byte code generated by a machine that ends up as assembly = assembly."

Re: Chrome breaks the Web

#220

Post by djur »

mediumdeviation wrote: post #189
quotemstr wrote: post #146

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.

It seems Firefox supports a non-standard fourth parameter, so that won't work either. addEventListener is possibly the worst organically grown API I've seen in a long time. If anything, its sordid history should be a lesson to the Chrome dev team that fucking around with proprietary extensions (which this most definitely is) just leads to future technical debt and pain for everyone. Why do they never learn?

That isn't an issue if you use a new method name -- I believe "addEventListenerEx" was meant to be read literally. (Appending "Ex" to a function name for an expanded parameter list is a Win32 convention.)
Post reply on HN