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.
Chrome breaks the Web
281–290 of 473 posts
Re: Chrome breaks the Web
#282Earlier quoted context omitted.
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…
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.
A few seconds of googling found quite a few prebuilt results. First one: https://github.com/faisalman/ua-parser-js
It doesn't have to be trivial to be worth doing.
Re: Chrome breaks the Web
#283This 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?
Re: Chrome breaks the Web
#284Earlier 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…
>The right thing to do is to bring the issue up with whoever is running the website What? No. Clearly it should never have been in the spec, and a browser should be the extension of the users desires.
> a browser should be the extension of the users desires.
In a perfect world that would be the case, because the browser would belong to the user. But how much did you pay for your last browser? Consider yourself lucky when the browser does something you consider beneficial.
Re: Chrome breaks the Web
#285Re: Chrome breaks the Web
#286> 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…
The real problem here is the fact that active listeners are still a problem to begin with.
It'd be absolutely insane if a native app did not get first crack at all input events. This is how they all work (iOS, Android, Windows - take your pick), and the mere existence of a touch/scroll listener is never a problem.
But on the web simply having a scroll listener is such a massive performance issue that it's worth introducing not just a new API to get events after they've happened, but to then make that the default? Why not just fix the performance problem instead of hacking and slashing around it?
Re: Chrome breaks the Web
#287Earlier 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…
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.
With evergreen browsers, that basically requires a dev team to adjust the code and release/deploy a new version every X months.
WHICH IS OKAY, if we're talking about security/privacy, but performance ... not really. Let the market (and the users) decide. If a site takes forever to load, and scrolling is impossible because it takes ages to scroll, and burns a mark in your palm in that time, then maybe you'll reconsider visiting that site ever again.
Re: Chrome breaks the Web
#288> 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…
This is just arrogance.
From a historical perspective, this is nowhere near the sort of behavior one saw from Microsoft in the 90’s, but that’s pretty faint praise - nobody wants anything like that to happen again. You shouldn’t have people contributing to competing products out of spite.
I hope we never hit the point again where it is a cliche for FOSS people to bond over shared hatred of a company. I’d like to think we have been inoculated against that. I like to see people who will speak up like this early and often.
Re: Chrome breaks the Web
#289Earlier quoted context omitted.
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.
A few seconds of googling found quite a few prebuilt results. First one: https://github.com/faisalman/ua-parser-js It doesn't have to be trivial to be worth doing.
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.
Re: Chrome breaks the Web
#290Earlier quoted context omitted.
In this case, the browser is the agent of those advertising to the user. It's not protecting your interests, it's protecting Google's interests. If it was protecting your interests, it would be a toggleable setting that defaults to normalized behavior.
> It's not protecting your interests, it's protecting Google's interests. But you can always install (or develop) another browser that might do this job better for you . > If it was protecting your interests, it would be a toggleable setting that defaults to normalized behavior. The problem with this view is that the vast majority of end users do not want, and in fact will never know about or use a new setting, and s…
Users don't use thousands of sites. If a site misbehaves and users want autofill on it, they should be able to override autocomplete=off for that site.
Google could even make an extension for this to allow users to gather and share a list of sites that behave in a user unfriendly way.
But of course, it was much easier to fuck up half of the Web.
Public choice and mandates are great for things that require cooperation and agreement against race to the bottom (like tax havens), not against autocomplete fucking off.