
Make the Web Work for Everyone - nachtigall
https://hacks.mozilla.org/2016/07/make-the-web-work-for-everyone/
======
danso
As a anecdata-point, Stanford's CS 142: Web Applications course was previously
focused on Rails, now it teaches a MEAN stack:

[http://web.stanford.edu/class/cs142/](http://web.stanford.edu/class/cs142/)

It requires students to test on Chrome:

> _Unfortunately, Web browsers are still not 100% identical in their behavior,
> so Web pages may behave differently on different browsers. For this class,
> the reference browser is Chrome: your project solutions must work on Chrome,
> and the CAs will use Chrome to test them. Your solutions need not work on
> any browser other than Chrome. You may use a different browser to develop
> your solutions if you wish (Chrome, Firefox, and Safari all have very
> similar behavior), but please test on Chrome before submitting. We do not
> recommend that you use Internet Explorer for development: historically, its
> behavior has been quite different from the other browsers, so things that
> work on IE may not work on Chrome, and vice versa._

I have mixed feelings on this. Sure...open web, and everything. But in
academia, Chrome is one of the more ubiquitous dev environments to be used...I
remember being locked into Visual Studio. And purportedly, the class isn't
just about job skills...it's attempting to teach HTML/CSS/HTTP/JS to students
who may have not had real exposure to any of those concepts, on top of
Angular/Mongo/Node/Express. Restricting the environment allows at least for
more consistent instruction/grading.

~~~
AndreyErmakov
Not the first time that I see academia teaching their students the wrong way
of doing things. I had to work with some graduates with certain strange ideas
about approaching the work and tried to teach them an alternative, at least
open their eyes and consider the possibility that what they are doing might
not be the right way. Tough job. Sometimes it feels easier to hire somebody
with no programming skills and teach them from scratch than to change the
mental pathways of stubborn graduates.

On that note, my experience has been that academic environment often does more
damage than good to its students. It sometimes takes a monumental effort to
make the graduates unlearn all the wrong things they learned in the academic
environment before they can proceed further in their professional development
without all that bad baggage that keeps pulling them in the wrong direction.

It's like children mistreated by their parents in their youth who will carry
their psychological trauma from the childhood through the years and that would
detrimentally affect their lives until they get some professional help from a
skilled counselor.

~~~
danso
I currently work in academia so I'm obviously biased, but I'll argue that
wrong things learned in college is quite a bit different paradigm than child
abuse. Hard to unlearn child abuse, it seems.

~~~
AndreyErmakov
The long term effects may be just as devastating.

Consider that as a lecturer every your word will carry a meaning. Even an
innocuous remark may turn out to be something that will stick with one of your
pupils for years and will lead them to make a sequence of wrong decisions that
will eventually ruin their life.

Having access to younger minds and influencing their personal and professional
development is not a joke. It's that kind of a job which if not done properly
may potentially produce the next tyrant.

~~~
tonyarkles
As a solid example of this... A fellow student was working on a problem that
had a key-value mapping, but instead of storing them in a hash
table/map/whatever the language wants to call it, he was storing them as pairs
in a list and complaining about the performance on a large data set.

I asked him why he wasn't just storing it in a hash table instead. His answer:
"Because I sometimes need to iterate over it and get both the key and the
value"

My brain had to sit and parse what he'd said for a few moments, before I
realized what the heck he was talking about. In all of the data structure
courses, he'd been taught "A hash table hashes the key, and stores the value
in the corresponding slot". In that mental model, there's no way to retrieve
the key, only to retrieve the value given the key.

I explained to him that real-world implementations do do that, but also store
the key along-side the value, so that you can still iterate across it. You
could see the look of amazement wash over him, and then he frustratingly
declared "Why the hell didn't they mention that?!"

~~~
magicalist
What does that have to do with academia? That's just having an overly
simplified mental model of something, which all humans do when learning any
new thing, whether through a lecture, a random stack overflow question, the
compiler manual, or through pure experimentation.

~~~
AndreyErmakov
Academia carries with it a larger amount of authority than a random
programming forum. Students have the expectation that the academic staff is
generally knowledgeable and wise and what they say in all probability is very
important, has to be remembered and followed (even if you don't quite
understand why yet but perhaps you will in the future).

~~~
type0
I don't think "Academia" that doesn't teach critical thinking and only
practices its authority over students should be called academic institution.

~~~
AndreyErmakov
I agree. And yet, this seems to be the rare type. Often it's just a few people
in the staff that are trying to do things the right way, for the others it's
simply a nice job (with few responsibilities and seemingly no obligations).
That's what I've been trying to get across. Teaching is a sensitive job with
far-reaching consequences, yet more often than not people don't take it
seriously and don't care what their students will carry with them into the
life when they leave the walls of that academic institution.

------
nathancahill
Bravo! As a Firefox user, the trend of web developers only testing in Chrome
(and ending up using features that only work in Chrome) is getting really
annoying. Most of the time, the fixes are really simple, like including more
prefixes than -webkit.

Very happy to see Mozilla raising awareness around this issue.

Personally, I have Firefox and Chrome open side by side for development. If
those two work, Safari and Edge generally will too. I'll add IE specific
rules/hacks afterward.

~~~
AndreyErmakov
I didn't realize Chrome was becoming the default testing environment. I find
it weird, given its terrible font rendering. I tried using Chrome but just
couldn't. Smaller size fonts render weak, pale, bleak, like drawn with a dull
pencil. I found it rather difficult to read large bodies of text in Chrome
which was giving me quite a bit of eye strain. Not sure why anyone would want
to test their pages in that in my opinion broken rendering engine.

I'm aware there is a setting which has to do with subpixel rendering or
whatever this is called, I tried switching it on and off for no perceivable
visual change. So I gave up on Chrome.

IE also has had broken font rendering since they moved to subpixel rendering
several years ago, but at least it draws fonts in a strong and dark fashion
making them more readable than in Chrome.

Personally, I design for Firefox which I consider the gold standard of web
development. Then, at some intervals I check if things are okay in IE and
Chrome and usually they are fine. Chrome was useful once in helping me spot
some sort of a race condition, its developer tools also conveniently allow you
to quickly bypass caching for testing purposes, but other than that I found it
useless and unusable.

~~~
ivank
You're probably seeing this bug
[https://bugs.chromium.org/p/chromium/issues/detail?id=146407...](https://bugs.chromium.org/p/chromium/issues/detail?id=146407#c155)
and it is indeed a sad story, especially because Chrome 21 worked just fine.
Then they rewrote some gamma correction code in the Skia that shipped with
Chrome 22.

~~~
AndreyErmakov
Thanks for the link. Based on some of the screenshots posted over there it
indeed looks like what I've been observing on my machine (version
47-something).

Not a problem really. Never used Chrome before. Only installed it out of
curiosity and also for testing purposes. Within the first day of using it on
my development machine it became clear I wouldn't be using this piece of
software in the future either.

------
AndreyErmakov
If I may contribute to the article somehow, I'd tell people this: stop using
JavaScript for basic markup. I sigh every time I visit a site whose entire
navigation structure is spit out in front of me as a disorganized wall of
text, and only when I enable JavaScript that mess gets cleaned up and arranged
back into something organized. It's just no way to design pages. CSS is for
visual appearance and styling. JavaScript is for interactivity. If you can't
give your site a proper look without resorting to JavaScript then you have no
business designing web pages yet and need to go learn the basics first.

~~~
tomjen3
Thats because CSS is not powerful enough, not helped that you can't use
something like flexbox if you need to support old browsers but even the latest
version of $YOUR_BROWSER does not have a way to say that I want a list element
to layout its elements in one vertical column that is also centered vertically
on the screen if it has fewer elements than there is space for on a screen,
but having it split into additional columns and align all elements in all
columns to the top if there are more elements than space on the screen. It is
a fairly simple layout and I ended up having to do it in JS because flexbox
only has a few standard modes for what to do when the content overflows and
those don't effect the margins of the element.

CSS needs to be replaced with a more capable scripting language, or at least
one based on constraints but until that happens we are stuck with javascript.

~~~
wwweston
> Thats because CSS is not powerful enough

This kind of objection is totally missing the point.

And this isn't an argument that CSS doesn't have painful limits (it does) or
even about what constitutes "enough" (within its limits, CSS offers enough
possibilities that your own ideas of what the app "should" be like may be as
much as a limit as the problems of CSS are).

The power of CSS is largely orthogonal to the underlying issue.

Ideally, your web site/app is still usable even with every last stylesheet
completely ignored. It should work with Lynx, or with entirely non-visual user
agents (screenreaders, search bots, Siri etc).

CSS should enhance via layout and other presentation rules where that's
possible.

JS should provide more convenient application behavior where that's possible.

Instead, we've slipped into a space where the browser (and, frequently enough,
_one_ browser) is simply considered The VM That Lived™, just another runtime
target. And that's a sign of its growing power, and that power isn't a bad
thing because there are in fact some applications that don't fit the
hypermedia model well and the browser's ability to play the just another
runtime role opens a space for them. But the rush to get into that space is
considerably overdone and apparently executed without a lot of awareness of
what's been lost in moving that way.

