Как работает Firefox reader view


резюме

Я ищу критерии, по которым я могу создать страницу и [справедливо] уверен она появится в Firefox Reader Посмотреть при желании пользователя.

некоторые сайты имеют эту опцию, некоторые нет. Некоторые с большим количеством текста не имеют этой опции, чем другие с гораздо меньшим количеством текста. Переполнение стека для экземпляр отображает только вопрос, а не ответы в Reader Вид.

вопрос

я обновил свой Firefox с 38.0.1 до 38.0.5 и нашел новую функцию под названием ReaderView - которая является своего рода наложением, которое удаляет "беспорядок страницы" и облегчает чтение текста. Readerview находится в правой части адресной строки в виде кликабельного значка на определенных страницах.

это нормально, но с точки зрения программирования я хочу знать, как работает "reader view", какие критерии к каким страницам он относится. Я провел некоторое исследование веб - сайта Mozilla Firefox без четких ответов (sod all programming answers of any sort I found), я, конечно же, погуглил / Бил это, и это только вернулось со ссылками на дополнения Firefox-это не аддон, а основная часть новой версии Firefox.

Я сделал предположение, что readerview использует HTML5 и будет извлекать <article> содержание, но это не так, как это работает на Википедии, которая не делает кажется, использовать <article> или аналогичные теги HTML5, вместо этого readview извлекает определенные <div>s и отображает их в одиночку. Эта функция работает на некоторых страницах HTML5 - таких как wikipedia - но не на других.

Если у кого-нибудь есть идеи, как Firefox ReaderView на самом деле работает и как эта операция может быть использована разработчиками веб-сайта, вы можете поделиться? Или если вы можете найти, где эта информация может быть расположен, вы можете мне точку в правильном направлении, как я не смог найти этот.

3   57  

3 ответа:

вам нужен хотя бы один <p> тег вокруг текста, который вы хотите видеть в режиме чтения и по крайней мере 516 символов в 7 словах внутри текста.

например, это вызовет ReaderView:

<body>
<p>
 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
 123456789 123456
</p>
</body>

смотрите мой пример на https://stackoverflow.com/a/30750212/1069083

чтение кода gitHub, сегодня утром, процесс заключается в том, что элементы страницы перечислены в вероятностном порядке - с <section>,<p>,<div>,<article> в верхней части списка (т. е. скорее всего).

затем каждому из этих "узлов" присваивается оценка на основе таких вещей, как количество запятых и имена классов, которые применяются к узлу. Это несколько многогранный процесс, в котором оценки добавляются для текстовых фрагментов, но также оценки, по-видимому, уменьшаются для недопустимых частей или синтаксиса. Баллы в подразделах "узла" отражаются в баллах узла в целом. т. е. родительский элемент содержит оценки всех нижних элементов, я думаю.

это значение оценки решает, может ли HTML-страница быть "просмотрена" в Firefox.

Я не совсем ясно, если значение оценки устанавливается Firefox или функцией читаемости.

Javascript действительно не моя сильная сторона,и я думаю, что кто-то еще должен проверить ссылку, предоставленную Ричардом ( https://github.com/mozilla/readability) и посмотрим, смогут ли они дать более подробный ответ.

то, что я не видел, но ожидал увидеть, было оценено на основе количества текстового контента в <p> или <div> (или другие) соответствующие теги.

любые улучшения на этот вопрос или ответ, пожалуйста, поделитесь!!

изменить: Изображения в <div> или <figure> теги (HTML5) внутри <p> элемент, по-видимому, сохраняется в представлении читателя, когда страница текстовое содержимое является допустимым.

Я проследил за ссылкой Мартина на читаемость.js репозитории GitHub, и посмотрел на исходный код. Вот что я об этом думаю.

алгоритм работает с тегами абзацев. Прежде всего, он пытается определить части страницы, которые определенно не являются содержательными формами и т. д., и удаляет их. Затем он проходит через узлы абзацев на странице и назначает оценку на основе богатства контента: он дает им очки за такие вещи, как количество запятых, длина содержимого, и т. д. Обратите внимание, что абзац, содержащий менее 25 символов, немедленно отбрасывается.

баллы затем "пузырятся" дерево DOM: каждый абзац добавит часть своего балла ко всем его родительским узлам - прямой родитель получает полный балл, добавленный к его общей сумме, дедушка только наполовину, прадедушка треть и так далее. Это позволяет алгоритму идентифицировать элементы более высокого уровня, которые, вероятно, будут основным разделом контента.

хотя это просто алгоритм Firefox, я думаю, если он хорошо работает для Firefox, он будет хорошо работать и для других браузеров.

для того, чтобы эти алгоритмы просмотра читателя работали для вашего сайта, вы хотите, чтобы они правильно идентифицировали тяжелые разделы вашей страницы. Это означает, что вы хотите, чтобы более содержательные узлы на Вашей странице получали высокие баллы в алгоритме.

Итак, вот некоторые эмпирические правила, чтобы улучшить качество страницы в глазах этих алгоритмы:

  1. используйте теги абзацев в своем контенте! Многие люди склонны упускать из виду их в пользу <br /> теги. Хотя это может выглядеть, многие алгоритмы, связанные с контентом (не только для просмотра читателем), сильно зависят на них.
  2. используйте семантические элементы HTML5 в разметке, например <article>,<nav>, <section>,<aside>. Несмотря на то, что они не являются единственным критерием (как вы отметили в вопросе), они очень полезны для компьютеров, читающих ваши страница (не только читатель Вид) для различения различных разделов ваш контент. Удобочитаемость.js использует их, чтобы угадать, какие узлы, вероятно, или вряд ли содержат важное содержимое.
  3. оберните основное содержимое в один контейнер, как <article> или <div> элемент. Это будет получать очки от всех тегов абзаца внутри него и будет идентифицирован как основной раздел контента.
  4. держите дерево DOM неглубоким в областях с плотным содержимым. Если у вас есть много элементов, разрушающих ваш контент, ты только усложняешь жизнь. для алгоритма: не будет ни одного элемента, который выделяется как родитель много содержания-тяжелые абзацы, но многие отдельные из них с низкими оценками.