Pull to refresh

Comments 101

Хм, странно. Большинство того, что вы перечислили, постоянно использую.
Вот Вы используете, вы молодец. Но очень много верстальщикв, особенно новичков, совсем не думают о семантике.
Так что полезная статья.
А что не используете, если не секрет?
<q> не ставит типографские кавычки, поэтому на практике бесполезен.
Можно заставить ставить любые кавычки. Правда правилам пунктуации тег соответствовать всё равно не начнёт.
Поделитесь секретом любых кавычек.

Помимо правил пунктуации есть проблема копирования «закавыченных текстов» в некоторых браузерах: текст цитаты копируется, а знак кавычек считается элементом оформления и не копируется. Тоже подстава.
Пример из MDN:

q::before { content: '«'; }
q::after  { content: '»'; }
Для Chrome такой подход имеет существенный недостаток: при копировании текста из браузера такие кавычки не скопируются.
В FF начало и конец тега <q> копируется как обычные кавычки.
Как ни странно, в IE11 всё шикарно: текст из псевдоэлементов копируется. Но даже, если псевдоэлементы не определены, кавычки “ ” вставляются автоматически (и тоже копируются).
UFO just landed and posted this here
UFO just landed and posted this here
А есть сложность в прикручивании их при помощи псевдоэлементов :before и :after? На многоязычном сайте можно было бы вообще разные кавычки для разных языков выводить, определяя нужный набор по атрибуту lang тэга html, например.
UFO just landed and posted this here
UFO just landed and posted this here
А есть нынче требование в употреблении <menu>, ведь его использование рекомендовано только в контекстных меню?
Автор некорректно изложил смысл тега <menu>.
UFO just landed and posted this here
Тема для перфекционистов. Я, конечно, тоже такой фигнёй страдаю, но иногда задумываешься о смысле жизни и о том, есть ли кому-нибудь дело до разницы между B и STRONG… Раньше все использовали B, потом это стало «несемантичным», теперь все точно так же, не задумываясь, используют STRONG, делая вид, что семантики добавилось.
UFO just landed and posted this here
Надо только не забывать, что точка зрения Google со временем меняется.
Скрин-ридеры для слепых их по-разному читают.
Ну всё-таки теги типа b или strong screenreader'ы для слепых читают как раз одинаково. В контексте web accessibility важнее семантическая вёрстка с атрибутами role и опционно с дополнительными метками ARIA.
Ой, да всё бы уже тыщщу лет назад использовали, кабы не зоопарк.
Это на хоумпейджах можно радоваться жизни.
А у больших дядек, то mutation observer нету, то 30% под ИЕ8.
НЕ травите душу, уже, а!
хм, вот смотрю частенько «отцовские сайты» студий России за которые платят миллионы рублей (например tyazhmash.com) и походу чего-то не понимаю. На старом доктайпе, с явно лишними (пустыми) блоками (вместо использования ::after), картинки с пустыми alt-ами и т.д. У верстальщика рвотные порывы на слово «семантика»? Конечно все понимают, что такое сроки, дедлайн и прочие прелести срочной работы, но не до такой же степени, чтобы в span вкладывать div-ы! (да, и такое видели, причем на XHTML доктайпе. Кто не верит могу найти).

Хотелось бы найти студию, где хоть один сайт построен так, как все вокруг спорят и твердят. На выходе имеем лишь базар как про какое-то НЛО — о нем все рассказывают, высказывают свои теории, строят догадки, кто-то даже верит, но видеть его никто не видел )

Прочел вчера на эту тему 2 статьи + 1 видео с конференции от проджект манагера одной из студий Харькова
habrahabr.ru/post/25680/
habrahabr.ru/post/114256/
У парня чуть ли не крик души, от того как все плохо вокруг верстают. Ну ок, плохо, покажи как хорошо (в статьях лишь своды правил, а хочется конкретики). Заходим на сайт его студии — ideus.biz, дабы глянуть портфолио и просветиться. И что видим, а ничего, постеснялись ребятки ссылки на свои работы давать. Их сайты до того ах%;№, что они просто постеснялись их показывать. Отличный ход, самый лучший троллинг который я когда-либо видел. )
> картинки с пустыми alt-ами
Никогда не понимал этого требования, текстовые браузеры имеют достаточно незначительный процент, обычно в alt попадает рядом написанный загаловок или оставляется пустым, имхо, это актуально для элементов управления но сейчас для иконок/кнопок никто не использует тег <img> да и не для этого он придуман.
UFO just landed and posted this here
ALT-текст нужен для пауков поисковых машин, вспомогательного ПО слепых и дислектиков, для сёрфинга на медленном соединении с отключёнными картинками… Печально, что даже здесь встречаются люди, которые этого не понимают.
Я не говорю, что он совершенно не нужен, однако его требование противоречит здравому смыслу, возьмем для примера хабр, а точнее данную страницу, тег <img> используется 2 раза, в анонсе статьи и для аватаров, в первом случае картинка не несет смысловой нагрузки(все картинки анонсов с alt=«image»), а случае аватаров очевидным alt'ом будет ник, который в ассоциации с картинкой только вреден для ревалентного поиска.

