Главная Cube CSS

Методология Cube CSS и другие основы

Динамическая позиция элемента

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

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

Что необходимо принять для начала работы:

  • Методология БЭМ может являться признаком множества споров. Вам следует продумать четко-выверенную и структурированную аргументированную доказательную базу в пользу её использования.
  • Методология mobile-first (по мнению владельца бизнеса) является неверным методом разработки проектов студии. Просто смиритесь и пишите код от большего к меньшему (desktop-first), даже если проект имеет дизайн-структуру mobile-first.
  • Использование единиц измерения REM - является фатальной ошибкой и плохо тестируется (по мнению компании). Здесь вам нечего предложить, кроме как использовать значения в px.
  • Использование вычислений (калькуляции) в CSS - является ошибкой (по мнению компании), которую необходимо избегать. Здесь вы должны иметь понимание того, для чего вообще и в какой момент нужно использовать калькуляцию. Если в данном блоке или элементе это можно обойти стороной - обходите.
  • Использование GRID-контейнеров в CSS - является ошибкой и плохо тестируется (по мнению владельца бизнеса), которую необходимо избегать. В данном случае, это связано с тем, что нет понимания, как работают GRID-CSS. Просто старайтесь использовать как можно меньше "гридов" в вашей верстке.
  • Использование большого количества вложенности в HTML - является фатальной ошибкой: старайтесь избегать, а в некоторых случаях включать смекалку и использовать минимальное количество вложенности в HTML. Это важно, если проект имеет SEO-подготовку для дальнейшего продвижения. Ключевыми элементами может оказаться навигация и текстовые ссылки (например в шапке).
  • Использование CSS-переменных типа var(--color) возможно, но только для служебных стилей. Например, использовать для белого цвета (#ffffff) переменную нельзя, потому что это является фатальной ошибкой (по мнению владельца бизнеса).
  • Написание такого класса для шапки сайта, как: <header class="header"> </header> - лучше так не делать, но все же возможно.
  • Узкая система брейкпоинтов: 360 ⬅ 720 ⬅ 1000 ⬅ 1500. На самом деле, можно сделать так: 0 ⬅ 576 ⬅ 720 ⬅ 992 ⬅ 1024 ⬅ 1200 ⬅ 1360 ⬅ 1440 ⬅ 1500 (не для всех случаев), чаще будете использовать: 0 ⬅ 720 ⬅ 992 ⬅ 1200 ⬅ 1500
  • Нет возможности создавать отдельные повторяющиейся элементы, например бургер-меню, не должно быть отдельным элементом. Если навигация есть в шапке, то при схлопывании на брейкпоинте она же становится схлопнутым бургер-меню. Это важно помнить при проектировании шаблона сайта на зачатках разработки.
  • Во FLEXBOX-контейнерах обращение к дочерним элементам лучше писать так: .flex > * {};
  • Придется дорабатывать или иногда додумывать дизайн-структуру в макете Figma, собирать свой иконочный шрифт, icon-pack для работы (советую использовать сервис Glyther)
  • Необходимо категорически избегать inline-стилей для элементов. Исключением могут быть повторяющиейся элементы в стеке, либо стили из вашего JS-кода.
  • Глобально определить стили для основных семантических элементов, таких как: h1-6, a, b, p, ul, ol и др.
  • Ваш JS-код должен быть сосредоточен в одном файле app.js и содержать всю логику работы функций на сайте. Только в крайнем случае, если у вас есть логика (например, для работы с личным кабинетом пользователя) и она достаточно объемная - допускается поместить её в отдельный файл. В противном случае - все критически важные и функции, которые выполнимы на всех страницах сайта должны оставаться в одном файле.

Обозначим вашу структуру статического сайта с СЕО-продвижением

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

Примерно так будет выглядеть структура вашего проекта:

  • /assets
    • /images
      • image.webp
      • bg.webp
      • gradient.webp
      • video.webp
    • /icons
      • sprite.svg
      • icon_1.svg
      • icon_2.svg
      • icon_3.svg
    • /fonts
      • font.eot
      • font.woff
      • font.woff2
      • font.ttf
  • /dist
    • /css
      • app.css
  • /src
    • /scss
      • _variables.scss
      • app.scss
    • /js
      • app.js
  • index.html

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