(Дата публикации оригинала — 12.04.2013)
Выбор JavaScript MVC фреймворка — тяжёлая работа. Нужно учесть много факторов, и число вариантов выбора может быть огромно. Достаточно взглянуть на проект ToDoMVC (о нем по-русски).

Я работал с 4 фреймворками: Angular, Backbone, CanJS и Ember. Поэтому решил сделать сравнение, чтобы помочь вам решить, какой из них использовать. Я выделю несколько факторов, которые вы можете использовать при выборе. Каждый фактор будет иметь оценку от 1 до 5 (больше — лучше). Я старался быть беспристрастным, но, конечно, оценки основаны на личном опыте.

В расширениях Хрома принято указывать версию скрипта в виде не более чем 4 чисел, разделённых точками, и величиной не более 32767 каждое и не начинающихся с цифры 0. Этого более чем достаточно, если в номер версии включены обычные данные: версия, подверсия, сборка. Если в версию хотим поместить дату в виде 3 чисел, то в наиболее удобной для чтения записи (версия.год.месяц.день) числа года, месяца и дня занимают 3 места из 4. На версию остаётся первое число (как более приоритетное перед датой), а на подверсию и минор ничего не остаётся. Задача: как расположить минорную версию, чтобы уложиться в формат, чтобы дата была читаемой, а версия с минором при сравнении 2 строк занимала правильное место в ряду версий? Кроме того, нужна процедура выделения даты и версии с минором из общей строки.

Время от времени всплывает умирающая технология XSLT и задаёт непростые вопросы. Как, например, взять максимум от 2 чисел в выражении или как организовать цикл. Соединением многих таких вопросов служит пагинатор — вывод навигации по нескольким страницам и, по возможности, удобный. На Javascript есть много примеров простых и удобных пагинаторов. Но если страницы с сервера выдаются в XML, то возникает крамольная мысль: почему бы всё оформление страниц, включая пагинатор, не сделать на статике, в XSLT? Ничего, что в эту статику можно включить JS и сделать всё проще. Кошерный подход лёгких путей не ищет.

Всё дело — в политике безопасности, аналогичной кроссдоменной. Обращение к страницам других табов или к фоновой странице расширения сознательно ограничено, потому что они считаются страницами других доменов, имеют запреты на прямой доступ к скриптовому окружению, аналогично чужим окнам и фреймам. Механизм сообщений «спасает» как при кроссдоменном доступе между фреймами, как и в доступе к страницам расширений (фоновая, настройки, попап, ...).

В расширении браузера Google Chrome (и Chromium) наиболее важна по функциям — фоновая страница. Она имеет специальный URL вида chrome-extension://ciegcibjokpkcklhgbpnmnikpkmkhbjk/, где длинное имя домена — случайное имя, создаваемое в недрах браузера, которым именуется также каталог расширения где-то в служебной папке ОС. Из контентного скрипта (аналогичного юзерскриптам, исполняемым на странице браузера) можно получить доступ к файлам и картинкам расширения. Но нельзя выполнить много функций, путь к которым лежит через фоновую страницу: устроить хранилище, относящееся к группе реальных доменных имён; хранить настройки расширения, общие для всего расширения. Нужно лишь добраться в Мордор к фоновой странице. Однако, нельзя просто так, по URL, это сделать.

Рассмотрим нетрадиционные способы комментирования сообщений в форуме на примере сайта Х и скриптов автоматизации HabrAjax. Они, как известно, имеют основное назначение — смотреть статьи и комментарии без перезагрузки страницы. Смотреть — это не писать в ответ, не ставить оценки комментариям, а просто смотреть. Если захотим прокомментировать, то у нас нет API Хабра, которое позволило бы отправить комментарий. Придётся открыть статью в новом окне, найти тот же комментарий и ответить на него. Неудобно. Но есть механизм контекстного цитирования и ответа на цитату, который до сих пор работал для комментариев в одиночной статье, но не в подгруженной статье в ленте. А также — он работал везде (в подгруженных и одиночных статях) для написания писем (личных сообщений) через Хабр.

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

Если надо что-то почитать с Хабра, а сайт не работает (как было за последние пару часов), раньше было только ожидание или переход на другие ресурсы. Сейчас в скрипт HabrAjax добавилось распознавание пустой страницы, которая бывает при 500-й ошибке, и предложение посетить страницы копировщиков. Страница — совсем без оформления, потому что стили сайта ведь тоже не подгружены. Но это — лучше, чем наблюдение пустой страницы и поиск аналогичных решений самостоятельно. Если просматривается статья, лежащая в Гугло-кеше, она читается (со стилями ZenComment, если они установлены). Как показывает опыт, страницы довольно быстро попадают в гугло-кеш (минуты — десятки минут), поэтому имеем слепок сайта незадолго до аварии.

Разница лишь в том, что «заход» на сайт через Гугло-кеш происходит из-под неавторизованного пользователя. Поэтому ленту /feed так просмотреть будет невозможно, а переход по ссылкам каждый раз будет сопровождаться предупреждением, что сайт не работает.

