Стив Фолкнер, консультант по удобству подхода и наш новый автор, взял на себя трудную работу по исследованию, сбору данных и применению, а также поговорил с заинтересованными разработчиками. Как объясняет сам Стив, он говорил.
. со многими разработчиками (разработчиками браузеров и разработчиками удобства подхода), веб-разработчиками, авторами и пользователями и получил от них информацию и рекомендации. Я был там, где болтается множество людей: на IRC-каналах, в списках рассылки, Твиттере, блогах, конференциях — везде.
Это привело к тому, что он написал расширение спецификации для и тщательно обосновал варианты применения.
Спецификация W3C
Основная цель — выступать основным элементом в HTML в карте ролей ARIA (Accessible Rich Internet Applications Suite). Это поможет скринридерам и другим услужливым технологиям понять, где начинается основное содержимое. Спецификации W3C описывает так.
Основное содержимое документа или приложения. Область основного содержимого состоит из контента, который напрямую расширяет центральную тему документа или центральную функциональность приложения или зависит от них.
Поскольку элемент теперь включен в спецификацию HTML, элемент в HTML4 изменил своё определение.
Элемент body представляет собой содержимое документа.
Подробнее
Важным аспектом является то, что он может быть использован на странице только один раз. Джереми Кит написал в рабочую группу, чтобы понять, почему это так (вернее, допускается ли несколько ). Хотя я не буду останавливаться на этом, обсуждение прочитать интересно.
Согласно спецификации валидатор W3C выдаст сообщение об ошибке если вы попытаетесь использовать несколько элементов в документе.
Отправная точка
Подобно многим другим новым элементам HTML5, не все браузеры понимают или содержат набор стилей для него. Вам следует убедиться, что он отображается в CSS как блочный элемент.
В настоящее время вы также должны использовать JavaScript, чтобы создать элемент для старых версий IE.
Конечно, если вы используете html5shiv, то обновится напрямую.
Реализация на HTML5 Doctor
Самый простой способ внедрения заключается в замене
И вот как это теперь.
Да, это действительно так просто. Если повезёт, то реализация займёт меньше пяти минут.
Версия WHATWG
Определение от WHATWG отличается от версии W3C; элемент не несёт особого смысла. Это всего лишь стилевая обманка (как
Элемент main может быть использован как контейнер для главного содержимое другого элемента. Он содержит дочерние элементы.
Мы рекомендуем использовать версию W3C для как описано выше.
Поддержка браузеров
Резюме
Основы CSS — Основы современной вёрстки
В прошлых уроках мы познакомились с разметкой элементов с помощью HTML. Многие из этих элементов уже имеют какое-то своё визуальное оформление: параграфы имеют отступы, ссылки выделяются подчёркиванием и цветом, заголовкам устанавливаются другие значения размера шрифта. Обычно этого недостаточно для создания полноценных современных сайтов. Какие-то стили нам просто не подходят, а какие-то элементы мы хотим стилизовать отдельно.
Для визуального оформления WEB-страницы создан язык CSS. CSS переводится как каскадные таблицы стилей (Cascading Style Sheets). Именно этот язык отвечает за то, как наши HTML-элементы будут выведены пользователю в браузере.
В этом уроке мы разберём ту часть аббревиатуры, которая относится к таблицам стилей. Что такое каскадность и как это работает вы сможете прочитать в следующем уроке.
Стили CSS
Чтобы добавить стиль к элементу, необходимо использовать селектор. Он указывает, к какому именно элементу или элементам нужно добавить наши стили. Для примера возьмём следующую HTML-разметку:
Изменим размер и цвет шрифта в этом предложении. Это можно сделать следующей CSS-записью:
Что означает эта таинственная запись выше? Её можно условно разбить на три основные составляющие:
Разберём некоторые свойства, которые помогут вам оформлять текст:
Подключение CSS
Использовать CSS на странице можно с помощью нескольких способов:
Параграф с размером шрифта 20 пикселей. Текст написан красным цветом.
Забудьте про div, семантика спасёт интернет
Давным-давно (лет пятнадцать назад) почти все делали сайты и не переживали о том, что под капотом. Верстали таблицами, использовали всё, что попадётся под руку (а попадались в основном
Семантическая вёрстка — подход к разметке, который опирается не на внешний вид сайта, а на смысловое предназначение каждого блока и логическую структуру документа. Даже в этой статье есть заголовки разных уровней — это помогает читателю выстроить в голове структуру документа. Так и на странице сайта — только читатели будут немного другими.
Дисклеймер: статья может обидеть тех, кто прикипел к вёрстке дивами. Но
Почему семантика важна
Чтобы сделать сайт доступным. Зрячие пользователи могут без проблем с первого взгляда понять, где какая часть страницы находится — где заголовок, списки или изображения. Для незрячих или частично незрячих всё сложнее. Основной инструмент для просмотра сайтов не браузер, который отрисовывает страницу, а скринридер, который читает текст со страницы вслух.
Этот инструмент «зачитывает» содержимое страницы, и семантическая структура помогает ему лучше определять, какой сейчас блок, а пользователю понимать, о чём идёт речь. Таким образом семантическая разметка помогает большему количеству пользователей взаимодействовать с вашим сайтом. Например, наличие заголовков помогает незрячим в навигации по странице. У скринридеров есть функция навигации по заголовкам, что ускоряет знакомство с информацией на сайте.
Чтобы сайт был выше в поисковиках. Компании, которые создают поисковики, не разглашают правила ранжирования, но известно, что наличие семантической разметки страниц помогает поисковым ботам лучше понимать, что находится на странице, и в зависимости от этого ранжировать сайты в поисковой выдаче.
Классический пример — расписание поезда «Сапсан» в выдаче Google.
Разработчики tutu.ru сверстали таблицу тегом
вместо
Семантика прописана в стандартах. Многие разработчики по старинке пользуются конструкциями типа
Ну и представьте, насколько проще читать вместо
Основные семантические теги HTML
Среди «старых» тегов из ранних версий HTML тоже есть семантические — например, тег
, который обозначает параграф. При этом теги или не семантические, потому что они не добавляют смысла выделенному тексту, а просто определяют его внешний вид.
Но в актуальной версии стандарта HTML Living Standard есть семантические теги почти для всех основных частей сайта, и лучше пользоваться ими. Вот несколько примеров семантических тегов.
Значение: независимая, отделяемая смысловая единица, например комментарий, твит, статья, виджет ВК и так далее.
Особенности: желателен заголовок внутри.
Типовые ошибки: путают с тегами и
Особенности: желателен заголовок внутри.
Типовые ошибки: путают с тегами и
Значение: побочный, косвенный для страницы контент.
Особенности: может иметь свой заголовок. Может встречаться несколько раз на странице.
Значение: навигационный раздел со ссылками на другие страницы или другие части страниц.
Типовые ошибки: многие считают, что в может быть только список навигационных ссылок, но согласно спецификации там может быть навигация в любой форме.
Значение: вводная часть смыслового раздела или всего сайта, обычно содержит подсказки и навигацию. Чаще всего повторяется на всех страницах сайта.
Особенности: этих элементов может быть несколько на странице.
Типовые ошибки: использовать только как шапку сайта.
Значение: основное, не повторяющееся на других страницах, содержание страницы.
Особенности: должен быть один на странице, исходя из определения.
Типовые ошибки: включать в этот тег то, что повторяется на других страницах (навигацию, копирайты и так далее).
Значение: заключительная часть смыслового раздела или всего сайта, обычно содержит информацию об авторах, список литературы, копирайт и так далее. Чаще всего повторяется на всех страницах сайта.
Особенности: этих элементов может быть несколько на странице. Тег не обязан находиться в конце раздела.
Типовые ошибки: использовать только как подвал сайта.
Как разметить страницу с точки зрения семантики
Процесс разметки можно разделить на несколько шагов с разной степенью детализации.
Заголовок всего документа и заголовки смысловых разделов. Теги:
Мелкие элементы в смысловых разделах. Списки, таблицы, демо-материалы, параграфы и переносы, формы, цитаты, контактная информация и прогресс.
Фразовые элементы. Изображения, ссылки, кнопки, видео, время и мелкие текстовые элементы.
Сомневаюсь, какие теги использовать
Есть простые правила для выбора нужных тегов.
Получилось найти самый подходящий смысловой тег — использовать его.
Для потоковых контейнеров —
Можете дать имя разделу и вынести этот раздел на другой сайт? —
Можете дать имя разделу, но вынести на другой сайт не можете? —
Не можете дать имя? Получается что-то наподобие «новости и фотогалерея» или «правая колонка»? —
Как точно не нужно делать
Не используйте семантические теги для украшательств. Для этого есть CSS.
Может показаться, что некоторые теги подходят для того, чтобы сделать страницу покрасивее, подвигать текст или добавить ему интервалов. Но то, что браузер по умолчанию отображает теги как-то, как вам нужно, не значит, что это нужно использовать. Посмотрим на пример.
Здесь сразу несколько ошибок:
должен использоваться для выделения в тексте цитат, а не просто случайного выделения текста. Так совпало, что в браузерах этот блок по умолчанию выделен, но это не значит, что нужно его использовать таким образом.
использован, чтобы визуально раздвинуть текст. На самом деле этот тег используется для выделения параграфов.
А любое выделение, сдвиг или иные превращения текста можно выполнить с помощью CSS.
Поэтому используйте семантические теги по назначению.
Более подробно методика создания семантической разметки описана в навыке «Создание семантической разметки по макету» и курсах HTML Academy. Можно начать с бесплатных тренажёров по основам HTML и CSS или с курса «Профессиональная вёрстка сайтов». А с промокодом SKUCHNO цена станет ещё приятнее.
Готовим идеальный CSS
Не так давно я понял, что работа с CSS во всех моих приложениях — это боль для разработчика и пользователя.
Под катом лежат мои проблемы, куча странного кода и подводные камни на пути к правильной работе со стилями.
Проблемный CSS
В проектах на React и Vue, которые я делал, подход к стилям был примерно одинаковым. Проект собирается webpack’ом, из главной точки входа импортируется один CSS файл. Этот файл импортирует внутри себя остальные CSS файлы, которые используют БЭМ для наименования классов.
Знакомо? Такую реализацию я использовал почти везде. И все было хорошо, пока один из сайтов не разросся до такого состояния, что проблемы со стилями начали сильно мозолить мне глаза.
1. Проблема hot-reload’а Импортирование стилей друг из друга происходило через плагин postcss или stylus-loader. Загвоздка вот в чем:
Когда мы решаем импорты через плагин postcss или stylus-loader, на выходе получается один большой CSS файл. Теперь даже при незначительном изменении одного из файлов стилей все CSS файлы будут обработаны заново.
Это здорово убивает скорость hot-reload’a: обработка
950 Кбайт stylus-файлов занимает у меня около 4 секунд.
Если бы импорт CSS файлов решался через css-loader, такой проблемы бы не возникло: css-loader превращает CSS в JavaScript. Он заменит все импорты стилей на require. Тогда изменение одного CSS файла не будет затрагивать другие файлы и hot-reload произойдет быстро.
2. Проблема code-splitting’а
Когда стили подгружаются из отдельной папки, мы не знаем контекст использования каждого из них. С таким подходом никак не получится разбить CSS на несколько частей и подгружать их по мере необходимости.
3. Большие названия CSS классов
Каждое имя БЭМ класса выглядит вот так: block-name__element-name. Такое длинное имя сильно влияет на финальный размер CSS файла: на сайте Хабра, например, названия CSS классов занимают 36% от размера файла стилей.
Google знает об этой проблеме и во всех своих проектах давно использует минификацию имен:
Кусочек сайта google.com
Меня порядком достали все эти проблемы, я наконец решил покончить с ними и добиться идеального результата.
Выбор решения
Для избавления от всех вышеперечисленных проблем я нашел два варианта решения: CSS In JS (styled-components) и CSS modules.
Критичных недостатков у этих решений я не увидел, но в конце концов мой выбор пал на CSS Modules из-за нескольких причин:
Базовая настройка
Немного настроим конфигурацию webpack’а. Добавим css-loader и включим у него CSS Modules:
Теперь раскидаем CSS файлы по папкам с компонентами. Внутри каждого компонента импортируем нужные стили.
Теперь, когда мы разбили CSS файлы, hot-reload будет обрабатывать изменения только одного файла. Проблема №1 решена, ура!
Разбиваем CSS по чанкам
Когда в проекте много страниц, а клиенту нужна только одна из них, выкачивать все данные не имеет смысла. Для этого в React’е есть прекрасная библиотека react-loadable. Она позволяет создать компонент, который динамически выкачает нужный нам файл при необходимости.
Webpack превратит компонент CoolComponent в отдельный JS файл (чанк), который скачается, когда будет отрендерен AsyncCoolComponent.
При этом, CoolComponent содержит свои собственные стили. CSS лежит пока в нем как JS строка и вставляется как стиль с помощью style-loader’a. Но почему бы нам не вырезать стили в отдельный файл?
Сделаем так, чтобы и для главного файла, и для каждого из чанков создался свой собственный CSS файл.
Устанавливаем mini-css-extract-plugin и колдуем с конфигурацией webpack’а:
Вот и все! Соберем проект в production режиме, откроем браузер и посмотрим вкладку network:
С проблемой №2 покончено.
Минифицируем CSS классы
Css-loader изменяет внутри себя названия классов и возвращает переменную с отображением локальных имен классов в глобальные.
После нашей базовой настройки, css-loader генерирует длинный хеш на основе имени и местоположения файла.
В браузере наш CoolComponent выглядит сейчас так:
Конечно, нам этого мало.
Необходимо, чтобы во время разработки были имена, по которым можно найти оригинальный стиль. А в production режиме должны минифицироваться имена классов.
Css-loader дает возможность кастомизировать изменение названий классов через опции localIdentName и getLocalIdent. В режиме разработки зададим описательный localIdentName — ‘[path]_[name]_[local]’, а для production режима сделаем функцию, которая будет минифицировать названия классов:
И вот у нас при разработке красивые наглядные имена:
А в production минифицированные классы:
Третья проблема преодолена.
Убираем ненужную инвалидацию кэшей
Используя технику минификации классов, описанную выше, попробуйте собрать проект несколько раз. Обратите внимание на кэши файлов:
Похоже, после каждой новой сборки у нас инвалидируются кэши. Как же так?
Проблема в том, что webpack не гарантирует порядок обработки файлов. То есть CSS файлы будут обработаны в непредсказуемом порядке, для одного и того же имени класса при разных сборках будут сгенерированы разные минифицированные имена.
Чтобы победить эту проблему, давайте сохранять данные о сгенерированных именах классов между сборками. Чуть-чуть обновим файл getScopedName.js:
Реализация файла generatorHelpers.js не имеет большого значения, но если интересно, вот моя:
Кэши стали одинаковыми между сборками, все прекрасно. Еще одно очко в нашу пользу!
Убираем переменную рантайма
Раз уж я решил сделать лучшее решение, было бы неплохо убрать эту переменную с отображением классов, у нас ведь есть все необходимые данные на этапе компиляции.
С этим нам поможет babel-plugin-react-css-modules. Во время компиляции он:
Обновим наши JSX файлы:
И вот мы перестали использовать переменную с отображением названий стилей, теперь ее у нас нет!
Соберем проект и изучим исходники:
Похоже, переменная все еще осталась, хотя она нигде не используется. Почему так произошло?
В webpack’е поддерживается несколько видов модульной структуры, самые популярные — это ES2015 (import) и commonJS (require).
Модули ES2015, в отличие от commonJS, поддерживают tree-shaking за счет своей статичной структуры.
Но и css-loader, и лоадер mini-css-extract-plugin используют синтаксис commonJS для экспортирования названий классов, поэтому экспортируемые данные не удаляются из билда.
Напишем свой маленький лоадер и удалим лишние данные в production режиме:
Проверяем собранный файл еще раз:
Можно выдохнуть с облегчением, все сработало.
Вначале наиболее очевидным мне показалось использовать уже существующий пакет null-loader.
Но все оказалось не так просто:
Как видно, помимо основной функции, null-loader экспортирует еще и функцию pitch. Из документации я узнал, что pitch методы вызываются раньше остальных и могут отменить все последующие лоадеры, если вернут из этого метода какие-то данные.
С null-loader’ом последовательность production процессинга CSS начинает выглядеть так:
Если у вас под рукой есть только один Vue.js, но очень хочется сжать названия классов и убрать переменную рантайма, то у меня есть отличный хак!
Все, что нам понадобится — это два плагина: babel-plugin-transform-vue-jsx и babel-plugin-react-css-modules. Первый нам понадобится для того, чтобы писать JSX в рендер функциях, а второй, как вам уже известно — для генерации имен на этапе компиляции.
Сжимаем CSS по полной
Представьте, в проекте появился такой CSS:
Вы — CSS минификатор. Как бы вы его сжали?
Я думаю, ваш ответ примерно такой:
Теперь проверим, что сделают обычные минификаторы. Засунем наш кусок кода в какой-нибудь online минификатор:
Минификатор боится, что из-за смены порядка объявления стилей у вас что-то поломается. Например, если в проекте будет такой код:
Из-за вас заголовок станет красным, а онлайн минификатор оставит правильный порядок объявления стилей и у него он будет зеленым. Конечно, вы знаете, что пересечения component1__title и component2__title никогда не будет, они ведь находятся в разных компонентах. Но как сказать об это минификатору?
Порыскав по документациям, возможность указания контекста использования классов я нашел только у csso. Да и у того нет удобного решения для webpack’а из коробки. Чтобы ехать дальше, нам понадобится небольшой велосипед.
Нужно объединить имена классов каждого компонента в отдельные массивы и отдать внутрь csso. Чуть ранее мы генерировали минифицированные названия классов по такому паттерну: ‘[componentId]_[classNameId]’. А значит, имена классов можно объединить просто по первой части имени!
Пристегиваем ремни и пишем свой плагин:
А это было не так уж и сложно, правда? Обычно, такая минификация дополнительно сжимает CSS на 3-6%.
Стоило ли оно того?
В моих приложениях наконец появился быстрый hot-reload, а CSS стал разбиваться по чанкам и весить в среднем на 40% меньше.
Это ускорит загрузку сайта и уменьшит время парсинга стилей, что окажет влияние не только на пользователей, но и на СЕО.
Статья сильно разрослась, но я рад, что кто-то смог доскроллить ее до конца. Спасибо, что уделили время!
7 сентября 2015 | Опубликовано в css | Нет комментариев »
Продолжая тему лаконичной и современной шапки сайта, в этом уроке мы рассмотрим самые основные элементы страницы, такие как блоки и формы. На наш взгляд, совершенно одинаковые блоки — это не очень интересно, так что мы создали четыре типа блоков с разными заголовками и подписями. А так же для примера дизайна форм мы создали форму обратной связи. Так что у нас получился дизайн целой страницы. Перед тем, как начать, посмотрите, что именно мы будем создавать в этом уроке:
Вот демонстрация работы и исходный код:
Скачайте пример, и приступим к работе.
Шаг 1. Код HTML
Сначала добавим основной раздел со всеми упомянутыми элементами:
index.html
Как видите, все довольно просто. В основном разделе всего два столбца и один элемент подвала страницы. В каждом разделе находятся разные блоки. По умолчанию, если нужно создать блок, используйте для этого класс block, а если нужно изменить внешний вид блока, используйте другое название класса, например, block_a, block_b или block_c. Так можно задать блокам, в частности, разные цвета. Еще можно использовать заголовки и подписи в блоках, в нашем случае элементы h3 классов head или foot. И также можно настраивать стили заголовков и подписей с помощью таких классов, как head_a, head_b, head_c, foot_a, foot_b и foot_c. В конце находится стандартная форма обратной связи.
Шаг 2. Код CSS
css/main.css
Теперь приступим к наиболее важной части — заданию стилей. Для начала зададим основные стили макета для столбцов:
Вот стили для разных блоков:
И, наконец, зададим стили форме обратной связи:
Если хотите поместить что-то в подвал сайта, можно использовать следующие стили:
Заключение
Это все. Надеемся, Вам понравился этот урок и он Вам пригодится.
Продолжая тему лаконичной и современной шапки сайта, в этом уроке мы рассмотрим самые основные элементы страницы, такие как блоки и формы. На наш взгляд, совершенно одинаковые блоки — это не очень интересно, так что мы создали четыре типа блоков с разными заголовками и подписями. А так же для примера дизайна форм мы создали форму обратной связи. Так что у нас получился дизайн целой страницы. Перед тем, как начать, посмотрите, что именно мы будем создавать в этом уроке:
