ウェブサイトでiOS 5 Safariリーダーを有効にする方法
IOS 5のMobile Safariのリーダー機能はどのように機能しますか？自分のサイトで有効にするにはどうすればよいですか。ページのどのコンテンツがこの機能をトリガーする記事であるかをどのように伝えるのですか？
ここに投稿された回答の多くには、誤った情報が含まれています。いくつかの修正/説明は次のとおりです。
<article>要素はラッパーとして正常に機能します。 Safari Readerはそれを認識します。 私のサイトは例です 。<body>または<p>以外のラッパー要素が存在する限り、どのラッパー要素を選択してもかまいません。<article>、<div>、<section>を使用できます。または、<nav>、<aside>、<footer>、<header>など、この目的のために意味的に正しくない要素または<span>（！）のようなインライン要素です。Readerが機能するために見出しは必要ありません。 Readerが正常に機能する
<h*>要素のないドキュメントの例を次に示します。 http://mathiasbynens.be/demo/safari-reader-test-
調査結果に関する詳細をここに投稿しました： http://mathiasbynens.be/notes/safari-reader
それが基づいているアルゴリズムはpタグを探しており、「。」のような区切り文字をカウントしているようです。 innerTextで。最もポイントの多いセクション（div）がフォーカスを取得します。
参照： http://lab.arc90.com/experiments/readability/
リーダーモードのベースであるようです。少なくともSafariは謝辞で属性を指定しています。
file：/// C：/Program%20Files/Safari/Safari.resources/Help/Acknowledgments.html
Arc90（読みやすさ）Copyright©Arc90 Inc.
可読性は、Apache License、Version 2.0の下でライセンスされています。
このとらえどころのないReader状態をトリガーするものを把握するために、iPhoneでこれを100個ほどテストしました。私の結論は次のとおりです。
私が影響を与えたことがわかったのは次のとおりです。
- 「リーダー」をトリガーする記事に約200以上の単語（または空白を含む1000文字）が必要なようです
- 170語未満の場合、読者は決してトリガーされませんでした。 180または190の単語があったときにトリガーされることがありましたが。
<ol>や<ul>などの特定の要素内のテキスト（通常はストーリーの格納に使用されない）は、200ワードにはカウントされません（ただし、リーダーがトリガーされた場合、リーダーに表示されます）その他の理由）<div>や<article>などのブロック要素で200ワードをラップする必要があるようです（それは、そうではないWebサイトがあったとしても驚かれることでしょう）
完全な開示のために、私が影響を与えなかったことがわかったのは次のとおりです。
- ヘッダーを使用するかどうか
- テキストを
<p>でラップするか、自由にフローさせるか - 句読点（つまり、すべてのピリオド、コンマなどを削除しても影響はありませんでした）
この質問（ WebページでSafariリーダーを無効にする方法 ）には詳細があります。ここにコピー：
SafariでReaderオプションをトリガーするものとトリガーしないものについてもっと知りたいです。私はそれを無効にするものを実装するつもりはありませんが、技術的な演習として興味があります。
これまでに基本的な遊びで学んだことは次のとおりです。
少なくとも1つのHタグが必要です。これは、文字数だけではなく、Pタグの数と長さによって決まります。おそらく、文区切り '。'を探します。およびその他の条件Safariは、Hタグを使用して「リーダー」を提供し、次の条件を満たします。
1 Pタグ、2417文字4 Pタグ、1527文字5 Pタグ、1150文字6 Pタグ、862文字上記のいずれかから1文字を引く場合、「リーダー」オプションは使用できません。
Hタグの文字数は重要な役割を果たしますが、上記の結果を判断したときに悲しいことにこれを認識していなかったことに注意する必要があります。 Hタグに20文字以上を想定し、上記の結果全体で修正されました。
その他の興味深いこと：
Pタグを設定すると、カウントから削除されます。表示を[なし]に設定し、Javascriptで230ミリ秒後に表示すると、リーダーオプションも回避されます。
誰かがこれを完全に決定できるかどうか興味があります。
私はこれに苦労していました。私はついに<ul>私の物語のマーキングとヴィオラ！動き始めました。
私は体の周りにラッパーを置きませんでしたが、偶然それをしたかもしれません。
Article Publishing Guidelines を参照してください。
読み取りおよび解析方法に関するAPIを次に示します。 Readability Developer APIs 。参照できるプロジェクトはすでにあります： Ruby-readability 。
簡単な歴史：AppleのSafari 5ブラウザーには Readability という名前のコードベースが組み込まれているため、Safari Readerの機能が使用され、ReadabilityはWebページをカスタマイズ可能な読み取りビューに変えるシンプルなJavascriptベースの読み取りツールとして始まりました。それは Arc9 （Arc90 Labの実験として）、ニューヨークに拠点を置くデザインおよびテクノロジーショップによって2009年初頭にリリースされました。また、Amazon KindleおよびFlipboardやReederなどの人気のiPadアプリケーションにも組み込まれています。 。
驚くかもしれませんが、実際にはHTML5記事タグに注意を払っていません。特に、Safari 5がCSSの記事、セクション、ナビゲーションなどを完全にサポートしていることを考えると、残念です。ブロックレベルの要素と同じように動作します。
まさにそのような目的のためにセマンティックHTML5ラベル付けの準備として、記事タグといくつかの内部セクションタグを使用してサイトを具体的に設定していました。そのような幸運はありません-おそらく、これは非常に理にかなっているので、これに関するバグを報告する必要があります。実際、ページ上のほとんどのh2レベルのサブヘッドは完全に無視され、それぞれがセクションとしてマークされ、前述の基準に準拠する単一のdivのみが表示されます。
皮肉なことに、同じサイトの古いバージョンは、記事、セクション、divタグのいずれも持たず、Readerで表示するために本文全体を認識します。
HTML5記事タグは、テストではトリガーしません。また、オフラインコンテンツ（つまり、ローカルマシンに保存されたページ）では機能しないようです。
それを引き起こすように思われるのは、多くのテキストを持つ多くのpを持つdivブロックです。
FirefoxとChromeの両方にiReaderという名前の同様のプラグインがあります。ソースコードを使用したプロジェクトを次に示します。
http://code.google.com/p/ireader-extension/
コードを読んで詳細を確認してください。
Pタグ理論はいいですね。他の要素も検出すると思います。 6段落のページの1つはReaderをトリガーしませんでしたが、4段落とimgタグのページはトリガーしました。
また、複数ページの記事を検出するのに十分スマートです。 nytimes.comまたはnymag.comの複数ページの記事で試してみてください。同様にそれを検出する方法を知りたいと思うでしょう。
私は、Safari Reader機能に似た情報「無駄」からWebサイトをきれいにするアルゴリズムに取り組んでいます。読みやすさほど良くありませんが、いくつかのクールなものがあります。
詳細については、 smartbrowser.codeplex.com プロジェクトページをご覧ください。