Соглашение об именах classов CSS

На веб-странице есть два блока управления (первичный и вторичный), какие имена classов будут использовать большинство людей?

Выбор 1:

Выбор 2:

 

Прямой ответ на вопрос находится прямо под этим , Курт.

Если вас интересуют соглашения об именах classов CSS, я предлагаю рассмотреть одно очень полезное соглашение с именем BEM ( Block, Element, Modifier ).

ОБНОВИТЬ

Подробнее об этом читайте здесь – http://getbem.com/naming/ – это более новая версия, которая делает следующий ответ устаревшим.


Основные принципы:

  • Страница построена из независимых блоков. Блок – это элемент HTML, имя classа которого имеет префикс «b-», такой как «b-страница» или «b-login-block» или «b-controls».

  • Все селекторы CSS основаны на блоках. Не должно быть никаких селекторов, которые не начинаются с «b-».

Хорошо:

 .b-controls .super-control { ... } 

Плохо:

 .super-control { ... } 
  • Если вам нужен другой блок (на другой странице, возможно), похожий на блоки, который у вас уже есть, вы должны добавить модификатор в свой блок вместо создания нового.

Пример:

 

С модификатором:

 

Затем вы можете указать любые изменения в CSS:

 .b-controls { font: 14px Tahoma; } .b-controls .super-control { width: 100px; } /* Modified block */ .b-controls.mega { font: 20px Supermegafont; } .b-controls.mega .super-control { width: 300px; } 

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

Я бы пошел с:

 

Пока ваш CSS структурирован правильно, primary и secondary не должны сталкиваться ни с чем другим в вашем приложении:

 .controls.primary {} 

Заметьте, что я также поставил controls впереди primary / secondary кода, поскольку это ваш основной class.

Я думаю, что первый набор ниже намного читаем, чем второй:

 .controls.primary {} .controls.secondary {} .primary.controls {} .secondary.controls {} 

Существует большая альтернатива NCSS .

Именованные каскадные таблицы стилей – это соглашение об именах и руководство для семантического CSS.

Зачем:

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

objective:

Предсказуемая грамматика для CSS, которая предоставляет семантическую информацию о шаблоне HTML.

  • Какие tags, компоненты и разделы затронуты
  • Каково отношение одного classа к другому

Классы:

Именованные каскадные таблицы стилей делятся на:

  • Пространства имен
  • Структурные classы
  • Классы компонентов
  • Типы classов
  • Классы модификаторов
  • Функциональные classы
  • Исключения

Дальнейшее чтение: https://ncss.io/documentation/classes

Примеры:

    

Headline

Box
в

Headline

Box

Дальнейшее чтение: https://ncss.io/documentation/examples

Инструменты:

Монтаж:

 npm install ncss-linter 

Проверка строки HTML:

 bin/ncss-linter --html='
'

Проверка локального пути:

 bin/ncss-linter --path=templates/**/*.html --namespace=foo 

Проверка удаленного URL:

 bin/ncss-linter --url=https://redaxmedia.com --namespace=rs --log-level=info 

Дальнейшее чтение: https://ncss.io/documentation/tools

Twitter использует SUIT CSS:

https://github.com/suitcss/suit/blob/master/doc/README.md

Тот же автор также написал Idiomatic CSS:

https://github.com/necolas/idiomatic-css

  • Соглашения об именах баз данных, таблицах и столбцах?
  • Существуют ли лучшие методы для организации пакетов (Java)?
  • Сингулярные или множественные имена controllerов и помощников в Rails
  • Соглашение об именах - подчеркивание в переменных C ++ и C #
  • Именование интерфейса в Java
  • Давайте будем гением компьютера.