惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
雷峰网
雷峰网
Recent Announcements
Recent Announcements
月光博客
月光博客
G
Google Developers Blog
腾讯CDC
S
Secure Thoughts
大猫的无限游戏
大猫的无限游戏
T
Tenable Blog
云风的 BLOG
云风的 BLOG
W
WeLiveSecurity
博客园 - 【当耐特】
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
博客园 - 聂微东
The Cloudflare Blog
阮一峰的网络日志
阮一峰的网络日志
人人都是产品经理
人人都是产品经理
P
Privacy International News Feed
MyScale Blog
MyScale Blog
K
Kaspersky official blog
T
The Blog of Author Tim Ferriss
Attack and Defense Labs
Attack and Defense Labs
Spread Privacy
Spread Privacy
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
aimingoo的专栏
aimingoo的专栏
I
Intezer
Vercel News
Vercel News
小众软件
小众软件
Simon Willison's Weblog
Simon Willison's Weblog
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
N
Netflix TechBlog - Medium
P
Proofpoint News Feed
Latest news
Latest news
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
T
Tor Project blog
S
Security Affairs
P
Proofpoint News Feed
博客园 - 三生石上(FineUI控件)
博客园 - Franky
C
Cyber Attacks, Cyber Crime and Cyber Security
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
美团技术团队
Recent Commits to openclaw:main
Recent Commits to openclaw:main
S
Security @ Cisco Blogs
L
LINUX DO - 热门话题
Know Your Adversary
Know Your Adversary
Project Zero
Project Zero
D
Docker
L
Lohrmann on Cybersecurity
F
Full Disclosure

Mathias Bynens

A horrifying globalThis polyfill in universal JavaScript JavaScript engine fundamentals: optimizing prototypes JavaScript engine fundamentals: Shapes and Inline Caches Asynchronous stack traces: why await beats Promise#then() ECMAScript regular expressions are getting better! Unicode property escapes in JavaScript regular expressions ES2015 const is not about immutability Valid JavaScript variable names in ES2015 Unicode-aware regular expressions in ES2015 Dear Google, please fix plain text emails in Gmail PBKDF2+HMAC hash collisions explained JavaScript has a Unicode problem Processing Content Security Policy violation reports Hiding JSON-formatted data in the DOM with CSP enabled Loading JSON-formatted data with Ajax and xhr.responseType='json' Reserved keywords in JavaScript How to support full Unicode in MySQL databases How to speedrun Dropbox’s Dropquest 2012 Unquoted font family names in CSS Unquoted property names / object keys in JavaScript Valid JavaScript variable names in ES5 CSS character escape sequences JavaScript’s internal character encoding: UCS-2 or UTF-16? The smallest possible valid (X)HTML documents JavaScript character escape sequences JavaScript foo.prototype.bar notation Ambiguous ampersands HTML element + attribute notation How I detect and use localStorage: a simple JavaScript pattern Unquoted attribute values in HTML and CSS/JS selectors The end-tag open (ETAGO) delimiter Using the oninput event handler with onkeyup/onkeydown as its fallback Everything you always wanted to know about touch icons In defense of CSS hacks — introducing “safe CSS hacks” AirPlay video support in iOS Safari — a bookmarklet Completing Dropbox’s Dropquest 2011 in 60 seconds Using CSS without HTML How to create simple Mac apps from shell scripts Using setTimeout to speed up window.onload Bulletproof JavaScript benchmarks Thoughts on Safari Reader’s generated HTML The XML serialization of HTML5, aka ‘XHTML5’ The id attribute got more classy in HTML5 The three levels of HTML5 usage The HTML5 document.head DOM tree accessor Bulletproof HTML5 <details> fallback using jQuery Displaying hidden elements like <head> using CSS Inline <script> and <style> vs. external .js and .css — what’s the size threshold? Using Showdown/PageDown with and without jQuery
How to enable Safari Reader on your site?
Mathias · 2010-06-10 · via Mathias Bynens

How to enable Safari Reader on your site?

Published · tagged with HTML, iOS, macOS

Yesterday, Mike Taylor raised a very interesting question on Twitter:

Anybody know what Safari 5 requires for a page to be Reader-ifiable?

I noticed Reader was already working on this site for most blog posts. For example, the article about the three levels of HTML5 usage triggers the Reader badge in Safari’s address bar. I concluded the use of the <article> element to wrap the actual content must be one of the things that trigger it.

Further investigation

However, there’s more to it than just using the right markup. For example, Reader doesn’t work on this page containing my notes on document.head, even though the markup is similar to that of any other article on this site. It seems as if the length of the content is important as well. But how does Safari measure content length? Does the number of children of the wrapper element matter? How about the number of characters inside?

Rob Flaherty decided to investigate this further and created some test documents. He made some interesting observations:

  • You need a wrapper element around the actual content, other than <body>. It doesn’t really matter which element you choose, as long as it’s not <p>.
  • Reader requires at least five child elements inside the wrapper. Using double line breaks (<br><br>) inside an element makes it count as two elements.
  • Reader doesn’t seem to work for local files.

All valid points, except “Reader requires at least five child elements inside the wrapper”, which doesn’t seem to be true. The number of child elements doesn’t matter, the content length seems to be measured another way. I’ll get to that later.

Clayton Ferris did some additional testing, and concluded the following:

It looks like that Safari Reader will detect a <div> or block level element that contains a header element (<h1> to <h6>), followed by a certain amount of text. The reader badge will appear when the content text (not including the header) is more than 2,000 characters.

Sadly, none of Clayton’s statements seem to be true. I created some quick test cases to demonstrate it’s just not that simple:

  • Test 1: 3 paragraphs, 1,863 characters (including heading and line breaks); Reader fails.
  • Test 2: same as test 1, but with <p>.</p> added — 4 paragraphs, 1,866 characters; Reader works.
  • Test 3: test without any heading elements — 6 paragraphs, 3,718 characters; Reader works.

This also proves that there is no fixed amount of paragraphs (or other elements) needed to enable Reader; it all depends on the contents.

Reader and the Readability bookmarklet

Apple attributes Arc90’s Readability experiment in the Safari Acknowledgements (Safari › Help › Acknowledgements or file:///Applications/Safari.app/Contents/Resources/Acknowledgments.html on Mac). This bookmarklet seems to be what Reader is based on, so it’s probably a good idea to dive in the source code.

For example, every paragraph containing double line breaks (<br>) counts as two paragraphs — this confirms what Rob concluded after his tests. Direct child text nodes and <div>s that don’t have block-level child elements count as paragraphs as well.

It turns out Readability then loops through all these ‘paragraphs’ and assigns a score to them based on how ‘content-y’ they look. This score is determined by things like the number of commas, class names used in the markup, etc. The content’s length appears to be measured by using .innerText; for every 100 characters inside a paragraph, that paragraph’s score goes up. Eventually, the number of elements is counted, adding their individual scores. I think it’s safe to assume Safari Reader is triggered based on this algorithm.

Conclusion

This definitely needs more investigating, but so far, these appear to be the most important factors for Safari’s Reader functionality to kick in:

  • Use the right markup, i.e. make sure the most important content is wrapped inside a container element. Whether you use <article>, <div> or even <span> doesn’t seem to matter — as long as it’s not <p>.
  • The content needs to be long enough. Use enough words, use enough paragraphs, use enough punctuation. Every paragraph should have at least 100 characters.
  • Reader doesn’t work for local documents.