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

71–80 of 473 posts

Re: Chrome breaks the Web

#71

Post by acobster »

brlewis wrote: post #49
acobster wrote: post #42

Earlier quoted context omitted.

This is a straw man argument. Randomly breaking stuff for the sake of breaking stuff is not what this is about. This update had a clear intent and only "broke the web" for sites running code that was already risking breakage by deploying an anti-pattern, namely blocking on scroll! I'm no believer in Google's faux-altruism, much less sympathetic to their cause (see: AMP). The rollout could've been less agressive, sure…

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. Breaking "if" semantics is just inducing chaos to no one's benefit.

Re: Chrome breaks the Web

#72

Post by [deleted] »

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…

[deleted]

Re: Chrome breaks the Web

#73

Post by jarym »

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 place currently. For example, how do Google's own apps disable autocomplete if autocomplete is ignored?

Re: Chrome breaks the Web

#74

Post by mcv »

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?

The browser only identifies itself by name, not by the features it supports. Having the server decide blindly on what features the browser can handle, would be terrible.

Having browsers identify themselves by the features they support would have been nice, but also very complicated, and it's not where we are now.

Re: Chrome breaks the Web

#75

Post by pluma »

biotech wrote: post #58
pluma wrote: 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…

Except in this case they're breaking forms that disable autocomplete for legitimate reasons.

If there is never a valid reason to disable autocomplete and therefore "the standard is wrong", there are ways to change the standard. The standardisation process for Web APIs actively involves browser vendors but allows for building a consensus before jumping the gun.

Re: Chrome breaks the Web

#76

Post by somebehemoth »

dx034 wrote: post #66
LoSboccacc wrote: post #18

Earlier quoted context omitted.

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…

> same with apple - "now we'll ignore user-scalable=no and screw every responsive webapp out there" Maybe because 90% of responsive webapps would be better implemented as standard html websites which would improve performance and help preserving battery.

90% according to whom?

Re: Chrome breaks the Web

#77

Post by lallysingh »

reificator wrote: post #28
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-synt…

For 1, 2, and 3: I figure you just need to parse the UA string to get the actual browser and version number, then have a variant for before and after a given threshold number. You're only doing this for the number of variants of code you want to run/maintain, so this isn't some sort of combinatorial explosion.

It's just another method of dispatch instead of runtime checks inside JS. At worst you put the runtime check in the "I don't know what you are" variant and let them run slower.

For 5: If the browser's lying, you're morally off the hook. The user's configured their browser to lie, and gets what they deserve.

For point 4, fair enough. Go for that when you can.

Re: Chrome breaks the Web

#78

Post by s17n »

> 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 trying to fix it.

Re: Chrome breaks the Web

#79

Post by WorldMaker »

akvadrako wrote: post #55
KeitIG wrote: post #48

Earlier quoted context omitted.

You are right, but my personal problem here is autocomplete is automatically applied where it should not be. [1] [1] https://bugs.chromium.org/p/chromium/issues/detail?id=587466...

There is no general solution; only the end-user is smart enough to know when autocomplete should be used, and asking them to specify it for every field is too much work. Personally, I installed a Safari plugin to ignore autocomplete=off because it was so annoying. So Chrome is doing what I want my browser to do.

That's just it, maybe it is time to put it back into the hands of the end-user? You don't need to ask the user for every field, just an override for fields that have autocomplete=off. Add a simple mark for "Autocomplete was turned off on this site for this field" where clicking it overrides. You could add similar marks for fields with onpaste handlers to deactivate them.

Re: Chrome breaks the Web

#80

Post by gpvos »

hbbio wrote: post #61
Spivak wrote: 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.

Password managers use browsers plugins, and as such can modify pages before they render as much as they like.

Mine (PasswordSafe) doesn't, and it's probably not the only one.
Post reply on HN