В последние годы мир веб-дизайна и разработки претерпел изменения. Фреймворки разработки — как на стороне сервера (Rails, Django, CakePHP), так и на стороне клиента с JavaScript (jQuery, Prototype) и CSS (фреймворки CSS, такие как Blueprint и Grid System 960) — обещают повышенный уровень производительности, меньшее повторное кодирование для общих функций и, в случае клиентских сред, абстракция от несоответствий браузера. В то время как серверные и JavaScript-фреймворки широко приветствовались и принимались разработчиками, CSS-фреймворки были гораздо более противоречивыми среди дизайнеров.
Хотя я согласен с тем, что CSS-фреймворки имеют широкий спектр недостатков (таких как ненужный объем, дополнительные HTTP-запросы и риск чрезмерной зависимости от кода других разработчиков) и преимуществ (более быстрое время производства, меньше проблем с браузером, упрощение разработки для начинающих), само их существование дает нам возможность пересмотреть то, как мы пишем наш собственный код. В идеале, если мы сможем использовать лучшие уроки повторного использования, абстракции и простоты использования из этих платформ, мы можем избежать необходимости использовать CSS-фреймворки, адаптируя наш код в соответствии с их идеалами. Фреймворки CSS — это просто решение проблем, с которыми ежедневно сталкиваются веб-дизайнеры, позволяющие им создавать чистый, гибкий, кросс-браузерный код. Несмотря на то, что у этих инструментов есть свои проблемы, они могут служить отличной моделью для создания более качественного, более переносимого и многократно используемого CSS.
Цель этой статьи не в том, чтобы обсудить, следует ли вам использовать платформу, а в том, чтобы выяснить, почему существует необходимость в таких решениях. Мы возьмем процессы, использованные (и извлеченные уроки) при их создании, и попробуем показать, как их можно применять к вашим собственным таблицам стилей. Если вы изучите исходный код любой платформы, вы откроете для себя мир, наполненный инновационными способами увеличения мобильности стиля и, как следствие, увеличения собственной производительности без недостатков, которые обычно приносит использование сторонних компонентов. Это.
При создании кода CSS для ваших собственных проектов, вы, вероятно, проходите очень простой процесс принятия решения о том, как вы хотите, чтобы ваши элементы HTML отображались. Вы можете начать с применения соглашений, которые наследуются по всему сайту (с помощью селекторов элементов), и, как только это будет выполнено, вы подключите достаточно селекторов classid Это, конечно, требует времени и усилий, и если вы создадите более одного веб-сайта, вы вскоре обнаружите, что повторяете определенные соглашения (такие как макеты столбцов, стандартные типографии или, возможно, даже способ отображения ваших навигационных меню).
Проблемы, которые пытаются решить, можно разделить на три группы:
- Причуды браузера
-
Все браузеры обрабатывают CSS по-разному; любой, кто имел несчастье кодирования для Internet Explorer 6, может сказать вам это. Одним из аспектов CSS, с которым регулярно сталкиваются большинство дизайнеров, является набор недостатков и причуда, от которых страдают браузеры, как в том, как браузеры реализуют код CSS, так и в поддержке различных уровней спецификаций CSS.
- Общие компоненты
-
Соглашения существуют по причине: они предоставляют проекты, к которым пользователи могут быстро адаптироваться. Формы регистрации, предупреждения и уведомления об ошибках, статьи и связанные с ними метаданные — все они могут иметь набор общих конструктивных особенностей. Поскольку такие компоненты пишутся снова и снова, вы можете потратить время на то, чтобы просто восстановить прежние позиции.
- Повторите свойства
-
Раздувание кода является серьезной проблемой в любом процессе разработки, и CSS ничем не отличается: поскольку мы все больше и больше вкладываем стили в наши дизайны, мы можем обнаружить, что повторно используем свойства CSS сотнями разных способов, многие из которых могут иметь одинаковое значение. Некоторые дизайнеры предпочитают группировать свой код; Тем не менее, это все еще очень вопрос о применении предварительных стилей.
С этими проблемами сталкиваются все дизайнеры, которые используют CSS, и если вы решите не использовать фреймворк, вам все равно придется решать их в своей работе. Если мы небрежны, мы потратим много времени на то, чтобы заново изобрести колесо. Иногда в этом нет необходимости, а иногда — потому что мы снова и снова копируем соглашение о дизайне в интересах удобства использования. Изучение нашего собственного кода на предмет тех оптимизаций и уточнений, которые могут помочь решить эти проблемы, часто является нашим последним соображением при работе над проектом. Однако, как я надеюсь показать вам, библиотеки CSS щедро заботятся и заботятся о том, чтобы код был максимально долговечным и совместимым.
Чтобы лучше понять, как библиотеки CSS создают компоненты, которые могут быть повторно использованы или применены к широкому кругу проектов (тем самым ускоряя процесс разработки и уменьшая объем работы, которую вам нужно сделать), мы должны внимательно посмотреть на их источник код. Здесь я попытаюсь выделить способы, с помощью которых фреймворки используют различные типы селекторов CSS для определения своих соглашений и ловушек.
Библиотеки CSS, используемые в качестве основы для изучения их функционирования, включают в себя: 960 Grid System , Blueprint , BlueTrip , Elements , Emastic , Reset Эрика Мейера , SenCSs , Tripoli , Typogridphy , YUI Grids и YAML (еще один многоколонный макет) .
Почти все проверенные CSS-фреймворки используют какой-либо механизм сброса. Механизм сброса CSS берет каждый элемент в спецификации HTML, которому в некоторых браузерах назначается стиль по умолчанию, и переопределяет эти стили значениями nil (тем самым сбрасывая их в значения «по умолчанию»).
- метод
-
Использует селекторы элементов и случайные символы подстановки (
* - Использован
-
960, Blueprint, BlueTrip, Элементы, Emastic, EMR, SenCSs, Триполи, Типогридфи, YUI, YAML
- аргументация
-
Удаляя любые стили по умолчанию, механизмы сброса уменьшают количество несоответствий рендеринга и причуд, которые могут возникнуть между браузерами.
- Пример:
-
От Эрика Мейера Сброс:
html, тело, div, span, апплет, объект, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, аббревиатура, адрес, большой, привести, код, del, dfn, em, шрифт, img, ins, kbd, q, s, samp, small, strike, сильный, sub, sup, tt, var, b, u, i, центр, dl, dt, dd, ol, ul, li, fieldset, форма, метка, легенда, таблица, подпись, tbody, tfoot, thead, tr, th, td {margin: 0; отступы: 0; граница: 0; контур: 0; размер шрифта: 100%; выравнивание по вертикали: базовая линия; background: transparent;} body {line-height: 1;} ol, ul {list-style: none;} blockquote, q {quotes: none;} / * не забудьте определить стили фокуса! * /: focus {outline: 0;} / * не забудьте выделить вставки как-нибудь! * / ins {text-ornament: none;} del {text-ornament: line-through;} / * таблицам по-прежнему требуется 'cellspacing = "0"' в разметке * / table {border-collapse: collapse; интервал границы: 0;}
- Урок
-
Даже если вы не используете платформу, важно знать стиль по умолчанию, который применяется к определенным элементам браузерами. Забыв перезаписать свойство на основе элемента, часто может привести к путанице между браузерами в будущем. Вы можете разработать свой собственный набор стилей сброса или просто сохранить копию стилей сброса из стороннего фреймворка под рукой и добавить их в каждый новый проект.
Многие CSS-фреймворки, помимо сброса стилей браузера по умолчанию, также вводят некоторые новые настройки по умолчанию. В отличие от настроек браузера по умолчанию, удаленных при сбросе, они будут согласованными и надежными во всех браузерах, поскольку они представлены самой платформой. Эти новые значения по умолчанию обеспечивают разумную основу, с которой нужно начинать писать собственные стили.
- метод
-
Использует селекторы элемента или атрибута для применения стилей к каждому экземпляру элемента.
- Использован
-
960, Blueprint, BlueTrip, Элементы, Emastic, SenCS, Триполи, Типогридфи, YUI, YAML
- аргументация
-
Базовые стили могут уменьшить количество кода, необходимого для будущей разработки, так как базовые цели направлены на решение общих изменений в рамках всего проекта.
- пример
-
Из BlueTrip CSS Framework:
html {font-size: 62,5%; семейство шрифтов: "Liberation Sans", Helvetica, Arial, Sans-Serif; } сильный, th, thead td, h1, h2, h3, h4, h5, h6 {font-weight: bold; } цитировать, эм, dfn {font-style: italic; } code, kbd, samp, pre, tt, var, input [type = 'text'], input [type = 'password'], textarea {font-size: 92%; семейство шрифтов: монако, "Lucida Console", курьер, моноширинный; } del {text-ornament: line-through; цвет: # 666; } ins, dfn {border-bottom: 1px solid #ccc; } small, sup, sub {font-size: 85%; } abbr, акроним {text-transform: uppercase; размер шрифта: 85%; межбуквенный интервал: .1em; } аббревиатура, аббревиатура {граница: нет; } abbr [title], аббревиатура [title], dfn [title] {cursor: help; border-bottom: 1px solid #ccc; } sup {вертикальное выравнивание: супер; } sub {вертикальное выравнивание: sub; }
- Урок
-
Посмотрите на ваши последние несколько проектов. Существуют ли общеэлементные стили, которые вы склонны использовать в каждом проекте? Ищите способ абстрагировать стили, которые вы последовательно применяете к данному элементу или группе элементов.
Хотя это редко встречается в CSS-фреймворках — просто потому, что их природа делает их менее подходящими для разных проектов — иногда используются хуки id
- метод
-
Использует атрибуты
idid - использование
-
Элементы, Emastic, Typogridphy, YUI, YAML
- аргументация
-
Многие веб-страницы в конечном итоге состоят из одних и тех же основных структурных элементов. Если определенные свойства этих элементов согласованы между проектами, абстрагирование их и использование соглашений об именах может помочь уменьшить количество повторений и сэкономить время разработки.
- пример
-
Typogridphy Framework
#wrapper {width: 94em; поле: 0 авто;} # header {width: 94em; обивка-топ: 1.5em; margin-bottom: 2em;} # nav {font-size: 2em;} # nav a {font-option: small-caps; цвет: # 000;} # nav a: hover {text-decor: none;} # nav span {float: right; margin-top: -1.2em;} # footer-nav {интервал между словами: 0.2em;} # footer-nav a {color: # 000; вариант шрифта: маленькие заглавные буквы;}
- Урок
-
Как и в случае базовых стилей, ключом здесь является самоанализ. Просмотрите свой код и попробуйте найти повторение. Подумайте, как вы могли бы создать набор стилей, которые облегчили бы перенос этих базовых линий в новый проект, оставаясь гибкими и позволяя легко перезаписывать их или выбирать между ними по мере необходимости.
Крючки idclass Предоставляя набор class
- метод
-
Использует как атрибуты
class - использование
-
960, Blueprint, BlueTrip, Элементы, Emastic, SenCS, Триполи, Типогридфи, YUI, YAML
- аргументация
-
В то время как хуки
idclassнапример, относящийся к типографии или макету. Затем их можно легко применить к любому элементу в любом проекте, просто добавив соответствующийclassclass - Пример № 1
-
Сетка 960 использует атрибут
classЛюбому блоку или столбцу может быть присвоен.grid_xclassx столбцов основной сетки:.container_24 .grid_1 {ширина: 30px} .container_24 .grid_2 {ширина: 70px} .container_24 .grid_3 {ширина: 110px} .container_24 .grid_4 {ширина: 150px} .container_24 .grid_5 {ширина: 190px} .contain6_24 ширина: 230px} .container_24 .grid_7 {ширина: 270px} .container_24 .grid_8 {ширина: 310px} .container_24 .grid_9 {ширина: 350px} .container_24 .grid_10 {ширина: 390px} - Пример № 2
-
Blueprint также использует ряд числовых классов для установки ширины элементов сетки, хотя нет никакой зависимости от контейнера, такого как 960 Grid System:
.span-1 {ширина: 30px;}. span-2 {ширина: 70px;}. span-3 {ширина: 110px;}. span-4 {ширина: 150px;}. span-5 {ширина: 190px;} .span-6 {ширина: 230px;}. span-7 {ширина: 270px;}. span-8 {ширина: 310px;}. span-9 {ширина: 350px;}. span-10 {ширина: 390px;} - Пример № 3
-
SenCSs использует ловушки классов для другой цели; вместо того, чтобы полагаться на них для быстрого доступа к предопределенному макету сетки, он использует набор
class.error {background: #fee; граница: 1px сплошной красный; Маржа: 1.5em; обивка: 0.666em; выравнивание текста: центр;}. извещение {background: #eef; граница: 1px solid # 00f; Маржа: 1.5em; обивка: 0.666em; выравнивание текста: центр;}. success {background: #efe; граница: 1px solid # 0f0; Маржа: 1.5em; обивка: 0.666em; text-align: center;}. warning {background: #ffe; граница: 1px solid # ff0; Маржа: 1.5em; обивка: 0.666em; выравнивания текста: центр;}
- Урок
-
Это сложнее. Типы стилей, из которых вы можете создавать перехватчики классов, не всегда будут упаковываться вместе по
classНо вы все равно можете найти куски кода с большим потенциалом для повторного использования. Целью, опять же, является абстракция. Представьте, что вы подключаетесь к этим стилям в будущем проекте. Если вы можете извлечь набор макетов или типографских свойств таким образом, чтобы их было легче закрепить, вы сможете сэкономить много времени в дальнейшей разработке.
Итак, мы видели некоторые способы, которыми фреймворки стремятся сделать свой код многократно используемым. Может быть, вы сейчас чувствуете, что разрабатываете свою собственную инфраструктуру, но даже если вы этого не сделаете, эти уроки можно превратить в продуктивность. Я изложил шесть простых правил, которым нужно следовать для оптимизации вашего кода на основе уроков, извлеченных из CSS-фреймворков, которые мы изучили:
- Использовать соглашения об именах
-
Одним из основных способов, с помощью которого изученные фреймворки позволяли быстро «подключать» свои стили к новому дизайну, было использование соглашений об именах. Постоянно присваивая имена страниц, вы гарантируете, что любой стиль, который вы хотите использовать повторно, может быть быстро заменен практически без изменений.
- План для повторного использования
-
Это ключевой урок, который вы должны извлечь из изучения кода этих CSS-фреймворков. Что должно быть для вас очевидным, так это то, что эти библиотеки планируются с самого начала для использования в совершенно разных контекстах. Будь то установление набора разумных значений по умолчанию, упаковка общих определений типографики в набор предопределенных хуков
class - Исправить типичные проблемы браузера
-
IE6 заставляет некоторых из нас захотеть поднять руки вверх и плакать. Библиотеки CSS являются фантастическим примером того, как надлежащая обработка распространенных недостатков браузера может сократить время, необходимое для отладки кода, поскольку некоторые базовые исправления можно легко перенести в новые проекты. Ценный урок заключается в том, что при возникновении ошибок часто существует многократно используемый способ их устранения.
- Структура и групповой код
-
Со временем библиотеки кода становятся высоко оптимизированными, структурированными и улучшенными для максимальной гибкости, совместимости и переносимости. В CSS мы слишком часто используем то, что выполняет свою работу, вместо того, чтобы тратить время на стресс-тестирование или настройку нашего стиля, чтобы его можно было повторно использовать без необходимости повторять его везде. Урок: немного любви и заботы принесет пользу, особенно для постоянного обслуживания сайта. Структурирование вашего CSS логическим способом не только облегчит повторное использование, но и даст намного более читаемый код.
- Удалить избыточность
-
Хотя библиотеки CSS часто плотно упакованы, они обычно имеют функции, которые вы никогда не будете использовать, что приводит к ненужному раздутию. В контексте ваших собственных таблиц стилей любые повторно используемые элементы, которые вы прекращаете использовать или не нуждаетесь в выполнении определенной задачи, могут быть удалены в каждом конкретном случае; это сэкономит использование полосы пропускания без необходимости.
- Документ, документ, документ
-
Большинство библиотек и сред исключительно хорошо документированы. Я считаю, что лучший урок, который мы можем извлечь из этих инструментов, — это всегда документировать ваш код. Имейте в виду, вам следует избегать большего количества комментариев, чем CSS (считайте эти калории пропускной способности!), Но хорошо документированный CSS делает обслуживание и дальнейшую разработку намного менее трудоемкими, устраняя необходимость тратить время на выяснение того, почему вы кодировали решение в определенной путь.
В этой статье я пытался подчеркнуть, что CSS-фреймворки — очень непонятые существа. Они возникли из-за необходимости в решениях общего назначения, которые, как известно, работают и на которые можно легко положиться при создании нового дизайна. Я надеюсь, что смог показать вам сходство этих фреймворков с вашим собственным кодом, и как с небольшой осторожностью и вниманием вы можете превратить свой собственный CSS в код, который работает для вас: делать работу лучше, чем предварительно написанная Например, и принимая во внимание потребности ваших проектов, будучи достаточно гибким для использования в других проектах.
CSS-фреймворки — хороший пример для подражания, который, к сожалению, пострадал от плохой прессы. Я думаю, что если вы избавитесь от шума, связанного с ними, и ленивые люди, кажется, предполагают, что их использование подразумевает, вы можете отказаться от некоторых практик, которые могут помочь вам стать лучшим дизайнером. Кто знает, через год вы, возможно, создали свою собственную библиотеку полезных фрагментов, которые можно было бы передать сообществу и добавить в постоянно развивающийся список фреймворков.