Reading mode doesn’t offer a consistently good experience for readers, it doesn’t offer publishers anything at all, and web developers don’t have any documentation for it. It’s a bad experience for everyone involved.
This article is part four in a series on web reading mode and reading mode parsers.
Bad experiences
Imagine if leading web browsers all had a toolbar button that seemingly at random appears on some webpages, after a seemingly random period of time after it has loaded, and that performs a weird and unexplained action with mixed results when pressed. This is exactly how reading mode works in web browsers today — for readers and web developers alike.
Readers have no guarantee of what will happen when they press the button. They may get a neat and clean copy of the article they intended to read, or they may get a high junk-to-content ratio, or they may get an unexpected article instead. My favorite is the new trend of showing privacy/cookie/GDPR screens instead of the expected article. Experience with pressing the button may teach readers that it works well on some websites and not others. They may remember which pages works well with but more likely they’ll learn to completely ignore the button.
Web developers likewise have little to no published standards or guidelines to work with when trying to adopt their content to reading mode.
I began this series comparing the promise of reading mode with the expectations readers have for the ideal paper printout of a webpage. As anyone who’ve printed a webpage knows, the results will be mixed and quite often disappointing.
Publishers may not know that they’ve a readability problem with their pages. Reading mode can be great for readers, but ideally publishers should be encouraged to reduce distractions and fix their designs instead. One potential way to achieve this would be to emit a measurable event when users abandon their web designs in favor of reading mode.
Safari Reader overlays reading mode on top of the regular webpage, but doesn’t emit a visibilitychange:hidden event even though it’s clearing hiding the page from view. Other web browsers all replace the current page with a separate page in reading mode and emit a visibilitychange:hidden event as they unload the old page. One idea that would work for both types of implementation is to extend the Page Visibility API to first emit something like a visibilitychange:enteringReaderMode event and then a second visibilitychange:hidden event either when hiding or unloading a page in favor of a reading mode.
This proposal wouldn’t give publishers a chance to block a user from entering reading mode, but it would allow them to measure it.
Publishers may not be too happy about reading mode. Reading mode cuts them off from their advertisement revenue and can make a mess of carefully laid out content. Publishers aren’t afforded to even display their name and link back to their home pages for pages in reading mode. Sure, Edge and Firefox will show “www.nytimes.com” at the top of each article but it won’t spell out The New York Times.
Overdue for standardization
The user experience suffers as a result as web developers don’t have the required information to make their websites display properly in reading mode. Readers are left guessing at whether an important paragraph of text, or an image or video have been omitted from the article or not when reading in reading mode.
Even a motivated web developer will have trouble figuring out exactly how reading mode works in any given browser. What little information that have been published about reading modes before have been almost entirely speculative.
Mozilla Readability’s weird title detection rules are particularly arcane. It’s bad for the open web that a few leading North-American video hosting services are given preferential treatment within web browsers to exclusively allow their video content to be played inside reading mode.
Readability.js was a neat trick back in the day and it’s still an excellent prototype. However, it has created an entirely separate rendering mode inside the web browser. Given its central placement in all the leading web browsers sans Google Chrome it’s overdue for a formal specification and standardization across web browsers.
Web browser vendors need to come together and rethink what reading mode is and how it should work. Individual web browser vendors can continue to tweak and improve reading mode over time. However, it’s not the 90’s anymore. The web wants standards and not vendor-specific solutions to universal problems.