Статьи

Написание гибкого CSS

Быть парнем из CSS сейчас не очень интересно. Еще несколько лет назад сцена css развивалась с активностью, пытаясь преодолеть различные ошибки браузера и недостатки css. Каждый месяц появлялся новый метод, который исправлял те или иные неприятные проблемы, избавляя нас от стресса и ругательств. Но эти дни прошли. Браузеры улучшились, большинство ошибок исправлено (хотя некоторые несущественные остаются), и мир снова установился на земле CSS.

Заглядывая вперед, есть много интересных изменений CSS, ожидающих произойти. К сожалению, они ждут, чтобы это произошло более 5 лет, и трудно растянуть волнение в течение такого длительного периода времени. Тем не менее, это не неудача, а просто еще одна возможность. Глядя на CSS, который написан сегодня, есть много возможностей для улучшения. Мы могли бы научиться преодолевать ошибки, но мы так и не достигли цели сделать это .

При написании CSS чаще всего есть несколько способов решить определенную проблему. И между этими выборами есть хорошие и плохие. Или, по крайней мере, выбор, который лучше и хуже. Способы, которые позволяют нам писать чистые и простые в управлении CSS и способы, которые приводят к грязным, запутанным CSS. Удивительно, но вряд ли кому-то все равно стоит задуматься об этом выборе. Вы сталкиваетесь с небольшими отрывками и отступлениями, которые предполагают превосходство определенных методов, но если вы ищете информацию о том, как сделать ваш CSS более управляемым и гибким, вы получите очень мало.

В этой статье рассматриваются несколько методов для улучшения вашего CSS, выбранных с учетом гибкости и простоты адаптации. Они не потрясающие и не революционные, но они улучшат гибкость вашего CSS, даже если он немного. То, что следует, очевидно, не является исчерпывающим списком методов и является лишь началом для начала.

Подумайте «страницы» и «компоненты»

Веб-сайт, как правило, представляет собой комбинацию страниц и компонентов. Несмотря на то, что (визуальный и функциональный) дизайн обычно довольно хорошо обрисован, когда сайт находится в разработке, вы никогда не знаете, что может произойти через 6 месяцев. Редизайн может быть довольно резким, и «Нет, никогда». имеет тенденцию превращаться в «Да, хорошо, но …». Всегда лучше быть готовым, когда это происходит.

В идеале это означало бы, что каждая страница на сайте будет иметь уникальный идентификатор (комбинация значений атрибутов id и class). Это, конечно, слишком оптимистично и практически невозможно осуществить. Тем не менее, когда вы начинаете выкладывать свои HTML-работы, имейте в виду, что было бы безопасно, по крайней мере, идентифицировать разделы (и подразделы) сайта независимо от того, какими могут быть преимущества текущего дизайна. Это защитит вас от будущих изменений и оставит вас во власти дизайна, просто указав компоненты в (под) разделах.

Используйте атрибуты id в элементе body для идентификации уникальных разделов на сайте, атрибуты класса можно использовать для дальнейшего указания подразделов (которые затем можно повторить в разных разделах — то есть с использованием классов). Это не приведет к наименьшему возможному HTML, но значительно улучшит гибкость ваших вариантов CSS.

Баланс вашего HTML и CSS

 /* messy css */  
.heading {font-size:108%; padding:0em 0.93em;}
/* clean css */
.heading {padding:0em 1em;}
.heading span {font-size:108%;}

Написание минимально возможного HTML-кода довольно утомительно, но даже тогда иногда бывает полезно добавить дополнительные структурные элементы, чтобы немного облегчить работу CSS. В идеальном мире, с идеальной поддержкой браузера и всеми инструментами CSS, это не будет рекомендуемой практикой. Но этот мир не существует, и хотя мы стараемся поддерживать наш html как можно более чистым, это часто приводит к тому, что мы испортили наш CSS.

Лучший пример, который я нашел, это добавить дополнительный тег span внутри каждого тега заголовка. Мало того, что это может использоваться для методов замены изображения, это также очень ценно при настройке размера шрифта заголовка. Таким образом, вы можете хранить объявления полей и отступов в теге заголовка, не затрачивая много времени на расчеты, чтобы все это работало, предполагая, что вы работаете над дизайном на основе em (поэтому при увеличении шрифта нет полей 0,93em). размер до 108%).

Дополнительный элемент span может показаться излишним, но он сохраняет чистоту CSS и делает HTML более перспективным для будущего. Именно то, что мы искали.

Один эффект, Одно место, Одно значение

 /* messy css */  
.parent {padding-left:0.5em;}
.parent .child {margin-left:0.5em;}
/* clean css */
.parent .child {margin-left:1em;}

