Я делаю шаблоны на чистом HTML/CSS уже больше восьми лет. За это время я убедился, что различные соглашения и документирование помогают в работе. Конечно, они не спасают от периодических CSS-кошмаров. Они лишь делают их менее болезненными. Мое решение — следовать определенным принципам в написании стилей. Эти принципы образуют основание, на котором будет строиться все дальнейшее написание стилей, облегчая работу над растущим проектом.
Люди стесняются полностью использовать наследование стилей. Многие, кто работал с CSS долгое время, пишут очень сложные псевдо-селекторы, чтобы обработать конкретный элемент. Это все хорошо и круто, но способствует развитию нездоровой привычки — мы перестаем писать простые правила.
Мне преподали этот урок уже много раз. Я предпочитал быть аккуратным. Писал стили, которые были по-настоящему четкими и конкретными. Но это плохо. Особые правила загоняют в рамки, из которых потом очень трудно выбраться. Вместо этого, более обобщенные правила сделают ту же самую работу, и останется только дописать нестандартный код, когда ситуация того потребует. Взгляните на пример ниже:
Второе правило будет применено к каждому абзацу на сайте. Но, во-первых, это ведь хорошо. Представьте, как просто будет добавить особенное правило позже. С ростом проекта стилей все больше, они становятся сложней, а ситуации, когда необходимы какие-то особенные правила, возникают сами собой. Если мы с самого начала воспользовались преимуществом наследования, можно просто переопределить нужный код, когда понадобится.
Чтобы увидеть, как делать не нужно, посмотрите на пример ниже (третий набор правил как раз описывает добавление специфичных для конкретной ситуации стилей):
Это вроде как фундаментальный урок CSS. Мы можем написать стили, применимые к большинству объектов, а для особенных сделать более конкретные. Большинство людей, пишущих CSS, знают это. Чего обычно не знают — гораздо безопасней избежать лишней сложности, не создавая слишком особенных правил. Вот что надо запомнить:
Работаете вы один или командой — начинать стили надо с одного и того же. Точка отсчета — это набор правил, который определяет, какое поведение вы ожидаете от окружения. Это обычно важно если вы работаете над стилями постоянно, и еще важней, если разработчиков несколько. Каждый должен видеть одну и ту же страницу, поэтому наличие одинаковой основы — лучший трюк, помогающий в этом.
Моя точка отсчета — CSS Reset Эрика Мейера. К несчастью, использование сброса стилей для продакшена — спорный вопрос. Опытные разработчики считают, что это ненужно или просто плохо, но на самом деле мы все используем сброс в той или иной форме. Проблема сброса на самом деле в том, что он так называется. Это не сброс, это основание, на котором строятся наши ожидания поведения браузера.
На самом деле, даже если мы не используем CSS-сброс, нам все равно приходится его реализовывать, только в еще более изощренной форме. Мы кругом повторяем сами себя, там где это нужно, чтобы добиться желаемого поведения. Самый известный пример — отступы (margins). Каждый браузер для каждого элемента имеет свои стили по умолчанию. Ни один нормальный человек не сможет запомнить их все.
Если не задать свою точку отсчета, придется работать с браузерной. А значит, среда разработки становится менее предсказуемой и контролируемой. Это на самом деле страшно.
Я не говорю, что CSS-сброс — Святой Грааль написания хорошего кода. Вовсе нет. Он может быть вашей головной болью, если не приспособить его как следует. Ведь многие не любят какие-либо настройки в файле сброса, например отключение жирности у элемента <strong>. Это потому что чужой файл сброса — всего лишь пример. Вам и вашей команде необходимо доработать его под свои нужды. Если надо, чтобы <strong> был жирным — подправьте сброс. Со временем вы разработаете свой reset.css (хоть и на самом деле стоит его назвать base.css). Ключевые моменты этого урока:
Основной принцип CSS — если написать два одинаковых селектора, приоритетней будет последний. Иными словами, важен порядок. Но это довольно опасно — порядок будет влиять, если вы напишете селекторы одинакового приоритета.
С увеличением стилей все хуже удается их контролировать. Чтобы не затруднять работу, мы делим файлы на секции. Или даже разделяем правила на отдельные файлы.
Надежда на порядок в нашем коде делает его хрупким и ненадежым. Ведь с внедрением какой-либо стратегии организации кода мы можем запросто разрушить порядок, в которым правила следовали изначально. А это важно, потому что, как я уже говорил, удобней сначала писать обобщенные правила. Это не значит, что для организации базового кода порядок должен стать основополагающим. Если у вас есть два правила с одинаковым весом, которые могут конфликтовать, надо сделать одно из них более «тяжелым», чтобы этот код потом можно было использовать во фреймворке.
К тому же, в большинстве случаев, когда у нас появляются свойства, перезаписываемые из-за порядка, в котором они следуют, мы имеем дело с дублирующимися селекторами. Эти случаи — идеальный пример того, что коду, возможно, необходим рефакторинг.
Ключевые моменты таковы:
Нужно хорошо себе представлять, чего вы хотите. Надо четко знать, как и что должно делаться в вашем документе. Как это делается в CSS? Очень просто — комментированием. Мы можем предоставить достаточное количество документации в наших CSS-файлах, просто их комментируя. Можно использовать комментарии для:
Давайте подумаем, почему мы не пишем комментарии и не документируем код, даже если это полезно. Первая причина в том, что наши файлы от этого увеличиваются в размерах. Да, это действительно так, но можно ведь запросто использовать YUI Compressor, или написать простенький скрипт, который автоматизирует процесс уменьшения файлов и удаления комментариев из кода для продакшена.
Вторая причина заключается в том, что вы, скорей всего, единственный, кто будет работать с этими стилями. Это очень недальновидно. Всегда, всегда (всегда!) думайте о том, что кто-нибудь когда-нибудь может работать с этим файлом кроме вас. Вы ведь не будете трудиться над этим проектом вечно. Иными словами — считайтесь с тем, что кто-нибудь, возможно, будет дописывать или редактировать ваши стили. Вы можете либо подсказать, как это сделать лучше всего и без вас, либо вычищать и переписывать все самому, когда вас позовут чинить сломанный сайт.
Уметь ясно изъясняться гораздо тяжелей, чем кажется. Как лучше всего рассказать, чего вы ожидаете от вклада другого разработчика? Лично я пишу свои лучшие практики в виде коротких наставлений с примерами и комментариями в начале файла. Что-то вроде такого:
Смысл в том, что можно использовать комментария для ясного и четкого объяснения манеры, в которой должен быть написан код. Просто оформляйте все свои файлы определенным образом. Пользователи Textmate могут воспользоваться специальным бандлом для этого. Что надо запомнить по этой теме:
Урок первый: Будь конкретным только там, где надо
Люди стесняются полностью использовать наследование стилей. Многие, кто работал с CSS долгое время, пишут очень сложные псевдо-селекторы, чтобы обработать конкретный элемент. Это все хорошо и круто, но способствует развитию нездоровой привычки — мы перестаем писать простые правила.
Мне преподали этот урок уже много раз. Я предпочитал быть аккуратным. Писал стили, которые были по-настоящему четкими и конкретными. Но это плохо. Особые правила загоняют в рамки, из которых потом очень трудно выбраться. Вместо этого, более обобщенные правила сделают ту же самую работу, и останется только дописать нестандартный код, когда ситуация того потребует. Взгляните на пример ниже:
Второе правило будет применено к каждому абзацу на сайте. Но, во-первых, это ведь хорошо. Представьте, как просто будет добавить особенное правило позже. С ростом проекта стилей все больше, они становятся сложней, а ситуации, когда необходимы какие-то особенные правила, возникают сами собой. Если мы с самого начала воспользовались преимуществом наследования, можно просто переопределить нужный код, когда понадобится.
Чтобы увидеть, как делать не нужно, посмотрите на пример ниже (третий набор правил как раз описывает добавление специфичных для конкретной ситуации стилей):
Это вроде как фундаментальный урок CSS. Мы можем написать стили, применимые к большинству объектов, а для особенных сделать более конкретные. Большинство людей, пишущих CSS, знают это. Чего обычно не знают — гораздо безопасней избежать лишней сложности, не создавая слишком особенных правил. Вот что надо запомнить:
- Сложность ваших стилей прямо пропорциональна сложности ваших селекторов.
- Рефакторинг CSS-селекторов с целью уменьшения их конкретности гораздо трудней написания изначально простых правил с добавлением более сложных потом.
Урок второй: Надо с чего-то начинать
Работаете вы один или командой — начинать стили надо с одного и того же. Точка отсчета — это набор правил, который определяет, какое поведение вы ожидаете от окружения. Это обычно важно если вы работаете над стилями постоянно, и еще важней, если разработчиков несколько. Каждый должен видеть одну и ту же страницу, поэтому наличие одинаковой основы — лучший трюк, помогающий в этом.
Моя точка отсчета — CSS Reset Эрика Мейера. К несчастью, использование сброса стилей для продакшена — спорный вопрос. Опытные разработчики считают, что это ненужно или просто плохо, но на самом деле мы все используем сброс в той или иной форме. Проблема сброса на самом деле в том, что он так называется. Это не сброс, это основание, на котором строятся наши ожидания поведения браузера.
На самом деле, даже если мы не используем CSS-сброс, нам все равно приходится его реализовывать, только в еще более изощренной форме. Мы кругом повторяем сами себя, там где это нужно, чтобы добиться желаемого поведения. Самый известный пример — отступы (margins). Каждый браузер для каждого элемента имеет свои стили по умолчанию. Ни один нормальный человек не сможет запомнить их все.
Если не задать свою точку отсчета, придется работать с браузерной. А значит, среда разработки становится менее предсказуемой и контролируемой. Это на самом деле страшно.
Я не говорю, что CSS-сброс — Святой Грааль написания хорошего кода. Вовсе нет. Он может быть вашей головной болью, если не приспособить его как следует. Ведь многие не любят какие-либо настройки в файле сброса, например отключение жирности у элемента <strong>. Это потому что чужой файл сброса — всего лишь пример. Вам и вашей команде необходимо доработать его под свои нужды. Если надо, чтобы <strong> был жирным — подправьте сброс. Со временем вы разработаете свой reset.css (хоть и на самом деле стоит его назвать base.css). Ключевые моменты этого урока:
- Собственные базовые (сбросовые) стили позволяют лучше контролировать окружение.
- Для групп разработчиков одинаковые базовые стили — ключ к удобству совместной работы.
- Базовые стили не гарантируют кроссбраузерности, но все равно дают ожидаемый результат.
Урок третий: Полагайтесь на конкретность правил, а не их порядок
Основной принцип CSS — если написать два одинаковых селектора, приоритетней будет последний. Иными словами, важен порядок. Но это довольно опасно — порядок будет влиять, если вы напишете селекторы одинакового приоритета.
С увеличением стилей все хуже удается их контролировать. Чтобы не затруднять работу, мы делим файлы на секции. Или даже разделяем правила на отдельные файлы.
Надежда на порядок в нашем коде делает его хрупким и ненадежым. Ведь с внедрением какой-либо стратегии организации кода мы можем запросто разрушить порядок, в которым правила следовали изначально. А это важно, потому что, как я уже говорил, удобней сначала писать обобщенные правила. Это не значит, что для организации базового кода порядок должен стать основополагающим. Если у вас есть два правила с одинаковым весом, которые могут конфликтовать, надо сделать одно из них более «тяжелым», чтобы этот код потом можно было использовать во фреймворке.
К тому же, в большинстве случаев, когда у нас появляются свойства, перезаписываемые из-за порядка, в котором они следуют, мы имеем дело с дублирующимися селекторами. Эти случаи — идеальный пример того, что коду, возможно, необходим рефакторинг.
Ключевые моменты таковы:
- Стили, жестко завязанные на порядке следования правил — ненадежны и подвержены проблемам, связанным с реорганизацией кода.
- Правила, которые могут быть переопределены из-за их порядка появления в коде, могут или должны быть переписаны.
Урок четвертый: Будь ясным и выразительным
Нужно хорошо себе представлять, чего вы хотите. Надо четко знать, как и что должно делаться в вашем документе. Как это делается в CSS? Очень просто — комментированием. Мы можем предоставить достаточное количество документации в наших CSS-файлах, просто их комментируя. Можно использовать комментарии для:
- Описания наилучших практик.
- Указания на организационные моменты.
- Обеспечения ссылок на ресурсы.
Давайте подумаем, почему мы не пишем комментарии и не документируем код, даже если это полезно. Первая причина в том, что наши файлы от этого увеличиваются в размерах. Да, это действительно так, но можно ведь запросто использовать YUI Compressor, или написать простенький скрипт, который автоматизирует процесс уменьшения файлов и удаления комментариев из кода для продакшена.
Вторая причина заключается в том, что вы, скорей всего, единственный, кто будет работать с этими стилями. Это очень недальновидно. Всегда, всегда (всегда!) думайте о том, что кто-нибудь когда-нибудь может работать с этим файлом кроме вас. Вы ведь не будете трудиться над этим проектом вечно. Иными словами — считайтесь с тем, что кто-нибудь, возможно, будет дописывать или редактировать ваши стили. Вы можете либо подсказать, как это сделать лучше всего и без вас, либо вычищать и переписывать все самому, когда вас позовут чинить сломанный сайт.
Уметь ясно изъясняться гораздо тяжелей, чем кажется. Как лучше всего рассказать, чего вы ожидаете от вклада другого разработчика? Лично я пишу свои лучшие практики в виде коротких наставлений с примерами и комментариями в начале файла. Что-то вроде такого:
Смысл в том, что можно использовать комментария для ясного и четкого объяснения манеры, в которой должен быть написан код. Просто оформляйте все свои файлы определенным образом. Пользователи Textmate могут воспользоваться специальным бандлом для этого. Что надо запомнить по этой теме:
- Используйте комментарии, чтобы обозначить, как код должен быть написан и отформатирован другими.
- Всегда помните, что после вас над файлом может работать кто-нибудь другой.
- Используйте комментарии для разбиения кода на разделы. Комментарии могут помочь в навигации по документам.
Примечание переводчика: опытным разработчикам читать здесь нечего, они и так должны все это знать. С другой стороны, сравнительно недавно написанная статья затрагивает моменты, которые редко рассказываются в учебниках и самоучителях по HTML/CSS. В свое время те же самые выводы я сделал на основе горького опыта, поэтому, думается мне, новичкам, еще не испытавшим все горести и тяготы неправильно заложенной основы разработки, эта статья сильно поможет. Все-таки, действительно — best practices.
Пользуясь случаем, хочу передать привет и благодарность разработчикам сервиса translated.by
