Live data from Hacker News

Chrome breaks the Web

tonsky.me

81–90 of 473 posts

Re: Chrome breaks the Web

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

This is a discussion about "addEventListener" not "scrollTo".

The article has nothing to do with scroll jacking other than the fact that all JavaScript events are listened to via "addEventListener".

Re: Chrome breaks the Web

#82
post #49

Earlier quoted context omitted.

This is not a straw man argument. See sibling comment https://news.ycombinator.com/item?id=15635929 It would be a straw man argument as a reply to the article, but it's a reply to a comment that advocates breaking the JS to make developers use it less.

I think that's a mischaracterization of the comment's argument, despite its perhaps simplistic language. Maybe I'm wrong but given the context the spirit of the argument seems to be "let's load less shitty JS," i.e. less code that does stuff like block on scroll. So in my view the argument is really not about the developer experience at all; it's about encouraging code with concrete benefits for the end-user. Breakin…

There is no adjective or other qualifier in the original comment. You're reading it in.

If you need more clarity, see the same commenter's "JS is a pox on the web" comment: https://news.ycombinator.com/item?id=15636056

Re: Chrome breaks the Web

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

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.

Re: Chrome breaks the Web

#84
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 are rarely if ever thinking about the good of their users, except in a very narrow profit motivated sense, and never thinking about the good of the ecosystem as a whole.

Google is also "breaking the web" by not auto playing videos, not allowing alerts in one tab to block the entire browser, etc. Those all seem like good things to me.

Re: Chrome breaks the Web

#85

Earlier quoted context omitted.

You have an interesting point of view. Why do you feel this way?

I think JavaScript is largely a pox on the web. I hate almost every website I come across today. I just try to ignore all of the bullshit for as long as it takes to consume the actual content, and 95% of the bullshit is possible thanks to JavaScript.

Do you think if JS weren't available advertisers and marketers wouldn't try everything to shake some $ off your pocket? You would be pissed the same way.

Also if it weren't JS, would it make a difference if the bullshit is created by lisp, java or erlang?

Re: Chrome breaks the Web

#86
First of all I 100% wholeheartedly agree with the message of this post. However I have a minor quibble:

> Chrome broke half of user websites, the ones that were relying on touch/scroll events being cancellable

Either I badly misunderstood or the author is asserting that 50% of all websites rely on touch/scroll events being cancellable. That's inflated by at least 100x. Exaggeration is doing no favors here; the rest of the article is pretty rational despite it being clear that the author is pissed off, but this one sentence undermines it.

---

Unrelatedly:

> We really don't have more than anecdote (and our metrics) on the "support" side, and no precise way to quantify the breakage. I'd love to have a more quantifiable way to make these sorts of trade offs.

(Emphasis mine.)

Wow. So they're breaking backwards compatibility in a standardized web API with no plan for how to measure the fallout? That's not very nice.

Re: Chrome breaks the Web

#87

Earlier quoted context omitted.

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.

Are there Chrome-only sites? I'm sure they exist on LANs, but are there public sites that only work with Chrome?

https://meet.google.com/

Although, it's not very good in Chrome either :)

Re: Chrome breaks the Web

#88
post #67
post #35

Earlier quoted context omitted.

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.

So the question becomes what's less bad: for website developers to break their own site, or for Chrome to break other people's site. I'm all for empowering browsers to override abusive behaviour from websites, but using bad defaults and breaking innocent websites as a result is not the solution.

You mention website developers and Chrome developers, but spare a thought for users as well. If I want to use a password manager and the website developer decided to stop me from doing that, I appreciate Chrome helping me out.

Re: Chrome breaks the Web

#89
post #58
post #50

Earlier quoted context omitted.

How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions (e.g. 6-8 characters, must include digits, upper- and lowercase letters, and special characters but no quotation marks or any known SQL keywords)? The right thing to do is to bring the issue up with whoever is running the website. If they decide not to act on it because they think they know security/UX b…

> How is this different from websites that think it's okay to force you to abide by ridiculous password restrictions The difference is that disabling of "autocomplete" is a user interface issue, and can be addressed by the browser I use. The problem of ridiculous password restrictions is not usually something that can be controlled by the client. I like the idea of convincing IT to change crazy password policies, but…

You don't necessarily have to convince IT. If you instead convince their legal department that by not following the NIST standards for passwords they are opening their company to a lawsuit, that could get results a lot faster.

When IT is convinced they have to decide when to put it into the budget. If they think their policy is not okay, just not perfect the fix will probably be buried in the bottom of the budget pile and cut every year.

When a company does not follow a NIST standard [that applies] that is admissible in court against them. While it isn't an automatic loss they have to defend why they didn't follow the standard. In some cases the defense is not to the jury, but the the judge while can make a "statement of fact" and tell the jury to assume negligence for not following the standards. When legal says the cost of not complying with NIST password guidelines is potentially 10 million dollars that puts fixing the password requirements much higher in the budget.

Re: Chrome breaks the Web

#90
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've also done something so threatening to users' security that I can't take them seriously on the issue. They've been doing it for years, they refuse to change, and it makes me conclude that they fundamentally don't understand the problem.

Every update of chrome erases their password manager entries. So for every site their password has to be re-entered.

Why is that dangerous? Because that means that my cousins and nephews other regular folks cannot trust Chrome to keep their passwords, so they must either reuse passwords or write them down somewhere. Obviously, a third-party password manager is simply not an option for these folks- they rely on the browser. The browser can get it right or get it wrong. Chrome gets it wrong.

Post reply on HN