Hacker News new | past | comments | ask | show | jobs | submit login
I Used the Web for a Day on Internet Explorer 8 (smashingmagazine.com)
21 points by daledavies 5 months ago | hide | past | web | favorite | 8 comments



Re: the Google results. Google uses another approach to backwards compatibility that devs may want to consider -

They branched the renderer codebase entirely, and then switch into the old renderer (which uses an API feed of search results that better be stable or else Google has bigger problems) for certain UAs. IE, non-evergreen browsers, and no-JS visitors get a renderer frozen in time in 2011; that's why it looks different from the current page. IE <6, pre-Mozilla Netscape, Lynx, WWW, etc. get a renderer frozen in time in 2007. Yes, you can still get the 10-blue-links experience if you set your user agent to Netscape 3 or something similar.

This has several advantages. Modern-day feature developers and QA testers don't need to think about ancient browser support - their code won't even be run by those browsers, and they aren't touching the code that will be run. Polyfills can be kinda hard to implement on really old browsers, they still run the risk of bugs, and they don't help at all if JS is unavailable. The usual downside of branching & copying code is the maintenance headache of keeping both versions in sync; this doesn't apply if one version is frozen in time forever and never maintained. It's relatively little work to generate this support (usually just need to branch the files, add in a if-statement, and ensure that backend APIs remain stable), and virtually no ongoing maintenance. Old browser users generally don't expect the latest & greatest features; if they did, they'd be on newer browsers. And old browser users don't pay the performance cost for new features, which can matter a lot when they're also on old computers and old connections.


I enjoyed looking at the examples and was impressed when he attempted to explain why they failed and how to correct them. Particularly when he used his employers website (the BBC).


> Someone in Asia is five times more likely to be using IE8 than someone in Oceania.

The above is based on 0.09% usage in Oceania vs 0.50% usage in Asia.

A bit off topic, but is that how statistics works? Like since the likelihood percentage is not on an absolute, unlimited scale but a relative scale I don't think it's meaningful to say that, is it?

I guess you can say that selecting a random person, you're 5 times more likely to pick an IE8 user in Asia than Oceania. But is it correct to say that a specific individual is 5 times more likely to use IE8?

I cant decide if there's a difference there, or if it's just a different way of saying the same thing.


I think you assume a random sample, because you can't say anything about a specific individual based on 1 aggregate statistic. If you pick a random person, that person is 5x more likely to be an IE8 user if you picked someone from Asia rather than Oceania.


On the stats page I wonder how many of the ie8 users are bots/scrapers with a user agent noone bothered updating.


>But by forcing TLS 1.1 or higher, some users will invariably be locked out

But that needed so that we can guarantee that their experience is secure.

Now maybe we should redirect to an information/explanation page if we auto-detect that they are configured to use an no longer supported TLS level (rather than the error page)


>> By allowing older, insecure standards and enabling users to continue to connect to our sites, we’re not helping them

> Yes we are because we are guaranteeing that their experience is secure.

I don’t understand - by allowing users to use insecure crypto we’re keeping them secure? What do you mean?


sorry I copied the wrong paragraph when first posted my comment and I have since updated my comment




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: