Hacker News Reader

Comment by thrownaway2424 | Hacker News Reader

FWIW, the statement about the superiority of Chromium does not match my experience. I certainly recall reading a page on mobile Chrome (iOS) under poor radio coverage and having the whole page replaced after a few minutes with an error about the page being not available.

View on HN

iOS Chrome is something like reskinned Safari under the hood, though, isn't it? It could very well be that desktop Chrome acts differently.

Right:

Apple’s App Store policies state: “Apps that browse the web must use the iOS WebKit framework and WebKit Javascript.”

This means that web browsers can’t implement their own rendering engines; they must embed a version of Safari’s rendering engine. They can’t offer a faster rendering engine or new web features. In effect, each third-party browser on iOS is a different interface around Safari.

http://www.howtogeek.com/184283/why-third-party-browsers-wil...

It's sad that after 20 years of the web, it still doesn't work properly. These kinds of bugs should have been solved years ago.

It's the cost of it working at all, at least in terms of it being as accessible as it is:

Making it feasible for people to create websites quickly enough to be worthwhile entailed allowing the tag soup non-standard HTML we see in practice now, and the confluence of desire and technical limitations made plug-ins inevitable.

A "better-regulated" Internet wouldn't have had the Web at all. Remember that, according to the people using it circa 1988, file transfer and hypertext were both solved problems, with FTP and Gopher respectively already in existence. Unstructured hypertext, something Gopher was not really designed for, wasn't especially desired until some random at CERN released WorldWideWeb and httpd to the world.

Parsing tag soup does not require reloading the page and displaying an error page when the network goes away.

This is actually a relatively new "feature" of web browsers. When I was a kid, if a page didn't load completely it would just make do with whatever assets it could grab. Images would be replaced with a stand-in icon and some descriptive text.

4realz are you serious? What is the actual downside of that? As a kid, it made perfect sense to me, and I often would right click the image and press reload or just refresh the whole page. Now whenever images don't load (which is often these days, since cloudfare blocks tor 90% of the time until you load the image in a separate window and fill out their captcha, and even without tor, wireless networks tend to be extremely unreliable), it's not easy to tell whether the page is broken, since it just collapses the spaces where the images would have been.

Further, if you directly view an image and it breaks half way, the browser will hide it and say it's corrupt (and have no "show anyway" button), unless the size wasn't provided, then the browser just thinks it's valid, despite that it could parse the JPEG file and find out that lines of pixels are missing. Calling either of these cases a feature seems very biased.

We aren't even talking about one of the worse problems, which is when a page fails to load, the browser doesn't try to reload it - you have to come back and press reload yourself. I've wasted literally hundreds of hours doing this.

Apparently there are people who think it's "aesthetically unpleasing", which doesn't make much sense to me either: http://forums.mozillazine.org/viewtopic.php?f=8&t=63343&star...

There's also this related bug which contains over a decade of discussion:

https://bugzilla.mozilla.org/show_bug.cgi?id=41924

I agree that it makes more sense to give the indication "here is an image but it couldn't be displayed" than to have them disappear completely.

Mobile Chrome seems to try to reload the page each time you focus out and in of the browser, change tabs, or whatever. Really terrible behaviour.

The main reason I use a custom android rom, to have firefox as my main browser and not have chrome as a system app.

Oooh, can we turn this in to general annoyances about browsers?

Frickin' Safari on iOS that won't render a page until whatever God-awful custom webfont the designer has specified has loaded. 1 in 20 blog pages I load in Safari load with invisible text, and it just ... hangs.

Yea, but luckily the reader view doesnt do that, as soon as possible ill switch into that.

4realz. For me (firefox on slow connections), those kinds of blogs just take seconds to load, then blank out for a few seconds, then the content is displayed again in a different font. Typically I'd be reading half way through the introduction and then the page turns blank. I usually just close the page at that point since those types of blogs don't typically have any useful information.

Chrome also likes to do the "blank out, then redisplay" stunt. Heh, I'd like a "slow connection" mode (maybe triggered by that "tethered" DHCP option on Android hotspots), which disallows custom fonts as well as images.

Reply on news.ycombinator.com