HTML

Статьи о вёрстке — HTML, CSS, Figma, графика, дизайн и другие темы.

Как фокус помогает

Как фокус помогает

Менеджер и дизайнер заставляют везде убирать аутлайн. Расскажите им, что это плохая идея! — просит наш зритель Дмитрий. Вы совершенно правы, Дмитрий. С удовольствием расскажу, почему так не нужно делать.

В интерфейсах есть два типа элементов: простые и интерактивные. Простые что-то представляют или обозначают. Интерактивные позволяют с ними взаимодействовать. Откройте страницу с формой в браузере и сразу начните печатать. Ничего не происходит, да? Все нажатия клавиш уходят прямо в страницу. Но если попасть в поле, то внутри побегут буквы, которые вы печатаете — оно перехватило фокус и все события. Клавиша пробела теперь не прокручивает страницу, а ставит пробел. Очень удобно.

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

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

Как происходит такое взаимодействие? Главная кнопка здесь — таб, он передвигается к следующему интерактивному элементу. Шифт-таб переносится к предыдущему — попробуйте сами. Как только вы попали на нужный элемент, дальше уже можно в ним взаимодействовать: энтер, пробел, стрелки или просто буквы с клавиатуры.

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

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

Главный аргумент для отключения, мол, некрасиво и нет такого в дизайне. И я даже понимаю тех, кому некрасиво — и правда бывает мимо, хотя обычно в рамках знакомого системного стиля. Но ведь можно не только отключить, можно переназначить! Сделать другой outline, заменить его на border, box-shadow или даже фоновый цвет элемента. Главное, чтобы он недвусмысленно говорил: я сейчас в фокусе.

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

Зайдите на главную Яндекса, Гугла, Гитхаба и понажимайте таб — все эти сайты доступны с клавиатуры. Хороший интерфейс больше, чем просто картинка. В ваших руках помочь дизайнеру сделать интерфейс лучше, а менеджеру сделать его доступным для самой широкой аудитории.

HTML
  • 5 июля 2017
Зачем нужны заголовки и какие теги использовать

Зачем нужны заголовки и какие теги использовать

Зачем нужны заголовки и какие теги для них использовать? — спрашивают наши зрители Андрей, Илья, Александр, Игорь, Михаил и другие. Этот вопрос нам задают чаще всего. Пришло время разобраться!

Когда много лет назад придумали HTML, мир был совсем другим. Авторы спецификации вдохновлялись текстовыми документами, где в одном потоке подряд шли абзацы, списки, таблицы, картинки и конечно заголовки. Прямо как в ваших рефератах и курсовых: самый большой заголовок — название, заголовки поменьше — части или главы.

В HTML с тех пор шесть уровней заголовков: от h1 до h6. Они озаглавливают всё, что за ними следует и образуют, так называемые, неявные секции. Такие логические части страницы. Неявные они потому, что закрываются только когда появляется следующий заголовок.

<h1>Еда</h1>

  <h2>Фрукты</h2>
  <p>Классные</p>

    <h3>Яблоки</h3>
    <p>Вообще</p>

Но секции лучше задавать явно с помощью элемента section, помните третий выпуск? Эти два фрагмента идентичны с точки зрения семантики, но этот гораздо понятнее, хоть и многословнее.

<h1>Еда</h1>
<section>
  <h2>Фрукты</h2>
  <p>Классные</p>
  <section>
    <h3>Яблоки</h3>
    <p>Вообще</p>
  </section>
</section>

Из-за такой системы неявных секций, спецификация настойчиво рекомендует не использовать элементы h* для подписей под заголовками. Это обычный параграф, а заголовок должен обозначать отдельную часть содержимого. В спецификации есть глава с примерами разметки сложных элементов: подписи, крошки, диалоги — почитайте.

Ладно! Раз у нас есть явные секции, то по вложенности легко определить отношение частей. Так может браузеры сами догадаются какого уровня заголовки нужны? А то считать: h1, h2, аж… сбился. Так было бы удобнее менять части кода местами.