~~~
softawre
If my users care about and/or use Lynx that I will support it. Until then,
it's just a feature that doesn't have the ROI to invest in.

~~~
wwweston
Sure, sometimes you have to make tradeoffs for what you have time to invest
in.

But this isn't really about supporting the world's Lynx users specifically.
There's a reason I put a whole class of non-mainstream UAs in there (and in
particular Siri, given how likely it is that _entirely non-visual UAs_ are to
become more mainstream at some point, perhaps soon, on top of the awareness
that intermediary UAs like GoogleBot are of course ubiquitous and clearly
important). And which UAs you try to support has a chicken and egg effect on
which UAs get employed as intermediaries in accessing your site/app... and
therefore which UAs you think you see using it. Usage follows accessibility
perhaps even more surely than accomodation follows demand.

If that weren't enough, the decision to do the things that would mean that
your site is usable in Lynx is not _just_ a feature -- it's also a technical
decision. And like other technical decisions (database, language, library,
application architecture, idioms and patterns you use, and data
serialization/interchange format... which is actually part of what this
decision actually _is_ ), it matters to how well your product performs and how
tractable it is to develop and maintain, as well as how widely it can be
consumed.

If you're having to make cold hard decisions about ROI for features, chances
are decent that you're better off for thinking about whether it works in Lynx
and why, even if not one single user visits with that specific UA.

