41–50 of 473 posts
I side with Google on this one. IMO we should be breaking JavaScript more often, especially in the name of performance, to make people use less JS and simpler JS on their websites.
Great idea. Why stop there? I say let's make "if" conditions randomly work on false values 1/1000th of the time. That will teach them.
I side with Google on this one. IMO we should be breaking JavaScript more often, especially in the name of performance, to make people use less JS and simpler JS on their websites.
Great idea. Why stop there? I say let's make "if" conditions randomly work on false values 1/1000th of the time. That will teach them.
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. But I don't think equating a step towards sane default behavior with wrench-in-the-gears chaos adds much to the discussion.
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.
> 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 wh…
Could they? From my understanding passive listeners do not stop execution, so even if a specific handler wants to bail out at run time it will already be too late to do so.
> once again minorities get to visit the mass grave
You don't think you're being a touch hyperbolic here? You can still use a non-passive listener if you want to, you just have to opt into it. Defaults should serve the majority use cases, that's the whole point of having them.
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.
> Yes, some people do it right Who? Any examples?
http://mobile.abc.net.au/news/2017-10-16/north-korea-missile...
Earlier quoted context omitted.
Great idea. Why stop there? I say let's make "if" conditions randomly work on false values 1/1000th of the time. That will teach them.
You're being sarcastic, but this is a great idea. Let's do it.
> 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…
Isn't this a reaction to moronic use of autocomplete=off in a user-hostile way by various websites? In a similar vein to how abuses of disabling the back button, popups etc have led to defensive measures by browser vendors.
Autocomplete=off is abused, certainly. It's commonly used to interrupt password manager functionality, in much the same way that copy/paste disabling is used on "repeat new password" fields. (As an aside: disabling autocomplete is a good idea, but only on the password manager level, not the website level. It's defense for user privacy, so employing it on well-meaning websites is worthless.)
But it's not abused in the user-endangering manner that circular redirects and back button hijacking have been. (Specifically, to make scam sites hard to escape and easy to click into.) It's just an inconvenience to users, and honestly I'm not thrilled to see browsers override code for non-security reasons.
> 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…
Isn't this a reaction to moronic use of autocomplete=off in a user-hostile way by various websites? In a similar vein to how abuses of disabling the back button, popups etc have led to defensive measures by browser vendors.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=587466...
Earlier quoted context omitted.
Great idea. Why stop there? I say let's make "if" conditions randomly work on false values 1/1000th of the time. That will teach them.
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…
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.
> 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…
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.
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 better than Google/you, they're stuck with crappier security/UX and the market should sort it out.
I've actually managed to convince a company to stop prohibiting copy-paste on logins by pointing them at the new NIST password guidelines. I don't expect this to work for every company, but if they intentionally don't change, it's okay to name and shame them for it. Whether it's a UX sin or security voodoo.