CSS DIY Организация

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

Введение: зачем?

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

«Насколько легко нам, разработчикам, быстро найти, понять, исправить или дополнить данную кодовую базу? Чем проще эта задача, тем лучше внутреннее удобство использования».

Есть пара понятий, которые я хочу охватить сейчас в целом, чтобы заставить мозговые соки работать. Во-первых, внимание уделяется удобству использования веб-разработки. Мы хотим, чтобы пользователи наших веб-сайтов быстрее находили вещи, перемещались более естественно и в целом понимали концепции наших приложений. Это очень достойное использование времени и энергии. Что иногда забывают, так это внутреннее удобство использования при планировании и обсуждении наших проектов. Насколько легко нам, разработчикам, быстро найти, понять, исправить или дополнить данную кодовую базу? Чем проще эта задача, тем лучше внутреннее удобство использования. На мой взгляд, эта концепция столь же достойна нашего времени и мысли, как и удобство использования интерфейса.

Во-вторых, помните, что в CSS есть C. Это каскадная часть. Метод, который я использую, может столкнуться с некоторыми обычными мыслями, но когда вы заглядываете в угол, используя только определенные аспекты CSS, вы теряете силу. Когда я планирую большой проект, я считаю селекторы идентификаторов «объяснять сущность», селекторы классов — «описывать сущность», а атрибуты стиля — «отменять то, что я только что сказал». Я каскадирую свойства, чтобы уменьшить код, и даю небольшой метод безумству. Опять же, нет правильных или неправильных путей, но когда у вас нет плана, вы настраиваете себя на большую дополнительную работу, не говоря уже о дополнительных накладных расходах.

Наконец, помните, что всегда есть компромиссы в разработке. Самые элегантные способы ведения дел не всегда самые эффективные.

Иногда наиболее эффективные способы выполнения операций обходятся вам дорого, когда вам приходится подбирать код для поддержки.

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

Пара вариантов: рамки или дикий запад

Скорее всего, вы используете либо фреймворк для обработки вашего CSS, либо добавляете свои стили таким образом, к которому вы привыкли, но без особой структуры. У обоих есть свои плюсы и минусы. Давайте сначала посмотрим на несколько фреймворков CSS:

Синяя печать

YUI 2

базисный

YAML

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

Дикий Запад

Другое решение — это то, что я называю «Дикий Запад», где что-то идет. Я буду честен и скажу, что много раз я просто что-то выталкивал за дверь, не задумываясь о будущем, или в случае очень маленького проекта, где CSS не очень существенен. Кривая обучения здесь не так уж плоха, потому что вы пишете свой CSS по ходу дела. У вас есть полный контроль над судьбой вашего стиля. Довольно круто до сих пор! Проблема заключается в внутреннем удобстве использования. Вернитесь к этому проекту после того, как он перестанет быть свежим в вашем уме, и возникнут некоторые проблемы. «Почему, черт возьми, я написал это так» или «Понятия не имею, что я имел в виду под этим комментарием», или «Почему этот ввод не меняет стили» или «Каков этот большой кусок контроля чума»? таблица стилей больше не свежа в вашем уме.

Мой выбор : гибридное решение

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

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

Соглашение об именовании файлов

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

Вот что работает для меня:

• reset.css : css для сброса — это тот, который устанавливает все или по крайней мере большинство стилей браузера для обнуления. Я использую css для сброса, чтобы бороться с некоторыми различиями в браузерах, и я вижу значение при работе с кросс-браузерными проблемами. Это не Нирвана, и есть некоторые, которые предпочитают не сбрасывать, или, как я недавно прочитал, мягкий сброс . Я предпочитаю сбрасывать все, и я использую аромат Эрика Мейера для сброса.

• forms.css : я отделяю свои стили форм от остальной части моего CSS. Я хочу знать, когда я работаю с формами, и они не совсем появляются, так как я хочу, куда именно идти.

• global.css : мой глобальный css-файл — это то, что я использую для каждого большого проекта, который я пишу. В этом маленьком файле содержатся небольшие классы, которые я мог бы использовать снова и снова в проектах. Мое эмпирическое правило: если есть ярлык для свойства, то оно, вероятно, не принадлежит глобальному файлу. Я бы не использовал свойство шрифта. Например:

Обратите внимание, что это очень специфические классы, которые добавляют к каскадным правилам стилей. Хотя ни один из них, как правило, не будет использоваться в качестве единственного стиля для элемента, они добавляются в описание элемента, к которому применяется их класс.