Опишем концепт интерфейса контекстного ввода цитат. Речь будет не про те облака, о которых все подумали. Облака — типа бенчмарка «Heaven», 4-я версия которого недавно вышла (рис. слева) или Небесного замка Лапута, а цитатник — элемент интерфейса типа летающих островов. На поверхности этих островов теплится жизнь, а сами они могут летать. В нашем случае — перемещаться мышью. Опору их составляют камни, а у нас — контекстные кнопки.

Как создаётся летающий остров? Выделяем мышью контекст. Выделение создаёт основу поверхности — цитату. Под ней появляется кнопка, едва заметная, полупрозрачная, которую мы привыкли видеть в Ворде, начиная с «2007». Она может вскоре исчезнуть, и правильно, если выделение текста создавалось для других целей. Но если навести мышь — создаётся опора нашего будущего цитатника, парящего в облаках.

Зачем нужен цитатник? Оказывается,

Пост содержит пару предложений по улучшению оформления Хабра.
1. Ввести флажки «Новость» для публикующих. Причём, лучше, если помечать будут таким флажком короткие новости, а не подробные обзоры нового, типа «Вышел sublime text 3 beta» с описанием нововведений.
2. Считать статьи с хабом «Переводы» переводом.

Поскольку предложения нескоро появляются в реализации, а то и вообще не появляются, соблюдена традиция: все предложения по возможности реализованы в HabrAjax. В нём появились пометки новостей по некоторым формальным признакам.

Опережая Ализара...
Нет, вопрос не в соревновании, а просто раньше, в новости про портирование игры на Linux (вышедшей под Windows 14 лет назад) и в других местах интересовались о доступности под MacOS. И вскоре, без лишнего шума и пыли, Half Life оказалась доступной на MacOS. На странице информации об игре с датой последнего изменения 26 января обнаруживается поддержка версии MacOS:

name_macos: 	Half-Life (Beta)
oslist:	windows,macos,linux

Традиционная работа HTML-страниц с картинками заключается в раскрывании картинок вместо этих страниц. Пришла пора прекращать это неудобство на отдельно взятом сайте. Ссылки — хорошо, но удобный просмотр — лучше.

Что такое удобный просмотр? Пример "лайтбоксов" разных показал, что лучше открыть псевдоокно просмотра внутри документа, не удаляя документ. Но при чтении статей этот подход не очень удобен. Мы не видим контекст документа. Получается, что видна или картинка, или документ. Лучше, если картинка не закрывает текст, как организовано, например, в скрипте Dollchan Extension Tools (подсказали здесь), где просмотр картинок занимает малую часть общей функциональности просмотра «имаджбордов» — примерно таких же текстово-картиночных потоков статей. Сделаем и мы контролы управления картинками, добавив кое-что своё.

Рассмотрим задачу парсинга HTML на клиенте (Javascript) с последующим оформлением полученных данных стилями и вёрсткой и выводом их в нужные места страницы просмотра. Применение такой подгрузчик страниц и блоков нашёл в юзерскриптах — когда разработчики подгрузчика никак не связаны с разработчиками сайта. Но есть основания использовать подход и для обычных сайтов для полного отделения View от Model.

Статья получилась теоретической, потому что из-за её объёма я не стал перегружать её практическими результатами. Да и трудно пока представить некие шаги, по которым каждый мог бы подхватить идеи и начать строить подобное. Вначале надо посеять идеи, но пока попытки посева (здесь, на Хабре) не давали всходов, хотя я и не особо старался в этом направлении. Подход развивался последние полгода и был даже анонсирован на Хабре примерно в апреле-мае. В статье рассказано, «как это сделать», и перечислены преимущества подхода. Он требует глубокого и специфического программирования на JS. По результатам работы, скорее всего, имеет смысл выделить библиотеку для аналогичных задач.

Цель заметки — показать один онлайновый сервис просмотра символов Юникода, поскольку в нём их удобно искать, и сравнить его с множеством похожих. Периодически бывает нужно найти среди множества текстовых символов, поддерживаемых некоторым шрифтом, те, которые наиболее точно передают мысль или отражают суть высказывания. Этим давно пользуются посетители различных соцсетей, где выразительные способности символов давно оценены и существуют руководства с перечислением сотни-другой интересных символов. Каких? Самых оригинальных, и, казалось бы, не нужных серьёзным разработчикам, для которых адресована данная статья: звёзды разных очертаний, стрелки, снеговики, часы, эмоции.

Разработчикам фронтенда бывают нужны символы для быстрого прототипирования страниц. Вместо того, чтобы потратить время на поиск или отрисовку символа, его возможно найти в шрифте, например, Arial или Helvetica и создать временный элемент интерфейса. Иногда нужно посмотреть и использовать символы редкого языка, иероглифы. Многообразие символов уже имеется в некоторых шрифтах некоторых ОС, остаётся «лишь» выбрать. В программах и самой ОС есть средства просмотра и выбора символов любого шрифта системы (пример). Но не всегда эти средства удобны и не всегда предоставляют нужную информацию. Становится нужен хотя бы один онлайновый сервис, чтобы взять, и быстро (попытаться) найти подходящее. Раньше помогал поиск таблиц юникода в интернете, но удручал их вид, редкость и слабая оформленность. И тут недавно появляется сервис, в котором создатели решили исправить ряд досадных интерфейсных недостатков поиска.

