Chrome breaks the Web - <AUTHOR> http://tonsky.me/blog/chrome-intervention/ <comment><USER3> > 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 `<form>` tags [1], because:

> The tricky part here is that somewhere along the journey of the web > autocomplete=off become a default for many form fields, without any real > thought being given as to whether or not that was good for users. This > doesn't mean there aren't very valid cases where you don't want the browser > autofilling data (e.g. on CRM systems), but by and large, we see those as > the minority cases. And as a result, we started ignoring autocomplete=off > for Chrome Autofill data.

Problem: Chrome now auto-fills wrong parts of forms with username/passwords and this breaks forms that get unexpected data when submitted. And now, they opened an issue on their tracker [2] to track "Valid use cases for autocomplete=off".

This is insane to think that the developer is wrong to use some attributes values, and to assume how a page should behave, ignoring devs intentions and Web standards.

[1] [https://bugs.chromium.org/p/chromium/issues/detail?id=468153...](https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164)

[2] [https://bugs.chromium.org/p/chromium/issues/detail?id=587466](https://bugs.chromium.org/p/chromium/issues/detail?id=587466)

<comment><USER4> > 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.

<comment><USER5> Woah woah woah. Let me recount/nutshell the crux of conversations I've had with my product manager(s) about things like this.

Me: Hey, I'd like to add a work-item to our current sprint that reworks semantic attributes into our site.

Them: What would that do?

Me: It improves the underlying architecture making the markup more usable and extensible.

Them: How does that benefit the users?

Me: Over time it will reduce the TTM for features and allows us to adopt a common standard others use on the web.

Them: So there's no UI and it won't affect their workflow?

Me: Well, no.

Them: Then why would you suggest it? We don't have the budget to add meaningless development tasks.

I might be biased towards thinking there are _plenty_ of developers and engineers out there thinking about this stuff but we don't always get the final say in what is done. Also, a lot of enterprise applications were and continue to be around before many of these standards. It's a struggle to improve what doesn't directly add to the bottom line.

<comment><USER6> Try to make those requests via e-mail, so you have something to show when it breaks or becomes hard to maintain.

<comment><USER7> I've learned when I have to start getting things in writing that it is time to find a better job. I can't stand playing games at work.

</comment></comment></comment></comment></comment><comment><USER8> > 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 opportunity for self reflection.

Janky scrolling behaviour on mobile has been a problem for a long time. Apple also implemented non-standard behaviour for years to avoid it. You should almost never be listening to scroll events in a non-passive way. The vast majority of times scroll listening is used, a passive listener is the correct implementation and just wasn't available when the code was written.

This is proven by the article itself: the change was made in February of this year. Do you remember the internet breaking that day, and all of us rushing to update our event listeners? No, me neither. Did Chrome really break when the web when absolutely nothing broke?

<comment><USER9> 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 behavior that folks may rely on continues to work.

The commitment to stability on the web is astounding; I don't see anyone changing that any time soon. Google should not be breaking things just for its users; because its users are affected when they break things too.

That's the problem with Javascript. When Javascript breaks, it's not the developers who get the error, it's users, who have no idea what it means and no way to fix it. This is not the case with e.g. compiled languages; there's no _extremely strict_ guarantee your code will still compile on a new release.

That said, Google did push this through the right channels ([https://github.com/WICG/interventions/issues/35](https://github.com/WICG/interventions/issues/35) , [https://github.com/w3c/touch- events/issues/74](https://github.com/w3c/touch-events/issues/74) , [https://github.com/WICG/interventions/issues/18](https://github.com/WICG/interventions/issues/18) ) and it seemed like browser vendors were in agreement that this wouldn't be a problem. This is something that does happen; browser vendors "unship" or break functionality after discussing it sometimes.

So while I'm not convinced Chrome stepped out of line here, breaking sites _absolutely is not putting users first_.

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

They won't if they use a <blink> 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 the minority user looking at an old site first, or you're putting the majority looking at newer sites first.

Maybe it wouldn't be the worst thing in the world to introduce an "archival" mode in a browser. Nothing published on the web is ever truly broken because it's very well documented what it _should_ do. So we can turn those features back on when viewing an older site that requires them - blinking text and all - while still moving forward on the platform people use every day.

<comment><USER10> > 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.

<comment><USER8> > 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.

</comment></comment></comment></comment></comment><comment><USER11> To be honest as a user, I'm glad they made this change, even though as a developer it might be a pain in the ass for a day or 2.

Scrolling on the mobile web sucked for a long time. Yes, updating the default broke many things, but the scope of that breakage was fairly limited in the grand scheme of things (like the author said, sliders, maps, touch-and- draggable things like lists are the biggest impacted, stuff like "sticky headers" and other junk would be impacted, but not "broken beyond usage").

We've seen time and time again that simply giving a developer the ability to fix things doesn't help, and letting the mobile web suck for several years while a few percent of the web slowly learned how to fix this would end up impacting far more people than the "breakage" ever would.

It's not ideal, and I wish that google provided a very quick and easy way to "opt out" of the breakage (like some one-line "polyfill" that reverted the change that site owners could use as a stop-gap until they could properly update their apps to work correctly), but I see their point and as a user I agree with it, even though as a developer this is the kind of stuff that ruins your day.

I personally have not hit a single website that was impacted by this that I could notice myself. That's not to say that I haven't been impacted by the breakage, or used sites that had something break because of it (that I didn't notice). But even knowing that this change was made when it was made, I didn't see any sites that were "unusable" or "broken" because of it.

<comment><USER12> > "polyfill" that reverted the change that site owners could use as a stop-gap > until they could properly update their apps to work correctly

then the site owners would just use the polyfill indefinitely, since it now works again. THe more expensive option of rewriting to conform is not going to give return on investment.

This is why breaking a bad thing is needed - the suffering has to happen. It's like getting the flu - to get better one must get sick first if you've been infected.

<comment><USER13> Except that millions of sites will not ever be fixed; they'll just be broken indefinitely.

<comment><USER14> Possibly, but if they are that useful to users, those sites either need to be maintained or forked. Your argument could have just as easily been used to argue for Adobe Flash support(OK it's still sort of around, but it's nearly irrelevant at this point).

<comment><USER15> > sites either need to be maintained or forked

Maintained by who, forked by who? You can't just fork someone's work, there is copyright. Also any saved copy of website(think web archive) will stop working.

<comment><USER13> Assuming you can even get at it; most useful tools have a significant server component that's inaccessible.

</comment></comment></comment></comment></comment></comment><comment><USER16> 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.

<comment><USER17> 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.

<comment><USER18> Couldn't they use Firefox?

<comment><USER19> So many websites have "Use with Chrome" that if a user sees the website not working in Chrome, it's likely that the user will assume the website is broken, not the browser.

</comment></comment></comment></comment><comment><USER20> 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.

<comment><USER21> "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. " The funniest part of this sentence is that it cites no source. Meanwhile, Google claims very clearly that they analyzed websites and determined pretty much nothing would break.

Given the internet did not break that day, i'm going to go with "They were probably right".

Especially since, unlike this website, they have the crawl data to know.

</comment></comment><comment><USER22> 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.

<comment><USER23> 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.

<comment><USER22> You're being sarcastic, but this is a great idea. Let's do it.

<comment><USER24> You have an interesting point of view. Why do you feel this way?

<comment><USER22> 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.

<comment><USER25> 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?

<comment><USER22> It it were lisp, java, or erlang I'd still be pissed. The web should not have a client-side scripting language.

<comment><USER25> That's just laughable. Somebody at some point would have created an alternative browser with client side scripting. Otherwise you end up with static text and video. Wonderful. And plugins! Because you don't allow scripts :)

<comment><USER22> I don't think that it was a mistake at the time. I think that in retrospect it has been abused, and many of the things that justified it are now possible without it. It should be deprecated and removed.

Yes, I know this is a fool's errand. I don't actually expect this to happen.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> OK, this sounds bad. But... Devil's advocacy here: are there any real-world examples of actual sites whose event behavior was actually broken by this change in Chrome 56? It happened a few months back, and I don't remember anyone complaining.

I mean... it broke the author's app. Probably a few others somewhere. But it seems not to have broken anything significant.

I guess I fail to see the concern here. It's an edge case of an existing API that apparently "no one used". Google found a way to get a benefit from exploiting a "change" in this "unused" API, presumably tested to make sure it was unused, and then went ahead and pushed the change over an 8 month period.

Is that really so awful? As someone who lived through the early '00's and IE, this seems pretty benign to my eyes.

<comment><USER27> It broke our web apps. Specifically, drag and drop list reordering functionality and image cropping. I was pissed when it happened. It wasn't a change that a typical content site would be broken by, but a lot of web apps were: drag/drop reordering isn't a very unusual feature these days.

</comment></comment><comment><USER28> > 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.

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

<comment><USER28> 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.

</comment></comment></comment><comment><USER30> A lot of fair points in here.

I think what it comes down to is backward compatibility for the web. There are SO MANY websites relying on old behavior that introducing new behavior is going to break some sites that don't KNOW about your shiny new shit.

IE used to have this kind of thing too, anyone here remember "Quirks Mode" and so on?

What web browsers sorely need is a backward compatibility standard that they can STICK TO. Such as feature detection as a first-class API to be tried first. Perhaps this way any new features can be detected across browsers. Like, they would actually have to coordinate to name EACH new change the same in EACH new browser.

But this is what you get when you have multiple browser makers. Some just won't coordinate with the others and you need another layer - a library - <USER2> abstract away the differences.

Which is why it would be super-useful for browsers to add content-addressable protocols (read: not just http) to fetch files from any website in a DHT. So these libraries can be loaded ONCE and become cheap to use!

Does anyone know any mainstream browserd planning to implement, I dunno, IPFS? The only one I've heard of doing this is Blockstack and dude, how much adoption does that have exactly?

Last question -- can there be a browser extension that can intercept http requests by their Subresource Integrity checks, and load them on demand as if they were content addressed? Maybe use service workers in Chrome? Is that possible? I would be willing to partner with someone here to write such a thing.

<comment><USER31> > Does anyone know any mainstream browserd planning to implement, I dunno, > IPFS?

It's actually not too far off - IPFS is already capable of running a full js- ipfs node in a WebExtension's background page and expose its API to content pages. What's missing is minor things like streaming to/from the background page, and WebRTC in the background page.

For proper ipfs:// protocol support in the address bar and in links, a better protocol handlers API in WebExtensions is required though, which will take some more time. Basically right now with the ipfs-companion extension, ipfs:// URLs get rewritten to [http://](http://).

</comment></comment><comment><USER32> > Google wasn't concerned about your websites at all. It was more concerned > about its own product performance

Why I'm not surprised?

<comment><USER33> No, Google were concerned about your websites. Your mobile websites which are so heavily overloaded with JS that basic interactions like scrolling don't work.

Complaining that Google "broke the web", when mobile developers have been making it slowly unusable—and unused—for years is pretty hypocritical. All the feature detection and backwards compatible changes in the world won't help developers when their entire userbase has fled to walled gardens like Facebook. But I guess some people will resent anything that forces them to accept short term pain, even if it's essential to their long term survival.

<comment><USER34> So this is a good thing because the gatekeeper is Google instead of Facebook?

How's about adhering to standards? We gave Microsoft a hell of a time for not adhering to standards, but Google gets a free pass now? Because "performance"? (read: some negligible gains on some synthetic benchmarks)

Then let's stop pretending: let's scrap the W3C and go back to the good old days of "Best viewed on Netscape Navigator at 800x600".

<comment><USER35> Let's also complain about Mozilla because they are removing Flash support and thus breaking backwards compatibility. It's obvious that they are all 'evil'.

<comment><USER36> Was flash a standard? Also, flash still works, it's a click away with a button in the location bar for sites that try to use it.

</comment></comment></comment></comment></comment><comment><USER37> Can't they just add another argument for the options map without breaking backwards compatibility?

That's ugly as hell too, but in a way that preserves backwards compatibility.

My feeling is that so many compromises have been made to maintain compatibility in JS/DOM-land that it seems capricious to make this kind of decision now.

<comment><USER38> > Can't they just add another argument for the options map without breaking > backwards compatibility?

The options map is a recent addition in the first place, and they want passive listeners by default. They originally made passive opt-in, then decided that they wanted it set.

</comment></comment><comment><USER39> 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?

<comment><USER35> > 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.

<comment><USER39> 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.

<comment><USER40> Why not? The user knows that the browser remembers field inputs, he wouldnt expect it to be different for your website. So if he really wanted the browser not to remember anything he typed in, he would use private mode or clear his recent history afterwards.

Because then there's the teacher who has to put in medical data for a whole class where everyone got the flu. The teacher is happy the browser does it job like always and that you couldn't dictate what is best for him.

<comment><USER39> 'Why not?' you ask? Let's look at HIPAA for starters: [https://www.quora.com/Do-current-HIPAA-rules-require- publicl...](https://www.quora.com/Do-current-HIPAA-rules-require-publicly- viewable-machines-to-not-have-tabular-lists-pull-down-menus-of-patients-or- autocomplete-except-for-fully-unique-matches)

"In summary, HIPAA does not specifically limit the use of drop down menus or auto-complete, but if patient information was exposed to the public through these features your business would have failed to control access to the protected health information."

So now there's a risk that if a user of a medical information system uses a shared computer (say one at home but that friends and family occasionally use) you can't be sure to have protected control. It's all very well saying 'users should use private browsing mode' \- you try enforcing that consistently when you have hundreds of users.

Ultimately, you end up having to restrict access which is why I felt it does a dis-service to users.

<comment><USER40> You shouldn't enforce anything, since you can't really anyway: The shared computer might record the screen or have a key-logger installed.

<comment><USER39> Well then let's just throw away any kind of data entry then since any computer might have a key logger installed.... _sigh_

<comment><USER40> > any computer might have a key logger installed

You know very well that for your own computer it's very unlikely that it has a key logger. But not for public computers, so it's a good thing that users are aware of that.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER41> > "Browser vendors have their own agenda. It mostly includes making their > browsers look fast, sometimes at the cost of your websites become broken."

I feel like you'd know the tree by it's fruit. I have a little more faith that vendors like Mozilla wouldn't pull a punch like this; might have been more receptive to community feedback, not that anyone here needs a continued lecture about Google.

</comment><comment><USER42> There's a good point here but the clickbait trappings are holding it back, especially since passive listeners aren't some obscure edge case which only Google needs.

<comment><USER43> I think the point of it was that they made every event listener passive by default, rather than making it an option.

<comment><USER42> My point was simply that while there's a good technical discussion to be had here, the doom and gloom styling hurts it. There is a reasonable point about backwards compatibility, the conflicts between Google owning Chrome and also making web properties which compete with other companies, etc. but there's a lot of hyperbole like this:

"Now, this is a terrible thing to do. It's very, very, very bad. Basically, Chrome broke half of user websites, the ones that were relying on touch/scroll events being cancellable, at the benefit of winning some performance for websites that were not yet aware of this optional optimization."

None of those claims are supported. If Mobile Chrome broke half of the sites on the web, we'd have heard a lot more outrage over the last six months, and the very strong language fails to consider all of the broken code which was making the web experience worse for almost everyone.

Again, I'm not saying that that the technical discussion isn't useful but that "breaks the web" seems unnecessarily hyperbolic. The fact that the React team is struggling with a simple JS/CSS change seems to say a lot more about the support cost of building huge JS frameworks which duplicate core browser functionality than whether the Chrome team should make decisions to help mobile performance.

</comment></comment></comment><comment><USER44> I've seen similar posts when Apple announced that there won't be Flash on mobile Safari. And I agree with Chrome team decision to force passive on document level listeners.

Also, note that not many people complained about "blocking video/audio autoplay on mobile browsers", because it's good for users.

BUT:

\- Passive event listener detection is horrible and it baffles me that they start thinking about proper way only now.

\- The announcement of this breaking change was quite silent. Chrome has so many influencers on social media, but almost no one shared/explained this change properly.

</comment><comment><USER45> 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.

<comment><USER46> 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?

<comment><USER47> 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.)

<comment><USER45> Right. The whole problem disappears if you just define a new function name.

</comment></comment></comment></comment><comment><USER48> I understand the push from browser vendors to (as they see it) encourage web developers to keep their sites up to date, but it's crazy how little Google and others seem to care about backwards compatibility.

So many websites from 10 or 20 years ago are unusable now -- if they're even still available. That seems to me a bit of a tragedy. It's sad to just write off that entire slice of human history.

Funnily enough, it's the sites that were quick to adopt the hot new HTML and CSS features from 10 years ago, but then were unable to keep updating indefinitely, that were the worst hit. Really old sites using basic HTML and CSS mostly work OK.

</comment><comment><USER49> 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.

<comment><USER27> <Raises hand> Took about a developer day to fix everything. Drag/drop list reordering, pan/zoom image cropper were the primary things busted. IMO, the change was an unacceptably aggressive move by the Chrome team made with good intentions.

<comment><USER49> > Drag/drop list reordering, pan/zoom image cropper

I'm curious, were these implemented using a 3rd party library or developed in- house?

</comment></comment></comment><comment><USER50> A great example of why I think the entire core ecosystem of the web is backwards.

I've had a number of comments here on HN related to this. Imagine this same scenario, except instead of the User being in charge of deciding which engine is used to render a website / webapp, the Developer is making that choice. What would a developer need to do if they were in control of which "engine" rendered their website on the user's computer?

Instead of being at the mercy of Google / Chrome, the developer of said site could simply change their HTTP Header "X-BrowserEngine" or something like this, and the client's computer would know how to (a) download the new engine if it's not on the computer already (b) sandbox the new engine (c) run the site / app in said engine.

I've called this idea the "Meta Browser" in the past. It's a concept for an app that sandboxes and runs sites on different browser engines seamlessly. The user experience is more or less as though they're continuing to use a single app to browse the web, but behind the scenes could be any number of custom engines rendering the content.

</comment><comment><USER51> I don't get this feature detection problem. The browser identifies itself in the request. Why not serve the right version at the beginning?

<comment><USER52> 1\. Because every browser pretends to be each other and so the UA is worthless: [https://webaim.org/blog/user-agent-string- history/](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-syntax related features, feature detection on the client is usually pretty simple.

5\. Because the UA is trivial to spoof.

<comment><USER51> 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.

<comment><USER52> Browser sniffing falls in the same category as time, crypto, and string encoding for me. If you think it's easy, you haven't spent enough time thinking about it.

<comment><USER51> A few seconds of googling found quite a few prebuilt results. First one: [https://github.com/faisalman/ua-parser-js](https://github.com/faisalman/ua- parser-js)

It doesn't have to be trivial to be worth doing.

<comment><USER52> Direct from the README of the linked library:

> However, it's not recommended to use this library as browser detection since > the result may not accurate than using feature detection.

</comment></comment></comment></comment></comment></comment><comment><USER53> This doesn't surprise me. Having spent years working on a very complex web app that's built to run primarily on Chrome (-2 versions), our API/DOM usage coverage was so great that we would often joke that our unit and integration tests were effectively a 90%+ coverage of all of Chrome's functionality, so any bugs or changes they made, we knew about immediately.

I think nearly every version introduced some change that broke behavior and had to be worked around, usually fairly minor and arguably reasonable. Sometimes that's not the case, something would be completely broken and we'd file bugs against Chrome to get them fixed, and our codebase is now riddled with comments about workarounds citing Chrome bugs, some years old.

There was even a recent change to contenteditable that was a breaking change and is not spec compliant, which totally breaks HTML-based rich-text editing systems built on it that don't want to just have a ton of style tags and/or empty tags everywhere in their markup. This API is probably one of the worst I've ever seen (it needs to be extensible and modifiable, you can configure it somewhat but you're left actually taking the output and massaging it yourself if you want anything resembling a good product based on it), so I'd be in full support of a rewrite of the spec and a new version of contenteditable, but as terrible as this one is, it should remain spec compliant.

At one point I held Chrome in reverence for pushing the boundary and improving the QoL of web application developers, but shifting to maintaining anything of decent complexity has made me regret the decision based on how much extra work Google makes for us. They really need to cut out the breaking changes and do better regression testing. If our app detects errors in beta/canary and we report them and they STILL make it to live, I just don't even know what to say. I'm not even sure I agree that just because 0.1% of websites rely on certain behavior that it should be "breakable." With all this talk about progressive web apps, where are the progressive web browsers?

</comment><comment><USER54> I have a few contradictory thoughts on this.

On one hand, I really feel Chrome is more on my side than the average webmaster. I don't want bloated websites, I don't want autoplay videos, I don't want copy/paste blocked, I don't waste text copying hijacked so that a phrase has a referral link to the article, etc. If Chrome breaks a website functionality to over-write these things, good.

The downside is that Chrome is a very big player and by working outside of the system then the rest of the web loses on the spillover benefits.

This is hard, committees are slow, bureaucratic and massively resistant to change - and saying fuck it, I'll fix it properly for myself is a lot easier, and I have little patience for it myself. However, in the long ran this is probably better.

</comment><comment><USER55> The highlighted comments from the Google agent are very jerkish, but to be honest,

        > But in Chrome we're fundamentally unwilling to allow the mobile web to continue to die from performance bankruptcy. Other browsers are less aggressive, and people who prefer to be more conservative (preferring maximal compatibility over being part of moving the web forward aggressively) should prefer to use a more conservative browser.

is very true.

The mobile web is dying. Native apps are obscuring it while it is made irrelevant by very poor website performance.

Now I don't know how to solve it.

</comment><comment><USER56> > The gist of it: if you mark onscroll/ontouch event listener as passive, > Mobile Google can scroll your page faster

onscroll has never been cancelable, and is fired after the actual scrolling takes place. So I don't see how it being passive by default changes anything. Is this an oversight in the article (and a bunch of comments here), or am I missing something?

[https://developer.mozilla.org/en- US/docs/Web/Events/scroll](https://developer.mozilla.org/en- US/docs/Web/Events/scroll)

</comment><comment><USER57> Reading the comments here make me feel Chrome is like Uber. They may be right in that the standards are outdated and force change. Yet, it breaks all rules and regulations which they shrug off saying the rules have to change.

Again, this is not a comment to choose sides. Just an observation. As with Uber I can't say if I'm in favor or against. By law, they are wrong. In time, it may turn out they have led change. Funny thing how you can get applauded as patriots for breaking the rules early as long as you were right in the end but critiqued otherwise.

<comment><USER58> Reading the comments here makes me feel like Google's PR team made its round.

The performance benefit in this has to be miniscule, the number of unmaintained webpages which are irrevocably broken by this has to be huge and the time period from introducing this feature to breaking webpages, which have not yet correctly implemented it, was simply far too short.

Even if you agree with having to enforce this somehow, this rushed execution of that was by all means irresponsible.

Despite that, it seems like 8 out of 10 highly upvoted comments here make no mention of this maybe not having been ideally executed or it maybe not necesseralily being advantageous to users either.

</comment></comment><comment><USER59> > Which means you can't practically use the new form without feature > detection.

That does not follow.

`{ capture: true }` works in both, since it's an object, and thus truthy.

There's no need for feature detection in the case you describe.

Sadly, that's the whole premise of this article.

It's only a problem if you want `capture: false` combined with other options — since you'd need to pass in an object, that would be truthy in the old implementations expecting a boolean instead. But then again, the additional options wouldn't be supported in those old implementations either.

I'm confused — what's the actual use case that's breaking here?

<comment><USER46> In older browsers, useCapture is NOT an optional parameter, and in most cases you do NOT want to use event capture instead of event bubbling. There's no trivial way to support addEventListener(event, handler, { passive: true }) on both new and old browsers without that really ugly feature detection code in the article.

<comment><USER59> > In older browsers, useCapture is NOT an optional parameter

Which browsers are those?

</comment></comment></comment><comment><USER60> Many tech people learned this in the context of Microsoft in the '90's, but it should be kept in mind universally:

"Embrace. Extend. Extinguish."

Maybe stop placing primacy on the "good/evil" aspects of this. Seems in part to work at a more fundamental level of human and organizational behavior.

P.S. I guess this could also apply to the people who hang ever-more JS off of their HTML skeleton, until our phones have to "boil an ocean" to load a page.

I guess that fits in with the "universal" aspect I described.

</comment><comment> old-gregg

      > they made all top-level event listeners passive by default.
      > Now, this is a terrible thing to do. It's very, very, very bad.

I disagree. This is similar to popup-blocking, yeah the "API" is there, so lets allow every site to just open windows because they want to?

Executing code during scrolling is a hostile action performed by web developers against users. These listeners shouldn't exist in the first place. Chrome developers sided with users, thank you Chrome developers.

</comment><comment><USER61> They broke userland.

They introduced a backwards incompatible change that causes a lot of sites to lose some functionality, behave differently or outright break.

Now you could say that the user (the developer here) used the feature wrong (I.e. they caused scroll jank), but that's a bit disrespectful - sure there are a lot of developers who had no idea what it'll do to performance, but others that weighed the options and decided that even with the jank the user experience for the majority of users is acceptable.

</comment><comment><USER62> This sort of thinking is not "moving the web forward." It's the same thinking that created the IE6 problem — favoring browser-specific features over web standards.

</comment><comment><USER63> > Think about it: a feature detection API that itself needs to be detected

There's already at least one such feature in the form of CSS.supports: [https://developer.mozilla.org/en- US/docs/Web/API/CSS/support...](https://developer.mozilla.org/en- US/docs/Web/API/CSS/supports)

</comment><comment><USER64> Adwords was asking me to test the new version, I clicked to update and it warned that only works in Chrome.

</comment><comment><USER65> I was a victim of this, thanks for pointing it out. Now I know what to fix at least!

</comment><comment><USER66> Let's be clear here, this isn't a change in favor of users. This is a change in favor of Google, to speed up their browser, and in favor of their advertisers, for better overlay control.

<comment><USER67> Is there a list somewhere of software which strives not to break the higher level things that depend on said software?

</comment></comment><comment><USER68> Google is toxic for the future of the internet, but its services are convenient so from time to time a few of us will complain when they inconvenience us, like in this case, but will continue using Google products and completely forget about our grievance with this company.

Case and point, I don't hear anyone complaining about amp anymore, or the fact that when you search for inventor in some US states you are presented with a bunch of irrelevant black people rather than actual inventors like Edison, Tesla, etc. Sadly, like with those cases this story too will blow over and nobody will care about it in less then a week.

</comment><comment> creative-coder Thats' why contribute and stick to Firefox.

\- Its more customizable \- Its more open and standards-compliant \- It doesn't eat up all RAM \- Its fast enough

</comment><comment><USER69> The main problem I have with the chromium team is that they removed Encoding menu.

I happen to visit an old unuqdated site from time to time now all I can read is gibberish.

</comment><comment><USER70> Back in the old days of IE / Netscape web. When Microsoft thought the respect of w3c wasn't fitting their vision. Yepee :(

</comment><comment><USER71> When Microsoft dominated the browser market they introduced non standard extentions. Now google dominates and does that too.

</comment><comment><USER72> Only thing I have to say in all this is any changes made on the web should always be backward compatible.

</comment><comment><USER73> where you been? web been broken for awhile now..it's all just duct tape and spit. We're also repeating the sins of the IE days all over again with chrome.. At this point i'm using alternative browsers and only fire up stuff like chrome if i have to

</comment><comment><USER74> Funtion overloading in a weak typed coersive language like JS seems like a bad idea.

</comment><comment><USER75> This is why Linus is very adamant to not break userspace applications.

</comment><comment><USER76> The tricky thing is somewhere in the travel of the autocomplete

</comment><comment><USER77> Why the heck would they take out the checkbox on javascript alert box to "not repeat anymore". Since they did, the only option to leave annoying website that pops javascript alerts in never-ending loop is Ctr+Alt+Del.

What were they thinking??

<comment><USER78> Didn't they make it so that you can switch tabs and close tabs even when one of the tabs has an alert open?

Of course, sometimes it still is nice to be able to turn off alerts and then keep using the page.

</comment></comment><comment><USER79> When did this breakage happen? I dont remember it at all.

</comment><comment><USER80> Whining for not much, just update your code. I think the move is best for users and web performance!

</comment><comment><USER81> Jesus Christ, to think there are people in this thread defending what the assholes in the Chrome team did is unbelievable. You make breaking changes opt-in, that is API design 101. Linus should take over Chrome development.

<comment><USER35> Stop being so dramatic. Valuing users over developers is not malice, it's common sense.

<comment><USER81> You can make it opt-in without breaking other people stuff. If a website doesn't opt in their users will migrate to another one that offers the same content with a better user experience. It just won't happen tomorrow (<\- common sense, of the real kind).

What really bothers me is that people like you can't figure out that there is a trend behind this and it's not good one.

<comment><USER35> > 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 browsers that you didn't even help to develop. It's not about you, it's about the users.

<comment><USER81> 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 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?

<comment><USER35> > 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?

<comment><USER81> 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...

</comment></comment></comment></comment></comment></comment></comment><comment><USER82> Google can break the Web because they own the Web. It's their platform. Maybe handing it to them wasn't such a good idea.

</comment><comment><USER83> I agree with everyone else that this change is for the better.

What will we do when they decide to make a change that isn't?

<comment><USER58> Make up even more ridiculous excuses for why this is clearly for the better of all of us and could not have been handled better.

</comment></comment><comment><USER84> Google is putting users before developers, which is dangerous because the users aren't the ones holding everything together.</comment>


DNS-based Authentication of Named Entities (Making CAs Obsolete) - <AUTHOR> https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities

<comment><USER2> So, basically, ditch CAs and put ultimate trust in the DNSSEC root?

<comment><AUTHOR> In the best case scenario we can combine this with some kind of decentralized DNS infrastructure [1].

[1] - [https://wiki.projectmeshnet.org/DNS](https://wiki.projectmeshnet.org/DNS)</comment></comment>


How Ripple could succeed but XRP be worth nothing - <AUTHOR> https://publication.widmerdun.com/how-ripple-could-succeed-but-xrp-be-worth-nothing-4c2c5152d184 <comment><USER2> This article seems to make the case not that XRP could be worth nothing, but that XRP will most likely be worth nothing, that it is very unlikely that banks would tie their entire international trading system to a speculative currency. Is this bullshit, or is the gigantic spike in interest in ripple just speculation?

If banks do end up using xcurrent without xrp is there any benefit to xrp, such as easy transfer using xcurrent, or will it just end up a dead fork, or at best a speculative store of value with no special features?

<comment><USER3> Quote from the article:

"Unfortunately the cost savings provided by XRP are not very high when compared to the risks of adopting it. In the best case scenario XRP would save banks an additional 33% over xCurrent."

So, according to the author, using XRP could save banks up to 33% in costs. His argument for saying that won't happen is that its too risky. Ripple (the company's) argument against that is they have escrowed away most of XRP and will release it at very specific intervals. They are very motivated to keep the currency stable. At higher prices, and higher volumes, that will happen.

<comment><USER4> Your argument seems to pivot from the banks claim that it's too risky to saying that Ripple can solve the volatility problem. While volatility is a big problem, I don't think it's the only (or even the largest) risk to banks using it.

<comment><USER3> I was assuming that the risk mentioned was volatility. What other risks are you thinking of?

</comment></comment></comment></comment><comment><USER5> Yeah, their tech is useful to the industry, that said the coin is a liability for a bank.

I see a future where banks exchange value with 1coin=1USD to speed up transactions but not using the value of XRP.

Plus for a random user making an investment, XRP not been a public blockchain is a no go for me.

They can hardfork / print money as they please.

</comment><comment><USER6> I think that the most successful cryptos will be successful with no or little value.

The use cases don't really care what the value is to successfully complete, they just need stability.

So XRP can be with a cent and be extremely useful for its purpose. It is actually less useful if the price appreciates quickly as transferring unpredictable amounts for settlement is difficult.

</comment><comment><USER7> It's interesting how XRP enables any group of individuals to nearly have the same remittance abilities as international banks. I think that if XRP doesn't get taken up by banks, there may still be a large enough market for Western Union style transfers for personal international payments.

</comment><comment><USER8> There's a lot of crypto celbs getting rich on XRP at the expensive of those believing the hype, pump and dump.</comment>


Code Rush – The Beginnings of Netscape and Mozilla (2000) [video] - <AUTHOR> https://www.youtube.com/watch?v=4Q7FTjhvZ7Y <comment><USER2> I really enjoyed this documentary. It's where I learned the term "Zarro Boogs". At one point jwz (Jamie Zawinski) makes a comment which essentially foreshadows net neutrality. I was also blown away by Stuart Parmenter contributing to the code base at age 16!

</comment><comment><USER3> If you like this kind of content I heavily recommend Halt and Catch Fire. It's fiction on the personal computing business of the 80s, online gaming/communities and the race for search engines and browsers in the 90s . It makes a lot of nudges to current industry leaders.

<comment><USER4> HaCF is one of my favorite shows! It's not very technically accurate, but it's still really good at portraying the social aspects of being a technological optimist at the dawn of the age of personal computing and the web.

</comment></comment><comment><USER4> I would also suggest _Dreaming in Code_ by Scott Rosenberg as a kind-of sequel to this documentary. In the early 2000s, a lot of Netscape people (including a lot of people depicted here like Michael Toy, but notably not JWZ) joined the Open Source Applications Foundation, and the book is essentially about their attempts to build the Chandler information organizer.

<comment><USER5> And more importantly it's failures. Its a great book and has great commentary on the state of the industry at that time</comment></comment>


Walgreens Threatens to End Theranos Agreement - <AUTHOR> http://www.wsj.com/articles/walgreens-threatens-to-end-theranos-agreement-1455156503 <comment><USER2> If Theranos is doomed in the end, does this paint Walgreens in a poor light for not properly vetting them in the first place? Or can no one really blame Walgreens for their actions up to now? I know their CFO was replaced in 2014 (he seems to be an easy scapegoat for this).</comment>


2 abandoned Soviet space shuttles rust in Kazakhstan - <AUTHOR> http://edition.cnn.com/style/article/baikonur-buran-soviet-space-shuttle/index.html <comment><AUTHOR> The technical museum in Speyer (Germany) has another one, in better condition.</comment>


Salaried employee. Offered raise with an increase in hours. Is this normal? - <AUTHOR> I'm currently working as a 40-hour salaried employee. The company I work for recently said that I'm one of their most efficient employees, and has offered me a 22% raise if I increase my hours to 50 hours a week. The logic was "we know you're working a second job, so why don't you work those hours here?".
Now, I understand that this is a personal decision, but my math side is coming out here.
If my hours go up by 25%, shouldn't the pay go up by more than 25%? I understand that salaried positions don't have to stick to an hourly rate, but is this typical of companies and offers like this? If so, why? <comment><USER2> If you are in the U.S. a couple of things come to mind.

First, you have a decent employer if they are making this offer at all. In the U.S. a salaried employee has no set maximum hours and an employer could require you to work 50 hrs under many circumstances without additional compensation (there are of course limits). But in general your only real recourse is to leave if you don't like it.

Second, The fact the employer is using a carrot and not a stick is also a good sign, e.g. I have seen employers go to employees and tell them to quit their second job or risk their primary one, and then force them to sign a document stating they won't work for other employers without prior approval which will never happen. Some states have protections against this behavior but not all.

In the end, to me the money wouldn't be the biggest factor, it would be what do you want to do? If you are happy doing side work or your second job and that is fulfilling and not just about money this isn't worth it. If you are doing it solely to earn extra income, than this is an option.

If you are interested in their offer, I would not approach them with the argument of 25% more hours deserves 25% more pay. I'd approach them and say you respect their offer and are very happy they consider you valuable, but the second job is already earning you more and you are enjoying it. So you want to point out that essentially their offer is to give you less, without being an ass about it. You want to imply, not demand here, be humble it will go further. If they are really interested in your extra time and they seem to be good people they'll automatically offer to go up some more or give you other options.

</comment><comment><USER3> your rate should go up at least as much as the time spent working. so you are right to think that. However, an employer isn't obligated to give a pay raise on every offer. an offer is just that, it's not the same as a raise. If they project to you that it is a raise in pay while its not, then that's actually not ethical, and depending on the wording and where you live might even be in breach of some terms/laws.

For example in my country it's not really allowed to reduce someone's pay, but if you agree to it and sign it is allowed. (so they can offer it and you are allowed to deny it without that reflecting back on you negatively...). This means that if they would want to lower your pay they will think of something creative like the offer you got, to try and reduce pay compared to productivity and wrapping it up in something that might get accepted by someone who doesn't dig a bit deeper.

I would advise just to make a counter offer, and say what you explained here, 'if i'm working 25% more i expect that much more in pay' , or if the other job is actually paying you MORE than these extra hours would yield you, you can even haggle with that and tell them the other job's hours are worth more to you. don't accept anything that feels like a step back, if your employer insists in putting you down like that, perhaps it's time to find a more decent employer.

</comment><comment><USER4> What's your second job and how much is it paying?

Also, what's the work like? do you enjoy it?

Seems like it's a one way street to. If you decided to quit your other job you could always stick to 40 hours. If you go to 50 your stuck at 50.

<comment><AUTHOR> My primary job is in Software and my second job is at a restaurant.

I get paid over $12/hr at my second job plus tip shares -- on average it's about $50 in tips per shift and on weekend close to $100 on tips.

I make about $20/hr at my primary job, but with the "raise" I'd be making less per hour. I like my job, but I don't like this offer much.

</comment></comment><comment><USER5> Why would it go up more than 25% for 25% more hours? Did you mean the 22% you stated originally? If you work 25% more, you should make 25% more, seems pretty simple.</comment>


METAFONT (1984) - <AUTHOR> http://tug.ctan.org/systems/knuth/dist/mf/mf.web <comment><USER2> The .web files aren't meant to be read raw; you should instead read the typeset version ([http://texdoc.net/texmf- dist/doc/generic/knuth/mf/mf.pdf](http://texdoc.net/texmf- dist/doc/generic/knuth/mf/mf.pdf))

Even better to read from volumes C, D, E of the _Computers and Typesetting_ series ([https://cs.stanford.edu/~knuth/abcde.html](https://cs.stanford.edu/~knuth/abcde.html)). Specifically in this case, Volume D ( _METAFONT: The Program_ ) — the mini- indices on each page spread are useful if you're trying to understand the program, and they're missing in the typeset PDF (above) that you can get with weave.</comment>


I bet you didn't know that you could read music - <AUTHOR> http://www.noisemademedoit.com/you-can-read-music/

<comment><USER2> this was posted on reddit 5 hours ago >.> [http://www.reddit.com/r/funny/comments/y1o5y/bet_you_didnt_k...](http://www.reddit.com/r/funny/comments/y1o5y/bet_you_didnt_know_you_could_read_music/)</comment>


Launching the 2017 State of Crystal Survey - <AUTHOR> https://crystal-lang.org/2017/07/31/launching-the-2017-state-of-crystal-survey.html <comment><USER2> Amazing language and maybe the future of Metasploit :)</comment>