
I Used the Web for a Day on Internet Explorer 8 - daledavies
https://www.smashingmagazine.com/2019/03/web-on-internet-explorer-ie8/
======
nostrademons
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.

------
thinkingemote
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).

------
davnicwil
> 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.

~~~
Konnstann
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.

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

------
ninju
>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)

~~~
chrisseaton
>> 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?

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