Считайте, что это очень важное правило в дизайне CSS, но, к сожалению, оно часто игнорируется. Для простого обслуживания CSS важно, чтобы вы попытались зафиксировать каждый (визуальный) эффект в одном операторе CSS. Пример выше иллюстрирует это правило. Общий эффект обоих операторов одинаков, а именно: разрыв в 1em слева от содержимого, но поддержка чистого примера намного проще, так как CSS более прозрачен. Если кто-то попросит вас адаптировать разрыв в 1em, это можно сделать в одном месте с одним простым изменением.

Такие беспорядочные CSS часто бывают результатом быстрых изменений, внесенных во время разработки. Вместо того, чтобы рассматривать лучший способ удовлетворить небольшой запрос на изменение, применяется первое решение, которое приходит на ум. В этом нет ничего плохого, если его потом почистить. Излишне говорить, что для большинства проектов это не более, чем иллюзия и грязный CSS, как это заканчивается в конечном результате.

Это правило, которое не всегда может быть выполнено, но, вероятно, должно быть всегда в глубине души, особенно при работе с отступами, полями, границами и другими типичными элементами, которые могут испортить ваш CSS.

Shorthands

 /* example 1 */  
.container {border-left:1px solid #000; border-right:1px solid #000;}
/* example 2 */
.container {border:1px solid #000; border-left:none; border-right:none;}

Одним из наиболее интересных приложений предыдущего правила является использование сокращений. Конечно, сокращенные объявления CSS используются для того, чтобы сделать CSS более компактным, но мы можем сделать с ним больше, если захотим.

Ответственно используя сокращения, мы можем выразить отношения между стилями связанных элементов. Приведенные выше утверждения снова приведут к тому же эффекту, но они выражают разную связь между обеими границами. Первый пример определяет их как отдельные элементы. Один может быть стилизован по-другому от другого. Второе утверждение определяет их как связанные элементы, где стиль обоих должен всегда оставаться одним и тем же. Цвет или ширину обеих границ можно изменить одним простым изменением.

 /* example 1 */  
.heading {padding:0.5em; background:#0f0;}
/* example 2 */
.heading {padding:0.5em 0.5em; background:#0f0;}

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

Хотя второй пример может показаться немного неловким на первый взгляд, это, вероятно, лучший вариант для выбора. В таком случае левый и правый отступы заголовка обычно зависят от контура содержимого под заголовком. Это может варьироваться вдоль линии, но это не повлияет на верхний / нижний отступ заголовка. Если вы выберете первый вариант и изменится содержание под заголовком, вам нужно будет переписать оператор css.

Тривиально ты говоришь? Возможно, но все еще является хорошим показателем для людей, работающих над изменениями спустя долгое время после того, как вы доставили исходный файл css, и вы можете даже удивиться влиянию, когда вы работаете с файлом, имеющим более 1000 строк (1 селектор / строка css ). Эти отношения поначалу могут быть не всегда понятны, но быстрое общение с дизайнером и достаточный опыт помогут вам в этом.

Поля и прокладки

 /* example 1 */  
.container {padding:0.5em;}
/*example 2 */
.container>* {margin:0.5em;}

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

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

По-прежнему существуют проблемы с переходом на поля, такие как обрезанные фоны и общая поддержка IE6, но с точки зрения гибкости поля значительно превосходят отступы.

Селектор элементов

 /* bad example */  
ul.breadcrumb {...}
/* good example */
.breadcrumb {...}

Наконец, есть выбор добавления селекторов элементов в объявления CSS. В приведенном выше примере мы объявили наши стили хлебных крошек для элемента ul. Тем самым мы заблокировали CSS для HTML.

Это нормально, если элемент html является семантическим эквивалентом компонента, который он представляет. Другими словами, до тех пор, пока семантическое значение используемого элемента html является точным соответствием для компонента. В случае с хлебными крошками мы используем простой список HTML. Элемент списка, очевидно, не является семантическим соответствием для хлебных крошек, поскольку он является более общим, что делает более безопасным исключение селектора элемента.

Это станет до боли очевидным, когда вы когда-нибудь решите заменить элемент ul на элемент ol. Чисто семантическая проблема HTML, которая не должна включать изменение CSS, так как стили и поведение компонента не изменились вообще.

Использование селекторов элементов нормально, если к разным html-элементам применен один и тот же класс или если семантическое значение отражает компонент, для которого он используется (например, стилизация абзацев). Если нет, то оставьте селектор элементов выключенным, так как это только принесет вам проблемы в будущем.

Вывод

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

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

Поэтому не думайте об этих методах как о конкретных рекомендациях, но не забывайте думать о гибкости, которую метод может дать вам в следующий раз, когда вы записываете что-то в свой файл CSS. И думайте об этом только как о начале, я уверен, что есть еще много интересных примеров. Было бы замечательно увидеть, как сцена css немного повзрослела, вдали от полуструктурированной кучи мусора, которой она является сегодня, в более гибкую и простую в обслуживании область.

Гибкость может быть лишь одним из многих факторов, с которыми мы сталкиваемся при написании CSS, но она все еще очень игнорируется, и это неправомерно.