Html шорты – HTML Шорты — Блог Академии — HTML Academy
Ссылки вокруг блоков — Блог Академии — HTML Academy
Можно ли оборачивать ссылкой блочные элементы? — спрашивает наша зрительница Маша. Можно, Маша, но осторожно. Давайте разберёмся.
Раньше было нельзя — это было запрещено прямо в спецификации 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>Есть и другие, ещё более сложные трюки, чтобы вложить ссылки. Об этом написал Рома Комаров, почитайте, если интересно.
Запомните главное: блоки можно оборачивать в ссылки, главное, чтобы внутри не было интерактивных элементов.
htmlacademy.ru
Какие нужны фавиконки — Блог Академии — HTML Academy
Фавиконка — это favorite icon, то есть иконка для избранного. Её придумали для IE5 в 99 году, чтобы у сайтов была узнаваемая картинка. Достаточно было бросить в корень сайта файл favicon.ico и браузер сразу её подхватывал и делал красиво. До сих пор все браузеры делают запрос в корень сайта и пытаются найти там файл в формате ICO. Бросил и забыл, расходимся? Рано!
Долгое время всё прекрасно работало. В контейнер ICO можно было зашить много разных иконок: от крошечной монохромной до огромной полупрозрачной. Браузер после скачивания иконки сам выбирал нужный формат. Проблема была в том, формат ICO страшно неэффективный. Если зашить в ICO две PNG-иконки 16 и 32, то иконка будет весить в два-три раза больше, чем исходные файлы. Браузерам приходилось тянуть не только ненужные форматы, но ещё и в неэффективном виде.
Но ICO признали все браузеры и научились подключать его не только из корня сайта, но и из произвольного места. Если указать в голове документа <link rel="icon">, то браузер пойдёт не в корень, а туда, куда вы ему показали. Линковать особый адрес приходилось на каждой странице, но это же не проблема — иконка ведь всего одна! Ну правда, что могло пойти не так? Так и жили.
<link rel="icon" src="images/my.ico">При отсутствии внятных стандартов, за дело взялась Apple. К первому Айфону прилагался прорывной мобильный браузер Safari, который тоже начал искать в корне сайта иконки, но на этот раз в формате PNG и с названием apple-touch-icon. Эту иконку видно в избранном и при добавлении сайта на домашний экран. Бросил в корень второй файл и забыл, расходимся? Нет.
Чтобы иконка была без блика сверху, нужен файл apple-touch-icon-precomposed, ещё один для ретины, потом ещё несколько для всех моделей Айпадов, тройной ретины… и в итоге вам нужно намусорить в корне или в шапке сайта целым ворохом иконок со специальными размерами: 72, 76, 114, 120, 144, 152, 180 и кажется что-то ещё. Чтобы разобраться во всех нюансах тач-иконок, читайте отличное руководство Матиаса Байненса.
<link rel="apple-touch-icon" href="apple-touch-icon-72x72.png"> <link rel="apple-touch-icon" href="apple-touch-icon-76x76.png"> <link rel="apple-touch-icon" href="apple-touch-icon-114x114.png"> <link rel="apple-touch-icon" href="apple-touch-icon-120x120.png"> <link rel="apple-touch-icon" href="apple-touch-icon-144x144.png"> <link rel="apple-touch-icon" href="apple-touch-icon-152x152.png"> <link rel="apple-touch-icon" href="apple-touch-icon-180x180.png">
Иконки Apple в какой-то момент стали стандартом де-факто. Их начали подтягивать не только другие браузеры, но и другие сервисы, чтобы сделать иконку для вашего сайта. Проблема была в том, что это было слабо документировано, учитывало интересы только одной компании и несло само её имя в формате. Нужен был стандарт.
В HTML5 появилось расширенное описание<link rel="icon">: добавился атрибут sizes, чтобы указывать размеры, и атрибут type, чтобы указывать формат иконки. Например, если у вас ICO с несколькими иконками внутри, то укажите все размеры через пробел в sizes. Если иконка векторная — да, так тоже можно — укажите размер any. Главное, не забудьте указать правильные типы. Теперь-то расходимся, проблема решена? Почти.
<link rel="icon" href="favicon.png" type="image/png">
<link rel="icon" href="favicon.ico" type="image/vnd.microsoft.icon">
<link rel="icon" href="favicon.svg" type="image/svg+xml">Для каждой иконки писать свой линк? Сложно! А если хочется фирменный цвет указать, заставку или какие-то особенности работы всего сайта? Не иконками едиными. Вот бы нам конфиг в отдельном файле! Было и такое: browserconfig.xml для плиточных иконок IE11, JSON-манифест для иконок-виджетов табло Яндекс Браузера. Экспериментов было много, но теперь есть и стандартное решение — веб-манифест.
Спецификация Web App Manifest описывает простой JSON-файл, в котором можно указать не только все иконки, их размеры и форматы, но и полностью описать ваш сайт или приложение. Фирменный цвет, цвет фона, язык и направление письма, полное и краткое название, ориентация, режим запуска и другое. Вы подключаете его с помощью
{
"name": "My App",
"icons": [{
"src": "64.png",
"sizes": "64x64"
}, {
"src": "128.png",
"sizes": "128x128"
}],
"display": "fullscreen",
"orientation": "landscape",
"theme_color": "tomato",
"background_color": "cornflowerblue"
}А что Apple? Что-что… До сих пор поддерживает свой формат тач-иконок и придумала даже ещё один: новый, нестандартный, как мы любим! С помощью <link rel="mask-icon"> для закреплённых вкладок Safari и кнопок на тач-баре Макбуков можно указать монохромную векторную маску и цвет для наведения. Спасибо, конечно, за вектор, но неспасибо за очередной велосипед.
<link rel="mask-icon" href="mask.svg" color="red"> Веб-манифест уже так или иначе поддерживают Chrome, Opera, Samsung Internet и Firefox, но пока только на Андроиде. В Edge он тоже скоро появится — разработка в процессе. Пока это будущий способ подключения иконок, а что делать сегодня, вот прямо сейчас? Сочетать всё, что мы знаем.
Для начала, забудьте про ICO, если только вам не нужен IE10. Подключите линком PNG-иконки: простую на 16 и 32 для ретины, чтобы было красиво в браузерной строке и закладках. Дальше подключите линком из корня сайта apple-touch-icon.png размером 180 × 180. Потом подключите веб-манифест, в котором указана иконка на 192 для Андроида. Ну и можно там же упомянуть 16, 32, вектор, цвета и название — пригодится.
Этого вам должно хватить, чтобы было красиво в основных современных браузерах. Но если нужно упороться по мелочам и сделать вот прямо идеально на каждой платформе — мои соболезнования и читайте документацию в описании к видео. Есть ещё сносный онлайновый генератор иконок, но я бы не доверил ему генерировать графику — будет мыльно. А вот код позаимствовать можно.
Ну что, чуда не произошло и всё по-старому: мусор в шапке, мусор в корне? Знаете, нет, я верю, что со временем веб-манифест наведёт порядок, поэтому подключайте его уже сегодня. Вот выбросим мусор и заживём!
htmlacademy.ru
Секции в футере — Блог Академии — HTML Academy
Можно ли вкладывать элемент section в footer? — спрашивает наш зритель Роман. Рома, можно. Если вы понимаете, что вы делаете. Давайте разберёмся.
Элемент section появился в HTML5 и разделяет содержимое на части или секции. Отсюда и название.
Как понять, что это вообще section? Это даже важнее, чем можно ли его куда-либо вкладывать. Section — это одна из частей содержимого, а значит он не имеет смысла в одиночку. Это как список из одного пункта, который скорее параграф.
<main>
<section>
<h3>Зачем?</h3>
</section>
</main> Если содержимое делится на несколько логических частей, значит каждую можно завернуть в отдельный section. Такой секции стоит дать заголовок, чтобы было понятней, что там содержится. Спецификация даже настаивает на этом.
<h2>Обед</h2>
<section>
<h3>Первое</h3>
</section>
<section>
<h3>Второе</h3>
</section>Многие думают, что section — это такой модный div и очень ошибаются. Смотрите, я использую HTML5! Нет. Этот элемент несёт определённый смысл и если вы его не понимаете, его лучше вообще не трогать.
Самый яркий пример использования section прямо из спецификации — это блок со вкладками. У вас есть группа вкладок и нажатие на заголовок каждой показывает её содержимое. Такая вкладка — это самый настоящий section.
Или типичный одностраничный лендинг: всё содержимое сайта на одной странице, но в отдельных частях высотой с окно. Описание компании, преимущества, адрес с картой — ну, вот это всё. Каждый такой блок — это section.
Ладно, с секциями разобрались, а что такое footer? Если очень коротко, то это такой справочный блок с датой публикации, автором, сносками. И он может быть не один на странице! О нём мы как-нибудь поговорим отдельно.
Итак, footer справочный, section делит на части. То есть: если в справке есть какие-то структурные части, то почему бы и нет? Бывает, что в подвал сайта кладут много информации, которая помогает сориентироваться: контакты, карту сайта, поиск. Хороший такой, жирненький footer.
<footer>
<section>
<h3>Поиск</h3>
</section>
<section>
<h3>Справка</h3>
</section>
</footer>Даёте каждой секции подходящий заголовок и делите footer на части.
Про семантику section и других элементов можно почитать на сайте HTML5 Doctor. Некоторые статьи писали авторы спецификации HTML, чтобы помочь разработчикам. Их также много переводили, так что все ссылки есть в описании к видео.
Мораль: используйте новые структурные HTML-элементы только если вы понимаете, как они работают. И не забывайте вставлять заголовки для секций. А если их нет на макетах, доступно их прячьте.
htmlacademy.ru
Спецификация W3C или WHATWG — Блог Академии — HTML Academy
Есть две спецификации HTML: W3C и WHATWG, какой из них верить? — спрашивают наши зрители Екатерина и Дмитрий. Верьте той, которая больше нравится, но не забывайте сверяться с браузерами. Давайте разберёмся.
Спецификация — это главный источник знаний: как для браузеров, так и для разрабочиков. Браузеры обрабатывают код по спеке, разработчики пишут код по спеке — и у нас всё вместе хорошо работает. Это называется «веб-стандарты» и вы не хотите знать, насколько всё было плохо до их широкого признания.
W3C — это консорциум всемирной сети, такая некоммерческая организация, в рамках которой разрабатывают технологии, на которых работает веб. WHATWG — это независимая рабочая группа по технологиям гипертекстовых веб-приложений, которую собрали в рамках W3C в середине 2000-х. Собрали не просто так, а по делу.
Когда-то в W3C решили отказаться от спецификации HTML 4 и начать разрабатывать XHTML, более строгую, формальную и, как потом стало ясно — слишком оторванную от реальности. В ответ на это собралась WHATWG, в которую вошли представители браузеров. Благодаря этому появилась спецификация HTML 5 со множеством по-настоящему полезных вещей. От XHTML осталась только привычка закрывать теги и кавычить атрибуты.
После выхода HTML 5 из рук WHATWG, спецификация пошла по формальному пути к рекомендации W3C и достигла её в 2014 году. Но по дороге что-то пошло не так и между WHATWG и W3C возникли разногласия. Из-за этого начали появляться различия между версиями. В 2011 году WHATWG вообще отказалась от нумерации HTML и начала разрабатывать спецификацию как живой стандарт, в духе вечнозелёных браузеров.
В итоге, сейчас у нас есть две спецификации: рекомендация HTML 5.1 по W3C и живой стандарт HTML по WHATWG. И у каждой — свои цели: HTML5 делает снимки реальности, нумерует их и выпускает рекомендации. Это отвечает на вопрос разработчиков: что уже есть в браузерах? WHATWG, напротив, старается опередить реальность, предложить что-то новое и предсказать изменения. Это уже ближе к задачам браузеров.
Так в чём же противоречия? Например, W3C рекомендует иметь всего один элемент main на странице, приравнивая его к ARIA-роли main. Это помогает скринридерам находить самое главное на странице. WHATWG допускает main в любом структурном элементе, как главную его часть, на манер header и footer.
<body>
<header>
<main>
<article>
<h2>
<footer>
<footer>
<body>
<header>
<main>
<article>
<h2>
<main>
<footer>
<footer>Из спецификации W3C убрали элемент hgroup, объясняя это отсутствием реализаций в браузерах, слабыми примерами использования и потенциальными проблемами. Вместо него рекомендуют обычный header и параграф для подзаголовка. В версии WHATWG элемент hgroup на месте — раз уж добавили, то чего убирать.
<article>
<header>
<h2>Заголовок</h2>
<p>Подзаголовок</p>
</header>
<p>Текст</p>
</article>Спецификация W3C также приводит расширенные примеры, рекомендации к использованию и развивает семантику элементов. HTML 5 поясняет важность уровней заголовков, рекомендует figcaption вместо атрибута title для картинок, объясняет как использовать alt, осуждает, но разрешает таблицы для раскладки, если есть role=»presentation» и так далее.
Вы наверное уже поняли, что мне версия W3C нравится больше. Прочная связь со спецификациями по доступности, большее количество примеров и недавний переезд на Гитхаб — очень подкупают. По-моему, у WHATWG просто отлично получаются другие спецификации: DOM, Canvas, Fetch, URL и многие другие.
Плохо, что у нас есть две спецификации вместо одной? Да. Так почему не объединить их в одну? М-м, это вряд ли: слишком уж разные подходы к разработке. Но знаете, всё не так плохо: это просто две площадки для дискуссий со своими правилами, куда приходят представители всех браузеров, комитетов и групп, чтобы так или иначе развивать веб. И вы приходите — всё на Гитхабе.
Какой спецификации верить? Слепо — ни одной, ориентируйтесь на реализации в браузерах и на практическую ценность. Если вы о ней не знаете, не значит, что её нет. Выберите ту спеку, которая больше нравится и обращайтесь к ней почаще — они написаны для вас.
Это были HTML Шорты и Вадим Макеев. Задавайте вопросы на нашей странице или в комментариях к видео. На самые интересные мы ответим в следующих выпусках. Пока!
htmlacademy.ru
Зачем нужны заголовки и какие теги использовать — Блог Академии — HTML Academy
Зачем нужны заголовки и какие теги для них использовать? — спрашивают наши зрители Андрей, Илья, Александр, Игорь, Михаил и другие. Этот вопрос нам задают чаще всего. Пришло время разобраться!
Когда много лет назад придумали HTML, мир был совсем другим. Авторы спецификации вдохновлялись текстовыми документами, где в одном потоке подряд шли абзацы, списки, таблицы, картинки и конечно заголовки. Прямо как в ваших рефератах и курсовых: самый большой заголовок — название, заголовки поменьше — части или главы.
В HTML с тех пор шесть уровней заголовков: от h2 до h6. Они озаглавливают всё, что за ними следует и образуют, так называемые, неявные секции. Такие логические части страницы. Неявные они потому, что закрываются только когда появляется следующий заголовок.
<h2>Еда</h2>
<h3>Фрукты</h3>
<p>Классные</p>
<h4>Яблоки</h4>
<p>Вообще</p>Но секции лучше задавать явно с помощью элемента section, помните третий выпуск? Эти два фрагмента идентичны с точки зрения семантики, но этот гораздо понятнее, хоть и многословнее.
<h2>Еда</h2>
<section>
<h3>Фрукты</h3>
<p>Классные</p>
<section>
<h4>Яблоки</h4>
<p>Вообще</p>
</section>
</section>Из-за такой системы неявных секций, спецификация настойчиво рекомендует не использовать элементы h* для подписей под заголовками. Это обычный параграф, а заголовок должен обозначать отдельную часть содержимого. В спецификации есть глава с примерами разметки сложных элементов: подписи, крошки, диалоги — почитайте.
Ладно! Раз у нас есть явные секции, то по вложенности легко определить отношение частей. Так может браузеры сами догадаются какого уровня заголовки нужны? А то считать: h2, h3, аш… сбился. Так было бы удобнее менять части кода местами.
Такая же идея пришла в голову авторам HTML5 и они описали в спецификации алгоритм аутлайна. Он разрешает использовать на странице только h2, а важность обозначать вложенностью структурных элементов вроде article и section.
<h2>Еда</h2>
<section>
<h2>Фрукты</h2>
<section>
<h2>Яблоки</h2>
</section>
</section>Разработчикам идея очень понравилась, многие даже бросились её внедрять. Но вот беда: алгоритм аутлайна до сих не внедрил ни один браузер, читалка или поисковик. На таких страницах все заголовки кричат, что они №1 и самые важные. Но если важно всё, то уже ничего не важно.
Не надо так делать, об этом теперь пишет сама спецификация. За уровнем заголовков нужно следить самим. На самом деле, это не так сложно: на типичной странице вряд ли наберётся структурных частей больше, чем на 3 уровня. Так что не ленитесь.
Нет, погоди. Я ставлю класс на div и все сразу видят — это самый большой заголовок, ставлю другой класс — заголовок становится меньше, видно же. Зачем тогда эта ерунда с расчётом уровней, если есть CSS?
<div>
Фрукты бесплатно
</div>
<div>
Только за деньги
</div>Вы конечно правы, стили создают визуальную модель важности: крупный чёрный текст важнее, меленький серенький вообще не важен. Но только если вы смотрите на такую страницу.
Есть две важные группы пользователей, которые читают вашу страницу по тегам разметки. Они не смотрят насколько крупный и чёрный ваш div — чтобы найти на странице самое важное, они ищут h2. Это читалки и роботы. С роботами всё понятно: это поисковики, которым нужно помогать понимать ваши страницы.
Читалками или скринридерами пользуются люди, которые плохо или совсем не видят ваши интерфейсы, или не могут управлять браузером привычным образом. VoiceOver, NVDA, JAWS читают содержимое вслух и ориентируются только по значимым тегам. Элементы div и span не значат ни-че-го, какие бы классы и стили вы не накрутили. Такой сайт — как газета без заголовков, просто месиво текста.
Да какая газета! Очнись, 2017 на дворе, я изоморфное одностраничное приложение делаю, а не стенгазету. У меня тут стейты компонентов — нафига семантика там, где нет текста? Очень хороший вопрос.
Все читалки идут по странице тег за тегом, от первого к последнему. И читают подряд всё, что внутри. Крайне неэффективно: каждая страница начинается с шапки и пока её пройдёшь, забудешь за чем шёл. Поэтому у читалок есть специальные режимы, показывающие только важные части страницы. Структурные элементы header, nav, main и другие, все ссылки, все заголовки.
Если вывести все заголовки и прочитать их, можно составить ментальную, а не визуальную модель страницы. А потом взять и сразу перейти к нужной секции, выбрав её заголовок. Меню, поиск, каталог, настройки, логин — все эти части вашего приложения можно озаглавить, чтобы упростить доступ к ним.
— Инстаграм
— Лента
— Закат
— Латте
— Настройки
— ПрофильНо бывает, что в дизайне нет заголовков для важных частей. Дизайнер рисует, ему всё ясно: меню с котлетой, поиск с полем и так далее. Но это не должно мешает вам делать доступные интерфейсы. Расставьте нужные заголовки, а потом доступно их спрячьте. Как? Только не display: none, его читалки игнорируют. Есть такой паттерн visually hidden, подробнее в описании к видео.
Думайте не только о том, как выглядит ваша вёрстка, но и о том, насколько логично организована разметка. Не забывайте о заголовках: пусть стили показывают, а заголовки рассказывают о ваших страницах или приложениях.
htmlacademy.ru
Адаптивная вёрстка — Блог Академии — HTML Academy
В чём разница между резиновой, адаптивной и отзывчивой вёрсткой? — спрашивают наши зрители Екатерина и Константин — как правильно их применять? Давайте разберёмся в отличиях подходов и попробуем сформулировать один общий вместо трёх.
Когда мобильного веба не было даже в самых смелых фантазиях, весь интернет был на десктопных компьютерах с небольшими экранами. Оптимизирован для разрешения 1024 на 768 и браузера Internet Explorer 5! — гордо писали тогда на сайтах. Но прошло время, экраны подросли и пришлось к этому как-то подстраиваться. Сначала это были просто резиновые таблицы: колонки по 25%, содержимое 50%, а в отдельной строке colspan=3 и распорка для минимальной ширины. Надеюсь, вы не поняли о чём я сечас говорил.
Резиновая вёрстка — это когда вы задаёте всему макету и отдельным его частям не фиксированную ширину, а эластичную — в процентах. За исключением минимальной и максимальной ширины. Высоту в вебе в принципе не принято задавать — обычно она подстраивается под содержимое. Фикс или резина? — спрашивали верстальщики 2000-х про макет и втайне надеялись на второе, поинтереснее. Сейчас сложно представить, но когда-то это было прорывной идеей, которая усложнила вёрстку, но сделала первый шаг в правильном пути.
Таблицы для раскладки ушли, а резиновая вёрстка осталась. Если у вас эластичные флоаты, флексы… да хоть гриды! — это всё равно резиновая вёрстка. Но если ширина внешнего контейнера зафиксирована — это уже фикс, сколько бы ни было резины внутри. Чуть более универсальный фикс, но всё равно. В общем, главное чтобы сайт двигался так или иначе вместе с окном, а не торчал кирпичом где-то в центре или с краю.
Когда расширился круг устройств с интернетом и появились первые мобильные браузеры — встала задача как-то подстраиваться под них. Простая резина здесь уже не справлялась — нужно было переписывать стили. Одной из первых, в 2006 году появилась техника адаптивной раскладки Марка ван ден Доббельстина. В статье на A List Apart Марк предложил добавлять классы при загрузке или ресайзе окна и на каждый диапазон вешать стили. До первой реализации медиавыражений в Safari оставалось два года.
Когда в начале десятых годов появилось для чего адаптировать и чем адаптировать — мобильные браузеры и медиавыражения — вышли книги, давшие названия подходам: «Адаптивный веб-дизайн» Аарона Густавсона и «Отзывчивый веб-дизайн» Итана Маркота. Подходы Аарона и Итана продолжали идеи Марка, но с более современными технологиями и несколько отличались направлением мысли.
«Адаптивный веб-дизайн» Аарона предлагал гибко адаптировать сайты к возможностям устройств и браузеров. Важной частью этой философии был ненавязчивый JavaScript с прогрессивным улучшением — и всё это поверх семантической разметки. Хотя Аарон писал не совсем об этом, сегодня принято считать, что главное в адаптивной вёрстке — привязка к конкретным разрешениям и устройствам. Стили переключаются от одного брейкпоинта к другому, то есть у вас есть фиксированные макеты для iPad и iPhone, а то, что между ними вас не волнует.
«Отзывчивый веб-дизайн» Итана ставил во главу три вещи: резиновый макет, гибкие картинки и медиавыражения. Все размеры и отступы Итан предлагал указывать в процентах с сумасшедшими дробями для точности. Отличительной чертой подхода стало плавное изменение сайта, с ориентацией не на конкретные устройства, а на содержимое. То есть ваш резиновый макет хорошо выглядит не только на iPhone и iPad, но и в любой точке между ними.
Чуть позже Итан сформулировал ещё один важный принцип в книге «Сначала мобильные». Если до тех пор отправной точкой для адаптации вёрстки служила десктопная версия, то он предложил перевернуть схему и начинать с мобильной версии, а потом её улучшать. Почему так? Потому, что усложнять простое проще, чем упрощать сложное. Вдуматесь! А ещё потому, что нет соблазна просто спрятать сложно адаптируемое и обделить мобильных пользователей.
Ну как, стало понятно? Вот адаптивная, вот отзывчивая… М-м, нет, не очень. Из-за путаницы между техникой адаптивной раскладки и философией адаптивного веб-дизайна, из-за того, что все эти подходы прекрасно сочетаются и уже не проследить чёткую границу между ними — из-за всего этого, я плюнул на терминологическую чистоту и стал называть всё это адаптивным дизайном или адаптивной вёрсткой. Это понятие всегда было достаточно широким, чтобы вместить все остальные способы.
Да и принцип дискретной адаптации от размеров устройств и без резины имел смысл лет 10 назад. При сегодняшнем разнообразии устройств полагаться на конкретные размеры и жёстко переключаться между ними — значит однажды очень больно промахнуться. Притом, никто вам не мешает при полностью резиновой вёрстке дописывать адаптацию под нужные разрешения.
Ну и как теперь верстать? Просто! Сначала делаете мобильный резиновый макет, который хорошо вписывается в небольшие устройства. А когда размеры экрана или окна начинают расти — начинаете использовать появившееся пространство для улучшения интерфейса. Появляется боковая колонка, вторая, растут размеры картинок и подгружаются новые разрешения и так далее. То есть медиавыражения меняют стили не когда вы дошли до экрана самого модного телефона, а когда это нужно для содержимого сайта и удобства пользователя. Мы именно так и учим делать на интенсиве по продвинутой вёрстке.
Чтобы сделать хороший адаптивный сайт, нужно понимать много нюансов: вьюпорт, медиавыражения, адаптивные картинки и другое. Сегодня мы сделали первый шаг и разобрались с подходами: он оказывается всего один. Про остальное ещё поговорим!
htmlacademy.ru
Зачем нужен БЭМ — Блог Академии — HTML Academy
Следуете ли вы БЭМу, и насколько он востребован вне Яндекса? — спрашивает наша ученица Евгения. Следуем, Евгения, и БЭМ вполне применим не только в Яндексе. Давайте разберёмся.
БЭМ расшифровывается как: блок, элемент, модификатор. Это такой набор абстракций, на который можно разбить интерфейс и разрабатывать всё в одних и тех же терминах. Как говорит сайт bem.info, БЭМ предлагает единые правила написания кода, помогает его масштабировать и повторно использовать, а также увеличивает производительность и упрощает командную работу.
Круто, да? Но зачем вам масштабируемость и командная работа, если вы один верстальщик на проекте, который не претендует на популярность Яндекса? Чтобы ответить на этот вопрос, нужно отмотать историю лет на 10 назад, когда это подход только начали формулировать.
В основу того, что мы сейчас называем БЭМом, легла идея независимых блоков, которую Виталий Харисов сформулировал и презентовал в 2007 году на первой российской конференции по фронтенду. Это было настолько давно, что тогда даже слова «фронтенд» ещё не было, тогда это называлось клиент-сайд.
Идея была в том, чтобы ограничить возможности CSS для более предсказуемых результатов. Использовать минимум глобальных стилей и каждый отдельный элемент страницы делать блоком со своим уникальным классом и стилями, которые полностью его описывают. Селекторы по элементам и ID, хрупкие связки вложенности — всё это заменялось на простые селекторы по классам. Каждый класс в стилях — это блок. Благодаря этому блоки можно легко менять местами, вкладывать друг в друга и не бояться конфликтов или влияния.
#menu ul > li {
color: old;
}
.menu-item {
color: bem;
}Потом появились абсолютно независимые блоки (АНБ), где у элементов внутри есть свой префикс с именем родителя, а состояния блоков снова дублируют класс, но уже с постфиксом. Подход обрёл черты современного БЭМа, одна из которых — многословность классов.
.block
.block_mod
.block__element
.block__element_modЭта многословность гарантирует уникальность элементов и модификаторов в рамках одного проекта. За уникальностью имён блоков вы следите сами, но это довольно просто, если каждый блок описан в отдельном файле. Глядя на такой класс в HTML или CSS, можно легко сказать, что это, и к чему оно относится.
Изначально АНБ, а потом и БЭМ, решали задачу важную для вёрстки любых масштабов: предсказуемое поведение и создание надёжного конструктора. Вы же хотите, чтобы ваша вёрстка была предсказуемой? Вот и Яндекс тоже. Ещё это называется «модульность» — о ней хорошо написал Филип Уолтон в «Архитектуре CSS», ссылка на перевод в описании.
Через пару лет в Яндексе окончательно сформулировали нотацию БЭМ. Любой интерфейс предлагалось разделять на блоки. Неотделимые части блоков — элементы. У тех и других есть модификаторы.
<ul>
<li>
</li>
<li>
</li>
</ul>Например, блок поиска по сайту. Он может быть в шапке и в подвале — значит это блок. В нём есть обязательные части: поле поиска и кнопка «найти» — это его элементы. Если поле нужно растянуть на всю ширину, но только в шапке, то блоку или элементу, который отвечает за это растягивание, даётся модификатор.
Для полной независимости блоков мало назвать классы правильно или изолировать стили, нужно собрать всё, что к нему относится. В проекте по БЭМу нет общего script.js или папки images со всеми картинками сайта. В одной папке с каждым блоком лежит всё, что нужно для его работы. Это позволяет удобно добавлять, удалять и переносить блоки между проектами. Потом конечно все ресурсы блоков при сборке объединяются в зависимости от задач проекта.
Когда БЭМ вышел за пределы Яндекса, сначала его воспринимали как магию и старались воспроизводить дословно, вплоть до префиксов b- у каждого блока. Такой смешной карго-культ.
.b-block
.b-block--mod
.b-block__element
.b-block__element--modНекоторые неверно понимали идею и появлялись даже элементы элементов. Потом за нотацию взялись энтузиасты и появилась одна из самых популярных: блок отделяется двумя подчёркиваниями, а модификатор — двумя дефисами. Наглядно и просто — сам так пишу.
.block
.block--mod
.block__element
.block__element--modА зачем вообще все эти нотации — я ведь один верстальщик на проекте, помните? Помню. А ещё помню, как сам верстал до БЭМа: в каждом проекте придумывал что-нибудь такое новенькое. А потом открывал код годичной давности и удивлялся — какой идиот это написал?
Возьмём, к примеру, русский язык. Мы же пишем с прописной имена людей, названия и прочее такое? Пишем. Чтобы легко потом считывалось: это Надя или надежда на лучшее? Уж не говоря про знаки препинания и другие полезные договорённости. Вот буква ё, например смягчает… так, о чём мы? Да, БЭМ.
До БЭМа были проекты с портянками стилей, которые нельзя трогать. Они копились годами, слой за слоем, как обои в древней коммуналке. Их просто подключали первыми, а потом перезаписывали что мешало. Когда у вас есть div { font-size: 80% } — это даже уже не смешно.
/* Не смешно */
div {
font-size: 80%;
}БЭМ продолжил развиваться в Яндексе и вырос за пределы вёрстки: появились уровни переопределения, богатый инструментарий, JS-библиотека для работы с БЭМ-классами, шаблонизаторы и целый БЭМ-стэк. БЭМу даже жест придумали, но это совсем другая история, специфичная для Яндекса.
Были и другие методологии: OOCSS Николь Салливан, SMACSS Джонатана Снука, вариации БЭМа и целые фреймворки. Даже у нас на продвинутом интенсиве HTML Академии можно было выбрать любую методологию для вёрстки учебного проекта.
Но выжил только БЭМ и его вполне можно назвать стандартом де-факто современной разработки интерефейсов. И что — это финальная ступень эволюции? Нет конечно. Как ни автоматизируй, многое в БЭМе приходится делать руками, и возможны конфликты.
Модульность и изоляцию стилей блока можно решить ещё лучше. Есть веб-компоненты, CSS-модули, куча решений CSS-в-JS и даже, прости господи, атомарный CSS. Но нет единого решения накопившихся проблем на следующие 10 лет, каким когда-то стал БЭМ. Что это будет? Посмотрим. Я ставлю на веб-компоненты.
А пока, если вы опишете интерфейс по БЭМу — код будет организован, предсказуем, расширяем и готов для повторного использования. Не только для вас, но и для других.
htmlacademy.ru