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

321–330 of 473 posts

Re: Chrome breaks the Web

#321

Post by Silhouette »

wereHamster wrote: post #133
KeitIG wrote: post #122

Earlier quoted context omitted.

Talking from the developer point of view here, not the user's: I'm expecting things to be working the same way they are documented in the manual. The changes some browsers have made to autoplay videos or alerts do not contradict what is in the manual.

What manual are you referring to? HTML5? That's a living standard, it evolves daily.

A living standard, in the sense meant here, is a contradiction. The entire point of industry standards is to create a stable foundation that everyone can rely on so they can build on top in a compatible way.

Re: Chrome breaks the Web

#322

Post by Silhouette »

sterlingfs wrote: post #162
saas_co_de wrote: post #84

Earlier quoted context omitted.

> 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 a…

I think many will see this as a type of tyranny, and therefore will be worried about the future implications of yielding authority to a single monolith.

Google have been doing something similarly questionable for a long time by dictating how sites have to be presented if they want to rank highly in the search engine. They're just being more brazen about it now by actually breaking sites in Chrome.

Re: Chrome breaks the Web

#323

Post by gw »

Klathmon wrote: post #317
gw wrote: post #314

Earlier quoted context omitted.

You're showing a pretty serious case of cognitive dissonance here. What previously was a theoretical problem was actualized with a real world example with actual affected users, and you've shifted to an entirely subjective argument that the breakage is "not integral to the application". You also chose to rationalize the breakage by shifting the blame to the victim -- they have "no business hosting anything themselves…

Reread my first comment. I pointed out that the breakage would be limited in scope. Very very few applications were broken by this (broken being defined as having it's core functionality unusable). And you seem to be completely ignoring the fact that the upgrade "path" is one click of a button. Whether you agree with my stance on the responsibility of hosting your own internet connected server or not, it's a one clic…

Against my better judgement I did a reverse image search and found the post that you found that screenshot from [1]. The post is full of people having exactly the sort of problems you would expect from an automatic software updater, along with instructions from Jeff on how to manually update using SSH and git.

These things happen. The world is messy, and whether due to technical inadequacy or run-of-the-mill software updater bugs, web backends will not always be updated. As you've noted, this could eventually lead to security problems, and I agree -- but that doesn't justify intentionally breaking their code. To say that their breakage is justifiable because they'll be 0wned at some point anyway is an absurdly darwinian argument.

To address your last question, the way you update a system like the web is exactly the way we always have -- accretion. With very few exceptions, websites from the early 90s still work today. We didn't remove the `table` tag when we introduced flex boxes. We add new APIs while preserving existing functionality. If you want to see a fantastic talk on this exact subject, watch "Stewardship: The Sobering Parts" by Brian Goetz [2]. It is well worth your time.

[1] https://meta.discourse.org/t/how-do-you-update-discourse/109... [2] https://www.youtube.com/watch?v=2y5Pv4yN0b0

Re: Chrome breaks the Web

#324

Post by pasbesoin »

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.

Re: Chrome breaks the Web

#325

Post by taneq »

UncleMeat wrote: post #304
ksk wrote: post #300

Earlier quoted context omitted.

How is breaking websites good for the user?

Adblock is "breaking websites". If a website is doing something crappy, I'd prefer to not have that crappy thing happen than experience the developer's true intent.

Adblock is opt in.

Re: Chrome breaks the Web

#326

Post by nashashmi »

UncleMeat wrote: post #304
ksk wrote: post #300

Earlier quoted context omitted.

How is breaking websites good for the user?

Adblock is "breaking websites". If a website is doing something crappy, I'd prefer to not have that crappy thing happen than experience the developer's true intent.

Adblock is opt-in. If the browser misbehaves because of an extension, the browser nor website is to be blamed.

Chrome cannot decide on a whim that old websites should be broken. It is not how the web moves forward. Take for example Firefox that kept breaking extensions with every update, now they have few compatible extensions.

Re: Chrome breaks the Web

#328

Post by jhasse »

nindalf wrote: post #88
mcv wrote: post #67

Earlier quoted context omitted.

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.

Its inconsistent though. I would also expect Chrome to disallow overriding the context menu for example or breaking the back button.

Re: Chrome breaks the Web

#329

Post by jhasse »

gkya wrote: post #151
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.

How does autocomplete=off affect password managers?

It would disable the builtin password manager.

Re: Chrome breaks the Web

#330

Post by extra88 »

mark-r wrote: post #280
bluGill wrote: post #89

Earlier quoted context omitted.

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 pil…

Are these the guidelines you speak of? https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver

The relevant bit being "Verifiers SHOULD permit claimants to use 'paste' functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets."

But that's a recent change to the NIST guidance. Searching for "Bill Burr NIST" will turn up recent stories about the original author's regret of a lot of the password recommendations from the original publication in 2003 that survived until the update this year.

Post reply on HN