------
niftich
For a long time in the early 2010s, Chrome had superior developer tools built-
in, while Firefox needed addons like Firebug and the Web Developer Toolbar.
While these addons were good, you needed to know about them and download them
separately, whereas Chrome shipped with better out of the box.

It took several years for Firefox to catch up [1], and in that time, Chrome's
market share exploded, and Chrome's underpinnings V8 and Webkit found new uses
outside of Chrome. Furthermore, Firefox was late to Android, where the Android
Browser, and later Chrome dominated.

Part of the problem is a website/webapp developed and debugged using Chrome
will work with Firefox more often than not -- so some people have been
cultured to not even bother checking it in Firefox. Ironically, if more things
broke spectacularly, more people would test in another browser.

This PR effort is nice, but it won't reverse the tide on its own. However,
once Servo is released and sees use in an embedded setting, developers will no
longer be able to get by without developing (or testing) on a Mozilla engine.

[1] [https://techcrunch.com/2013/03/18/mozilla-promises-to-
improv...](https://techcrunch.com/2013/03/18/mozilla-promises-to-improve-
firefox-developer-tools/)

~~~
chriswarbo
> For a long time in the early 2010s, Chrome had superior developer tools
> built-in, while Firefox needed addons like Firebug and the Web Developer
> Toolbar. While these addons were good, you needed to know about them and
> download them separately, whereas Chrome shipped with better out of the box.

