В классификаторе расширений браузеров произошло изменение. Все многочисленные статьи про расширения Хрома теперь можно пометить этим хабом, что призываю сделать авторов ранее написанных статей. Кроме этого, по случаю праздника, хотел бы написать обзор о расширениях и юзерскриптах Хрома, о том, как они сформировались и к какому виду пришли.
Упорная, но сомнительная поросль: резальщики рекламы
Вначале, много лет назад, в годах 2000-2005-х, расширений браузеров в том виде, в каком мы видим их сейчас, не было. Скрипты в браузере подразумевались написанными непременно авторами сайта и страницы, наблюдаемой в браузере. Казалось бы, ничего странного в этом нет — авторы сайта имеют полное и безраздельное право пользоваться ресурсами браузера… стоп. Нашла коса на камень. Почему авторы страницы должны пользоваться ресурсами моего браузера? Писать свои произвольные скрипты, не дающие показать содержание своей же страницы? Отвлекать неудачными стилями от содержания своей страницы? А реклама на ней?
И заработала пытливая мысль пользователя. Мой браузер — он по определению должен приносить удобства мне, а не продвигать интересы владельца сайта, который я сейчас рассматриваю. Нет, есть, конечно, и мазохисты, которые будут отстаивать право автора сайта, не будучи авторами, но не все будут согласны с ними. Пример — избыточная или не очень, реклама, не относящаяся к содержанию, ради которого пришёл читатель. Или несовершенства или ошибки в оформлении страниц. Или желание читателя видеть дополнительную информацию на той же странице. Всё это приводит к желанию иметь рядом с браузером механизм, перерабатывающий некоторые части страниц.
Например, самые ранние примеры переработки страниц реализовывались как локальный прокси-сервер, через который пропускались страницы для фильтрации её содержимого, в основном, для удаления рекламы. История помнит попытки исков владельцев сайтов против создателей этих программ. Например, был легендарный представитель этого класса программ, Proxomitron, автор которого в июне 2003 г. отказался от поддержки и развития своей программы по причине давления на него, грозившего вылиться в судебные преследования. Таких примеров было несколько, но уже через пару лет программ-прокси было такое количество, что бороться с ними стало бессмысленно, а реальных примеров борьбы практически не было — существовали только некоторые программы, прекратившие развитие.
При этом совсем не обязательно язык, на котором писался парсер рекламных вставок, был Javascript. Язык адблокеров был и есть декларативный и специализированный, он таким остался и в самом известном AdBlock Plus — блокере, который сформировался уже в эру Javascript-расширений браузеров. В то же время, парсить входные страницы в прокси-сервере программа-блокер могла и на Python, например. Основное назначение блокеров — резать части страницы, максимально эффективно отыскивая ненужные, не нарушая при этом каркас (раскладку) страницы.
Подробнее о современных взаимоотношениях блокеров и рекламодателей (англ.) — www.computerworld.com/s/article/9245190/Ad_blockers_A_solution_or_a_problem_.
Пользовательские стили
Другой класс идей по воздействию на страницы — модификация страниц. поскольку в большой степени на отображение влияют правила CSS, возникла последующая идея — примешать в множество правил CSS свои правила пользователя. Кстати, они могут частично выполнять задачи по скрыванию ненужных блоков, хотя не так эффективно, как резальщики HTML. Но у них есть плюс в том, что правила стилей продолжают влиять на страницу и при динамической модификации DOM (структуры элементов страницы), что всё более типично в последние годы, начиная примерно с рубежей 2008-2009 годов. К тому же, модификаторы стилей выполняют не только разрушительную, но и оформительскую роль, могут облагораживать или просто менять исходный стиль страниц. Возможность установки пользовательских стилей введена даже в браузер IE6 («Accessibility — Format documents using my style sheet» в настройках) и в Windows Mobile 3003 (через реестр).
Примешивание стилей несложно провести и через включение правил CSS в HTML методом работы с прокси-сервером.
Пользовательские скрипты
Прокси-сервером можно не допустить внедрения скриптов Javascript в страницу сайта, но нельзя модифицировать последующие изменения DOM (если не считать случая внедрения собственноручно написанных скриптов вместо или в дополнение скриптов сайта). Для облегчения доступа скриптам в пространство страницы с течением эволюции браузеров изобрели пользовательские скрипты. Первая версия аддона Greasemonkey браузера Firefox появилась в марте 2005 года и позволяла писать короткие и простые пользовательские скрипты. Точнее, модифицировать поведение браузера (плагины Internet Explorer, аддоны и плагины Firefox) можно было и раньше, но весь вопрос был в трудоёмкости вмешательства, в поддержке способа вмешательства с появлением новых версий браузеров и в совместимости пользовательского плагина с другими. Круг технологий и порог вхождения методично уменьшались, чтобы небольшое воздействие на сайт с помощью своего скрипта было простым и чтобы оно не конфликтовало по возможности с процессом развития браузера.
Опять же, нет причин отказываться от прокси-серверов для внедрения скриптов. Ведь юзерскрипты фактически запускались поначалу в момент окончания загрузки вебстраницы, и это было хуже, чем внедрение тегов с включениями скриптов, потому что все остальные теги со скриптами сайта успевали запуститься и выполниться. При желании, скрипт сайта мог бы противодействовать юзерскриптам успешнее, чем они — скриптам страницы. Но ни один скрипт при этом не подавлялся полностью, потому что каждый имеет собственное локальное окружение переменных скрипта для своего выполнения. (Конкурировать за общие ресурсы типа Global Scope и DOM, переписывать их — да, могут любые из этих скриптов.)
Ещё один довод в пользу включений прокси-сервера против юзерскриптов — универсальность для различных браузеров. Любой браузер легко приучить работать с прокси-сервером, но не все браузеры поначалу имели механизм внедрения юзерскриптов в своём арсенале. Интересно, что довольно скоро все новые браузеры посчитали своим долгом иметь похожие механизмы внедрения и поддерживали ставшие стандартом де-факто функции Greasemonkey, кроме браузеров семейства IE, но и они заимели способы внедрения юзерскриптов с помощью сторонних программ. Правда, IE долгое время, до версии IE9 имел сильно отличающийся способ работы с DOM на уровне Javascript, что определило его изолированность от основного потока развития браузеров. В версии IE11 разработчики браузера эти различия постарались свести к минимуму. Но проблема остаётся в охвате пользователей по платформам (операционным системам). IE11 может быть установлен или поставляется изначально лишь с системами windows 8 (с июня 2013) и Windows 7 (с ноября 2013). Пользователи других ОС даже не могут установить этот браузер, если не считать использование виртуальных машин. Поэтому число потенциальных пользователей браузера и юзерскриптов в нём сильно ограничено политикой распространения.
Похожая ситуация с ограниченностью распространения сложилась и с браузером Safari с мая 2012 года, когда было выпущено последнее обновление Safari 5.1 для Windows и далее он на этой системе и остальных, кроме Mac OS, не развивался. Но до этого момента разработчики могли рассчитываить на довольно большой охват пользователей юзерскриптов на платформах Windows и Mac OS.
В Опере 8.0 в апреле 2005 года тоже появилась поддержка юзерскриптов, одновременно с Firefox. В отличие от него, у Оперы механизма аддонов ещё долго не было, и устанавливать скрипты приходилось вручную (создавать файл со скриптом) и через настройки браузера.
Ко всему, надо сказать, что пользователей юзерскриптов, юзерстилей и прокси-серверов было достаточно мало относительно общего числа посетителей сайтов. Большей частью, эти технологии сделаны гиками для гиков, а относительная простота установки скриптов через Greasemonkey — само по себе большое и нетипичное достижение.
Проблема не только в том, что скрипты приносят дополнительную опасность доступа к пользовательским данным. Первая проблема — в том, что убедить пользователя сделать лишнее движение и установить программу-надстройку — сложная задача, выполнимая примерно для 1-5% от общего числа пользователей какого-либо сайта. В основном ведь владельцы сайтов старались делать их удобными для пользователей, поэтому не часто была сильная необходимость в смене функций и оформления.
Даже аддоны, о которых речь ниже, которые смогли уменьшить дистанцию установки до 2 кликов, не смогли и не смогут решить проблему доверия пользователей к посторонним надстройкам. Все надстройки останутся маргинальными, пока есть вызывающий доверие владелец сайта. А если доверия не будет — в интернете скорее появится другой сайт с другим владельцем, вызывающим доверие, чем кто-то будет массово «спасать» первый сайт, целиком завися при этом от сайта-донора.
Аддоны браузеров
Юзерскрипты, запускаемые после запуска скриптов страницы не всегда устраивали (их немногочисленных) пользователей. Скрипт страницы успевал что-то сделать ненужное, попортить внешний вид, мелькнуть баннером и вообще — потратить время процессора на своё исполнение. Поэтому у Firefox, начиная с версий 0.Х был изначальный подход в идее построения системы плагинов, более простых в написании, чем плагины IE и чем никуда не исчезнувшие плагины самого Firefox. Если задача позволяет ограничиться меньшим кругом технологий, чем знание всего строения браузера, то она решалась в рамках построения аддона (add-on) на базе технологии XUL (XML User Interface Language), сделанной специально для работы с Firefox, движком Gecko и основанных на нём продуктах.
Со временем и этот подход пересматривался, и для аддонов Chrome, которые получили название «extensions», уже не изобретали новый язык и технологию (аналогично и Safari extensions). Всё построено на HTML и Javascript API. Со временем понадобилось создавать много похожих надстроек, API множатся, частично дублируясь, в Chrome Apps, Chrome OS, но подход не выглядит неповоротливым и не создаёт специфического порога вхождения. Порог есть, но он определяется строением приложений как фреймворков (например, нужно знать назначение элементов файла manifest.json) и количеством функций API.
В итоге
В результате, в зоопарке браузеров получили не очень разнообразный, что уже хорошо, зоопарк аддонов, расширений и скриптов.
* Greasemonkey и Scriptish в Firefox — addons.mozilla.org/en-US/firefox/
* юззерскрипты в Firefox, Chrome, Опере и Safari (с NinjaKit) — userscripts.org/
* расширения старой Оперы; новой Оперы — addons.opera.com/en/extensions/
* расширения Хрома — chrome.google.com/webstore/category/extensions
* приложения Хрома — chrome.google.com/webstore/category/apps
* расширения Safari — extensions.apple.com/
Можно вспомнить, уже в прошедшем времени, про расширения старой Оперы, которых было относительно немного, но они были достаточно просты на уровне сложности расширений Safari и Chrome. Новые расширения для новой Оперы, построенной на том же движке, что и Chrome, имеют минимум отличий по функциям от расширений Chrome. Скорее всего, там присутствуют ограничения из-за нереализации специфических особенностей браузера Chrome, но не отличия в движках и API.
В процентном отношении, наиболее активно развивается ветка расширений Хрома. Это — и наиболее популярный и быстрый браузер, работающий везде, и хорошо развиваемое и гибкое API, и простота доступа к нему.
Как примеры, можно привести много расширений, сделанных специализированно для сайта Habrahabr и ориентированных за последние 2 года в первую очередь на Chrome.
Автор: spmbt