Такая же идея пришла в голову авторам HTML5 и они описали в спецификации алгоритм аутлайна. Он разрешает использовать на странице только h1, а важность обозначать вложенностью структурных элементов вроде article и section.

<h1>Еда</h1>
<section>
  <h1>Фрукты</h1>
  <section>
    <h1>Яблоки</h1>
  </section>
</section>

Разработчикам идея очень понравилась, многие даже бросились её внедрять. Но вот беда: алгоритм аутлайна до сих не внедрил ни один браузер, читалка или поисковик. На таких страницах все заголовки кричат, что они № 1 и самые важные. Но если важно всё, то уже ничего не важно.

Не надо так делать, об этом теперь пишет сама спецификация. За уровнем заголовков нужно следить самим. На самом деле, это не так сложно: на типичной странице вряд ли наберётся структурных частей больше, чем на 3 уровня. Так что не ленитесь.

Нет, погоди. Я ставлю класс на div и все сразу видят — это самый большой заголовок, ставлю другой класс — заголовок становится меньше, видно же. Зачем тогда эта ерунда с расчётом уровней, если есть CSS?

<div class="big-black">
  Фрукты бесплатно
</div>
<div class="small-grey">
  Только за деньги
</div>

Вы конечно правы, стили создают визуальную модель важности: крупный чёрный текст важнее, меленький серенький вообще не важен. Но только если вы смотрите на такую страницу.

Есть две важные группы пользователей, которые читают вашу страницу по тегам разметки. Они не смотрят насколько крупный и чёрный ваш div — чтобы найти на странице самое важное, они ищут h1. Это читалки и роботы. С роботами всё понятно: это поисковики, которым нужно помогать понимать ваши страницы.

Читалками или скринридерами пользуются люди, которые плохо или совсем не видят ваши интерфейсы, или не могут управлять браузером привычным образом. VoiceOver, NVDA, JAWS читают содержимое вслух и ориентируются только по значимым тегам. Элементы div и span не значат ни-че-го, какие бы классы и стили вы не накрутили. Такой сайт — как газета без заголовков, просто месиво текста.

Да какая газета! Очнись, 2017 на дворе, я изоморфное одностраничное приложение делаю, а не стенгазету. У меня тут стейты компонентов — нафига семантика там, где нет текста? Очень хороший вопрос.

Все читалки идут по странице тег за тегом, от первого к последнему. И читают подряд всё, что внутри. Крайне неэффективно: каждая страница начинается с шапки и пока её пройдёшь, забудешь за чем шёл. Поэтому у читалок есть специальные режимы, показывающие только важные части страницы. Структурные элементы header, nav, main и другие, все ссылки, все заголовки.

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

— Фотосервис
  — Лента
    — Закат
    — Латте
  — Настройки
  — Профиль

Но бывает, что в дизайне нет заголовков для важных частей. Дизайнер рисует, ему всё ясно: меню с котлетой, поиск с полем и так далее. Но это не должно мешать вам делать доступные интерфейсы. Расставьте нужные заголовки, а потом доступно их спрячьте. Как? Только не display: none, его читалки игнорируют. Есть такой паттерн visually hidden, подробнее в описании к видео.

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


HTML
  • 7 июня 2017
Секции в футере

Секции в футере

Можно ли вкладывать элемент sectionв footer? ** — спрашивает наш зритель Роман. Рома, можно. Если вы понимаете, что вы делаете. Давайте разберёмся.

Элемент section появился в HTML5 и разделяет содержимое на части или секции. Отсюда и название.

Как понять, что это вообще section? Это даже важнее, чем можно ли его куда-либо вкладывать. Section — это одна из частей содержимого, а значит он не имеет смысла в одиночку. Это как список из одного пункта, который скорее параграф.

<main>
  <section>
    <h2>Зачем?</h2>
  </section>
</main>

Если содержимое делится на несколько логических частей, значит каждую можно завернуть в отдельный section. Такой секции стоит дать заголовок, чтобы было понятней, что там содержится. Спецификация даже настаивает на этом.

<h1>Обед</h1>
<section>
  <h2>Первое</h2>
</section>
<section>
  <h2>Второе</h2>
</section>