I agree regarding the relative quality, but developer tools have no place in a
default Firefox install; the whole point of Firefox was to streamline Mozilla
by moving as much as possible to plugins. It's unfortunate that they've
recently started bundling stuff again (developer tools, PDF reader, pocket
(whatever that is), etc.).

> Chrome's underpinnings V8 and Webkit found new uses outside of Chrome

To be clear, WebKit came from Apple (as a fork of KDE's KHTML), so this wasn't
really due to Chrome devs; they were just part of the WebKit bandwagon.

Gecko (Firefox's rendering engine) was already quite widespread before Chrome
existed, e.g. it was/is used in Gnome and GTK programs (Epiphany for sure, and
I assume other HTML-consuming applications like Liferea); similar to the way
KHTML is used in KDE programs, although it was more painful to integrate. Some
of these programs were cross platform, so may have had a reasonable userbase
(I don't know; I've used Linux exclusively for about 15 years).

Programs based on the XUL toolkit presumably had a much larger installed base;
e.g. Thunderbird, RSSOwl, Songbird, Miro, etc.

I didn't notice any conspicuous users of Mozilla's Javascript engine except
for Gnome 3, although there were other JS engines around for those who wanted
them (e.g. Rhino for JVM applications). V8 certainly opened the floodgates for
embedding JS though; I think I first started treating JS as a serious language
when the D8 repl came out; node.js followed quite soon after.

> Furthermore, Firefox was late to Android

Well, Chrome and Android are both Google projects; we could say that Chrome
was late to FirefoxOS ;)

> Part of the problem is a website/webapp developed and debugged using Chrome
> will work with Firefox more often than not

This is tricky; when I was doing Web dev around that time, I'd do a quick
checking in FF or Chrome (whichever I had open) to spot glaring problems, then
switch to IE6 for my serious testing.

~~~
niftich
> but developer tools have no place in a default Firefox install

Completely agree! But the fact is, Google shipped them anyway, and so people
began using them. Now Firefox has to live with the (unintended) consequence of
their decision.

> Well, Chrome and Android are both Google projects; we could say that Chrome
> was late to FirefoxOS ;)

Sure, but marketshare! My point is, Mozilla is doubly disadvantaged by having
to battle against a vertical entity (Google), AND also being very late to the
game on that platform.

> I'd do a quick checking in FF or Chrome (whichever I had open) to spot
> glaring problems

I'm pretty sure this is what most people do, and that's the problem, because
most of the danger is from stuff that's only subtly broken, that a quick look
won't catch. The non-web world has automated tests to help with this. Maybe we
need tests that can run inside the browser script engine to test our webapps.

------
vanderZwan
Speaking of accessibility: the "tota11y" bookmarklet by the Khan Academy
people is a useful tool to check your website