Не хотелось бы обидеть слепых и дислектиков, но картинки интересны в первую очередь как картинки, статья не станет милее от надписи "[здесь изображен котенок]".

Ну и не забываем про веб-приложения.
UFO just landed and posted this here
для слепого пользователя, очевидно, нет абсолютно никакой разницы [изображение: табличка с надписью «Сарказм»]


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

Рассуждения типа «таким пользователям это нужно, а таким — нет» — это просто прикрытие для говноделов, которые вместо того, чтобы соблюдать несложные правила, которые не требуют от них каких-то запредельных усилий, готовы выпускать дерьмовый продукт, подводя под это какую-то философию. Давайте не будем уподобляться таким людям. На худой конец, давайте просто честно признаваться, что нам лень делать так, как надо.

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

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

Кроме того, это вопрос общей грамотности разработки. Я могу написать «карова даёт малако» и оправдываться тем, что я не в школе на диктанте. Однако в обществе это всё-таки считается неприемлемым. Вот и в обществе разработчиков отсутствующий или пустой ALT-текст также должен считаться обычной безграмотностью.
В случае текстового браузера, я бы не хотел видеть надпить "[изображение: <НИК> — аватар] <НИК>", я немного параноик и не хотел бы видеть свое лицо по запросу по нику.

Повторюсь, там, где нужен alt — это контент пользователей, верстальщик и разработчик не имеет доступа к их мозгам, единственное что может сделать разработчик(в теории) — существенно ухудшить юзабилити и заставить заполнять alt. Alt нужен не всегда, а иногда даже вреден, т. к. по ряду причин с картинкой будет ассоциирован не отражающий ее реальное содержимое текст.

Отсутствие alt не должно быть нарушением синтаксиса, соблюдение синтаксиса необходимо для программ, не для людей.
UFO just landed and posted this here
В случае текстового браузера, я бы не хотел видеть надпить "[изображение: <НИК> — аватар] <НИК>", я немного параноик и не хотел бы видеть свое лицо по запросу по нику.

Нет, вы не параноик. Работодатель (а может и ваша будущая супруга) может захотеть выяснить ваш психологический портрет по всем изображениям, которые вы когда-либо использовали для своего <НИК>. А так поиск по вашему нику в картинках выдаёт картинки из всех статей, где вы когда-либо участвовали.
Всё это какой-то бред! Если уж человек занимается «социальным стриптизом» и выкладывает в Интернете свои фотографии, то о какой паранойе может идти речь? Параноики в принципе не постят свою личную информацию в открытом доступе.

Какая разница? Люди просто по нику попадут на страницу на Хабре и увидят фотографию там. Ну и кто от кого спрятался в таком случае?
Альт должен описывать содержание, а не назначение изображения. Это — альтернативная версия содержания, то, что увидят пользователи, не способные увидеть оригинальное содержание.

Альт к аватару должен быть не «НИК — аватар», а описание содержания аватара. Например, в моём случае альт к аватарке должен быть «Глаз с объективом вместо зрачка».

Это идеальный вариант, но здесь уже каждый пользователь должен будет описывать свой аватар, а на это я бы особенно не надеялся.

Я говорил о том, как это должно быть сделано с точки зрения автоматизации. Движок автоматически аватарам должен задавать именно такие описания, чтобы без возможности воспринять графику было примерно понятно, что в этом месте торчит. Если будет опция прописывания кастомного ALT-текста, то это, конечно, круто, но программа-минимум должна быть именно такой, как я описал.
тег <img> используется 2 раза, в анонсе статьи и для аватаров, в первом случае картинка не несет смысловой нагрузки(все картинки анонсов с alt=«image»),


Это косяк того, кто туда вставил эту картинку.

а случае аватаров очевидным alt'ом будет ник, который в ассоциации с картинкой только вреден для ревалентного поиска.


У аватаров должен быть alt=«oWeRQ — аватар»

Не хотелось бы обидеть слепых и дислектиков, но картинки интересны в первую очередь как картинки, статья не станет милее от надписи "[здесь изображен котенок]".


Картинки — это способ представления информации. Размещая картинку, мы делаем это не для того, чтобы разместить картинку, а для того, чтобы донести информацию. Верстальщик обязан информативно подписывать абсолютно все картинки, несущие смысловую нагрузку.

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

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

Ой, не вспоминайте об XHTML доктайпе… бОльшая часть не является XHTML, почти всегда отправляется не как XHTML…
UFO just landed and posted this here
Я тот самый «парень из Харькова» (:
Спасибо, рад что вам понравились статьи и видео!

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

Я посмотрю что из последних работ мы имеем право «светить» и выложу тут завтра ссылки.
Клацнул я тут как-то случайно на «Inspect Element» в консоли EC2. Сразу перед глазами прокрутилась стопка различных напутствий из серии «уруру float не круто, используйте inline-block, а ещё лучше flexbox».

image
Не удивительно для студий, которые на словах заявляют — «каждый элемент дизайна должен либо нести функциональную нагрузку, либо быть удалён» (своими словами), а на деле вставляют элементы с горизонтильной прокрутой (ещё и не поддерживающей горизонтальный скролл жестами) на сайт.
UFO just landed and posted this here
Не рекомендовал бы использовать <menu> для меню сайта. Так как нет четкого соглашения для каких целей его использовать.

Используемая мной структура:
<nav> <ul> <li> <a> <span>
UFO just landed and posted this here
Единственно что не использую — input time, попробовал и вспомнил почему, тупо text как-то более предсказуемо себя ведет и места меньше занимает.
Все правильно, но есть небольшой нюанс относительно
<q>
<i> и <b>
<abbr>
<mark>


Текст в основном набираеться в wysiwyg редакторах, и если редактор страницы не в курсе их существования, врят ли он их будет использовать как надо (при их наличии в wysiwyg-редакторе). И уж темболее точно не будет заморачиться о семантике.
Не понимаю минусования. Действительно, если разрабы не садисты, юзерам подсовывается wysiwyg, которому на всю эту семантику покласть. Обычные статьи очень часто пишутся не верстальщиками, поэтому про семантику можно забыть. Хорошо, если секретарши пробелами форматировать не будут…
Да я уже не удивляюсь, и спокойно к этому отношусь. Здесь уже не удивительно сливание кармы просто так, для фана (вероятно)
Интересно, насколько долго и дорого было бы обучить редактора (человека в смысле) писать, используя markdown. Или добавить в wysiwyg те самые «семантичные» кнопочки, и научить редактора их нажимать :)
Обучить — недолго. Убедить в необходимости — невозможно.
Аааа, ППКС. Мне тут однажды в ответ на вопрос «а зачем вам вообще CMS для сайта на 3 страницы?» ответили: мол, CMS — это кнопочки «жирный» и «курсивный».
Не припомню человека, который неразрывный пробел вместо обычного использовал.
Вы их не замечаете, а они есть. Я довольно часто ставлю неразрывный пробел даже в комментариях, например, когда пишу длинные числа, потому что число 1 000 000 000 000, разорванное на разные строки, выглядит тупо.
Я вот ограничился пока длинным тире и кавычками.
UFO just landed and posted this here
Всегда считал, что мысль
Так же существует неразрывный дефис (‑), для аналогичных целей.
есть как раз полное извращение идеи «HTML для людей». Вроде «хочешь типографики — мучайся!»

Если   как-то запоминается («Non-Breakable SPace»), то цифровые коды символов () вообще задумывались как обходной вариант, для редких ситуаций — и никто не задумался ввести неразрывный дефис как символьную сущность со своим кодом. Уж лет 10 прошло, как его используют!
Ваше негодование непонятно. Никто не заставляет использовать цифровые коды. Они введены не для каких-то загадочных «редких ситуаций», а для вставки символов, которые отсутствуют в кодировке документа. Если страница, например, в UTF-8, то можно просто использовать настоящий символ неразрываного дефиса, как и любой другой юникод-символ (кроме служебных для HTML). В юникоде более сотни тысяч символов, и не очень разумно вводить новую мнемонику для каждого распространенного символа. Вы же не требуете мнемоники, например, для русских букв. А они тоже весьма распространены. Да, отсутствие мнемоники для неразрывного дефиса может доставлять некоторое неудобство, но каким-то особенным извращением оно не является.
Так я бы понял, если бы неразрывный дефис был придумал вчера, либо его бы никто не использовал, и только редкие извращенцы, числом 3-4 человека в мире, его вставляли в документ, но ведь это не так.

Так что я не рад тому, что w3c и прочие стандартизирующие организации находят силы написать стандарты или RFC для самых хитрозакрученных вещей, но добавить HTML-сущности (криво звучит, HTML Entities как-то привычнее) для частоиспользуемых типографических элементов — это ну вот никак.
Понятие «HTML entities» на русский переводится как «мнемоники HTML», если не путаю.
UFO just landed and posted this here
Их заменили на теги <em> и <strong>, обозначающие соответственно эмфазис и сильный эмфазис.


Не путайте. em означает «stress emphasis», тоновое ударение, выделение главного слова в предложении, которое в английском языке сплошь и рядом обозначается курсивом, а в русском языке обычно никак. А strong — это «strong importance», выделение смысловой важности фрагмента текста. Это не разные степени одного и того же.

В HTML5, наконец, эти теги получили отличную семантическую интерпретацию. ‹…› Тег <b> помечает текст, который стилистически отличается от обычного текста, но не имеет какого-либо выделенного семантического значения. Чем это отличается от использования <span>? Ключ в том, что <b> не несет какого-либо семантически отличного смысла.


Просто «отличная семантическая интерпретация» — «стилистически отличается.., но не имеет какого-либо выделенного семантического значения»! Да, чем это отличается от span?! Что значит «не несет какого-либо семантически отличного смысла»? А span несёт, что ли?

В HTML5 появился элемент <mark>, которым помечается текст, выделенный для справочных целей из-за его высокой важности.


То есть отличие от strong исключительно в «справочных целях». Что это такое — не очень ясно. Хотя спецификация объясняет, но всё равно это не очень хорошо улавливается.
Нормальная же статья. За что народ карму сливает не пойму.
А что в ней нормального? Перечислены некоторые HTML5 элементы, которые легко находятся в спецификации от w3c. Верстать нужно начинать с понимания семантики документа.
Ну если так рассуждать, то хабр вообще особо-то не нужен. API везде описаны, а все остальное можно и в своих блогах писать. ИМХО хабр нужен для интеграции и обсуждения идей. Статья предложила хорошую тему для обсуждения: а в каком состоянии СЕЙЧАС html5 со своей семантической составляющей? Иногда нужно остановиться и оглядеться, как-то так.

Более 500 человек добавили в избранное, значит хоть кто-то нашел для себя что-то новое…
Одно дело интегрировать и обсуждать, а другое переводить бредовые статьи. Перед тем как начать верстать читают доки и спеки.
В этой же статье предлагается заменить использование обычных (что это за обычные теги, ни один не перечислен) тегов, на «волшебные». А начало вообще фееричное, почему <q>, в каких моментах использовать <q>, а в каких <blockquote> не говорится. И так далее.
Одного не пойму. Вот абзац:
Большинство фронтенд-разработчиков используют   при написании HTML, но многие не знают его истинного значения. Неразрывный пробел не разрывает строку.

А для чего фронтенд-разработчики его тогда используют?
возможно, просто для пробела. к примеру, чтобы поставить два пробела подряд.
Интересно, насколько уместно использовать mark для подсветки результатов поиска?
Использовал только  
Отличный совет про непереносимый дефис
блин, а куда делся мой nbsp? :)
Касаемо input не согласен. Тайпы использовать можно и нужно, но опять таки, привет IE.
Никогда не понимал этого зоопарка тегов, вместо всех этих новомодных article, nav, menu, section использую старый добрый див и не парюсь. Когда видишь, как в выдаче от гугла сверху стоят явно проплаченные ссылки, понимаешь, что от этой оптимизации пользы 2 горшка 2 вершка.
По коммерческим запросам с некоторой долей вероятности вываливаются проплаченные. Однако высококонкурентные, коммерческие запросы — это «голова». А часто «хвост», состоящий из низкочастотных и запросов, набираемых раз в месяц/год/10 лет значительно больше этой «головы». Для привлечения трафика по ним хватает правильной разметки, хорошего контента и прочих признаков профессионально сделанного сайта. Кроме того, правильная семантическая разметка помогает поисковым системам составить более подходящий сниппет.
UFO just landed and posted this here
Они влияют на понимание роботов, какого рода информация представлена в этом текстовом блоке. Робот лучше понимает хорошо структурированную информацию. А из этого уже у ПС складывается мнение о том, какого типа сайт и что на нём за информация.

И это влияет на вид сниппета в выдаче. Если у вас адрес компании в теге , то больше вероятности, что при запросе «Продажа гаечных ключей адреса» в сниппете вашего сайта будет выведен адрес.

