Tom Adler’s blog

скрытые данные в html5

В спецификации html5 сейчас есть любопытное свойство элементов dataset, идущее в комплекте с атрибутами data-*. Эта парочка предназначена для удобного встраивания скрытых данных в документ. Например, яваскрипту, обрабатывающему элементы списка, могут пригодиться внутренние системные айдишники этих объектов, но сейчас у разработчика нет нормального способа разместить эти данные в документе. Конечно, числа можно с какими-то особыми префиксами запихать в атрибуты id или class, но я бы не стал хвастаться таким подходом. Кроме того, с более сложными данными это не прокатит. Вариант включать эти данные в скрытые элементы нравится мне ещё меньше.

Теперь нам предлагается, что атрибут data-name будет доступен как свойство name в свойстве dataset самого элемента. Подробнее об этом в посте «HTML 5 data- Attributes» Джона Резига, который и сподвиг меня на действие. (Кстати, там в комментах любопытный флейм.) Но на пути к счастью стоит обычная проблема: браузеры эту фичу ещё не поддерживают. И решается она обычным способом — небольшой доработкой фреймворка.

Element.addMethods({
    getDataset: function(element) {
        if (element.dataset) return element.dataset;
        var match, dataset = {};
        $A(element.attributes).each(function(attr){
            if (attr.nodeName.startsWith('data-'))
                dataset[attr.nodeName.substring(5)] = attr.nodeValue;
        });
        return element.dataset = dataset;
    }
});

Конечно, круче было бы использовать геттер, но рано ещё : (

update: вместо localName нужно использовать nodeName

, ,

мои.рекомендации.filtered

я читаю новости в Google Reader. В нём есть возможность отметить новость особой галочкой, в результате чего она попадёт в поток рекомендованных мной новостей и на экраны к тем, кто его читает. Проблема в том, что помимо серьезных вещей я рекомендую довольно много развлекательных. К сожалению, гугл не даёт возможность разбить рекомендации по тегам ридера (а назначать их каждый раз вручную мне влом). Но у нас есть мощный инструмент обработки фидов — Yahoo.Pipes, и мы можем его использовать!

схема будет довольно простая: берем поток рекомендованных новостей и поток вообще всех новостей с нужным тегом, и находим их пересечение, оставляя только рекомендованные новости с этим тегом. Правда, пересечение тоже приходится получать через задний проход: объединять два потока, группировать записи по урлам, и выбрасывать всё, что не сгруппировалось.

вот результат: страница самого конструктора и фильтрованный по тегу rss-поток рекомендаций, на который я рекомендую подписаться всем читателям : )

кстати, вы можете легко собрать для себя аналогичный конструктор — достаточно склонировать мой, благо Pipes это поощряет кнопкой Clone ; )

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

tinyMCE v3

TinyMCE уже давно — один из лучших wysiwyg-редакторов на javascript. Я раньше работал со второй его версией, а теперь мигрирую на третью. И я очень сильно впечатлён улучшением качества кода в новой версии: предыдущая была кашей в духе раннего PHP, а сейчас всё очень стройно, правильно, и в соответствии с рекомендациями.

только одно плохо — старый код для него приходится переписывать подчистую : )

, ,

javascript libraries un-benchmark

сегодня обнаружил в рассылке прототайпа интересное письмо от John Resig:

I wanted to bring up one point: we at the jQuery project have had a long-standing policy of not releasing library speed comparison numbers. It looks like you're shooting for some performance optimizations here so you'll be forced to make a similar decision.

We've found that public multi-library comparisons just lead to needless bickering and frustration, especially when only one author controls the tests. Now private comparisons - or tests that've been mutually agreed upon - are absolutely fine. Competition is healthy and everyone benefits from the result.

I'd just like to ask that if any comparison tests are created that we be contacted and be given, at least, some lead time. We will be happy to do the same for you, should the situation ever arrise.

Happy hacking!

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

кстати, команда прототайпа планирует множество оптимизаций. Можно посмотреть планы на 1.6.1, но для понимания неплохо бы знать внутренности библиотеки.

,

кому решать проблемы навигации?

Нашел сегодня via Simon Willison пару любопытных обсуждений «навигационного поиска»: «The Truth about Web Navigation» и «Will Mainstream Users Ever Learn About The Browser's Address Bar?». Давно не секрет, что многие пользователи вводят веб-адреса не в адресную строку, а в поле поиска, и потом переходят по первой ссылке, но я в первый раз задумался, какие выводы из этого можно сделать. Может быть, проблема всё-таки не в юзерах?

Если искать корень зла в браузерах для простых людей, то найдутся довольно любопытные вещи. Во-первых, чаще всего юзеры делают так потому, что стартовой страницей задан поисковик, и фокус уже стоит в поле ввода поиска, поэтому можно сэкономить один клик, не переводя фокус на адресную строку. Не означает ли это, что сама идея стартовой страницы плоха? Вдруг разумнее пойти по следам Оперы (опять? : ), и показывать аналог Speed Dial, с наиболее употребляемыми страницами и полем поиска? Вроде бы Firefox уже движется по этому пути, и после свежей установки предлагает пользователю несколько соответствующих локали ссылок.

Во-вторых, поиск сайтов через гугл даёт неплохую степень защиты от фишинга. Да, все популярные браузеры, кроме Сафари, уже защищают пользователя, но защищают с другой стороны. Если юзер уже оказался на вредном сайте, и кто-то уже внёс этот сайт в базу данных о фишерах, то юзера предупредят, да. Но вдруг проблему можно было решить раньше, ещё когда юзер опечатался при ввода адреса? Предложить ему более известный вариант, чтобы никто не перепутал whitehouse.com и whitehouse.gov.

Ну и наконец — неустранимая проблема: как бы мы ни старались использовать ЧПУ на наших сайтах, всё равно урлы не очень-то дружелюбны к пользователю. Взять хоть символы «://», или весь ворох проблем с субдоменом www, и схемой http. Строка поиска в этом плане гораздо более приятна, потому что более-менее понимает обычные человеческие слова, написанные обычным образом через пробел, безо всяких слешей. Может быть, через несколько лет именно она займёт центральное место в интерфейсе, оставив технарям включение адресной строки в настройках?

Кстати, о тех сопутствующих фичах, которые мы сейчас включаем в строку адреса: RSS, сертификаты, закладки, виджеты, Universal Edit Button. Юзеры их не видят, потому что даже не смотрят на адрес. Может быть, поэтому индикация опасных сайтов сейчас стала делаться не в адресной строке, а на весь экран? Модальные интерфейсы для простых людей, немодальные — для гиков?

,