Three years ago, I created the Pareto Browser Filter, a simple method for avoiding problematic browsers. Back then, it mostly just excluded IE7 and below, which had less than 20% combined usage but definitely accounted for more than 80% of cross-browser authoring pain.
The worst offenders with measurable market share today are IE9 and below and Android pre 4.3, which both have about 5% global share (sadly, IE numbers are much higher in a few Asian countries including China). Opera Mini (about 4%) is also missing some key features; however, its usage is mostly international, which means many US-centric developers were never testing on it anyway.
With those numbers in mind, we can construct a new filter aimed at reducing development pain:
The new test is much simpler, however it is slightly over-aggressive, covering just under 77% of browsers based on global share. Naturally, usage numbers can vary greatly by site, so the actual number depends on the audience. Fortunately, this percentage will only increase, and should increase to 80% in less than a year.
Back in 2011, even if with the filter you still had to worry about the old IE event model.aspx). You also needed hacky scripts in order to create decent responsive designs. In 2014, once you get over the pain of dropping a fifth of your worldwide audience, there are a bunch of fun browser features you can use without guilt (or polyfills):
Audio & Video elements
CSS Transforms (including 3D)
It’s tough to predict what the next version of this filter will be, since it depends heavily on future market share. Auto-updates in Chrome and Firefox mean new features can hit 50% very quickly. However, they’re held back by the much slower release cycles of IE and iOS.
With the release of IE9, this test passes for the current and previous version of all major browsers. Depending on which browser usage statistics you use, this covers 70 to 80% users. For that reason, I call it the Pareto Filter, a nod to the Pareto Principle a.k.a. the 80-20 rule.
Aside from serving as an effective filter for older browsers, these three pieces of functionality (especially querySelectorAll) are incredibly useful when building modern applications. Being able to count on fast, bug-free implementations saves a lot of headaches (and download time) for authors.
Once IE8 market share falls (which will probably take a while since IE9 doesn’t work on Windows XP), I look forward to adding document.addEventListener to this filter. IE’s non-standard event model has always been a pain when trying to write compact cross-browser code.
If space is a concern, you could drop the querySelector test. If you already don’t care about IE8, add document.addEventListener.
I’m happy to announce that the source code for the Treesaver.js Framework is now public. I’m still working on fleshing out the documentation, so let me know which parts are confusing or just require more explanation. The best place to start right now is the Walkthrough, a simple tutorial that goes through the steps of using Treesaver for some sample content.
My business partner in crime, Roger Black, has written up the history of Treesaver, describing how (and partially why) we’re on this crazy mission to change the world of online reading.
The response and interest so far has been fantastic, and it’s great to finally be able to talk about what I’ve been working on for the past several months.
We’ve been getting a ton of questions, and I thought I’d take some time to answer the most common ones.
What is Treesaver?
Why use HTML?
There are many reasons to use HTML, but the most important ones in our opinion are:
Lingua Franca of the Internet: HTML is supported by an incredible variety of devices, from expensive desktop computers to cheap mobile phones.
Linking & Search Engines: Articles within Treesaver websites have their own URL which can be linked to or spidered by search engines. Users searching in Google can be taken directly into the rich Treesaver experience.
Bookmarking & Social Media: Because Treesaver can run in the browser, users can bookmark and directly link to articles when sharing with friends. Friends and Family can immediately view shared content in a rich experience without having to go to an app store to download a viewer.
Leverage existing content: Treesaver articles are simply-structured HTML files, meaning little to no conversion is required for existing text content. Existing web assets like video and Flash can continue to be embedded (assuming the browser/device supports Flash, of course).
Ecosystem: Because Treesaver is built upon standard technologies, it can leverage the wide variety of tools available in the web ecosystem: Google Analytics, embedded YouTube videos, slideshow widgets, etc.
Embedding: You can embed a Treesaver article within other webpages, as you would a YouTube video. Embedded articles continue to be formatted by Treesaver, meaning branding and advertising are preserved, even if the article has been embedded on another site.
What are Treesaver’s Browser/Device Requirements?
The column and page-based layout works on most modern browsers, specifically:
Internet Explorer 7 and above
Firefox 2.0 and above
Safari 3 and above (including iPhone, iPad, and many smart phones)
Chrome 3 and above
Opera 10 and above
Because Treesaver content is just HTML, it degrades gracefully onto legacy devices. Users with IE6 or older phones will still be able to read any article that uses Treesaver, although it will have a simpler, primarily text layout.
Can Treesaver content be distributed via the App Store?
Yes. We will provide the ability to package Treesaver content as an application that can be downloaded and sold through the App Store.
When can I use Treesaver?
We’re not giving public access to Treesaver right now, although we will be doing a limited beta test in the coming weeks. Subscribe to the Treesaver mailing list to be notified when beta invites are ready to be sent out.
I’m interested in using Treesaver for my publication, how do I get in touch?
Today’s web browsers don’t provide hyphenation, which makes justified text prone to rivers of white space. However, browsers do support the soft-hyphen: the &shy; HTML entity. Soft hyphens tell the browser where it can break a word, if necessary.
Adding these hyphens manually is quite tedious. The Soft Hyphenator takes HTML and adds the soft hyphens automatically.
Note: This library is no longer available. Just use media queries, they work well. The original post is below, but the links have been removed.
Dynamic Layout is a simple library that allows you to easily adjust page layout based on the current browser width.
The script works by modifying the class property on the body element, adding a new class name that will look something like bw-1000, where 1000 is one of the numbers in a predefined list of possible browser widths.
Unless you’re reading this in your RSS reader, you can see a live demo by resizing your browser window. I’ve also created a simple multi-column demo, which will display one, two, or three columns depending on your browser width.
To download, and for details, see the Dynamic Layout project page.