HabAjax — скрипт, который существует около года, выполняет много мелкой и крупной работы по оформлению страниц сайта. Начавшись приблизительно с 20 функций обработки страниц, он развивался и получал новые возможности. Поддерживается 3 основными браузерами — Firefox, Opera, Chrome и несколько отошёл от поддержки 4-го браузера — Safari. Его основная цель — представить страницы более компактными и с меньшим количеством графического мусора — элементов, без которых можно обойтись.

 

В последние дни, наверное, все, использующие Punto Switcher (начиная с некоторой, не очень старой версии) и имеющие выход в интернет, получили такое сообщение, как на скриншоте:

Punto Switcher: доступно обновление.

Что же в этом криминального, спросит читатель?
Суть ситуации подсказывает слово «все» в первом предложении. «Все» — это означает "даже те, кто не собирался узнавать и обновлять". Иллюстрацию поясняет следующий скриншот:

Из-за того, что под название каждой статьи в футере отводится 33%, а длина названий различна, появляется пара-тройка неприятных эффектов:
1) пустоты, если названия короткие, а соседнее — длинное;
2) названия прилипают к верхней кромке блока;
3) кликать нужно только на текст, а не на весь блок.

Например, здесь в средней ссылке, как и во всех, надо целиться в текст.

Все, кто привык к полноценно оформленным страницам сайтов, предпочитает вид «прибитого» (прилипающего, sticky) к низу футера страницы. Но есть в интернете две беды: нерастущие вниз поля ввода и неприбитые (к низу окна) футеры. Например, когда открываем короткие по высоте страницы типа habrahabr.ru/settings/social — сразу бросается в глаза, что информация, призванная быть в нижней части окна просмотра, прилипает к содержанию и находится где-то посередине, а то и в верхней части окна, когда внизу — пусто.

Так, вместо того, чтобы .
Данное пособие для начинающих верстальщиков покажет, как за 45 минут сделать «прибитый» футер, исправив недоработки даже такого уважаемого издания, как Хабр, потягаться с ним в качестве исполнения своего перспективного проекта.

Сегодня на сайте появился блок «Похожие посты», сразу после статьи, перед комментариями. Его формат выделяется стилевой «непричёсанностью», если смотреть через юзерстили ZenComment, поэтому захотелось «облагородить» его. Сразу же выявился дополнительный интересный факт: на самом деле, в них присутствует не 4, а 12 ссылок, остальные 8 просто скрыты. Далее, оказалось, что этот блок просто перенесли из правой панели, немного пообтесав.

Если в стандартной вёрстке этот блок выглядит сравнительно нормально и даже даёт долгожданный разделитель между статьёй и комментариями (не очень заметный тем не менее), то в стилях ZenComment, ценящих компактность, он выглядит инородным и нарушающим общий стиль. Решение? Взяться за дело и исправить стиль представления, заодно открыв временно скрытые похожие посты.

Но даже и без стилей ZenComment в статье есть, что предложить сайту, чтобы показать не 4, а все 12 ссылок на похожие статьи.

Изменение политики установки юзерскриптов в Google Chrome.

В браузере Chrome версии 21 появилось новшество, известное ещё с её бета-версии: при попытке установить юзерскрипт браузер выдаёт провокационное, но некорректное по сути сообщение (в баре на странице вверху):

Расширения, приложения и пользовательские скрипты могут быть добавлены только из Интернет-магазина Chrome. Подробнее…

Ещё 20 августа было всё нормально, но с установкой новой версии политика начала действовать.

На самом деле, как они дальше поясняют, это утверждение неверно и представляет собой, по сути, дешёвый провокационный трюк, подталкивающий авторов опубликовать расширения в их «магазине». Выгода небольшая, но прямая, потому что регистрация автора — платная (однократно 5$), и часть авторов пойдут на это, потому что не каждый пользователь нажмёт ссылку «Подробнее...» и так и будет думать, что устанавливать расширения стало возможным только из «магазина». Даже поиск в Яндексе показывает такой типичный ход мыслей пользователей:

(Окончание перевода статьи Эдди Османи о сравнении и выборе библиотеки для проекта со значительной ролью JS на клиенте.)
Содержание первой части:

■ Что такое MVC или, лучше сказать, MV*?
■ Когда нам нужен MV*-фреймворк JS?
■ Где же мы будем нуждаться в MV*, а где нет?
■ Проблема выбора: слишком много вариантов?
■ TodoMVC: общее приложение для обучения и сравнения
■ Предложенные нами критерии выбора фреймворка
■ Dojo и усложнение фреймворков на JavaScript
■ Коллекция TodoMVC (фреймворки, на которых сделаны реализации тестового приложения Todo)