[http://khan.github.io/tota11y/](http://khan.github.io/tota11y/)

~~~
bostonvaulter2
That looks really cool. I don't think that accessibility will get too much
traction unless the tooling for checking it is much easier.

As a side note I wish that there was a link to "installing" tota11y near the
top of that site.

------
Aoyagi
And ironically enough, whatever they use to set width of the text doesn't work
for me.

Web working for everyone is easy, you just don't add crapton of pointless
script bloat and use what's been working for decades - unless you need to do
something special, but then you can't expect it to work for everyone.

~~~
CaptSpify
This is what's so frustrating to me. A perfectly working web is _easy_. Most
sites actually put more effort into making it work _less_. This is insane to
me. Keep it simple and minimal (in size, features, frameworks, etc, not "lots
of whitespace") and it will work for more users. Most sites are _not_ special
snowflakes. There are exceptions where lots of formatting/scripting needs to
happen, but most sites are better off without.

~~~
nathancahill
[http://bettermotherfuckingwebsite.com/](http://bettermotherfuckingwebsite.com/)

~~~
kps
Yes, but — as soon as _Cascading_ Style Sheets existed, browsers _should have_
had a sane base so that
[http://motherfuckingwebsite.com/](http://motherfuckingwebsite.com/) looked
like
[http://bettermotherfuckingwebsite.com/](http://bettermotherfuckingwebsite.com/)

~~~
patates
There comes the question, why not go a bit further and make it like
[https://thebestmotherfuckingwebsite.co/](https://thebestmotherfuckingwebsite.co/)

And then we start displaying ads. Maybe add analytics? Probably a developer
with 300 stars implemented scrolling better in JS than the boring old native.
Then you look at the calendar and it's already 2016.

~~~
ploxiln
I was only familiar with the original, and enjoyed finding out about these
"better" and "best" variants. But I'll note:

[http://bettermotherfuckingwebsite.com/](http://bettermotherfuckingwebsite.com/)
is really quite good, and it's a single 4KB request

[http://thebestmotherfuckingwebsite.co/](http://thebestmotherfuckingwebsite.co/)
is 19 requests, 1.37MB, and the appearance and functionality are terrible

Yeah it's what everyone does these days, but it's everything I hate about the
"modern" websites:

    
    
      * it shows no content without scrolling
      * full background photos with no relationship to the content
      * gratuitous transitions and layout changes
        with only the most tenuous relationship to the content
    
    

There's also a link to
[http://evenbettermotherfucking.website/](http://evenbettermotherfucking.website/)
which cuts the contrast too far, but otherwise is fine, and only 5KB.

So really, the "best" variant is not "a bit further", it's a full
hop/skip/jump into the deep-end of "modern" anti-patterns

------
awalGarg
Is there any research about whether users prefer web "applications" (SPAs and
everything related) or good old web pages?[1] Hackernews and sites similar to
this work on pretty much all browsers and devices. So, other than clients
wanting to put big CSS banners and animations and using bootstrap and The
Theme™[2], is there any valid reason to intentionally bloatify a page?

Edit: Sorry for not being clear, I meant websites where SPAs are _not_
required, and plain old websites would do. In other words, do users
(unconsciously?) prefer eye-candy over readability?

[1]: The benefits which users will prefer "applications" for like progressive
enhancement with offline first thingy isn't here yet, and virtually no one is
using it in real life. So please don't count on that yet. [2]:
[http://adventurega.me/bootstrap/#](http://adventurega.me/bootstrap/#)

~~~
thedz
I think it's going to vary wildly to what the website actually does. Something
like Gmail or Slack? I'm probably going to be happier with a (well-
constructed!) SPA. If managing state across things is important to the core
functionality of the site, then use the paradigm that's appropriate.

~~~
stephengillie
The ticketing part of Zendesk is a tabbed SPA of sorts, while the help center
is a wiki-style set of webpages. It works well.

------
makecheck
Everything in the web technology stack has been intertwined to the point where
incomplete browser support for some JavaScript API could cause a bug with any
level of severity, ranging from “site is ugly” to “nothing works at all”. (And
it drives me crazy when some site can’t even show me a critical _button_
because of its fanciness.)

There needs to be more work separating a critical base set of features from
the rest. There needs to be more separation of the fancy from the functional
(i.e. instead of requiring some bizarre mixture of JavaScript support in order
for anything to look right, you have two choices: “turn on animation support”
or “turn off animation support”, or some such division).

------
Animats
Maybe we should go back to XHTML and get serious about syntax enforcement.
Suggested XHTML 3 rules:

\- Everything is UTF-8.

\- All tags must balance and nest properly.

\- Any syntax errors or JavaScript errors generate a visible error message for
the user telling them the site is broken. Then everything renders in the
default font with default formatting.

\- When something goes wrong, the site gets a HTTP PUT request with an error
report, so sites can tell this happened.

That last feature would make it possible to fix things.

~~~
euyyn
> Any syntax errors or JavaScript errors generate a visible error message for
> the user telling them the site is broken.

This would make users not use the browser that implemented it.

> When something goes wrong, the site gets a HTTP PUT request with an error
> report, so sites can tell this happened.

If I bother to implement a handler just to get error reports from browsers, I
surely took first the easier step to open my website in such a browser to
check how it looks.

~~~
Animats
The parent article says that users leave the site, not the browser, when
there's a problem.

If some ad code or third-party Javascript library blows up, your site may
never know.

------
defied
Making sure a website works for everyone is exactly what the company I'm
working for [1] is focussing on.

We run a large grid of all different browsers, both old and new versions. You
create a test where you verify certain aspects of your website and then run it
on all these versions on our grid.

With the feedback we provide (screenshots/videos) you can fix any issues that
may have come up across different browsers/versions.

[1] [https://testingbot.com](https://testingbot.com)

------
bcheung
While I understand and agree with what the article is saying, I think a
primary driver for other browsers catching up was that they were forced to
because developers refused to spend the time dealing with quirks and browsers
that didn't correctly implement standards.

Necessity is the mother of invention.

If developers catered to the other browsers like they used to we wouldn't have
seen the dramatically improved compatibility we now have.

------
mark_l_watson
Good article. Web standards and portability should be a much higher priority.
A little off topic, but I like to use Chrome for anything touching Google,
Facebook, and Twitter, and use Firefox for everything else. Another good
practice is setting browsers to delete all cookies when the browser shuts
down. With password managers, this is not much of a nuisance, and makes me
feel like I am getting extra privacy and safety.

------
greenshackle
"it was found that there are more hard of hearing users in the United States
than the population Spain and more users who are blind and low-vision than the
population of Canada."

Really? There's more than 35 millions internet users with vision impairment?
The previous section says there are 8 million people with vision impairment in
the USA.

~~~
Sgt_Apone
If they include world-wide users, I can see 35 million users being a
reasonable statistic. If we're talking about just the USA though, depending on
the definition of "blind and low-vision," I found figures between 8 million
[1] and 22.5 million [2].

[1]- [https://nfb.org/blindness-statistics](https://nfb.org/blindness-
statistics) [2] - [http://www.afb.org/info/blindness-statistics/adults/facts-
an...](http://www.afb.org/info/blindness-statistics/adults/facts-and-
figures/235)

~~~
greenshackle
They mean in the USA, it's based on a misintepretation of the graph below the
quoted phrase, or on poor wording on their part.

The graph says there are as many vision-impaired American internet users as
there Canadian internet users - not the entire population - around 20-25
millions (the graph is hard to read). I'm sceptical of that number because it
suggests ~10% of the USA is vision impaired, seems too high.

Anyway the only reason I care is that I'm Canadian ;)

~~~
Paul-ish
If the numbers include older people who undergo the usual loss of near sight
vision, it isn't so hard to believe. I think a lot of web developers are young
and forget that older people use the internet and that older users may have a
hard time seeing the small font some webpages use.

------
jay_kyburz
Yeah ok, but am I supposed to find workarounds for your bugs to support your
browser? Or should I just tell users we don't support firefox until the bug is
fixed?

My website has a position:fixed canvas area that works in every browser except
Firefox. For firefox I have to re-apply the fixed property regularly for it to
sick, otherwise the canvas scrolls with the rest of the interface.

The bug is logged with Mozilla, but nobody over there cares. If they don't
care, why should I care?
[https://bugzilla.mozilla.org/show_bug.cgi?id=1258911](https://bugzilla.mozilla.org/show_bug.cgi?id=1258911)

~~~
endemic
Your users.

------
taf2
I really believe Mozilla, Google, Apple, and Microsoft should consider working
together. A single open source code base - rendering engine would be a better
result for the web than multiple competing engines. The linux kernel takes
contributions from thousands of organizations and it's true we do have BSD and
it's great - linux as a unified open source code base serves everyone better
than when we had multiple fragmented unix variations. There will always be
room for experimental rendering engines and JavaScript runtime engines. But
having a unified rendering engine and even unified JavaScript engine IMO would
be a huge advance!

~~~
ocdtrekkie
I recommend looking up the term 'software monoculture'. What you're talking
about is, at least in my opinion, one of the worst things that could ever
happen to the web, and already unfortunately, a serious risk with the
prevalence of other browsers also being Chromium-based.

Competition in the software space is what encourages innovation to happen.
Problems being tackled in different ways by different groups often leads to
the best solution being found among them.

~~~
Rezo
The corollary is that after a best/good-enough solution is found and the
underlying platform unifies and stabilizes, most of the innovation moves up in
the stack. Things that used to be important and hotly debated become mundane
things that you can rely on simply being there, a new space then opens up for
new types of software to compete in, and the pattern repeats.

See hardware architectures -> operating systems -> browser engines ->
frameworks -> services etc. The first two are effectively fully commoditized,
few people get excited about them anymore, even as Linux development is more
active than ever. Similarly the browser engine is now entering the unification
phase, with Chromium swallowing competitors. Meanwhile the battle to define
how higher level components are created on top of the browser is in full swing
with rapid innovation.

~~~
ocdtrekkie
Lack of choice in hardware architecture and operating systems, particularly in
mobile, is a huge issue, and I'd argue, a poor support for unification being a
good thing. It's pretty hard to get a device that isn't running Android and a
Qualcomm processor, other than an iPhone.

As Google becomes more of a looming threat on privacy, the idea that they win
in the mobile space and the browser space, and we suggest that nobody should
compete with them is a terrifying situation.

------
return0
Not to mention respect for meta-standards. Trying to parse RSS feeds is an
impossible job. Let alone the RSS/atom dichotomy, nobody respects the
standards, or purposely violates them.

------
lllorddino
> Millions of websites have compatibility problems on one or more of the major
> browsers, leading to a poor user experience.

Can we just let these older browsers die out by not developing for them?
Surely the users using them will update once every website they visit is
broken.

Personally I only add the html5shiv and make HTML5 elements display block.

------
ngrilly
> The 18.2% of IE users running IE8 are on a browser that Microsoft no longer
> patches

Where does this figure come from?

~~~
bigger_cheese
I don't find this all that surprising. My work transitioned to IE 11 late last
year - we were running IE version 8 before that.

I work for a large company. Opposite of agile. A huge chunk of the people who
work here are non-technical. Most machines are heavily locked down and users
do not have permission to install their own applications. Upgrades (like
changing versions of the browser) are rolled out from our Information Services
department. I imagine there are many many "large corporate" environments
around the world which have similar application policies to us.

The transition to IE 11 was was not all that smooth a large number of internal
sites broke (including our intranet which runs Microsoft's own SharePoint
product). Even today some months after upgrade some sites still behave oddly
and you have to go through the enable/disable "Compatibility Mode" dance to
get some sites to wok correctly.

~~~
ngrilly
I know that :-) I still had to maintain and test our main application for some
corporate users running IE 8 until a few months ago. And I can still see some
IE 8 (less than 0,5 %) visiting our main public website. But it doesn't
explain where does this figure come from. The percentage seems really high,
compared to stats I've seen elsewhere.

------
datashovel
When I think about this problem, I feel like there are 2 major priorities that
tug from different ends of the spectrum on this issue.

1) I want innovation. I want new features for the web. I don't want innovation
to be hampered by the priority of making features cross-browser compatible.

2) I want cross-browser compatibility. I don't want to have to develop N apps
(N representing the total # of browsers my website / app supports).

Personally I don't care if X browser has feature Y. As a developer, if I find
a feature I want to program into my website / application, I don't want to
have to wait for N-1 other browsers to implement this feature before I start
using it.

I want to be able to "declare" or send a "hint" in my HTTP headers (or meta
tags?) telling the browser that my site is supported by X,Y,Z browser engines.
Each browser would implement a bare bones interface that decouples the
"chrome" of the browser window from the "application" window, and makes the
application window interchangeable (plug n play) with other browser engines.
This would make browser engines interchangeable without requiring a user to
close one browser and open another.

Granted, if a user doesn't have browser engine 'X', and refuses to download /
install it, that's my loss as a developer / website owner. Or of course I
could write some graceful degradation into my app / website. Already I hear
some folks saying "but this is what we do now". Not quite. It's a subtle but I
think important difference. Most people are willing to install (or already
have installed) all major browsers on their computers. The point is, currently
we must develop for / test for all major browsers to get the desired reach (or
to prevent a user from having to switch browsers). This alternative approach
moves the needle when a user installs a browser, not when they use the
browser. So if there are a substantial # of people who have both Chrome /
Firefox installed on their computers, but 'X'% of those people regularly use
Firefox, I can still develop ONLY for Chrome and still get the desired reach
into the world's population who have internet access.

There are of course going to be pros / cons no matter what you do, but given
the above priorities, and the predispositions of all actors involved (web
browser developers, web browser users, website / web app developers) I really
think this is going to be the most scalable, least intrusive / obstructive
path forward.

------
reitanqild
Dear AndreyErmakov,

I agree with a lot of what you say but I won't upvote a comment that compares
bad practices in academia to child abuse.

For the kids that are beaten, burned, neglected, abused etc: please change
that.

~~~
AndreyErmakov
Dear AnonymousUserWhoLikesToHideTheirName,

That's just hilarious. For as long as I'm saying things that conform with the
majority's opinion, I will be upvoted. But when a have a different opinion,
then I will be downvoted until I censor myself back into conformity. Is that
how things work here, on Hacker News?

Have you by any chance heard of concepts like pluralism of opinions, freedom
of expression and that sort of things? I'm not sure where you come from, but
in some parts of the world people are freely able to have a civilized
discussion around complex and sometimes controversial matters. You may
consider going abroad, living there for a while and learning how a liberal
society works. Will be a great help to you.

~~~
reitanqild
As said, I agree with the ideas, it just so happens that that _one_ comparison
seems to overshadow the important parts of your message.

BTW: I did _not_ downvote you.

~~~
AndreyErmakov
What if it happens to be my opinion, the way I view things? I should be able
to express it, right?

I can't really crop my ideas if some parts of them are not well received. They
come as packages, I either tell what's truly on my mind regarding some matter
or I don't tell it at all.

If I can't say what I mean, then I can never mean what I say. And then the
entire dialogue becomes meaningless.

------
richev
The layout of that page is borked in IE11 - the text takes up a narrow portion
on the left of the browser window.

Not much better in Chrome where the body of the article is not-really-centre-
aligned.

In IE the search box is also of insufficient height, meaning that lower
portion of the watermark text is not visible.

Maybe the author was being ironic.

~~~
Etzos
I can't comment about the IE situation but the page looks nearly identical in
Chrome for me.

I don't see any alignment issues at all actually; the text is _supposed_ to
sit just to the left of the center of the page.

------
kome
Am I really seeing this debate again? Really, fuck you web professionals. In
2005 this debate was over, and the standards were understood as positive,
accessibility was recognized as important.

Now what we have got is again proprietary code, app just for smartphones, and
one browser taking over all the others. Bravo. Great progress here...

I wish the web could stay open.

~~~
AndreyErmakov
Actually, the web is more open than it was a decade ago. Back then I had to
use IE-only tricks to make my pages look okay in IE. Today I don't care
anymore. It's been several years since I last used an IE trick, and I have no
plans of using tricks specific to other browsers in the future. If something
doesn't work out of the box in all browsers, I consider this functionality not
implemented and do not use it. That's something you could do too and educate
others to approach it the same way.

~~~
davegauer
You are both absolutely correct. It's better than it was AND we have to be
very careful to keep it that way.

I use the exact same strategy you do: if the feature doesn't work in all
browsers, it's not ready yet and I don't use it. It can be painful, but I will
NEVER AGAIN use browser-specific tricks or hacks because I remember a time
when we pretty-much had to.

