I suspect the problem might be some people at Cloudflare writing code for the checks who are not aware of how to make it work for most browsers, and e.g. demand/expect some header behaviour that's only seen in a small number of browsers (say, Origin:, which has been involved in the past). So the issue would manifest itself no matter the kind of approach involved. At one point, the issue was even that such a header behaviour was requested in the fallback code intended for other browsers, causing a redirect to step zero and a DDoS against Cloudflare.
I haven't tried to debug the issue yet this time, and I'm not sure I want to, because that'd be the (at least) third time I'd get deep into the network inspector to try to compare headers and identify the issue in the middle of obfuscated and/or minified JS, and a chain of requests that are probably intended to defeat this kind of analysis (making it more difficult to identify what is causing the issue). If this was one occurrence every two years or so and Cloudflare were willing to help, and receptive to comments about it breaking in some configurations, the matter would be different (one of the times, their support kept dismissing reports as "unsupported!" and it might have been solved only because someone from Cloudflare saw it here on HN).
On top of that, I'm dealing with a hardware issue that means I don't have enough memory to do the debugging comfortably now...
A sad thing about the Github situation is that, until some months ago, it was perfectly fine for browsing directory tres and clicking to view files on the web, all that worked without javascript. Now it doesn't, except perhaps for the top-level and its README.
That's a shame, I used that a lot for quick browsing, checking and/or comparison of code in repositories hosted by Github.
Some may even be just CSS. I'm still waiting for a way to toggle the CSS ones off for all websites, without breaking them.
These often even look sluggish, but maybe it is a relative thing and some see the prompt movement of UI elements as unpleasant and call the animations "smooth". Or maybe it really takes a very powerful GPU on the right hardware to fully experience animations without feeling annoyed? Or both?
> Regardless if you feel that the web was made only for documents it has become the only truly cross platform runtime you can always expect users to have installed. That's incredibly valuable. Why would we throw that away?
That's not much better than "everyone runs Windows" (but is a good way to view this). (And yes, you cover choosing an OS later in the post.)
What happens is that a select few browsers have what's considered at this point the runtime. So you are always leaving people out. Maybe the runtime price tag in itself isn't a problem now, but the hardware might be. The interface. And there will certainly be users who just want to avoid the low-contrast always-animating nature of some sites, for example.
Nowadays to me the environment is pretty much like Microsoft in the late 90s, early 2000s with their Windows+Office monopoly, and cultures that saw no problem is assuming that was available. But now, instead of these two, we're all expected to be running one of the select browsers that implement a recent enough version of the "living standards", and with powerful enough hardware and graphics acceleration.
But still, in some cases it has to be more complicated to make sites incompatible with other browsers and in the absence of javascript. Recently, I think I read something attributing trends in loading and rendering using javascript to the way Google ranks entries in search results.
> That's not much better than "everyone runs Windows"
It's absolutely better. It's open standards based instead of proprietary, all current engines are opensource, there are multiple implementations.
> select few browsers
There are three current engines, and I try https://ladybird.dev/ every now and then. It's gotten pretty good and proves that even with a small team you can write a browser that will work with many sites.
> And there will certainly be users who just want to avoid the low-contrast always-animating nature of some sites, for example.
You could make all of that without JS. I'm not sure why people keep conflating the language with the design decisions the website author took. Just HTML+CSS is enough to make all the badly designed sites you want.
>You could make all of that without JS. I'm not sure why people keep conflating the language with the design decisions the website author took. Just HTML+CSS is enough to make all the badly designed sites you want.
Yup, now days you can make pretty good animation site with out JS! Why are people insisting on using JS to be a criteria to see a web page? Could be that the some big players are using it to fingerprint users?
There are sites which load the content dynamically using javascript, there are even sites where this is done with the content already in the served HTML document, as JSON.
There are sites that blank the viewport until scripts change css rules or class names, or load stylesheets.
The latter is especially noticeable when such a site has absolutely no error checking or fallback and stops on some javascript error, leaving the page "blank".
IMHO you need to step back and consider that there are more views of design, you think some newer look is "more modern" and better in itself, you say "outdated past vision". But those concepts are subjective too.
I like the Modern SeaMonkey theme. I also like the look of the classic theme (not default, but the old default, sometimes called "XPFE Classic"). Not sure if just out of nostalgia or because it looks neat to me. What I value more is that SeaMonkey's looks are customizable. I don't know if it's customizable enough to make a theme that behaves in the way you prefer, but at least there is room for customization. (I'm mentioning this because I do think this is an interesting feature to have.)
So, please consider relativizing your position, it seems you're insisting on a bias against the design just because it is not recent enough, but also wording that as an absolute.
To me that sounds like people who say some train models "look old" and "have to be replaced" just because they feature Budd-style corrugated stainless steel.
That makes me wonder, regarding AOL/Yahoo/Verizon/... what's the story behind "8 BITMIME" and their mail server's broken 8-bit handling ([0],[1])? Did they just get server software with bugs in one of the acquisitions/mergers? Or is it some incompatibility or configuration issue comparable to the 500-mile e-mail story [2]?
(Note: I had no idea they hadn't fixed it yet (at least the utf8 part)... I tested just now, and, sure, it's still broken... currently it is operating in "State 2".)
that actually matches the timeline i described. it's already on mayer and Icahn destroying it. i think only senior left on mail was responsible for spam and nothing else.
User interface design is about designing interfaces that can be used by users.
You can prefer a style, you can customize it to your liking if themes are available (in this case, they are), but if you just replace the whole UI design field with "design is supposed to look nice", what you get might be an aberration. It might be pleasing to some people (but then still some, I really doubt you can find something that is universally pleasant?), but what good is that without being usable? Or if it makes usage much more difficult?
Bro design is supposed to be functional and ergonomic AND look nice obviously. Do you think I'm so dumb that I actually believe the first half of that equation should be left out? I was just pointing out how you seem to have absolutely no appreciation for the second half of the equation, which is tantamount to completely neglecting a huge part of what design is.
Distro build hosts and distro package maintainers might not be a bad guess. Depends on whether getting this shipped was the final goal. It might have been just the beginning, part of some bootstrapping.
The issue is on CloudFlare's side. It is possibly related to lack of Origin: or References: in a POST request that is part of the turnstile workflow.
On a previous occasion, their support staff kept telling people their browsers were unsupported, until the matter was noticed by someone inside CloudFlare, and the issue then got fixed.
This time, their response to Moonchild chalks this down to "suspicious activity" or some custom rule, but does not even mention any kind of browser version limit. No, what is happening (and I've tested this enough to be sure of it) is that they are requiring a behaviour that was only implemented in (for the mozilla codebase) Firefox 70.0, and it is failing for browsers that don't behave in that way.
Let me state it clearly: CloudFlare checks (at least those of "turnstile"?) are rejecting legitimate browsers and users.
CloudFlare may as well have decided they want to reject all but a few browsers - it's their business - but then they should clearly advertise this. Their potential and current customers should be clearly told entering a deal with CloudFlare means they are limiting their user base to those using CloudFlare-approved browsers.
In the past, what happened with their "browser integrity check" appeared to be an error on CloudFlare's side which required such a behaviour (in that case, the Origin: header had to be always present) from all browsers even in fallbacks clearly meant for browsers that did not implement such behaviour. Now is this the case here too with turnstile or has CloudFlare decided to significantly change the purpose of their "protections" to do more than just banning e.g. bots?
This is affecting at least SeaMonkey and Pale Moon.
Sadly comments like [3] are realistic observations here; as I said, it's not the first time this happens. At least the support conversation at [2] isn't full of "your browser is outdated" like [4] from 2022 (when Cloudflare's servers were requiring Origin: on all requests, which I think is also what the hackernews thread at [5] was about).
I haven't tried to debug the issue yet this time, and I'm not sure I want to, because that'd be the (at least) third time I'd get deep into the network inspector to try to compare headers and identify the issue in the middle of obfuscated and/or minified JS, and a chain of requests that are probably intended to defeat this kind of analysis (making it more difficult to identify what is causing the issue). If this was one occurrence every two years or so and Cloudflare were willing to help, and receptive to comments about it breaking in some configurations, the matter would be different (one of the times, their support kept dismissing reports as "unsupported!" and it might have been solved only because someone from Cloudflare saw it here on HN).
On top of that, I'm dealing with a hardware issue that means I don't have enough memory to do the debugging comfortably now...