Safari was the first mainstream browser to include a built-in reader view five years ago. Over the last two months both Firefox and Edge have released their own reading view experiences, and Chrome is experimenting with their own version.
The same cross-browser concept ended up having four different URI protocols and schemas, and behaviors in all the major browsers. Here is a quick overview over the URI schemas used to render pages in reading view from the big browser vendors:
Microsoft Edge 12’s Reading View
read:http://example.com/URI is properly registered and can be called from anywhere in the operating system. The URI is stored in the browser session data, so pages reopen in reading view when resuming a session.
Pages added to the Reading List open in either the standard view or Reading View depending on which view they were opened in when they were added to the list. This makes the reading list somewhat inconsistent and confusing, but it also respects and remember the user’s decisions.
Links opened from inside the Reading View normally doesn’t send a Referer (sic) header when following links. However, links opened by right-clicking on a link and opened from that context menu will send the page’s URL prefixed by the “read:” protocol schemas. This can cause issue for logparsers and analytics software who don’t handle unusual protocols very well.
Windows 10 and Windows 10 Mobile versions behave the same way.
Mozilla Firefox 39’s Reader View
about:reader?url=http%3A%2F%2Fexample.com%2FURI is callable from inside Firefox and by websites and add-ons. It’s not registered in the system and can’t be used from other programs. The URI is stored in the browser session data, so pages reopen in reading view when resuming a session.
Links opened from inside the Reader View don’t send any Referer (sic) headers.
Update (): Firefox’s reading list feature has been deprecated in favor of Mozilla’s Pocket reading-list service. The following paragraph is therefor no longer accurate.
Pages added to the Reading List always open in standard view regardless of whether they were added from Reader View or standard view. Android and desktop versions of Firefox behave the same way.
Safari 9’s Reader View
safari-reader:example.com/URI is only used internally in Safari and isn’t callable even from inside Safari. It’s not registered in the system and never exposed to the user. Safari is unique in not preserving the original URL. The URI isn’t stored in the browser session data and pages always reopen in standard mode when resuming a session.
Pages added to the Reading List open in standard view or Reading View dependent on what view they were opened in when added to the list.
Links opened from inside the Reader View don’t send any Referer (sic) headers. iOS mobile and Mac versions behave the same way.
Google Chrome 44’s Page Distiller
Google — a giant in the advertisement industry — has a huge conflict of interest when it come to allowing their users to hide their own advertisement. Never the less, they’ve an experimental reader mode called “page distiller” available in Chrome 44.
Update (): Almost three years later, the Chrome DOM Distiller finally shipped as an accessibility feature in Chrome 65 but only on Android.
chrome-distiller://uuid/?url=http%3A%2F%2Fexample.com%2FURI is callable from inside Chrome and by websites and add-ons. It’s not registered in the system. The URI is stored in the browser session data, so pages reopen in page distiller mode when resuming a session.
Links opened from inside the Page Distiller don’t send any Referer (sic) headers.
The UUID’s purpose is unknown but you can supplement any string and still have it work.
Chrome doesn’t have a Reading List, but pages opened in the page distiller mode can be bookmarked and resume in distilled mode when reopened.
Android and computer versions behave the same way.
We can only wonder how they all ended up with different URI protocols and why there’s so little apparent cooperation between the browser vendors. Unless the browsers are forced to cooperate, they seem to always go their separate ways to differentiate at the expense of interoperability.
Out of the current generation of browser reader modes, I think I’ll crown Microsoft Edge as the best implementation. It’s reader mode is the most accessible to third-party integration and it has the neatest and simplest URI schema of the lot. Good work, Microsoft Edge team!