Наша бессмысленная погоня за семантической ценностью

Дивья Маньян 9 августа 2012

Мета-утопия — это мир достоверных метаданных. Когда же отравителю становится выгодно отравить колодец, то мета-воды становятся крайне токсичными очень быстро.

Кори Доктороу

Позвольте мне описать одну ситуацию:

  1. Вы разрабатываете сайт.
  2. И думаете: «Так. Надо бы добавить элемент».
  3. Потом думаете: «Нет. Добавление <div> вызывает у меня чувство вины. Каша из дивов — это ужасно, я же про это знаю».
  4. Потом: «Ну, нужно что-то ещё использовать. Например, сюда может подойти элемент <aside>».
  5. Погуглив три раза и прочитав пять статей, вы приходите к выводу, что в данном случае использовать <aside> семантически неправильно.
  6. Вы останавливаетесь на <article>, потому что по крайней мере это не <div>.
  7. Только что вы выкинули в помойку 40 минут, ничего не прибавив к вашему коду.

Это просто полный отстой

Эта тема поднимается уже не в первый раз. В 2003-м году Энди Бадд написал статью о выборе между семантической чистотой и семантическим реализмом.

Если ваша главная проблема с HTML5 — выяснить какая разница между <aside> и <blockquote> или, скажем, как правильно разметить адрес — знаете, вы используете HTML5 не для того, для чего он предназначен.

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

Веб больше не состоит из структурированного содержимого

В золотые времена веба страницы замысливались как хранилища информации и смыслового содержимого — и ничего больше. Сейчас в вебе есть содержимое, но его смысл — производная от действий пользователей с этим содержимым.

XML, RDFA, Dublin Core и другие структурированные спецификации применимы для очень важных сценариев использования, но в число этих сценариев не входит большинство взаимодействий внутри веба. Чёрт побери, нет ни одного сайта, на котором действительно существовала бы та идеальная семантическая разметка, которую требуют эти спецификации. Об этом гораздо лучше, чем я, пишет Марк Пилгрим.

Если у вас есть содержимое, которое требует семантической чистоты: библиотечный каталог, документ с оглавлением, онлайн-книга (то есть всё, для чего имеет смысл семантическая чистота) — тогда, разумеется, верстайте его так, оно соответствовало алгоритму разметки HTML5 и спорьте сколько угодно о том, какой элемент должен быть <article>, а какой — <section>. Нет ни одного инструмента, с помощью которого пользователь мог бы напрямую, благодаря этому алгоритму, построить оглавление документа. Ни в одном браузере таких инструментов тоже нет.

Это делает содержимое доступным?

Если причина, по которой вы используете семантическую разметку — доступность для людей с нарушениями восприятия, поймите, пожалуйста, что в действительности доступность и семантическая разметка очень слабо коррелируют друг с другом по причине массового неправильного использования HTML-разметки в вебе. Я бы сослалась на пост Марка Пилгрима об этом, но он недоступен, так что придется вот так.

Теги <b>, <strong>, <i> и <em> совершенно эквивалентны тегу <span> с точки зрения спецификации. И некоторые теги HTML5 — тоже.

Как написано в HTML5 Accessibility, практически каждый новый элемент HTML5 дает специальным возможностям для пользователей ровно столько же семантической информации, сколько элемент <div>. Так что если вы думаете, что использование элементов HTML5 сделает ваш сайт более доступным для людей с нарушениями зрения, подумайте ещё раз. Сколько дополнительной информации содержат теги <figure> и <figcaption>? Нисколько.

Недавний спор (или, скорее, разгромный пост) об элементе <time> — ещё одно доказательство недолговечности семантического значения, которое связывается с тем или иным элементом.

Это облегчает поиск по содержимому?

Если великая цель, для достижения которой вы используете семантическую разметку — SEO, что ж, знайте, что большинство поисковых систем не станут доверять странице больше из-за её разметки. Единственное, что рекомендуется в руководстве Google по поисковой оптимизации — использовать релевантные заголовки и ссылки (другие поисковые системы работают точно так же). Будете ли вы использовать элементы HTML5 или <strong> и <span> — это никак не повлияет на восприятие вашей страницы поисковыми системами.

