The w3m test

I've managed to avoid writing complaints (or, rather texts which are not quite related to programming) for more than a year now. But everything comes to its end, so a lot of highly subjective criticism will go below.

1 Web standards

It's 2015, and we have formal and non-proprietary web standards supported by all the major browsers now, which is a great thing. Unfortunately, we also have browser-specific features, which are used outside of their experimental playgrounds, and browsers that don't complain much about violations of those standards.

Fun fact: it seems that most of w3c members don't pass their validation tests without warnings, and even some of w3c.org pages don't.

(There was a list of rants here, which got removed because there's nothing new: just the usual bloating, poor quality, common standards and guidelines violations, etc.)

2 Minimalism to the rescue

Though there probably is no "silver bullet", elegant solutions are often good, and good solutions tend to be simple, just as with plans. Clean code usually contains less errors, and clean markup – less opportunities for something to go wrong. Simple and elegant code usually doesn't try to be "smart" (to spare a user from thinking and decisions, that is), hence it's predictable; simple markup is usually used for minimalistic sites.

Minimalistic design tends to be accessible, easy to implement and to maintain, which helps to resolve many of the issues mentioned above.

2.1 GNU sites

By the way, though I have been inclined towards minimalistic designs for years, I never managed to understand why the GNU websites are so weird. They have their own guidelines (other GNU guidelines tend to be relatively strict, and to go beyond usual standards and requirements, too), but they don't really explain not-quite-eye-candy designs. Nevertheless, either because the web has changed, or because I have, now I prefer GNU sites' style to random ones, and it's a notable example of accessible design.

2.2 W3C guidelines

There are w3c accessibility guidelines, too. I don't think that many of front-end developers have actually read them though.

3 Introducing the w3m test

For the last few years, when I'm making a site (a hobby site, that is, which is possible to make nicely), I'm checking it with a w3m-alike browser (eww, links, lynx – doesn't really matter). Sometimes checking other sites with it, to sort-of-confirm the quality estimation I've made using a graphical browser, and it even matches most of the time.

If the site is usable in w3m, it doesn't rely on javascript to function – and hence there's a good chance that it's not bloated with javascript. It also probably doesn't rely too much on CSS for things like positioning, if everything isn't messed up in w3m. And it wouldn't be readable in such a browser if there were chunks of various additional content at random positions around.

3.1 Experiments (or examples)

Website My regular browser w3m with images in emacs
gnu.org fine, though not eye-candy better than in a regular browser
idris-lang.org good, maybe a bit overweight good
xkcd.com (same) (same)
Wikipedia, with formulæ (same) (same)
org-mode-generated (same) (same)
hoogle, hackage fine okay, usable
github.com laggy and glitchy crashes emacs
explosm.net designed for tablets, pretty broken horrible, not quite usable
trello.com barely usable, designed for tablets failed to login

4 Conclusion

I consider using w3m to actually browse the web; often it's not really worse than regular browsers (here is a screen), and there's not much sensible use of their advanced features nowadays: often they are used for communication, but there are IRC, XMPP and MLs for that.

Update (2017-07-26): plenty of websites are less broken in w3m than in FF with noscript and colors/fonts overriding nowadays.

Moreover, it looks like the websites that are made without accessibility in mind, and which abuse web technologies, rarely contain any useful information.