I’m curious to know more about what triggers the Reader option in Safari and what does not. I wouldn’t plan to implement anything that would disable it, but curious as a technical exercise.
Here is what I’ve learned so far with some basic playing around:
- You need at least one H tag
- It does not go by character count alone but by the number of P tags and length
- Probably looks for sentence breaks ‘.’ and other criteria
Safari will provide the ‘Reader’ if, with a H tag, and the following:
- 1 P tag, 2417 chars
- 4 P tags, 1527 chars
- 5 P tags, 1150 chars
- 6 P tags, 862 chars
If you subtract 1 character from any of the above, the ‘Reader’ option is not available.
I should note that the character count of the H tag plays a part but sadly did not realize this when I determined the results above. Assume 20+ characters for H tag and fixed throughout the results above.
Some other interesting things:
<p style="display:none;">for P tags removes them from the count
I’d be interested if anyone can determine this in full.
“You need at least one
<h*> element” — this is simply incorrect. Here’s an example: http://mathiasbynens.be/demo/safari-reader-test-3
My answer on the other Safari Reader question provides some more info.
You could also read my blog post on enabling Safari Reader for all my findings on the subject.
Adding markup to potentially “readable” tags, like
div, can cause the Readability algorithm to ignore the tag, thus lowering the score, hopefully to a point that it doesn’t trigger the Reader icon to display.
Looking at the Readability source, one area to do this is in the
class attributes, as it does pattern matching on the combined data from these two attributes. For example, adding a “comment” class, like so
<p class="myClass comment">...</p>
will cause that element to be ignored. The pattern that is being matched for “unlikely” candidates is:
Placing flags on the elements that might add to the Readability Score can allow you to disable the Reader icon.
See http://code.google.com/p/arc90labs-readability/source/browse/trunk/js/readability.js for “the code” for readability.
Here is what worked for me:
I placed all content inside an ol tag.
<ol style = "padding:0;margin:0"> my content </ol>
From what I read elsewhere, the reader is partly triggered by the number of words on a page, but it does not count words inside an ol.
It looks like a quite complex algo the one adopted by Safari reader. I guess something more simple sticks behind this.
Most probably a well W3C document with some SEO best practice like the one you mentioned.
I believe something like this:
- At least an H1
<p>tags open and closed, and properly following each heading tags
- a general containing layer
Most probably the reader is looking for something close to the new HTML 5 specific, so a class caller article or something like that.
It’s interesting to understand why Apple didn’t disclose anything about this.
I had a div inside my that wrapped all my content.. Changing this div to be a element, and adding a class to remove all padding that is created by the , removed the reader button on my mobile site.