Есть другой способ предоставлять поисковым системам больше данных — использовать микроданные (microdata и Schema.org — прим. редактора). Это никак не повлияет на положение вашей страницы в поисковой выдаче, но это добавит полезную информацию к результатам поиска в том случае, если поисковая система посчитала ваш сайт подходящим.

Это делает содержимое портируемым?

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

… Ману Спорни сказал, что ребята, занимающиеся семантическим вебом, по результатам исследований заключили, что внешние данные (out-of-band data) сложнее держать синхронизированными с содержимым. Могу сказать, что в случае MediaWiki это не так… Единственные сценарии, которые я могу придумать для использования RDFa или микроданных вместо отдельного RDF — это либо если у вас нет достаточно хороших инструментов для генерации страниц, либо если вы хотите, чтобы метаданные обрабатывались специфическими, заранее известными клиентами, которые поддерживают только встроенные метаданные (например, поисковые системы, поддерживающие спецификацию Schema.org и т.п.). Если страница всё равно обрабатывается скриптом, и если автор скрипта имеет доступ к инструментам на стороне сервера, которые могут извлечь метаданные в отдельный RDF-поток, тогда в обычном случае опубликовать отдельный поток должно быть так же просто, как и встроенный. И это сохраняет довольно большой объём данных, который передается просто так при каждой загрузке страницы.

Что же теперь делать?

  1. Никакого вреда от использования элементов <div> не будет, вы можете спокойно продолжить использовать их вместо <section> и <article>. Мне представляется, что мы должны использовать новые элементы для того, чтобы сделать разметку более читаемой, а не для того, чтобы добиться внутреннего семантического соответствия правилам разметки самим по себе. Если вы хотите использовать HTML5-элементы <section> и <article>, чтобы улучшить какую-нибудь текстовую документацию для того, кто действительно её впоследствии прочитает — пожалуйста, делайте это.
  2. Уже сейчас существуют иструменты, которые пользуются элементами <nav>, <header> и <footer>. NVDA делает заключение о предполагаемой семантике документа с помощью этих элементов. Эти элементы просто понять и просто использовать.
  3. Стандарт ARIA достаточно хорошо поддерживается программами, читающими с экрана, но будьте осторожны при их использовании с элементами HTML5.
  4. В HTML5 масса новых возможностей. Мне кажется, что мы должны изучать их, использовать и высказывать своё мнение, чтобы сделать эти возможности более функциональными и стабильными. Да, большинство этих возможностей предполагают, что вы понимаете JavaScript, пишете на нём и применяете те функции, которые помогают пользователям более полно взаимодействовать с вашим сайтом. Если эта задача кажется вам слишком сложной, учитесь писать код, особенно на JavaScript.

Что вы думаете?

Эта статья является авторским мнением и может не соответствовать мнению редакции. Согласны ли вы с автором? Расскажите об этом в комментариях. Если вы готовы высказаться самостоятельно, написав возражение — свяжитесь с нами.

Перевод оригинальной записи «Our Pointless Pursuit Of Semantic Value» Дивьи Маньян (Divya Manian), опубликованной на сайте Smashing Magazine. Переведено и опубликовано с разрешения журнала и автора.

Перевод выполнил Влад Андерсен.

Теги: , ,

