От автора: давайте говорить на чистоту: почти все используют библиотеки типа normalize.css или создают свои собственные базовые стили для элементов. Причин может быть несколько.
Возможные причины:
вам не нужны элементы без стилей;
вы хотите писать простой и чистый HTML;
вы хотите писать код быстро и мало.
Я прекрасно понимаю ваши желания. Но я думаю, вы согласитесь, что у CSS есть свои преимущества?
можно создавать повторно используемые правила;
вы отделяете разметку от стилей.
Если ваш ответ да, я задам вам вопрос: Зачем вы до сих пор стилизуете элементы?
Почему стилизовать элементы это плохо?
Когда вы стилизуете элементы, вы прикрепляете стили к DOM. Могу поспорить, что вы встречали что-то похожее:
1 |
<h1 class="as-h2">I am an evil styled element headline</h1> |
Зачем это нужно? Тут же необходимо стилизовать h1. Почему не использовать h2? Потому что вас заставляет делать это ваша структура контента, вы заботитесь о семантике. Вот и используете h1. В классе .as-h2 вам необходимо переписать все правила тега h1, которые вы хотите убрать из стилей h2. Думаете, там дел-то всего ничего? А про другие заголовки не забыли? В самом худшем случае вам нужно несколько классов заголовков, которые будут соответствовать каждому тегу заголовков. Выглядеть это будет так:
1 2 3 4 5 6 7 8 9 10 11 12 |
.h1-as-h2 .h1-as-h3 .h1-as-h4 .h1-as-h5 .h1-as-h6 .h2-as-h1 .h2-as-h3 .h2-as-h4 .h2-as-h5 .h2-as-h6 ........ .h6-as-h5 |
Еще не поняли? У меня полно примеров!
Делали так раньше?
1 2 3 |
a:hover { //Я злой элемент text-decoration: underline; } |
Если да, то, скорее всего, вы делали это в меню:
1 2 3 4 5 |
nav { li a:hover { text-decoration: none; } } |
И в стилях кнопок на теге <a>:
1 2 3 |
.button:hover { text-decoration: none; } |
И опять… Один ленивый разработчик не может просто так взять и стилизовать элементы.
И это не все! Тот же бардак творится в отладке. Пример панели разработчика в Chrome:
Chrome отлично справляется, показывая нам реальные стили и зачеркивая переписанные. Однако намного проще было бы читать стили, избежав всего этого. Скриншот выше – пример реального сайта, который я нашел. Помимо перезаписей здесь есть еще одна проблема: кто-то переписал text-decoration: none;, хотя он уже стоял в none. Зачем? Может человек просто запутался? Или он хотел убедиться, что изменения в <a> не сломают стили кнопки?
Такой же бардак творится в командах разработчиков
Вы когда-нибудь работали в компании с местным SEO гением? Могу сказать, что большую часть времени работа проходит так: вы создаете проект, аккуратно пишите разметку, проектируете ее со всей любовью и заботой, после чего вашему SEO специалисту необходимо провести оптимизацию… и он говорит: Нужно изменить все элементы.
Неееееееет! Ты знаешь, сколько я это делал? Невозможно, дедлайн уже завтра!!
Знаете что? Я знаю, как этого избежать. Никогда не стилизуйте элементы (глобально)! Думаю, вы поняли.
Классы спешат на помощь
Лучше используйте классы. Используйте классы для всего. Сначала покажется, что так вы пишите гораздо больше кода, но если поднять глаза чуть выше, вы поймете, что это не так. Вы будете писать много классов, но если все делать правильно, вам не нужно будет переписывать правила.
1 |
<p class="paragraph">I am always a beautifully styled paragraph.</p> |
Я знаю, о чем вы сейчас думаете! Ты хочешь мне сказать я должен создать класс paragraph для параграфа?
Да! Тег <p> буквально говорит: «я параграф». Но он не выглядит, как параграф. Это уже задача CSS! Теперь вы можете подумать, что ваш тег <p> всегда будет похож на параграф, а не на что-то еще. Что в этом случае?
1 2 3 |
<p class="intro">I am always a beautifully styled intro</p> <p class="hint">I am always a beautifully styled hint</p> <p class="description">I am always a beautifully styled description</p> |
Надеюсь, вы поняли 🙂 А что со ссылками? Все просто! Используйте классы.
1 2 3 |
<a class="link">I am always a beautifully styled link</a> <a class="text-link">..</a> <a class="navigation-link">..</a> |
Работа с заголовками
Вместо того чтобы стилизовать теги h1-h6, проименуйте их. На мой взгляд, очень трудно придумать семантические имена заголовкам, так как дизайнеры по большей части используют их, как хотят и где хотят. Для таких как вы, логически мыслящих разработчиков, иногда не так просто понять, почему один заголовок отличается от другого, даже если иерархия у них одна и та же. В большинстве проектов я придерживаюсь следующего подхода:
1 2 3 4 5 6 7 |
.headline { ... } //использовать для всех заголовокв .headline.large { ... } // использовать для самых больших заголовков, в основном h1 .headline.big { ... } // в основном h2 .headline.medium { ... } // в основном h3 .headline.minor { ... } // в основном h4 .headline.small { ... } // в основном h5 .headline.mini { ... } // в основном h6 |
Проблема тут в том, что вы, зная английский, можете подумать, что «large» больше «big», но кто-то еще может подумать, что «big» — самый большой заголовок. Та же беда со «small» и «mini».
Работа с разметкой, генерируемой из CMS
Основная проблема при работе с CMS заключается в том, что вы не всегда можете контролировать выходные данные WYSIWYG редактора. Если можете, используйте классы. Если не можете, используйте классы-обертки.
1 2 3 4 5 6 7 8 9 10 |
.wysiwyg { h1 { ... } h2 { ... } p { ... } a { ... } ... } // или так .paragraph, .wysiwyg p { ... } |
Если вы используете препроцессор типа Sass, вы с легкостью можете использовать правило extend.
1 2 3 |
.wysiwyg { p { @extend .paragraph; } } |
Но я вас прошу, используйте класс .wysivig аккуратно! Всегда применяйте его к низшему уровню, чтобы он изменял только контент, поступивший из CMS.
Списки меню
Эта же проблема может возникнуть в динамически генерируемых меню. Используйте те же правила. Если можете контролировать разметку, используйте классы. Выглядеть это будет так:
1 2 3 4 5 6 7 8 9 10 11 12 |
<nav class="navigation"> <ul class="navigation_list __level-1"> <li class="navigation_item __level-1"> <a class="navigation_text __level-1">Navigation item name</a> <ul class="navigation_list __level-2"> <li class="navigation_item __level-2"> <a class="navigation_item __level-2"></a> </li> </ul> </li> </ul> </nav> |
Если не можете, убедитесь, что используете безопасный класс-обертку и стилизуйте теги ul и li внутри него. Пока что лучше ничего не придумали. Классы можно также добавлять через JS, но это может быть не так приятно. Пытайтесь не писать правила, которые стилизуют элементы больше чем на один уровень, потому что так вы будете часто переписывать сами себя. Если в вашем меню более двух уровней, вы быстро разочаруетесь.
Боженьки ты мой, теперь мой HTML ужасен
Что, правда? Мне такой код читать намного легче. Вам нужно именовать все, что вы делаете. Так будет легче общаться с остальными. Не просто ul, а список меню, не просто <p>, а описание товара. Не просто первый <p>, а вступление.
Normalize.css использовать нельзя?
Конечно, можно. К примеру, если вы боитесь, что стили браузера по умолчанию все испортят. С другой стороны все стили браузера по умолчанию можно переписать в классах. По моему мнению, эта библиотека не нужна. Она только засоряет ваши стили, что приведет к еще большим перезаписям.
Используйте свойство display во всех классах
Чтобы по-настоящему отделить стили от разметки, вам необходимо будет в каждом классе задавать свойство display. Зачем? Из-за стилей браузера по умолчанию. Представьте:
1 |
<div class="hint">Remember to always set a display property</div> |
И тут подходит ваш SEO специалист и говорит, что код должен быть таким:
1 |
<small class="hint">Remember to always set a display property</small> |
Давай-давай, ты сам можешь все поправить, — скажете вы, как разработчик, который использует независимый CSS. Вы знаете, что тег small инлайновый по умолчанию, но вам-то какое дело. Вы, как маг CSS, предвидели такой сценарий и добавили свойство display еще до того, как SEO специалист попытался разрушить ваши мечты.
Обобщаем правила
не стилизуйте элементы, используйте классы, везде;
если не можете использовать классы, используйте обертки;
переписывайте значения браузера по умолчанию в классах, особенно свойство display;
не перезаписывайте сами себя.
Что мы получаем
меньше магии: стили наследуются только, если вы этого хотите;
меньше писанины: вы не переписываете сами себя;
меньше используем правило !important: специфичность никогда не должна вызывать проблем;
меньше путаницы при чтении разметки.
Ура! Хотите больше, подписывайтесь на меня 😉 Если у вас остались вопросы или отдельные случаи, спрашивайте меня в комментариях.
Автор: Marc Mintel
Источник: //medium.com/
Редакция: Команда webformyself.