Про Хабракат — хорошая идея: можно определять, есть ли в статье этот тег, а если его вдруг нет, то добавлять ссылку «хабракат в студию!». То есть, как только человек 100 тыкнет на кнопку и хабракат всё-таки появится в статье, она сама смоется. ;-)
А ещё, как вариант, можно рядом с ссылкой-кнопкой «ответить» (на комментарий) добавить ещё одну, примерно как «сделать приватную дискуссию»: собрать имена пользователей, участвующих в данной ветке и сделать небольшой инбокс. Было бы тоже полезно в некоторых случаях.
Я сделал вывод, что для Хабрахабра это уже не первый пользовательский скрипт. Регулярно пользователи создают что-нибудь новое и оформляют это вот в виде таких скриптов. Я думаю, большинство в курсе как их устанавливать, а кто не в курсе — могут спросить в комментариях. Люди у нас добрые, люди подскажут.
Чтобы использовать пользовательские скрипты, вам следует поставить расширение Greasemonkey. Данный скрипт — не расширение, а лишь пользовательский скрипт.
Я не решаю, когда ей появляться. Я лишь добавляю кнопку для того, чтобы пользователь сам решил, когда форме нужно появиться, а когда ей нужно скрыться. Не скрипт должен командовать пользователем, а пользователь должен использовать функции, предоставляемые скриптом.
Здесь можно полагаться только на чувство меры человека, отправляющего сообщение об ошибке. Я думаю, что после публикации статьи автор продолжает следить за ней (и заодно за своей Хабрапочтой), поэтому заметит пришедшее сообщение и постарается исправить указанную в нём ошибку. После этого другой читатель статьи уже не пришлёт подобное сообщение. Посмотрим, что получится.
В конце концов, эту форму можно использовать не только как сообщитель об ошибках, но и как форму для благодарения автора, правда, в таком случае, её не мешало бы переименовать.
Давайте попробуем посмотреть на то, что происходит внутри браузера.
Каждое расширение должно зарегистрировать объект, который будет прослушивать запросы браузера. При появлении нового запроса (и последующей загрузке данных с удалённой страницы), расширению будет многократно передан объект документа, ассоциированный с данным запросом. После этого можно обратиться к свойству документа, отвечающему за хранение текущего URI. Это свойство обычно заполняется сразу после того, как браузер начал свою работу по выполнению запроса, потому что URI удалённой страницы заранее известен. После того, как получен URI, можно проводить его проверку на соответствие нужному. Обычно это производится с помощью регулярного выражения.
Из этого можно сделать вывод, что основной урон производительности наносит не сама проверка адресов, а регистрация большого количества прослушивающих объектов, каждому из которых нужно будет передавать инициализированный объект документа (иногда даже не один раз, а несколько: на каждом этапе загрузки удалённой страницы необходимо обновлять соответствующий ей документ [такая загрузка есть инкрементальная загрузка]). В случае же с GreaseMonkey регистрируется один такой слушатель (в лучшем случае, если у нас только он и установлен), и он реализует проверку соответствия URI текущего загружаемого документа и зарегистрированных.
GreaseMonkey выгоднее для производительности, но если установлены другие расширения, то эта выгода сходит на нет.
GreaseMonkey также, в любом случае, является расширением, так что в производительности разницы особой нет между расширением, написанным с нуля, и связкой GreaseMonkey + Userscript.
Про Хабракат — хорошая идея: можно определять, есть ли в статье этот тег, а если его вдруг нет, то добавлять ссылку «хабракат в студию!». То есть, как только человек 100 тыкнет на кнопку и хабракат всё-таки появится в статье, она сама смоется. ;-)
А ещё, как вариант, можно рядом с ссылкой-кнопкой «ответить» (на комментарий) добавить ещё одну, примерно как «сделать приватную дискуссию»: собрать имена пользователей, участвующих в данной ветке и сделать небольшой инбокс. Было бы тоже полезно в некоторых случаях.
В конце концов, эту форму можно использовать не только как сообщитель об ошибках, но и как форму для благодарения автора, правда, в таком случае, её не мешало бы переименовать.
Каждое расширение должно зарегистрировать объект, который будет прослушивать запросы браузера. При появлении нового запроса (и последующей загрузке данных с удалённой страницы), расширению будет многократно передан объект документа, ассоциированный с данным запросом. После этого можно обратиться к свойству документа, отвечающему за хранение текущего URI. Это свойство обычно заполняется сразу после того, как браузер начал свою работу по выполнению запроса, потому что URI удалённой страницы заранее известен. После того, как получен URI, можно проводить его проверку на соответствие нужному. Обычно это производится с помощью регулярного выражения.
Из этого можно сделать вывод, что основной урон производительности наносит не сама проверка адресов, а регистрация большого количества прослушивающих объектов, каждому из которых нужно будет передавать инициализированный объект документа (иногда даже не один раз, а несколько: на каждом этапе загрузки удалённой страницы необходимо обновлять соответствующий ей документ [такая загрузка есть инкрементальная загрузка]). В случае же с GreaseMonkey регистрируется один такой слушатель (в лучшем случае, если у нас только он и установлен), и он реализует проверку соответствия URI текущего загружаемого документа и зарегистрированных.
GreaseMonkey выгоднее для производительности, но если установлены другие расширения, то эта выгода сходит на нет.