3 Янв 2016Категория: Основная Автор:

Несокрушимая в CSS: написание таблиц стилей для быстро меняющихся, долгоживущих проектов

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

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

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

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

Что этот пост делает попытки, чтобы инкапсулировать мой нынешний подход к написанию CSS для прочного веб-проектов. Она будет охватывать необходимые инструменты, привилегированные структуры проекта и мой нынешний CSS для разработки методологии (что-то я полу-в шутку присвоен акроним, весело!).

Это длинный, отсюда и слово «индекс»:

Во-первых, важно оборудовать:

Технология и оснастка

Возможности и подход важны, технология не

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

Неважно, Сасс, меньше, Стилус, миф или любой другой препроцессор используется для создания таблиц стилей. Авторские таблицы стилей должны быть как легко перенести в другой Мета-язык, как это возможно, если и когда это необходимо.
Кроме того, пре-процессора, работающих должен наилучшим образом удовлетворять потребности проекта в целом – нет предпочтения какого-либо отдельного автора. Тем не менее, есть некоторые необходимые возможности для пре-процессор и поэтому мы расскажем, что (вкратце) следующее.

Предпосылки для пре-процессоров

Я считаю пре-процессора для разработки основных стилей. Это позволяет провести дифференциацию между ‘разработки’ стилей (таблицы стилей, что автор пишет в своих препроцессора выбора) и ‘равнодействующая’ стилей (скомпилированный и сжатый CSS, который получает предоставляются пользователю).

Несмотря на заявление, что пре-процессор необходим, необходимые функции, необходимые являются довольно тривиально:

  • переменные (для снижения человеческих ошибок с цветом сбор и определение констант как сетка меры)
  • фрагмента/фрагментов стилей (чтобы облегчить один-к-одной четности с объектов филиала или шаблон)
  • базовые математические операции (чтобы свести на нет зависимость от ‘магии’ числа)
  • цвет манипуляций (для обеспечения последовательного манипуляции вышеупомянутых переменных)

Все другие способности рассматриваются как не имеющие существенного значения и должны оцениваться конкретным потребностям проекта.

Система сборки

Построения системы должны быть также доступны, которые могут выполнять автоматические ‘в пансионате’ на авторских стилей. Человеческий фактор должен быть устранен по возможности и инструменты, используемые, чтобы сделать повседневные задачи с большей точностью. Типичные инструменты для сборки входят крякнул, залпом иброкколи , чтобы назвать только некоторые. Просто так как нет универсально «правильного» пре-процессор, так что нет универсально «правильного» инструмента сборки.