Многие думают, что section — это такой модный div и очень ошибаются. Смотрите, я использую HTML5! Нет. Этот элемент несёт определённый смысл и если вы его не понимаете, его лучше вообще не трогать.

Самый яркий пример использования section прямо из спецификации — это блок со вкладками. У вас есть группа вкладок и нажатие на заголовок каждой показывает её содержимое. Такая вкладка — это самый настоящий section.

Или типичный одностраничный лендинг: всё содержимое сайта на одной странице, но в отдельных частях высотой с окно. Описание компании, преимущества, адрес с картой — ну, вот это всё. Каждый такой блок — это section.

Ладно, с секциями разобрались, а что такое footer? Если очень коротко, то это такой справочный блок с датой публикации, автором, сносками. И он может быть не один на странице! О нём мы как-нибудь поговорим отдельно.

Итак, footer справочный, section делит на части. То есть: если в справке есть какие-то структурные части, то почему бы и нет? Бывает, что в подвал сайта кладут много информации, которая помогает сориентироваться: контакты, карту сайта, поиск. Хороший такой, жирненький footer.

<footer>
  <section>
    <h2>Поиск</h2>
  </section>
  <section>
    <h2>Справка</h2>
  </section>
</footer>

Даёте каждой секции подходящий заголовок и делите footer на части.

Про семантику section и других элементов можно почитать на сайте HTML5 Doctor. Некоторые статьи писали авторы спецификации HTML, чтобы помочь разработчикам. Их также много переводили, так что все ссылки есть в описании к видео.

Мораль: используйте новые структурные HTML-элементы только если вы понимаете, как они работают. И не забывайте вставлять заголовки для секций. А если их нет на макетах, доступно их прячьте.


HTML
  • 10 мая 2017
Ссылки вокруг блоков

Ссылки вокруг блоков

Можно ли оборачивать ссылкой блочные элементы? — спрашивает наша зрительница Маша. Можно, Маша, но осторожно. Давайте разберёмся.

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

В современной спецификации HTML5 блочные элементы можно оборачивать в ссылки. На это теперь не ругается валидатор W3C и браузеры правильно обрабатывают такую вложенность.

Но есть нюанс. Если вы положите ссылку в ссылку, то что получится, когда вы кликнете по такому? Какая ссылка отреагирует? Непонятно.

Поэтому спецификация прямо запрещает: интерактивные элементы класть в ссылку нельзя.

<a href="">
  Ссылка
  <a href="">
    Нельзя
  </a>
</a>

А какие есть ещё интерактивные элементы, кроме ссылки? Например такие, с которыми можно взаимодействовать. Кнопки, поля формы и лейблы к ним, элементы audio и video, если у них включены контролы.

<a href="">
  <button>Нельзя</button>
</a>

Всё дело в интерактивности: если контролы отключены и видео с аудио играют сами по себе — значит уже можно, они стали неинтерактивными.

<a href="">
  <video>Можно</video>
  <video controls>Нельзя</video>
</a>

А если вы зададите атрибут tabindex любому элементу, чтобы его можно было выделить с клавиатуры, то он станет интерактивным и его уже нельзя будет завернуть в ссылку.

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

Но в таком случае вы всё равно можете оказаться в ситуации, когда у вас ссылка над ссылкой или другим интерактивным элементом и непонятно, на что можно кликнуть, а на что нет.

А ещё это провоцирует делать пустые, недоступные ссылки без текста внутри и тогда скринридерам непонятно куда она ведёт. Не делайте так.

<a href=""></a>
<article>
  Не надо так
</article>

Есть и другие, ещё более сложные трюки, чтобы вложить ссылки. Об этом написал Рома Комаров, почитайте, если интересно.

Запомните главное: блоки можно оборачивать в ссылки, главное, чтобы внутри не было интерактивных элементов.

HTML
  • 26 апреля 2017
8 идей для создания первого сайта

8 идей для создания первого сайта

Не можете придумать, с чего начать практиковать свои навыки HTML, CSS и JavaScript? Вот несколько интересных идей, которые, вероятно, не приходили вам в голову.

