Здравствуйте дорогие читатели. Я уже говорила, что с удовольствием размещу гостевые статьи в своём блоге. На этот призыв недавно откликнулся товарищ Игорь, из нового белорусского digital ресурса wedigital.by, представив прекрасную статью-исследование по работе веб студий в Беларусии. Оригинал статьи, также размещён тут: Как белорусские веб-студии отвечают на запросы клиентов. Я надеюсь вам будет интересно.
Как белорусские веб-студии отвечают на запросы клиентов
Мы устроили небольшую проверочку самочувствия обычного клиента, который собирается заказать разработку самого обычного сайта. Оказалось не таким уж простым делом выбрать подходящую веб-студию и получить добросовестный и адекватный ответ на письмо. Нами взяты 44 компании из топа Яндекса по запросу “создание сайта” в регионе “Минск” и из рейтинга marketing.by на 2011 год:
Поскольку я давно не писала(отдыхала, болела, и т.п.), я думаю что самое время дать слово гостям моего бложика. Если вы IT-специалист и вы хотите донести до мира какую-то важную информацию — Welcome! Либо если хотите попиарить свой блог — это тоже хороший способ. Перевод иностранных статей также приветствуется, обязательно со ссылкой на орининал.
Так же в списке статей — и на самой странице статьи везде будет указано имя автора.(и предположительно аватар).
Я обещаю что вернусь к написанию статей в ближайшее время.
Хочу написать пару интересный вещей, на случай если кому-то пригодится.
1) В файрфоксе вкладки можно прикреплять, тогда вкладка будет считаться "App tab", будет всегда прикреплена слева иметь приоритет выполнения скриптов такой же как активная вкладка.(В неактивных вкладках различные анимации и т.п. будут приостанавливаться). Но главную интересную фишку, я нашла недавно. Прикреплённые вкладки, например gmail могут мигать, оповещая пользователя об изменениях на странице. Мигает вкладка в том случае — если у данной страницы меняется title. Это легко проверить следующим кодом:
<script>
// for firefox glowing pinned tab
// window.setInterval(function(){document.title=Math.random();},500);
</script>
2) В случае с <input type="number">, если вы сами хотите оформить стрелочки инпута — движки webkit позволяют их отключать. Используйте вот такой код:
input::-webkit-outer-spin-button,
input::-webkit-inner-spin-button {
/* display: none; <- Crashes Chrome on hover */
-webkit-appearance: none;
margin: 0; /* <-- Apparently some margin are still there even though it's hidden */
}
Хочу специально заметить что в случае полей ввода для цифр — не желательно использовать input type="text", так как на мобильных устройствах для этих полей будет показываться текстовая клавиатура, вместо числовой.
Пока этого нет в nightly, но надеюсь скоро появится. Так что можете заранее начать переделывать иконки своих сайтов, если хочется =). Будьте первыми. Надеюсь другие браузеры так же будут использовать большие иконки в своём UI.
Замечу что это касается только favicon.ico. Для айпадика например вы можете задавать большие иконки, но для совершенно других целей.
With Apple's formatting(rounded corners, reflective shine)
4) Ни для кого не секрет какой тормозной плагин скайпа к браузерам, который подсвечивает телефоны на странице. Он перехватывает все изменения DOM в поисках номера, чем заметно тормозит скрипты, и портит дизайн страницы. В Firefox этот плагин в чёрном списке(надеюсь что приложила к этому руку). Тем не менее, где-то мелькала новость что плагин на конкретном сайте вебмастер может отключить добавив следующий метатег.:(подробнее тут)
Вчера мы с коллегами настроили ещё один метод подтверждения писем, под названием DKIM. Его можно использовать вместе с SPF.
Authentication-Results: mxfront7.mail.yandex.net; spf=pass(mxfront7.mail.yandex.net: domain of usabili.ru designates 209.85.212.180 as permitted sender) smtp.mail=askme@usabili.ru; dkim=pass header.i=@usabili.ru
Разница в том, что SPF - подтверждает IP адрес отправителя. DKIM же ip-адрес не учитывает, но подтверждает факт того, что конкретно отправитель имеет секретный ключ, который можно проверить публичным ключом, указанным в днс-записи.
Яндекс, судя по всему, считает DKIM более приоритетным средством борьбы со спамом. См. статью «Цифровая подпись — Яндекс.Помощь: Почта». По этой причине, только письма проверенные через DKIM получают красивенькую медальку рядом с адресом отправителя.
Проверка DKIM для получателя гораздо проще, чем SPF. Так как для проверки DKIM требуется запросить всего одну днс запись, например для моего домена default._domainkey.usabili.ru, и получить оттуда публичный ключ домена, которым можно проверить хеш заголовков, т.е. цифровую подпись(что докажет что я владелец секретного ключа).
В случае же с SPF, процедура проверки сложнее, т.к. надо взять днс запись, из неё взять список разрешённых ip, и ссылки на другие spf записи, которые тоже надо рекурсивно обработать и т.п. Затем сверить ip отправителя с данным списком. В случае, когда письмо проходит через несколько серверов, желательно подписать их все.
А вот отправителю, наоборот, настроить у себя поддержку SPF на порядок проще, чем настроить DKIM. Как я уже писала, для настройки SPF достаточно создать запись:
usabili.ru. IN TXT "v=spf1 a include:_spf.google.com ~all"
Эта строчка разрешает слать почту только с ip указанного в A-записи домена, и с серверов гугл.
Зайти на нужную страницу в панели владельца домена гугл
Выбрать домен и получить код для вставки в днс
Вставить нужный код в TXT запись поддомена. Например, у меня google2._domainkey.usabili.ru
Активировать
...
Profit. Ваши письма, посланные из Gmail, теперь подписываются ключом домена.
Как настроить подпись писем с сервера, при отправке через PHP
Если вы отправляете письма в PHP через SMTP сервера гугла, то всё уже сделано. Гугл использует подпись при отправке через SMTP.
Если же вы отправляете почту функцией mail, то в системе необходимо установить пакет dkim-filter.
yum install dkim-filter
Или
aptitude install dkim-filter
Затем сгенерировать ключ через dkim-genkey. Лентяи вроде нас, могут использовать его для всех доменов на сервере. Сгенерированный в файле .txt публичный ключ нужно добавить в днс записи доменов.
Пользователи линукса могут набрать команду # dig google2._domainkey.usabili.ru TXT
Либо послать письмо на ящик в гугле или яндексе.
В гмайл, если нажать на стрелочку, будет видно что-то типа
от:
BoughCMS Notifynoreply@usabili.ru
кому:
***
дата:
28 июня 2012 г., 15:08
тема:
Usabili.ru: Письмо с сайта
отправлено через:
***.ru
подписан:
usabili.ru
Заключение
Хочу обратить внимание на ещё несколько пунктов.
Если вы используете возможность гмайла "Отправлять письма как:", т.е. не отправлять их напрямую со своего ящика. То гмайл будет подписывать DKIM оригинальным ящиком отправителя, а не вашим доменом.
Если вы абсолютно уверены, что успешно настроили DKIM, то можете запретить другим серверам принимать письма с вашим доменом, но без подписи, добавив ADSP запись:
_adsp._domainkey INTXT"dkim=all"
Update
Я совсем забыла рассказать про то как присваивать доменные подписи конкретным email адресам. Дело в том что вы можете отправить почту с домена X, через почтовый сервер домена Y, а подписать его ключом домена Z. И это даже будет работать =). Настройка ключей происходит в файле /etc/mail/dkim-milter/keys/keypath. Здесь стоит обратить внимание на часть строк, задающую sender-pattern, она может содержать звёздочку, как часть или весь домен. В случае указания просто звёздочки, данным ключом и доменом будут подписываться все письма.
# sender-pattern:signing-domain:keypath
# *:example.com:selector
*@usabili.ru:usabili.ru:/etc/mail/dkim-milter/keys/default
# тут всякие остальные домены, а ниже домен для подписи по-умолчанию.
*:verytec.ru:/etc/mail/dkim-milter/keys/default
Внимательный читатель заметил, что путь к секретному ключу один на все домены. Это ничуть не мешает работе подписей.
Так что я предлагаю вам описание от автора. Которое правда весьма сумбурно, по сути это цитаты из логов скайпа. Я постаралась почти не цензурировать всю экспрессию, но оформить из этого нормальное описание. Плюс я помогла сделать пару demo и, главное, demo_bookmark, так чтобы можно было заранее примерить тулбар на любом известном вам сайте.
Я уже несколько лет читаю статьи с призывами "Остановим IE6", "Поместим кнопочку, чтобы апгрейдили" и т.п. Даже Microsoft сделала пару сайтов по этому поводу. Отдельные сайты протестуют против отдельного IE6. Везде пишут поучаствовать — но никто не предлагает как. В лучшем случае делают прямоугольные баннеры "stop ie" — большого размера. Причём страшные, что пиздец. А пользователи ie6 — не ходят на сайты посвящённые протесту ie6 — они ходят на сотни других интересных сайтов.
Я бы рад был поучаствовать раньше — но блин меня останавливало 3 момента:
Куда приткнуть злосчастный баннер, если нет места.
Если тулбар — то его надо самому верстать, и он точно сломает вёрстку тех элементов, которые абсолютно позиционированы от границ body.
Почему только ie? Мне вот недавно сказали, что у одного из сайтов едет вёрстка в Opera 9 — я даже отвечать не стал. Плюс, нельзя человеку советовать, например, обновить ie8 до ie9, если у него XP.
Ещё мне никогда не нравились ссылки, потому что по ссылкам "Скачайте новый браузер бесплатно" — всегда вирусы или реклама. Поэтому в тулбаре вместе со ссылкой я пишу кратко, как обновить браузер из самого браузера. Плюс тулбар сделан неброским.
Тулбар будет показывать пользователю предложение обновить браузер, если у него старое говно.
В скрипте, для примера сейчас список стабильных версий специально завышен. Чтобы сейчас любом браузере можно посмотреть результат, в качестве стабильных в demo используются версии:
var stable_browsers={'Explorer':10,'Firefox':15,'Opera':12,'Chrome':22};
Если не задавать версии в ручную, то по умолчанию используется следующее:
var stable_browsers={'Explorer':8,'Firefox':4,'Opera':10,'Chrome':10};
Это вариант когда обновить предлагается совсем уж старое п.о. Все цифры, разумеется можно указывать дробно, например 'Opera':11.64.
Сложнее всего было сделать корректный тулбар под ie6+, так что под ie6-7 не так красиво как под ie8 и обычные браузеры.
Особенность тулбара — в том что он никак не херит существующую вёрстку: http://2s.ru/2012/t142_browser_suggest/demo2_ru.html — пример — где вёрстка с абсолютно позиционированным блоком справа, и футером точно внизу страницы.
Тулбар подстраивается так — чтобы не затронуть никакие стили body — он как бы подвигает весь body и все его элементы вниз. Весь день на это потратил. На сайте игры(*название вырезано. прим. Елена, потому что пока сырая альфа.*) будет примерно этот же тулбар + не будет показываться блок входа вообще в случае IE. Вместо него ещё одно предупреждение.
Сам тулбар — в DOM лежит вне body. Т.е. он как бы прямой потомок <html>. А самому <html> задаётся paddingTop, а body - position:relative. Для ие6-7 к сожалению нельзя создавать элементы прямо в <html> приходится сувать в body. Но вёрстка от этого не сильно пострадает. В ие6-7 и без тулбара вёрстка страдает =)) Т.е. он всё равно ведь будет позиционироватся над body. Т.е. с отрицательным margin. А paddingTop у <html> работает и в ие6.(Прим. Елены: Вот например скриншот usabili из ie6, в тех местах где вёрстка поехала — тулбар не виноват. Замечу, что как раз тут видно что все абсолютно позиционированные элементы сверху — очень правильно сдвинуты тулбаром вниз).
Так же js содержит в себе png градиент, для ie8+ и нормальных браузеров. в ие 6-7 градиент делается через filther, поэтому я его красненький сделал. Сами иконки браузеров правда не вшил пока в код, а так бы совсем хорошо было.
Как-то распространить надо бы. Я залил это в открытый репозиторий на https://bitbucket.org/mr_troll/bs_toolbar/ может кто форкнет. А так же теперь добавлен репозиторий на GitHub — https://github.com/mr-troll/bs_toolbar
Так что в идеале, можно будет вбить список минимально допустимых версий и ставить этот скрипт вообще на каждый сайт.
Т.е. в самом мягком варианте — показывать тулбар только для ie6-7, firefox< 3, Opera< 10, Chrome <10(владельцы интернет магазинов редко любят у себя лишние тулбары, но всегда можно договориться).
Если владелец сайта не против инноваций — то можно и для ie8 показывать и для FF<10, Opera<11.5, и Chrome<18.
Спрайты
Как уже говорилось, градиент тулбара уже вшит в js-код. Но спрайты браузеров пока нет. Вот они:
На всех страницах бложика — тулбар работает со стандартными настройками. Если перейти конкретно на страницу этой новости(не на главную) — то тулбар будет форсированно показан. Как он вам, дорогие читатели? Оставляйте комментарии, читайте код, присылайте правки, делайте переводы на другие языки или делайте свой форк. Ну, и самое главное, скачивайте и ставьте тулбар на свои сайты, давайте немножко ускорим исчезновение старых браузеров.
Долбаная прокрастинация. Нужно заканчивать важный проект, а я с утра 4 часа занималась редизайном блога.
Вот неполный список правок:
Увеличен размер шрифта статей. Потому что текст статей — это единственное и основное что есть в блоге.
Изменён шрифт заголовков. Да, я знаю что уже 5-6 шрифтов используется в оформлении блога, и можно было использовать Arial, но мне этот нравится. Мой же блог =). Раньше был Hortensia, теперь Conkordia.
Картинка со ссылкой на RSS теперь больше и заметней
Вёрстка теперь лучше себя ведёт на разных разрешениях. В общем-то ориентировалась я конечно на большие разрешения. Но волею судеб у меня сейчас 15' монитор, так что при низком разрешении всё тоже надеюсь получше.
Регистрация стала ещё быстрее и проще. Теперь окошко открывается на той же странице. Замечу, что регистрация и раньше была простой, т.е. пользователю нужно заполнить всего три поля: Отображаемое имя, email, и пароль. Подтверждения email не требуется, вдруг пользователь захочет указать левое мыло — его полное право, правда он тогда не сможет восстановить пароль если его потеряет, и я не смогу написать ему лично, но это ведь его осознанный выбор. Пароль так же не нужно повторять. Я уверена, что любой человек читающий мой блог сможет ввести свой пароль в регистрации без ошибок, если не сможет — значит он сильно пьян. В любом случае сразу после регистрации его автоматически залогинивает(кукса ставится на год, так что восстанавливать пароль ему придётся не скоро). Так же во всех моих проектах я настаиваю на том, что в регистрации нельзя ограничивать пароль. Когда на каком-то левом сайте, например торрент-трекере мне пишут что длина пароля минимум 6 символов — я бешусь, я становлюсь Халком и перехожу на тёмную сторону силы. Более того, мои клиенты студии — сами настаивают чтобы пользователь мог регистрироваться вообще без пароля. В онлайн-магазинах 95% пользователей регистрируются чтобы сделать один заказ, и более никогда не вернутся. Так же движок блога никогда не ограничивает символы в пароле — потому что пароль должен всегда и у всех хранится как md5, а не в открытом виде, так что ограничений в пароле вообще нет.
Ну, а главное изменён блок авторизации. За пару лет, с момента предыдущего редизайна, я написала несколькостатейоб авторизации. Я наконец применила их и для своего блога. В частности форма ввода логина и пароля показывается сразу, это позволяет браузеру заполнить пароль автоматически, а также возможность открытого пароля, что полезно для планшетных устройств. Если вы уже залогинены, вы можете выйти по ссылке logout и посмотреть.
При комментировании незарегистрированным пользователем — ему теперь подробно описывается что на регистрацию тратится 5 сеунды, либо ему придётся совершить движение мышкой и поставить галочку, я недеюсь что это остановит большую часть ботов(я не хочу показывать капчу даже гостям).
Форма быстрого поиска с поисковыми подсказками также ищет теперь чуть лучше(используя не только fulltext search но и прямое вхождение, а так же более правильную релевантность). Кстати Лебедев сделал себе вчера такой же. А у нас он уже полтора года на всех сайтах. Я писала год назад про Opensearch тут и тут.
Собственно всё. С радостью выслушаю все отзывы и пожелания.
Как сказал Якоб Нильсен(Jakob Nielsen) в своей недавней статье«Computer Screens Getting Bigger» — экраны компьютеров становятся больше.(На что кстати сослался Лебедев =)).
Дословно, гуру юзабилити сказал следующее: "Дизайнеры должны начать экспериментировать со способами утилизировать горизонтальное пространство экрана, и создавать веб-страницы с улучшенным взаимодействием для людей с большими и широкоэкранными мониторами.(Они так же должы использовать методы, такие как responsive design, для продолжения поддержки маленьких экранов, которые будут с нами до конца десятилетия)".
И вот вопрос вам, дорогие читатели — как мы можем это сделать?
В моей практике, я использовала несколько простых приёмов:
Если у вас есть, каталог товаров — вы можете использовать float или inline-block, чтобы разместить их на экране.
Вы можете использовать css media queries или их js-эквиваленты, например чтобы сделать размер текста или картинок больше и т.п.
Вы можете просто задать свойства min- и max-width для вашей обёртки контента(такой как body). Я так делаю в вёрстке блога, чтобы задать размер статей между 1000 и 1200px по ширине, для меня 1200 — это предел читабельной ширины строки текста. Так же я делаю для магазинов, чтобы при разрешении 1920px они не выглядели плохо.
Если ваш сайт, на самом деле веб-приложение, например онлайн игра, тогда вам нужно принимать целый комплекс мер, который относится к разработке пользовательского интерфейса, особенно оптимизируя сайт под мобильные устройства, так что я спрашиваю не о них.
Так же потихоньку разрабатывается свойство css text-size-adjust. Говорят на уровне префиксов кроме мозиллы уже поддерживается в -webkit- и -ms-, возможно можно использовать его.
Итак, вы владелец сайта, например блога, такого как мой, или магазина. Если вам гипотетически потребуется оптимизировать его для использования на мониторах шириной 2000 или 4000px, что бы вы использовали?
Или, представьте, что все дисплеи в мире шириной 4000px(не говорим про планшетки), может ли это изменить всю парадигму сайтостроительства? Какие изменения в интерфейсе браузеров могли бы произойти?
У меня чувство досады от того что данные представлены в сети не в виде "данных". Что такое "данные"? Это то что может понять компьютер. ... Я хочу представить себе мир, в котором все разместили свои данные в сети. Тим Бернерс Ли(Руководитель W3C, 2009, конференция TED).
Семантическая вёрстка — это когда я верстаю таблицами и думаю о таблицах. Или что-то типа того. Алексей Шилов aka mr.troll.
Четыре года назад мы даже не думали о HTML5(а многие ждали XTML 2.0).
Три года назад нам сказали, что HTML5 непременно к 2020 году будут использовать.
Два года назад мы узнали, что HTML5 уже можно использовать.
Год назад оказалось, что HTML5 давно все используют.
Сегодня, всё что не имеет доктайпа <!doctype html> выглядит остатками мамонтов (и пахнет точно так же).
Html5 принёс нам много-много всяких спецификаций и технологий. И хотя главное назначение html5 — это расширение мультимедийных возможностей браузера(в черновиках html5 назывался как Web Applications), всякие video и audio теги, их кодеки, canvas и WebGL, инкапсуляция(sandboxing) ифреймов и объектов, и т.п. — всё это довольно скучные для обсуждения вещи. То, что действительно интересно обсуждать — это новые семантические теги — nav, article, section, header, footer, и дюжину других.
О семантических тегах
Неделю назад(точнее уже три недели назад) вышла статья "Let’s Talk about Semantics(by HTML5 Doctor)", я настоятельно рекомендую с ней ознакомиться прежде чем читать далее.
Вот топ 10 самых популярных значений атрибутов Name и Id :
Name attribute value
frequency
Id attribute value
frequency
keywords
2,189,708
footer
288,061
description
2,100,858
content
228,661
generator
943,496
header
223,726
robots
937,844
logo
121,351
author
818,017
container
119,877
movie
530,989
main
106,327
quality
504,666
table1
101,677
revisit-after
475,765
menu
96,161
copyright
423,210
layer1
93,920
progid
281,339
В своей статье, HTML5Doctor, нас убеждают в том, что основываясь именно на данных списках и были приняты решения о внесении новых тегов в спецификацию HTML5. Однако, из таблицы видно что это не совсем так. Я очень люблю id="footer" или id="content" — но я никогда не использовала id="article". Значение "article" — находиться на 186 месте в рейтинге значений класса и на 728 месте в рейтинге значений id. Т.е. данные атрибуты используют меньше чем 0.1% вебмастеров из статистики. Я считаю что это очень показательные цифры, я не могу понять почему html5doctor ссылается на них.
Так откуда же появились новые теги? Если ответить коротко — они просто придуманы редактором спецификации html5 Яном Хиксоном(Ian Hickson). Когда я спросила его об этом два года назад, он ответил примерно следующее:
Element names in HTML have little relationship to the usage of those names
in reality, to be honest. I wouldn't pay too close attention to the
meaning of the element names in common conversation; only their definition
in the spec matters. - Ian Hickson(16 Mar 2010)
Это честно. И вполне разумно. Я верю что Ян Хиксон проделал колоссальную работу по составлению списка данных тегов и максимально конкретных описаний и примеров к ним. Однако большой проблемой является то, что все веб-разработчики по разному понимают данную спецификацию(ситуация чем-то похожа на библию). Кто-то прочитал и понял неправильно, кто-то подумал что он понял правильно, у многих вообще не было времени чтобы прочитать её, но было время прочитать статьи популярных авторов которые писали о том как поняли они, и т.п.
Также есть множество веб-разработчиков, которые считают, что в вёрстке названия как-то связаны с той ролью, которую выполняет тег. Я сама вкладываю в термин "семантика" именно такое значение. Было бы логично предполагать, что если тег a — означает anchor, h1 — заголовок первого уровня, abbr — аббревиатуру, то и тег menu — можно было бы использовать для меню, nav — для любого обособленного блока со ссылками на другие страницы и навигации по сайту, header — как шапку страницы, article хмм... как статью, а section — какую-то часть содержания, например той же статьи. Однако же можно привести примеры вёрстки, где, по спецификации, данные теги будут обозначать совершенно другое, и наоборот, можно привести примеры, где все значения соответствуют совершенно другим тегам.
Например тот же Ян Хиксон не рекомендует использовать тег <menu type="list"> для разметки меню. Вместо этого советуется <nav><ul></ul></nav> и т.п. Так же по спецификации возможно не рекомендуется использовать <nav> для разметки такой навигации как "хлебные крошки" и формы поиска, хотя для меня это было бы семантично(о чём я не раз писала три года назад тут и тут).
Что же я думаю по поводу новых семантических тегов? У них есть ряд положительных свойств:
В будущем можно действительно улучшить обработку и индексацию данных тегов поисковыми роботами и другими программами.
Ну, по крайней мере это лучше чем div.
Но есть и ряд и недостатков:
Названия элементов — не связаны с их значением. Например article — это любой объект который сам по себе представляет какой-то контент, а section — это группирующий элемент, например когда нужно связать много <article> воедино.(Тут важно группировать по смыслу, а не как визуальную обёртку ). Вместо <article> безусловно лучше был бы <zoidberg>.
Никто честно не говорит вслух — почему верстальщик должен использовать семантические элементы вместо div? Единственный ответ — "для поисковых роботов". Самому верстальщику — долгие раздумья, над тем какой тег использовать, приносят больше вреда чем пользы, imho.(За исключением конечно того, что таблицы надо верстать таблицами, а списки — списками. Прочие тривиальные вещи объяснял, например, Вадим Макеев, однако его объяснение про html5 не очень внятное). Веб-браузерам довольно всё равно какую кашу из тегов написал верстальщик. Прочие браузеры, типа машин Брайля — в России например составляют 0% от общего числа. Поэтому вёрстка html5 тегов — важна для роботов, и только.
Описания довольно размыты и их толкование во многом субъективно. В html 4.01 было меньше разночтений.
Очень мало примеров. В идеале — нужно создать сайт, html5samples — где собрать типовые примеры вёрстки различных сайтов. Блога, Каталога, Магазина и т.п. С подсветкой при наведении того, какие теги использовались и описанием почему. Если бы были конкретные примеры — тогда бы и html5doctor.com был бы не нужен. Вот Bruce Lawson например сделал html5 тему для wordpress, уже хоть что-то.
В html есть клёвые "стерильные" элементы div и span названия которых ничего не значат.(С большой натяжкой div можно расшифровать как division). Я считаю эти имена лучше подходят для html тегов чем "семантические" названия.
WAI-ARIA и Микроформаты
Это совершенно другой путь развития смысловой аннотации содержания. Несмотря на то что он менее удобный — верстальщику приходиться полагаться на атрибуты, а не на сами по себе теги — данный метод позволяет точно добавить семантику. Например у вас был код типа
<div style="font-size:30px;">some big big caption</div>
Несмотря ни на что — это полноценная html разметка. А затем вуаля
<div style="font-size:30px;" role="heading" aria-level="2">some big big caption</div>
Разметка показывает, что теперь это осмысленный заголовок второго уровня(конечно для тех же целей есть <h2>).
Нет никакой иллюзии в том что они используются в основном для поисковиков и других ботов.
Описания микроформатов всегда конкретны. Т.е. на каждый случай — свой микроформат.
Они отлично документированы.
В составлении микроформатов(например от Schema.org) активно участвуют сами поисковые системы — как следствие они уже хорошо поддерживаются ими.
Их проще понять
Из недостатков:
Их сложнее запомнить(если под рукой нет ссылки на wiki)
Они занимают больше места чем теги.(Однако когда не было CSS, всевозможное оформление занимало ещё больше места в html коде).
Эксперимент
Итак... После статьи на html5doctor я решила поставить небольшой эксперимент, касающийся в основном html5 тегов. Я сделала вот такой макет страницы каталога онлайн магазина:
и спросила некоторых известных людей как бы они её сверстали, по пунктам. Текст письма был примерно такой:
I have a question about semantic markup online store pages .
I'm wondering which tags you would use for the following items(see
attachment picture):
1) a horizontal menu of links to different pages
2) the entire block containing the page header(logo, cart block, and a
horizontal menu).
3) the block containing the search filters(the most important
navigation in curtain shop)
4) one filters block
5) block containing shop items
6) block of one items(which includes photo, item title, etc.)
7) pagination
8) page footer.
Can I quote your answer in my blog?
Thank you.
Данный вопрос я послала разным веб-евангелистам. Многие конечно не ответили(например html5doctor, работа у них такая, не отвечать на вопросы) — это нормально. Однако не ответил кое-кто кто обещал — это досадно. Впрочем я не буду называть тех кто не ответил, лучше поприветствуем тех кто смог ответить. Итак:
