От автора: написание HTML — сложная задача. По крайней мере написание семантически обоснованного, верного HTML. Это может стать сюрпризом для тех, кто только поверхностно анализирует возможности HTML. Что может быть такого сложного в нескольких элементах, верно? По крайней мере, это не объектно-ориентированный, мультипарадигмальный язык программирования. Но как только вы начинаете копать глубже, вы понимаете, что в HTML можно во многом ошибиться.
Например, HTML теперь содержит сотни элементов. Одно это может затруднить поиск подходящего элемента для работы. Но также, если вы знаете весь доступный набор элементов, есть еще много вещей, чтобы рассмотреть. Например, какие элементы могут быть вложены в другие элементы или какие атрибуты может иметь определенный элемент. Не забывайте о доступности: если мы используем семантически правильные элементы, мы гарантируем, что наш контент будет понятен вспомогательными технологиями, таким как программы чтения с экрана, и что наши интерфейсы будут доступны для всех. Использование нативного элемента кнопки вместо div кнопки, когда вам нужна кнопка, не только поразит ваших друзей, но и добавит стандартные стили и специальные возможности, такие как выделение фокусом и дополнительные события клавиатуры.
Поэтому существует множество причин, по которым вы должны писать семантический, корректный и доступный HTML. Но как убедиться, что ваш код не содержит ошибок? Если вы работаете в более крупной команде или с командой контент-менеджеров, может быть сложно поддерживать высокие стандарты, особенно если разные члены команды имеют разный уровень опыта работы с HTML.
Вы можете, и это, безусловно, будет лучшим решением, настроить среду тщательного тестирования, в которой каждый элемент HTML или ошибка доступности будет немедленно помечена. По правде говоря, мы далеки от того, чтобы тестирование стало приоритетом — или даже областью знаний — для многих разработчиков и клиентов. Кроме того, когда вы находитесь на более ранней стадии проекта и, например, все еще работаете с прототипами в HTML или строите базовые шаблоны HTML, у вас может не быть решения для автоматизированного тестирования.
Так как же вы можете убедиться, что ваш HTML корректен? Тестирование HTML вручную с помощью W3C Markup Validation Service может быть еще одним вариантом. Но это тоже может быть утомительным. Разве не было бы полезно видеть ошибки HTML прямо в браузере? Вот тут на помощь и приходит CSS. Благодаря природе CSS вы можете фильтровать элементы в самых удаленных уголках DOM. И, как оказалось, вы также можете использовать его, чтобы, по крайней мере визуально, проверить свой код, выделив элементы, которые содержат ошибки.
Адам Аргайл на днях в Твиттере опубликовал пример того, как это может выглядеть:
|
1 2 3 4 |
/* CSS */ :is(ul, ol) > *:not(li) { outline: 2px dotted red; } |
В этом случае селектор сопоставляет все элементы, которые находятся внутри списков, но не являются элементом списка li, и отображает их с красным контуром. Контур имеет смысл, потому что, в отличие от использования border, он не меняет размер поля элемента. Адам использует новый псевдо-класс :is(), который все еще имеет ограниченную поддержку в браузерах. Но вы можете легко написать это без :is():
|
1 2 3 4 |
/* CSS */ ul > *:not(li), ol > *:not(li) { outline: 2px dotted red; } |
Этот метод может использоваться для многих других полезных вещей, например, для обнаружения изображений без атрибута alt:
|
1 2 |
/* CSS */ img:not([alt]) { ... } |
Как правило, у изображений всегда должен быть доступный атрибут alt. Когда атрибут установлен, программа чтения с экрана будет читать альтернативный текст. И когда он пуст, программа чтения с экрана будет игнорировать изображение. Однако если атрибута alt нет вообще, программа чтения с экрана будет читать его src. Не очень полезно в большинстве случаев.
Ире Андринокун написала отличный пост о многих других вариантах использования HTML с CSS, таких как проверка на наличие пустых интерактивных элементов, элементов без меток, а также на наличие битых или отсутствующих целей ссылок:
|
1 2 3 4 5 |
/* CSS */ a:not([href]), a[href="#"], a[href=""], a[href*="javascript:void(0)"] { … } |
Она даже создала расширение Chrome, которое объединяет многие из этих селекторов в таблицу стилей, которую можно применить к любой веб-странице, чтобы проверить HTML на наличие проблем с доступностью. И есть еще много интересных вещей, которые вы могли бы сделать. Например, проверка ранее упомянутых div-кнопок:
|
1 2 3 4 5 |
/* CSS */ div[role="button"] { text-decoration: blink; /* На самом деле не используйте здесь blink, это просто шутка. */ } |
Или, если вы не против использования гигантских селекторов, вы можете проверить, содержит ли span только разрешенный «контент фраз», или какой-нибудь любитель div поместил в ваш span прекрасный div:
|
1 2 3 4 |
/* CSS */ span > :not(abbr):not(audio):not(b):not(bdo):not(br):not(button):not(canvas):not(cite):not(code):not(command):not(data):not(datalist):not(dfn):not(em):not(embed):not(i):not(iframe):not(img):not(input):not(kbd):not(keygen):not(label):not(mark):not(math):not(meter):not(noscript):not(object):not(output):not(picture):not(progress):not(q):not(ruby):not(samp):not(script):not(select):not(small):not(span):not(strong):not(sub):not(sup):not(svg):not(textarea):not(time):not(var):not(video):not(wbr) { outline: 3px dashed red; } |
Использование для отладки всего кода CSS, охватывающего все возможные способы, которыми HTML-элементы могут быть использованы неправильно, наверняка будет излишним. Но, в зависимости от вашего проекта, этот метод все еще может быть весьма полезным для работы с наиболее распространенными и наиболее серьезными ошибками, такими как отсутствующие ссылки или атрибуты alt. Можно даже подумать о наличии файла debug.css по умолчанию, который содержит стандартный набор наиболее полезных правил. Я думаю, что попробую это в одном из следующих проектов.
Автор: Matthias Ott
Источник: //matthiasott.com
Редакция: Команда webformyself.