Множество начинающих веб-разработчиков понимают, что им нужна только практика, практика и ничего кроме практики изученных навыков. Разработка реального проекта поможет найти трудности, которые не опишет ни один учебник или интерактивный урок. Практика поможет стать увереннее, если вы собираетесь использовать HTML, CSS, JavaScript в своей карьере. Но опыт, который может быть действительно полезен, трудно получить.

Я часто вижу новичков, спрашивающих на Reddit, Quora, Facebook и других интернет-площадках о том, за какой проект им взяться. Поэтому представляю вам восемь весёлых идей, которые помогут проверить навыки и подготовят к трудностям, с которыми сталкиваются веб-разработчики. Все они строго фронтенд: HTML, CSS, JS и jQuery. Они настолько прекрасны в своей нелепости, что будут выгодно выделять ваше портфолио на фоне остальных. Ведь если добавлять в него проекты «как у всех», то будет трудно выделиться среди большого количества однотипных работ других разработчиков.

Читать дальше
HTML
  • 23 января 2017
Как проектировать, создавать и анимировать SVG

Как проектировать, создавать и анимировать SVG

Это перевод статьи Сурбхи Оберой «How to Design, Code, and Animate SVGs».

Вы можете считать масштабируемую векторную графику (Scalable Vector Graphics — SVG) отзывчивой графикой. SVG основан на формате XML, который позволяет создавать изображение, используя определённые теги и атрибуты. Ваш код сгенерирует изображение, которое можно изменять прямо в текстовом редакторе.

Это пример SVG. Если посмотреть на его исходный код, то можно заметить, что он состоит из тегов и атрибутов так же, как и в HTML-документе. Все они находятся внутри тега <svg>. Здесь есть тег <rect>, рисующий прямоугольник с чёрной рамкой и белым цветом фона. И внутри него эллипс (почти что круг, но обратите внимание на атрибуты <ry> и <rx>), который залит красным цветом.

SVG в вебе можно использовать двумя способами. Например, использовать SVG-файлы в атрибуте src тега <img>. То есть мы получим <img src="japan.svg"> — точно так же, как с PNG или JPEG-изображениями.

Но более интересное использование заключается в том, что мы можем вставлять SVG напрямую в <div> внутрь HTML-кода. Мы можем стилизовать эти блоки (или даже группы таких блоков) как захотим. Можем использовать CSS, анимацию или даже добавить интерактивности с помощью JavaScript. Это то, что прямо сейчас делает SVG одним из самых универсальных и крутых элементов в HTML.

SVG бесконечно масштабируем, отзывчив, имеет очень маленький размер файла, перспективен для следующего поколения экранов с неисчислимой плотностью пикселей и может быть стилизован, анимирован и оживлён при помощи известных веб-технологий — CSS и JavaScript.

Все эти вещи ранее были возможны только с использованием Flash, для которого требовался flash-плеер и много сложной работы. К тому же сейчас никто не любит использовать Flash.

Читать дальше
HTML
  • 27 октября 2016
Всегда используйте label

Всегда используйте label

Это перевод статьи Адама Сильвера — «Always use a label»

Иногда дизайнеры слишком сильно упрощают форму, убирая подпись к полю (примечание переводчика: здесь и далее имеется в виду тег label). Проблема в том, что минимализм не всегда означает простоту в использовании, а это, безусловно, и происходит с подписями.

На самом деле, подпись к полю является важной частью для создания лёгких в использовании форм. Вот почему:

1) Зрячие пользователи смогут видеть инструкции и будут знать, что делать. Без подписей к полям в лучшем случае это будет сложно.

2) Незрячие пользователи смогут **услышать инструкции** благодаря использованию скринридеров. Без подписей к полям это будет невозможно.

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

Читать дальше
HTML
  • 30 сентября 2016
Форматы изображений для веба

Форматы изображений для веба

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

Читать дальше
HTML
  • 29 сентября 2016
Плейсхолдеры в полях формы вредны

Плейсхолдеры в полях формы вредны

Это перевод статьи Кэти Шервин — «Placeholders in Form Fields Are Harmful».

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

Читать дальше
HTML
  • 9 декабря 2014