• style.css : мой style.css — мой главный контроллер моего стиля. Если вы думаете с точки зрения OO для CSS, мой style.css — это мой класс, в то время как другие файлы расширяют мой класс (во всяком случае, в некоторой степени) и увеличивают наследование моих основных объектов. Я использую свой style.css для импорта других моих файлов и для определения моих локальных, только проекта, селекторов идентификаторов и классов.

Идентификаторы и селекторы классов : мысли немного иначе

Мой гибридный метод здесь отличается от большинства людей, так как мое общее правило с идентификаторами — просто объяснить рассматриваемый элемент. Селекторы ID используются только один раз на страницу (включая процессы GET), поэтому я хочу, чтобы они были очень специфичными по своей природе. Чтобы по-настоящему максимизировать повторное использование кода, любое свойство вне этого объяснения элемента, я действительно предпочел бы использовать селектор класса. Поскольку этот идентификатор уникален для страницы, я хочу использовать только уникальные объяснения для этого селектора.

Например, моя ширина будет несколько уникальной. Мои отступы и поля будут несколько уникальными. Моя позиция была бы несколько уникальной. Можно утверждать, что отображение для этого селектора будет несколько уникальным. Мой цвет для элемента; не совсем уникальный. Мой фон, опять же не совсем уникальный. Что касается не совсем уникальных элементов, я думаю о них как об «описании элемента», для которого я использую селекторы классов.

Давайте проиллюстрируем это небольшим кодом. Для простоты я использую недавнее руководство Джеффри Вей под названием « Быстрый совет: практические формы CSS» . Что если мы взяли оригинальный CSS:

и трансформируется в это:

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

Если вы на мгновение думаете, что можете использовать эти описания где-то еще, возможно, для подзаголовка, то у нас есть некоторое повторное использование кода. Давайте посмотрим, что мы можем сделать сейчас. Вот как это выглядит изначально:

и вот как это выглядит с подзаголовком:

Я только добавил новое определение сейчас:

Наряду с небольшим количеством HTML:

У нас есть повторное использование кода, и у нас есть метод, который является последовательным. Если вы возьмете этот метод и примените его, вы уменьшите количество стилей (или объектов, если вы предпочитаете), которые вы пишете. Меньшее количество кода с помощью метода означает более легкую поддержку на более позднем этапе. На самом деле, ничего страшного в этом нет, но когда вы начинаете объяснять свои селекторы идентификаторов, но описываете свои классы, это простой способ добавить немного здравомыслия в ваш код.

Атрибуты стиля

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

Когда вы должны использовать атрибут style, это когда вам нужно сделать быстрый финальный вызов, чтобы переопределить что-то в каскадном отображении для элемента, который не имеет смысла добавлять в ваш файл global.css. Например, вам может потребоваться переопределить стиль из уровня поведения на основе действий пользователя. Это немного увеличивает сложность, но добавляет каскада. Я не буду использовать несколько свойств, так как это быстрое переопределение, или, скорее, «забудь то, что я только что сказал тебе, сделай это вместо этого». Это каскад, и вы должны относиться к своему CSS как таковому, по моему мнению.

Отступы, расположение и комментарии

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

Если мы сделаем отступ в нашей разметке, почему бы не сделать такой же отступ в нашем CSS:

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

При выборе макета вашего файла стиля, это правило, которое я использую. Вы должны @import ваших дополнительных CSS-файлов, сначала начиная с файла reset.css, а затем остальные. Определите ваши следующие элементы, такие как h1, якоря и т. Д. Затем определите ваши селекторы идентификаторов в вашем style.css. Если вы работаете с несколькими страницами, прокомментируйте начало каждой новой страницы в пределах отступа. Например, #container, вероятно, является элементом макета, который является контейнером для каждой страницы, поэтому начните с отступа и постарайтесь прокомментировать, где вы используете каждый элемент. Наконец, определите ваши классы. Обычно я не делаю отступы в своих классах из-за того, что они часто используются повторно, а отступы не показывают, где они используются.

Наконец, и, возможно, самое главное, прокомментируйте свой CSS так же, как и свой код на стороне сервера. Если есть какой-либо контекст, который вы можете дать классу, например, элементы, которые он использует, или ID, которому он соответствует, прокомментируйте его. Любой контекст, который вы даете своему будущему я, подобен машине времени. Марти МакФлай, возможно, не сбил бы этого жуткого парня с пути встречного движения, если бы он сначала прочитал комментарии к конденсатору потока.

Вывод

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

Спасибо за чтение, и, пожалуйста, поделитесь своими идеями.