Комментарии +

  1. Elena 20 августа 2012 в 17:56

    Прочитав статью, сложилось впечатление, что основная мысль автора - "Зачем что-то менять и обновлять, если и старое работает?!"
    И почти все аргументы ведут именно к этому выводу.

    А ведь и правда, зачем?
    У нас же есть IE6, который умеет работать с веб-страницами.
    Есть Windows XP, которая тоже имеет графический интерфейс и является полноценной ОС.
    Есть Notepad, в котором тоже можно редактировать и писать код.
    Все эти указанные примеры полностью соответствуют своему предназначению.

    Но тем не менее, почему-то на свет вышел IE9 (и уже демо IE10), появилось больше кол-во альтернативных браузеров, которые лучше/удобнее.
    Появились и новые ОС Windows 7 и Windows 8 с поддержкой новых функций, более приятным и удобным интерфейсом.
    Мы - разработчики (web или desktop - нет разницы) не кодим в обычном notepad без необходимости.
    Мы используем специальные программы, которые так и называются - "среда разработки", они разработаны с учетом всего необходимого для процесса разработки.

    Почему же мы отдаем предпочтение эти новшествам?
    А потому они удобнее, практичнее, приятнее. И все они будут дальше модернизироваться и улучшаться. Ведь это и есть прогресс - движение вперед.

    Тоже самое касается и новых стандартов.
    Да, спецификации дополнились, появились новые правила, порядки.
    На ознакомление с ними надо уделить время.
    Но это ведь не освоение знаний с нуля - это корректировка и дополнение, повышение квалификации специалиста (которого, кстати, могло бы и не быть, если бы он когда-то не изучил первые для себя понятия html|css).

    Лично у меня ушло около 1,5 часа времени для первоначального обновления своих знаний по html5 (из них 1 час на видео от Пепелсбея и 30 минут на прочтение спецификации по новым тегам и их свойствам). Да, дальше я возвращалась к спецификации пару раз, но только что обновить или уточнить свои знания в конкретных случаях.
    Но я не жалею этого потраченного времени, поскольку это помогло мне сделать свой код короче, чище, читабельнее, по нему легко ориентироваться и мне, и моим коллегам.

    Элементарные примеры экономии:
    1) Есть навигационное меню с ссылками.
    По новому стандарту я сделаю с помощью nav и a-шек. Если по-старинке, то через ul, li и a. А потом еще в дополнение надо обнулить значения в css (чтобы убрать штрихи и дефолтные отступы).
    2) Вставка музыки/видео. Для html4 мне надо будет подключать дополнительные плагины, которые смогу отобразить плеер и проиграть эти файлы. В html5 мне достаточно использовать соответствующие теги и указать пути к файлам.
    Примеры еще можно приводить и приводить.

    Но сколько же статей в интернете, которые также критикуют дополнительное время на изучение спецификаций, критикуют использование дополнительных классов (модификаторов), правильное именование классов, использование комментариев: "Ведь и без всего этого все будет работать".
    Будет, но заявленной производительности или скорости по факту и нет.

    Да, я потратила это время, постигла дзен и больше не копаюсь в горе из селекторов, не вылавливаю часами баги из-за того, что какие-то селекторы друг друга переопределили.
    Я дописала немного кода, поставила классы - и жизнь уладилась.
    А дала правильное имя и модификатор, разделила разные части кода комментами, и жизнь уладилась не только у меня, но и у моего коллеги, которому может достаться поддержка моего проекта.
    Это достаточно очевидные вещи, на которых видно, что скорость никак не теряется, а жизнь становится лучше :)

    В сторону скорости можно указать и момент использования нового css3.
    Разве не быстрее написать 1 строку css для появления тенюшки/скругленного угла/градиента/прозрачности, чем сидеть и вырезать из макетов тонны графики, делать из них спрайты, а html засорять лишними блоками, обертками, подписывая в разные места хаки, при этом забивая на опрятность кода для нормальных браузеров?
    А потом запускать и вылавливать баги от своего IE-шки.
    В то время, как css корректно отработает при условии соблюдения правил. Для старых браузеров же сработает деградация.

    Абсолютно не согласна с тем, что семантика и использование новых стандартов не понимается браузерами.
    Еще как понимается.
    Гугл лучше и быстрее обрабатывает сайты на html5, они выше в выдаче.
    Семантичная верстка более адаптивная к различным устройствам - правильно сверстанный сайт будет корректно отображаться и масштабироваться как на PC, так и на планшетах.

    Есть еще один интересный момент. В странах СНГ он не так популярен, но на западе на него давно обращают внимание - это верстка для слепых.
    Ведь слепые/слабовидящие такие же равноправные члены общества, которые тоже хотят пользоваться благами нашего прогрессивного общества.
    И тут опять приходит на помощь семантика. Потому что именно благодаря правильному обозначению элементов, указанию всех соответствующих атрибутов браузер сможет корректно считать страницу и перевести ее в "режим ограниченных возможностей".

    Так стоит ли так цепляться за старое?
    Может стоит сделать шаги вперед к улучшению и воспользоваться по-полной бонусами, которые мы можем получить уже сейчас?

    Наша IT сфера одна из самых непостоянных. Она постоянно движется и развивается. И мы, как специалисты этой сферы, должны постоянно ей соответствовать, повышать свой уровень квалификации. Аналогично, как врач должен знать о новых вирусах, препаратах и методах лечения, а строитель - о новых стройматериалах и их свойствах.
    А квалификацию никак не повысить, если не уделять это "лишнее" (по мнению автора) время и не работать над собой.
    По факту, достаточно 1 раз уделить время на прокачку 1 объема знаний - и они у тебя будут на службе. И дальше просто обновлять, пополнять их и конечно использовать на практике.
    Только так можно стать(оставаться) специалистом высокого класса.

  2. Антон 20 августа 2012 в 21:46

    Elena, меньше пафоса.

  3. Михаил 21 августа 2012 в 17:24

    Elena, ваши аналогии некорректны, нет никакого смысла изучать и применять что-то новое, если это не дает новых возможностей или не улучшает существующие. А с новыми элементами это именно так. Есть только небольшой набор элементов, которые действительно что-то улучшают (datalist, например). В большинстве случаев же, разработчики тупо копируют из проекта в проект html5shiv для старых IE в надежде, что использование section и aside добавит семантики и от этого будет лучше поисковикам и людям с ограниченными возможностями, но это не так.

  4. ko 21 августа 2012 в 19:19

    Антон, Елена всё правильно сказала.

    Вообще я автора непойму, на своем сайте он использует адаптивную верстку, теги nav, blockquote и атрибут placeholder. Наверно он избавляется он конкурентов)

  5. Даник 22 августа 2012 в 15:45

    Лично я не использую всякие новомодные footer, section, nav и тд - а нафига? Они ни чем не лучше div.footer, div.section, ul.nav, не дают преимуществ, зато добавляют еще одну зависимость от js (для ие7-8) - да нафиг она нужна то?
    А вот placeholder я с удовольствием использую - тут наборот, можно избавиться от js в нормальных браузерах( для ие как полагается - костыль). И это удобно и работает лучше чем onfocus/onblur. И доктайп я использую краткий - ибо это удобней, и не создает никаких проблем.
    nav a я не использую, потому что мне нужны теги ul > li > a > span для добавления микроданных (Breadcrumb) . Ведь это удобнее чем nav > div > a > span. Плюс даже без стилей документ выглядит корректно(хотя в этом нет реальной пользы)

    Итог: плевал я на всякие aside - div с понятным классом - наше все. Другими словами Divya все правильно пишет!

  6. Elena 25 августа 2012 в 0:45

    Михаил, вы точно полностью знакомы со всем новшествами html5?
    Судя по Вашему ответу, нет, раз вы не считаете, что в новых тегах нет бонусов.

    Вы пишете:
    "В большинстве случаев же, разработчики тупо копируют из проекта в проект html5shiv для старых IE в надежде, что использование section и aside добавит семантики и от этого будет лучше поисковикам и людям с ограниченными возможностями, но это не так."
    Почему вы утверждаете что это неправильно? Разве не улучшиться семантика и читабельность страницы браузером?
    Вы точно знакомы с темой верстки для режима "ограниченных возможностей"? Уверена, что нет.

  7. Elena 25 августа 2012 в 0:49

    ko, спасибо!
    Тоже для себя отметила момент с сайтом самого автора статьи :)
    Первым делом после прочтения решила его посмотреть - сплошной html5!
    Почему-то весь контент четко разложен по семантичным уровням.
    Для себя автор не поленился "потратить 40 минут времени".

  8. Elena 25 августа 2012 в 1:17

    Даник, вы пишете только про 1 единственную "устрашающую" вас зависимость от js для старья (ИЕ7-8).
    Но! Поясню, чем она не страшна.
    Вы сверстали страницу, использовали короткий доктайп (кстати, все противники html5 почему-то сразу ухватили эту новую фишку, удобно ведь ;) ). Контент у вас располагается по соответствующим тегам.
    Какие бонусы получаем на выходе:
    1) Чистый код - семантический HTML код чище и меньше по объему, чем не семантический. А чем меньше кода, тем проще найти нужный участок или локализовать ошибку, с ним проще работать.
    2) Понятный (читаемый) код — имеет важное значение, когда над сайтом работает команда разработчиков.
    Когда ты не фрилансер, а член целой команды, то с этим фактором приходится считаться.
    3) Семантический код напрямую влияет на объем HTML кода. Меньше кода —> легче страницы —> быстрей грузятся, меньше требуется оперативной памяти на стороне пользователя, меньше трафика, меньший объем баз данных. Сайт становиться быстрей и менее затратным (очень важно, когда идет разработка сайта с большим числом пользователей....тут каждый байтик на счету).
    4) Упрощается жизнь и для пользователей голосовых браузеров, для которых важны теги и их атрибуты, чтобы произнести правильно и с нужной интонацией содержимое, или наоборот не произнести лишнего.
    5) Сейчас в повседневную жизнь вошли мобильные устройства, которые не на полную мощь еще поддерживают CSS и поэтому ориентируются в основном на HTML код, отображая его на экране согласно используемым тегам. Т.е. не придется создавать отдельную версию верстки под них - ваша будет по умолчанию отображаться корректно.
    6) Получаем бонус при использовании дополнительных плагинов, которые позволяют быстро перемещаться по документу.
    7) Поисковые системы постоянно совершенствуют методы поиска, чтобы в результатах была та информация, которую действительно ищет пользователь. Семантический HTML способствует этому, т.к. поддается гораздо лучшему анализу — код чище, код логичен (четко видно где заголовки, где навигация, где содержимое).

    Итог, ваш сайт обновлен, получает ряд бонусов и будет иметь выигрышное положение ближайшие годы - он перспективный. Совсем близко время, когда отойдут и ИЕ7-8. И что вам надо будет сделать, так просто удалить 1 строку в html, где вы подключаете html5.js. А не переверстывать, подправлять свое детище под новые требования, которые у заказчиков будут появляться.

    В чем с вами могу согласиться и поддерживаю - так это нацеленность на классы. Но чистое указание классов, без использования селекторов.
    Указание селекторов в css приводит к замедлению отработки css браузером, а также путает самого верстальщика.
    Вы пишете, что лучше будете использовать " div.footer, div.section, ul.nav". А что вам тут мешает просто оставить в css ".footer, .section, .nav"?
    Уж точно у вас не будет в html такого:
    :)

  9. Андрей 26 августа 2012 в 18:36

    Всем привет!
    Я лично использую HTML 5 тэги (т.е. именно те тэги, которые кроме семантики ничего не привносят) по следующим причинам:
    1. Хорошая читаемость. Тут спорить никто, думаю, не будет. Полотно из дидов читается хуже. Отмечу также, что IE 7-8 я не поддерживаю, и нет причин не использовать новые тэги.
    2. SEO. Зря вы полагаете, что поисковые движки не используют новые тэги в своих алгоритмах. Гугл во всю уже оперирует этими тэгами и не собирается останавливаться. Если навигация будет в nav, то Гуглу будет проще состряпать карту вашего сайта и при выдаче показывать её. Если адрес вашей конторы положить в address, то скоро при выдаче рядом с линком будет и карта с вашим адресом, и тд и тп. Про людей с ограниченными возможностями можно не упонимать.
    3. Чистый HTML, не засоренный CSS стилями. Опять же хорошая читаемость кода. Гораздо приятнее читать чистый html без классов, без айдишников.
    Пример: есть простой попап с хэдером, футером, ну и скажем c блоками полей внутри.

    
    div class='popup'
       header
       section
          label
          input
          label
          input
       section
       section
       ...
       footer
    
    

    Так вот, достаточно добавить класс лишь к верхнему диву.
    А остальное в css. Т.е. достигается максимальное отделение контента от дизайна, а это один из основных принципов верстки, точно так же как и отделение контента от его поведения (js). Popup в нашем случае компонент. И классом popup мы задаем и дизайн и поведение одновременно. Всё чисто, красиво и читабельно. Примерно по такому принципу пишут Twitter Bootstrap (правда классов там чуть-чуть больще).

  10. Some Guy 28 августа 2012 в 15:17

    У многих в сознании пересекаются «семантика», «SЕО» и «валидация» там, где оно не должно пересекаться. Оттуда и рождаются мифы в стиле «замени div на header — посетителей прибавится на 10%» или «google забанит сайт за использование -webkit-border-radius». Неграмотные СЕОшники подливают масло в огонь.

  11. Some Guy 28 августа 2012 в 15:18

    p.s. бывают исключения, типа тега nav и input type="email", потому что они уже работают в iPhone.

  12. Ed 2 сентября 2012 в 4:51

    @Андрей насчет третьего пункта не согласен. В css лучше использовать классы чем селекторы с наследованием. Это повысит скорость загрузки страницы.

  13. Богдан 3 сентября 2012 в 15:10

    Похоже на тролинг..
    Помните времена - верстали таблицами .. а div это для семантических задротов..))

    Думаю всегда будут те кто не признаёт эволюционных этапов развития, web верстка в частности.

    Документ должен быть грамотно размечен.. а используешь HTML5 или XHTML тут не важно..

    И ещё умиляют фразы .. доктайп строчкой это удобно..
    хех..
    Мой аргумент при сокращенном доктайпе сложнее проверять код на валидность

  14. SelenIT 3 сентября 2012 в 20:43

    при сокращенном доктайпе сложнее проверять код на валидность

    На валидность чему, простите?

    а используешь HTML5 или XHTML тут не важно..

    Загвоздка в том, что даже если автор думает, что использует XHTML — браузеры всё равно воспринимают это как HTML5, со всеми вытекающими. По построению браузерных парсеров и самого стандарта. Поэтому лишние символы в доктайпе вносят лишь путаницу.

  15. Богдан 6 сентября 2012 в 11:54

    На валидность чему, простите?

    )) что за нах?
    (валидация - проверка синтаксической корректности кода)

    Загвоздка в том, что даже если автор думает, что использует XHTML — браузеры всё равно воспринимают это как HTML5

    может вы имели ввиду различный Content-Type: text/html или text/xml? и браузеры по умалчанию парсят XHTML как text/html?

    HTML5 — попытка определить единый язык разметки, который мог бы быть написан как в HTML, так и в XHTML и был бы синтаксически корректен.

    Лишние символы.. путница...ну ну...
    Моё мнение в XHTML strict больше порядка чем путницы..
    я не кого не переубеждаю и не настаиваю

  16. SelenIT 6 сентября 2012 в 18:31

    проверка синтаксической корректности кода)

    Продолжайте, пожалуйста. Можно с конкретными примерами. Фрагмент кода <div/> — синтаксически корректен? А <br></br>?

    может вы имели ввиду различный Content-Type: text/html или text/xml? и браузеры по умалчанию парсят XHTML как text/html?

    Прекрасно, а как современные браузеры (FF4+, Хром 7+, Сафари 5.1+, Опера 11.6+, IE10) парсят text/html? И как на это влияет доктайп?

    попытка определить единый язык разметки, который мог бы быть написан как в HTML, так и в XHTML и был бы синтаксически корректен.

    Это называется Polyglot Markup. Это возможно в HTML5 (в отличие от прошлых версий), но обязательно ли?

  17. Богдан 6 сентября 2012 в 20:32

    А ?

    в контексте xml - корректен

    Перевод строки делать тегом контейнером?
    Откройте смысл сего примера?
    Тогда как вам ?

    Это называется Polyglot Markup.

    Polyglot Markup: HTML-Compatible XHTML Documents
    W3C Working Draft 29 March 2012
    Как же мы жили без этого... у меня открылись глаза...
    спасибо .. теперь солнце светит гораздо ярче и теплее..
    До новых встреч

  18. SelenIT 7 сентября 2012 в 2:11

    в контексте xml

    В контексте XML оба примера корректны. И потому полностью валидны в XHTML любой разновидности. Потому что XML-у начихать на смысл, для него все теги равноправны, его единственная забота — синтаксис. Деление элементов на пустые и контейнеры, блочные и текстовые, замещаемые и т.п. — это уже уровень DTD (или того, что пришло ему на смену).

    А вот при HTML-парсинге как минимум первый пример точно поломает вёрстку (поскольку это незакрытый тег).

    Как же мы жили без этого... у меня открылись глаза...

    Если вы жили без этого — значит, вы никогда не читали спецификации XHTML (или читали в ней только выделенное зеленым и красным). Если слова «жопа» отдельной спецификации для чего-либо нет, это не означает отсутствия самого предмета. Хотя и спецификация была (хоть ее и забросили в связи с роспуском рабочей группы XHTML2 и признанием идеи XHTML тупиковой, а наработки переняла рабочая группа HTML5).

    Открывайте глаза почаще, это полезно для кругозора (и безопасности:). И на будущее старайтесь подкреплять самонадеянность не грубостью и неуместным сарказмом, а «железным» знанием матчасти. В общем, приятно было побеседовать, приходите еще! :)

    P.S. Для примеров разметки используйте &lt; и &gt;.

  19. Adaptor 2 февраля 2013 в 4:41

    Верстальщик для пользователя или наоборот ...
    У человека устаревшая ОС и браузер? Ну и что? Они лицензионные. Человек не вор и вам ничего не должен.
    И как видео, подключенное одним тегом, будет выглядеть в IE6 или Firefox 3? Ах надо обновляться и пользователь чайник ... Пользователь не всегда может и должен следить за новинками. Он пользователь, а не веб-мастер. И всегда прав. И пользователи все разные. А ты верстальщик и должен под них всех подстроиться.
    Тебе проще в HTML5? Да пожалуйста! Но не в ущерб пользователю.
    Нужно вынудить пользователей перейти на новые технологии? Это не благодарное занятие. А иногда и не выгодное, если речь идёт о коммерции. Например, Windows 8 продаётся ещё хуже чем Vista (источник: http://ru.wikipedia.org/wiki/Windows_8). Или как массово люди стали мигрировать с Ubuntu на Mint после смены Gnome 2 на 3. Ну и так далее. Вам проще писать код? А пользователю это интересно? А покупателю?

  20. Андрей 5 октября 2014 в 16:45

    Он пользователь, а не веб-мастер. И всегда прав.

    Всегда прав сервер.
    Вы же в театр с поп-корном и бутылкой пива, надеюсь, не ходите? Я, как веб-мастер, автор того что делаю и именно я буду решать, что и кто будет смотреть.
    Безусловно должен быть баланс доступности, но вы же не забегаете в магазин компьютерной техники с криками дать вам шариковую мышку с COM разьёмом. Процент использования старых версий IE в общей сложности сейчас упал ниже 10%. Так что моё мнение - пусть эти гордые 10% испытывают разочарование где нибудь за пределами моего домена.

Перейти к началу