На момент написания, типичные примеры того, какие задачи необходимо выполнить на таблицы стилей системой сборки могут включать в себя:

  • Проверка (например, для Сасс может быть СКС-нибудь вкусненькое, чтобы включить код соответствия и предотвращения нерабочий код достигая развертывания
  • УСБ-гребень, чтобы обеспечить любой педантичный нормализации в CSS презентация не обслужены с линт средства, такие как заказ и интервал деклараций
  • Autoprefixer, чтобы позволить быстрый и точный поставщика префикса и предотвратить префиксов, присутствующих в ‘разработки’ таблицы стилей

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

Написании CSS

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

Обычно, моя первоочередная цель при написании CSS для прочного и быстро меняющихся веб-приложения длительной ремонтопригодностью. В качестве конкретного примера; будучи в состоянии удалить всю Сасс частичное (скажем, 9KB) в полгода раз безнаказанно (в том, что я знаю, что будет и никак не повлияет на удаление) гораздо ценнее для меня, чем 1КБ экономия понравилось, потому что я повторно использована или расширена какие-то смутные абстрагируйтесь стилей.

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

Это в некотором роде, поскольку быстро меняющиеся проекты, в результате итерации моделей, что может быть много мелких отличий от предыдущих версий. Конечно, любые новые проекты должны быть похожими и стандартизированы, насколько это возможно (и мы должны бороться, чтобы убедиться, что любые новые элементы дизайна отличаются, потому что они должны быть, не только потому, что кто-то хочет им быть) с существующими стилями, но иногда они должны быть тонко разные; и это должно быть легко для меня/вас приспособить, что для дизайнеров я/ты работаешь.

В резюме, я считаю, писать стили для дизайна в руку, быстрее и предпочтительнее, чем адаптация в значительной степени от расплывчатой абстракции.

Я хотел бы быть ясно, что я не говорю, что не искать часто используемые визуальные образы и абстрактные их для повторного использования. Но такие абстракции должны быть довольно низко висящие фрукты; что я термин Utility или единственной обязанности стилей (больше которых в ближайшее время).

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

Удовольствие!

Я провожу много времени именование вещей. Как вы пишете в CSS, вы тоже. Я пробовал все популярные подходы УСБ архитектура и никто из них не совсем подходит для меня. По ем свой корм для собак и обнимая пинг Кинг ли я в настоящее время именование подход очень положительно как удовольствие. Это акроним для сыпучих методологии выступает мой подход:

Весело:
– Плоская иерархия селекторов
– Утилита стилей
– Имя-разнесенные компоненты

Плоская иерархия селекторов

В первой основной ингредиент удовольствие-это соблюдение всех через одного, «плоской» иерархии, класса на основе селекторов. Преимущества только делая селекторы как нужны были хорошо документированы. Для меня три самые большие победы приходят из :

  • Использовать только для селекторов классов, за исключением особых обстоятельств
  • Никогда не гнездятся селекторов, если важно
  • Полное избегание ИД укладки

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

Вот такой сложный как F часть получает!

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

Утилита стилей

Утилита стилей являются единственной обязанности стилей. w100 бы width: 100%;, Tblбы display: table; table-layout: fixed;. Они должны были не полагаться на других селекторов или конкретных структур.

Я нашел это очень полезно текст реферата стили в некоторых случаях и можно спорить эти можно было бы назвать коммунальных стили также. Например,txt-Cart_A будет текстовое название-космический элемент, который предназначен для использования в корзину и это вариант. Я бы не указать шрифт-семьи нет, но шрифт-размер и цвет – и иногда шрифт-вес.

Служебные классы должны, как правило, идут работать, когда вы можете быть уверены затруднений. Например, я бы не хотел, чтобы добавить w100 к элементу, если бы я не был уверен, действительно ли товар необходимо 100% ширины на всем видовом экране размеры.

Ваши утилиты будут, и должны, быть отличными от моих или чьих-то еще.

Некоторые люди префикс их полезности стили как `U`, например в `U-100`. Тем не менее, имя их собственного Конвенции. Для меня, если он используется Нижний регистр и без дефисов обе стороны, это утилита стиля.

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

Имя-распорный элемент

Третьим и последним ключевым принципом трех направлениях УСБ методология имя-интервал визуальных компонентов.

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

Мои предпочтения-это просто 2-3 буквы пространства имен для каждого компонента. Здание корзину? Попробовать .sc- как ваш префикс пространства имен. Здание следующей версии этой же корзине? Это будет .sc2- потом. Это просто достаточно, чтобы изолировать компонент стили и стили позволяют повысить собственную документирования. Например, обертка для корзины может быть что-то вроде .sc-Wrapper. Есть ли кнопку Удалить объект? Что-то вроде .sc-RemoveItem бы подходящий.

Я все еще наслаждался стандарт именования документированы я здесь, но важным моментом является то, что независимо от того, какие Конвенции вы принять; просто его придерживаться и выполнять его.

Как имя-разнесенные компоненты почти гарантированно не попадала и других компонентов, это делает его невероятно легко пристроить и перебирайте их на новые компоненты как новый дизайн просьб. Это дает доселе ООН-предоставляемая одеяло безнаказанности.

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

В некотором смысле это противоположность сухого; мы набираем степень изоляции компонентов в ущерб детализации.

Не я забочусь о CSS наворотов?

Да, я делаю. Однако, в условиях быстро меняющегося и несокрушимая проект, где много разных руках имеют, и будут на УСБ, мои эмпирические выводы, что больше CSS-наворотов накапливается из-за удаления автора страха (“я не знаю, что это так просто оставить ее в”), чем дублировать стили.

Вполне вероятно, что УСБ авторы чаще просто добавить к существующим CSS в чем риск удалением огромное недоверие, потому что трудно быть полностью уверены, что будут пострадавшие.

Рассмотрим пример. Предположим, что компонент веб-приложение является устаревшим, и вы бы хотели удалить с соответствующим кодом (мы рассмотрим, как этот сценарий относится к шаблонам и любые связанные JS в минуту), не затрагивая ничего другого. Обычно это создает некоторые трудные вопросы: где находятся правила CSS, которые больше не нужны? Находятся они в одном файле? Многие файлы? Он часто прибегает к » найти в проекте’ в текстовом редакторе. Даже тогда, как вы можете быть уверены, что ничего другого в HTML/шаблоны полагается на эти стили? Ведь они являются абстракциями, предназначенных для повторного использования там, где это возможно.

Есть инструменты, которые находятся в зачаточном состоянии (на момент написания), которые пытаются решить эту проблему: UnCSS будучи одним из таких примеров. Я смотрю их с большим интересом, так как это потенциально еще одна задача, которую мы можем отложить для машины в ближайшем будущем.

Однако, если необходимые стили для каждого компонента имя-расположенными, что они могут быть легко удалены; тем более если таблицы стилей ‘partialed’ по компоненту или функции (я иногда создают частичный просто использовать параллельно создается отдельная ветка в git). Чтобы проиллюстрировать, представьте, что все мое имя-разнесенных компонент стили для корзины сохраняются в один фрагмент: _sc-shopping-cart.scss.

Для дальнейшей помощи легкого удаления старого кода и компонентов, организационный проект файлы этих компонентов проходит долгий путь, чтобы изолировать код. Как пример, если я дописать CSS для корзины v2, а я могу быть достаточно уверенным в том, что частичное(ы), относящиеся к v1 корзины могут быть удалены из проекта без каких-либо последствий. Теперь, если только шаблоны/HTML и JS в соответствующие были все в одном месте вместе с таблицами стилей. Возможно, они могли бы и должны быть.

Проектная Организация

Хранение связанных файлов

Это общий шаблон разделения файлов в проект по технологии Тип. Как правило:

my-project/
- html/
- js/
- sass/
- css/

Беда, однако, что после определенной точки, даже давая файлов, связанных с именами, трудно удержать понятие как друг стилей и шаблон связаны. Там может быть 80+ Сасс фрагментов в sass папку и 50+ шаблон заглушки в html папку.

Затем он становится все более необходимым полагаться на ‘найти’ в текстовом редакторе и найти любые шаблоны, что определенный класс используется на. То же верно и в обратном направлении; ‘найти’ необходим для поиска частичных(ы), содержащий стили, необходимые для определенного компонента шаблона. Это не делает вещей неосуществимых, просто неэффективно и требует немного умственной ориентации запомнить, что с чем надеть.

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

html/
- shopping-cart-template.html
- callouts-template.html
- products-template.html

js/
- shopping-cart-template.js
- callouts-template.js
- products-template.js

css/
- shopping-cart-template.css
- callouts-template.css
- products-template.css

Мы стремимся что-то вроде этого:

shopping-cart-template/
- shopping-cart.html
- shopping-cart.css
- shopping-cart.js

callouts-template/
- callouts.html
- callouts.js
- callouts.css

products-template/
- products.html
- products.js
- products.css

Это, казалось бы, неважных дихотомию но приносит следующие выгоды:

Код для каждого компонента становится физически замкнутые. Затем, на нашего долгосрочного проекта, когда функции нужно изменить или устарели, все связанное код для этого компонента (стили, HTML и JS) может быть легко обновлены/удалены.
За исключением по-настоящему глобальная утилита для css, все код, что связано с представлением компонента должны быть в том числе и в частичных, которые соседствуют с HTML/JS и этого компонента.

Когда организации, составляющей не представляется возможным

Это не всегда практично, чтобы содержать все связанные с этим файлы компонентов в папке. Однако, называя всех частичных согласно их компонент получает вам некоторые преимущества. Например: _partials/_components/_shopping-cartv2.scss для стилей, относящихся к нашей вымышленной v2 в корзину.

Краткие соображения по CSS поставки

В начале 2013 года IIya Григориком выдал фантастический соединиться преодолев 1000 мс время стеклянные передвижные барьер. Ключевой для нашего обсуждения вот предложение положить критических ‘выше раза’ в CSS (что бы блокировать процесс визуализации) встроенные в головной части HTML-кода.

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

Однако, попробовав его вскоре после IIya первоначального говорить, это не то, что я могу полностью перейти на борт. Главным образом потому, что в то время как начальная загрузка страницы будет быстрее (и то), последующие визиты будут страдать понапрасну.

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

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

Если вы хотите максимальной скорости первой загрузки страницы, за счет всех других соображений, изложенных подходов твои Гекльберри.

Лично я сторонник более консервативного и традиционного подхода:

Разных местах большого приложения или веб-проекта зачастую нужны разные, зачастую не связанные между собой, УСБ.
В этом случае вряд ли имеет смысл иметь один ‘стили.в CSS’ файл, содержащий все возможные стиль нужен (для аргументов ради, предположим, что Файл весит 80КБ), когда только 20% из различных областей сайта между ними требуют 60КБ этих стилей.

Любая существенно разных областях сайта должны получить свои собственные таблицы стилей. Как все (насколько это возможно/целесообразно) делится на ‘компонент’ частичных мы можем лучше облегчить эти отдельные таблицы стилей.

Допустим, у нас есть предложения ‘страницы’. Содержимое этого файла может можно составить от препроцессора с подмножество частичных:

предложения-страница.в CSS (общим весом 45 КБ):

@include "core";
@include "_components/forms";
@include "_components/login";
@include "_components/callouts";

Тогда как на домашней странице может потребоваться только это:

Домашняя страница (общий вес 20КБ):

@include "core";
@include "_components/nav";
@include "_components/home-offer";

Примечание: Вы также можете использовать Подстановку файлов для импорта наборов связанных стили/компоненты если у вас есть дополнительные степени зернистости в ваши куски. Например:

@include "_components/login/**"; 

А это значит больше файлов для браузера кэшировать (там не только один ‘стили.в CSS’, которая обслуживает все возможные адресаты пользователь заходит) каждый пункт назначения имеет меньший след в CSS и поэтому быстрее время начальной загрузки (не туда встраивание критических помощью CSS, но некоторые пути к ней). Есть преимущества в каждом подходе; я не верю ни «правильно» – это просто образованный выбор вы должны сделать.

Это в значительной степени исчерпан мой нынешний подход.

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

Вот неполный список того, что я считаю распространенных ошибок при написании несокрушимая УСБ.

Общие CSS-разработки подводных камней (я уже в них всех)

Не пренебрегайте разработки собственных именах

Если бы я мог порекомендовать только одну вещь из всего этого-улучшить ремонтопригодность и понятности кода CSS, применяя правила именования бы его. Нет «правильного» именования. Есть только соглашение об именах, которое является правильным для вас. Нынешний де-факто стандарт-это классический БЭМ синтаксис. Это задокументировано так сильно, что я не буду повторять его здесь.

Я хотел бы просто добавить, что не стоит принять, что синтаксис оптовая прежде чем подталкивал палкой цинизма. Это матч, как вы работаете? Не кажется ли вам сразу ясно?
Я задокументировали мои собственные вариации на синтаксис, что и везде. Вот краткая версия:

[пространство имен]-[ComponentPart]_[вариант]-[необязательно-регулятора]

Так, «реальный» селектор » может выглядеть следующим образом:

sc-Wrapper

Или этот:

sc-InnerItem_Odd

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

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

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

Ужас совершенной абстракции собой.к. собой. имя с умыслом

Вы, вероятно, умнее, чем я так вам не делать этого. Но я это сделал.

Давным-давно я создала себе маленький проект под названием » Пст!’. Это был акроним для позиции структуры темы. Идея была я бы от семантического класса имен. Вместо любого элемента может быть разработан с сочетанием положении, класс, структура, класс и дополнительный класс тема. Элемент стиле с ‘Пст!’ может выглядеть следующим образом в HTML:

<div class="p1 s3 t4">Content</div>

Прелесть! Это был плотный, времени не было потрачено впустую, придумывая подходящее имя для следующего селектора (просто добавляется ряд как Вы ходили), он дал немногословный разметки, но, и вот ключевой момент:

Оно было неразборчиво.

Можете ли вы представить себе целую страницу из разметки только с теми видами HTML-классы? Не было никакого способа различить одну часть дома от другой.

Тогда еще один минус – отзывчивостью. Как определить, что s3 должны делать на то, что размер области просмотра, а внутри другой структуры. Короче: мерзкий, ужасный эксперимент.

Который приносит мне к явной точке. Имя с умыслом. Я фанат таких классов, как.WarnUser и .sc-CurrencyDropDown бьющее по назначению прямо на нос (и, следовательно, могут быть визуально разными в разных контекстах). Я пока еще не пробовал ничего, что убедило меня это не путь.

Не указывать префиксы поставщиков создание и настройка таблиц стилей

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

Избегайте библиотеки миксинов

Существует множество пре-процессор библиотек, которые предоставляют готовый сортовой прокат ‘примеси’ для выполнения стандартных CSS задач (clearfixes, фон, градиенты и т. д.). Не используйте их. Автор, по возможности, совместимые с W3C CSS кода. Это делает создание и настройка стилей более портативный если вы решили перейти препроцессора или Скопировать код в новый проект и снижает зависимость (в качестве бонуса, особенно если использовать sass, он может также значительно уменьшить время компиляции).

Не помещайте образцы разметки в CSS комментарии

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

Избежать ‘умный’ код абстракций

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

Миксины и логических петель иногда предпочтительнее и выгоднее (они могут значительно сократить многословие и повторения в авторской таблицы стилей) но не стоит излишне усложнять простые потребности. Даже Уго Giraudel, дерзость псих рисует линию где-то.

Например, создание ряда коммунальных Ширина таблицы стилей могут быть достигнуты такой в sass и характеризует предел того, что я считаю разумным в плане сложности:

/* ==========================================================================
   Table modifiers
   ========================================================================== */
$widths: 5 10 20 30 40 50 60 70 80 90 100;
%Tbl-base {
    display: table;
    float: left;
    vertical-align: middle;
}
@each $width in $widths {
    .tbl#{$width} {
        @extend %Tbl-base;
        width: $width * 1%;
    }
}

Как контр пример, миксина для создания кнопки, которая требует трех или более аргументов, передаваемых всего установить стили границ, Цвет фона и размер текста, вероятно, никому не нужны осложнения.

Опасайтесь @продлить

Этот финал один очень Сасс ориентированных. Не продлить что-либо кроме замещающий селектор (например %Placeholder) и не оставляйте какие-либо вложенные стили в место держателя. Он редко создает CSS, который вы представляете.

Не пренебрегайте глядя на ваше производство CSS файлы

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

Я провел

Это все, что я получил для вас. Как всегда, хотел бы услышать ваши собственные мысли и мнения.

Источник: benfrain.com
Переведено Яндекс переводчиком


Смотрите так-же:

    Обратите внимание

    Pearson - Success 1 Textbook 1B
    store.cross-roads.ru
    Pearson - New Opportunities Upper-Intermediate Test Book, 2007 год
    store.cross-roads.ru
    YoudaЛесные феи
    games.parnas.info

    Оставьте комментарий

    Необходимо войти что бы оставить комментарий.

  • Рекомендую

    Business Key Top Sites
  • Реклама