Сам я столкнулся недавно с проблемой. И дело было в обычных заголовочных темах. На странице должен быть один тег H1. Не название сайта — название страницы. А в шаблоне джумлы заголовок страницы помещался в H2. Итого на странице было 3-7 H2. И сайт висел на второй странице по не очень-то конкурентным запросам. Подправил шаблон — позиции вверх пошли. Сайты, на которых всё было в div и span (включая заголовки и абзацы) встречал. И некоторые в самом деле имели хорошие позиции, но за счёт поведенческих факторов, внешних ссылок и некоторых других параметров — контент хороший был

Если вы считаете, что ПС на такие вещи плевать — то примите к сведению: на тегах семантическая разметка не заканчивается, она пошла гораздо дальше.
Почитайте это
Поддерживается с 2011 года Bing, Google, Yahoo! (да ими и было разработано), чуть позже присоединился и Яндекс. Мы с Яндексом рекомендуем использовать семантическую разметку на своих сайтах.
UFO just landed and posted this here
На странице должен быть один тег H1.
Это не так. Теперь тегов h1 может быть сколько угодно на странице, главное, чтобы только один такой тег был в разделе.
<body>
 <h1>My great page</h1>
 <section>
  <h1>Section one</h1>
 </section>
 <section>
  <h1>Section another one</h1>
 </section>
 <section>
  <h1>Our fantastic section three</h1>
  <section>
</body>

Такая разметка, как представлена выше, отныне полностью валидна.
UFO just landed and posted this here
Это я в курсе, конечно. Но Фолкнер вообще экстремист в этом смысле и, прямо скажем, довольно неприятный тип, который не склонен к поиску компромиссов и гнёт свою линию от имени w3c, прикрываясь недостаточной поддержкой каких-то задумок юзерагентами. Я его в других местах читал, видел, как он ведёт себя в рассылках и комментариях. Именно с его подачи, кстати, весной был выпилен перспективный hgroup из спек w3c. Несмотря на это, в варианте whatwg тег hgroup до сих пор есть.

Возвращаюсь к h1. В спеках whatwg и w3c (ссылки я давал в предыдущем комментарии) прямо говорится о том, что тег является заголовком раздела. Валидатор от того же w3c (надо оговориться, что это экспериментальная версия для HTML5) пропускает разметку с несколькими h1, упакованными по одному на раздел, без предупреждений. Так что проблем с использованием быть не должно.

А Фолкнер в статье по вашей ссылке в присущем ему стиле сыплет грозными предостережениями о том, как сломается outline (не знаю, как правильно назвать по-русски), если в будущем будет решено вернуться к старой схеме последовательного применения h1-h6, «забывая» о том, как сейчас всё ломается, когда страница формируется по кусочкам какой-нибудь CMS, где спокойно получается что-нибудь вроде:
h1
   h3
   h2
      h3
   h2
      h4

Но это всё не даёт ответа на ваш вопрос о том, как это видят поисковики :(
Но это всё не даёт ответа на ваш вопрос о том, как это видят поисковики :(

Я в данном случае придерживаюсь мнения: пока точно неизвестно — лучше сделать по-старому.
Я думаю, ваш осторожный подход оправдан, особенно, если можно быть уверенным в том, что заголовки на конечной странице не будут перемешиваться так, как в моём примере с CMS. Конечно, всегда есть соблазн использовать максимум возможностей (в том числе и с заголовками первого уровня в разных разделах), но лучше делать по небольшому шагу вперёд, будучи уверенным, куда именно ступаешь, чем бездумно ломиться вперёд, проваливаясь в «болото» по пояс. В конечном итоге, вёрстка по старым правилам по-прежнему валидна в HTML5.
CMS обычно ведь собирает файл из шаблонов, шаблоны можно редактировать. Я этим как сеошник занимался не раз. В том числе правил кривую иерархию заголовков. Небольшие шаги вперёд тоже предпочитаю делать, но на другом направлении. Сейчас изучаю Shema.org, сами же поисковые системы и продвигают этот стандарт.
Да, но даже редактирование шаблонов не всегда даёт гарантию, что дальше всё будет хорошо, потому что иногда начинают вылезать косяки уже постфактум, когда появляются новые типы выборок материалов, например. Но тут уж ничего не попишешь — надо просто быть готовым к тому, что придётся снова править шаблоны.

Schema.org — замечательная штука, но она ведь никак не влияет на иерархию, её задача — увеличить машиночитаемость конкретных данных на странице.
UFO just landed and posted this here
В целом, согласен с вами. В особенности по последнему тезису:
если в силах автора уменьшить неоднозначность (написать код, который будет одинаково понят и по старым, и по новым правилам) — лучше так и сделать
Sign up to leave a comment.

Articles