Как верстать веб-интерфейсы быстро, качественно и интересно

image


Всем привет! Давно хотел и наконец написал небольшую книжку — бодрое пособие по своей профессиональной области: актуальным подходам к разметке интерфейсов, экранному дизайну и доступности. Она о моем оригинальном подходе к созданию GUI, препроцессорам CSS (для объективности, немного и об альтернативных подходах), и его эффективном практическом использовании с javascript и популярными реактивными компонентными фреймворками Vue и React. Материал представлен аккуратно последовательно, но безумно интенсивно и динамично — ничего лишнего или даже слишком подробного — для того чтобы увлеченный и подготовленный читатель не потерял интереса и «проглотил на одном дыхании». С другой стороны, текст, достаточно сложный ближе к концу, и на всем протяжении — густо насыщенный идеями, ссылками на технологии и подходы — поэтому, очевидно, будет «на вырост» начинающим. Но, в любом случае, как и если вы только начали интересоваться данной тематикой, так и если уже давно занимаетесь веб-дизайном, версткой и программированием фронтенда — вам может быть полезно на него взглянуть.


Мотивация


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


Начну с некоторого огульно обобщающего и, поэтому, несколько провокационного наблюдения, «вброса»: большинство, не только начинающих, но даже опытных программистов испытывают своеобразное предубеждение-стереотип о некой «несерьезности» верстки интерфейса как отрасли деятельности в веб-индустрии — «верстка это не программирование!». Очень многие считают что заниматься разметкой «некруто и скучно» для «серьезного» специалиста. И как следствие — уделяют предмету мало своего внимания и времени, имеют мало реального релевантного опыта. Проще говоря, большинство разработчиков не любит и не умеет верстать. И уже и как причина и как следствие — зачастую сами подходы, технологии и архитектура используемые для организации GUI даже на серьезных коммерческих проектах — отставляют желать лучшего, не отвечают реалиям современной веб-индустрии, устарели и недостаточно эффективны. Неудачные, якобы временные, слабые решения и дальнейшие бесконечные быстрые «фиксы», кривые «кряки» наслаиваются друг-на-друга, кодовая база неоправданно распухает и становится все менее связной и контролируемой. Шаблоны, или ныне — в эру компонентных фреймворков — компоненты, стили и логика для них часто и закономерно превращаются в невнятную и крайне излишнюю по сути «свалку», «густой лес», «джунгли» с очевидно неподъемной ценой рефакторинга и масштабирования. Очевидно, что такое состояние системы может легко приводить к серьезным затруднениям, снижению темпов или даже срыву сроков и, ирония как раз в том, что в реальной коммерческой ситуации, авторам подобной громоздкой и неуклюжей системы, все равно придется потратить еще больше времени на то, чтобы, по крайней мере, исправить все оплошности и несовершенства разметки, оформления и логики для них, но делать это придется в изначально плохо организованном коде, по замкнутому кругу — только увеличивая беспорядок и вероятность сбоев. С того момента как вы перестаете быть «джуном», ваша ответственность состоит не только в том чтобы закрыть все «баги» на трекере и навернуть как можно скорее «фичи», любой ценой. Надежная и легко поддерживаемая система — продукт который вы продаете бизнесу.


Реальный жизненный кейс: будучи начинающим специалистом я работал удаленно в одном приятном стартапе. Когда проект запустили, после презентации многие присутствовавшие на ней высказались о том, что кегль основного текста и полей ввода в интерфейсе — мелковат. Получив задачу в трекере, я потратил всего пару минут, поправив одну переменную своей системы — чтобы поднять кегль на всех нужных полях и контролах, и еще 15 минут чтобы удостовериться что ничего действительно не сломалось ни на одном шаблоне. Ваша система изначально должна быть написана так, и только так, чтобы ее было можно легко скорректировать и улучшить, поддерживать и расширять. По-настоящему лаконичный и выразительный качественный код — невероятно мощно экономит время и нервы даже если вы работаете с проектом в одиночку. Кроме того, уважаемые авторитеты в коммерческом программировании утверждают [см. Роберт Мартин — «Чистая архитектура»] что «то что сделано изначально плохо» — в реальности, не только «никогда не будет переписано», но и приводит к постоянному крутому росту стоимости дальнейшей доставки нового функционала, а в перспективе способно полностью блокировать прогресс по проекту!


Хорошее понимание возможностей и ограничений современных браузерных технологий очень желательно и полезно не только для веб-разработчиков, но и для гуманитариев-дизайнеров проектирующих GUI. Часто даже востребованный специалист, выдающий приятный стиль и не делающих серьезных ошибок по UХ, не может внятно ответить на простейшие технические вопросы о своем дизайне при сдаче макета на верстку, то есть — «не понимает что рисует».


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


Кому будет полезен текст?


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


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


Дизайнерам. Вы веб-дизайнер, но хотите начать верстать.


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


Препроцессор


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


Препроцессор, JavaScript и фреймворки


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


Левон Гамбарян.
Июнь 2020 года.



Препроцессор




Простейший пример плохого кода


Безобразного кода с каждым днем становится все больше, несмотря на то, что больнее всего страдают от этого сами авторы, горе-разработчики. И если определенную функциональность или рендер можно покрыть тестами, то ошибки оформления выявляются только «ручками».


Также, просто парадоксально, что все программисты слышали о простых основополагающих принципах качественного программирования KISS и SOLID, но подавляющее большинство напрочь забывает о них, когда речь заходит об организации оформления, представления веб-интерфейса.


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


Давайте посмотрим на самый простейший пример плохого кода на CSS:


/* Примитивнейший пример обычного плохого кода на CSS */

/* Где-нибудь в файлах стилей: */

.selector--1 {
  width: 200px;
  height: 200px;
  border: 1px solid #ADADAD;
  border-radius: 3px;
  /* ... и дальше еще огромное количество самых разных правил */
}

.selector--2 {
  width: 200px;
  height: 400px;
  border: 1px solid #ADADAD;
  border-radius: 3px;
  /* ... и дальше еще огромное количество самых разных правил */
}

Не делайте так больше почти никогда! ))) Почему? Код валидный, «в браузере все по макету», да и все именно так обычно и пишут. Но все и не «верстают как бог», правильно? В контексте любого проекта чуть большего чем совсем крохотный, подобный код «плохой и чреват проблемами в будущем». Он конкретен и невыразителен, излишен, его сложно модифицировать и переиспользовать.


А как надо?


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


Справедливости ради, нужно упомянуть, что последние годы, в связи с стремительным ростом популярности компонентных js-фреймворков и их подходов, все больше сторонников набирают также различные «CSS-in-JS»-реализации (например: Styled Components). Скоро, вероятно, можно будет спокойно использовать переменные в самом CSS (CSS Custom Properties). Тема холиварная, существуют контексты и ситуации когда подобный CSS-in-JS подход может оказаться более оправданным и изящным, без сомнения. И даже существует масса реалистичных кейсов когда проще всего будет действительно обойтись несколькими наборами правил на CSS, а любое его расширение будет излишним. Но в общем случае, в реальной коммерческой практике, имхо, для верстки сложных дизайнов и интерфейсов удобнее и эффективнее всего сейчас использовать любой препроцессор, и, шок — даже с компонентным фреймворком, дальше я планирую показать «как именно это лучше всего делать». Препроцессоры дают максимум возможностей и позволяют стремиться к максимальной выразительности и переиспользуемости. Вот во что превратился бы «плохой код» выше в SCSS-синтаксисе, наверное — самого популярного на сегодняшний день препроцессора — Sass:


// В @/src/scss/utils/_variables.scss:

$colors__border: #adadad;

$border-radius: 3px;

// В @/src/scss/utils/_placeholders.scss:
%border-block {
  border: 1px solid $colors__border;
  border-radius: $border-radius;
}

// В @/src/scss/utils/_mixins.scss:
@mixin size($width, $height) {
  width: $width;
  height: $height;
}

// В любом месте проекта:
.selector {
  $selector--1__size: 200px;
  $selector--2__width: 200px;
  $selector--2__height: 400px;

  &--1,
  &--2 {
    @extend %border-block;
    /* ... включение других сущностей препроцессора
      и специфическиих правил общих для селекторов */
  }

  &--1 {
    @include size($selector--1__size, $selector--1__size);
    /* ... включение других сущностей препроцессора
      и специфических правил уникальных для селектора */
  }

  &--2 {
    @include size($selector--2__width, $selector--2__height);
    /* ... включение других сущностей препроцессора
      и специфических правил уникальных для селектора */
  }
}

Точно тоже самое легко сделать и на, кажется, недооцененном, но очень удачном Stylus — совершенно не важно какой именно расширенный синтаксис вы используете, главное как и зачем. Очень много раз мне приходилось видеть плохой чужой код написанный якобы для препроцессора, видимо, «потому что так сейчас модно», но, на самом деле, практически ничем не отличающийся от кода CSS. Не делайте так! Препроцессор дает нам крайне ценную возможность абстрагировать общие качества гайдлайна, стиль и основанные на нем частные стили, организовать их намного более выразительно и лаконично, легко модифицировать и переиспользовать при необходимости.


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


Первый пример демонстрирует что на начальных этапах развития проекта хорошо продуманного кода препроцессора может быть даже визуально несколько больше, чем неорганизованного, внутренне плоского, скучного CSS. Но давайте разберем очень часто встречающийся кейс, в котором мы очевидно сразу сильно экономим много трафика и явно оптимизируем возможную поддержку. Такое очень часто встречается: нам нужно создать большое количество, предположим — 20 штук — модификаторов одного селектора — квадратной иконки размеров в 100 пикселей — и поставить в них нужные картинки в бекграунд. В Sass мы можем написать цикл с интерполяцией для создания селектора модификатора и указания пути до ресурса. И хотя такая синтаксическая возможность не является чем-то идейно решающе важным — на практике она экономит кучу времени и повышает качество жизни на работе:


// В @/src/scss/utils/_variables.scss:

// Paths
$images__path--root: "../../assets/images/";

// Sizes 
$icons__size: 100px;

// Views
$icons: 20;

// В любом месте проекта (в папке В @/src/scss/project/):
.icon {
  // корректируем путь до картинок
  $image-path: $image_path--root + "icons/";

  @include size($icons__size, $icons__size); // эта примесь уже создана выше

  @for $i from 1 through $icons {
    &.icon--#{$i} {
      background: url("#{$image-path}icon--#{$i}.svg") center center no-repeat;
    }
  }
}

Пример предполагает что в вашем проекте следующая структура:


.
└─ src
   ├─ assets
   │  └─ images
   │     └─ icons 
   │        ├─ icon--1.svg
   │        ├─ icon--2.svg
   │        └─ ...
   └─ sscs
      ├─ project
      │  └─ ...
      └─ utils
         ├─ _mixins.scss
         └─ _variables.scss

Теперь в шаблонах мы можем использовать:


<div class="icon icon--1"></div>

Если вы желаете чтобы картинки были с осмысленными именами — можете перебирать список:


.icon {
  $image-path: $image_path--root + "icons/";
  $images: "name1", "name2", "name3"; // Список имен

  @include size($icons__size, $icons__size);

  @each $image in $images {
    &.icon--#{$image} {
      background: url("#{$image-path}#{$image}.svg") center center no-repeat;
    }
  }
}

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


.selector {
  $width: 100px;

  width: calc(100vw - #{$width});
}

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


Абстрагируй все!


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


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


// В @/src/stylus/utils/variables.styl:

$colors = {
  mint: #44c6a8,
  // ... другие конкретные значения цветов
}

// Создаем "основной цвет", абстрагируясь от конкретного цвета
$colors['primary'] = $colors.mint
// ... другие "функциональные" цвета

Любое имеющее глобальное значение и потенциально переиспользуемое качество гайдлайна и дизайна должно быть отражено в файле переменных препроцессора. Теперь в любом месте где потребуется предоставить основной «брендовый» цвет:


.selector
  color $colors.primary

Очевидно, что если весь остальной код будет аккуратно использовать правильную переменную — просто «по щелчку пальцев» возможно изменить этот основной цвет по всему интерфейсу! Все это логично и закономерно приводить нас к идее некой общей «стилевой базы», медиатора единого стиля оформления интерфейса. Такую глобальную абстракцию легко способен предоставить препроцессор, и ее, вероятно, будет удобно использовать даже для оформления «изолированных» компонентов.


Структура и стилевая база препроцессора


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


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


Но давайте уже организуем препроцессор, если с SCSS:


.
└─ src
   └─ sscs
      ├─ core // обшие и компилируемые сущности препроцессора
      │  ├─ _animations.scss // keyframes
      │  ├─ _base.scss // минимальная нормализация основных HTML-элементов
      │  ├─ _grid.scss // сетки
      │  ├─ _typography.scss // типографика
      │  └─ _utilities.scss // быстрые удобные классы-утилиты для включения прямо в разметку
      ├─ libraries // папка с файлами стилизаций сторонних модулей
      │  └─ _modal.scss - например какая-нибудь готовая модаль
      ├─ project // стили конкретного проекта
      │  ├─ _elements.scss // отдельные простые элементы-компоненты
      │  ├─ _fixes.scss // этот файл всегда должен быть практически пустой, и предназначен только для редких общеизвестных "собственных проблем браузеров"
      │  ├─ _layout.scss - стили общей для всех страниц GUI-обертки над контентом интерфейса
      │  └─ _widgets.scss - сложные составные комбинации простых элементов-компонентов
      ├─ utils // обшие и некомпилируемые основные сущности препроцессора
      │  ├─ _functions.scss // на практике нужны крайне редко
      │  ├─ _mixins.scss // параметризируемые и способные принимать контент примеси-микстуры
      │  ├─ _placeholders.scss // повторяющиеся наборы правил - растворы
      │  └─ _variables.scss // самый важный файл с переменными )
      ├─ _main.scss // точка сборки всех стилей препроцессора
      └─ _stylebase.scss // стилевая база

То есть, на самом деле — порядок сборки всей кухни имеет значение, конечно же:


// В @/src/scss/_stylebase.scss:
// Stylebase
//////////////////////////////////////////////////////
//////////////////////////////////////////////////////

// Uncompiled kitchen
@import "./utils/_functions";
@import "./utils/_variables";
@import "./utils/_mixins";
@import "./utils/_placeholders";

// Core base normal style and common utils
@import "./core/_animations";
@import "./core/_typography";
@import "./core/_base";
@import "./core/_grid";
@import "./core/_utilities";

// В @/src/scss/_main.scss:
// Project styles
//////////////////////////////////////////////////////
//////////////////////////////////////////////////////

// Stylebase for components
@import "_stylebase";

// App styles
@import "./project/_fixes";
@import "./project/_elements";
@import "./project/_widgets";
@import "./project/_layout";

/* External libraries customization */
@import "./libraries/_modal";

Итак, «стилевой базой» мы будем называть некое основное ядро стилей, доступный всем остальным компонентам системы общий код препроцессора. Более детально, он состоит из условно двух разных видов файлов:


  1. Растворяемые при компиляции инструменты-помощники, сущности позволяющие генерировать лаконичный, оптимальный, связный код:


    1. функции
    2. переменные
    3. параметризуемые примеси
    4. включения-плейсхолдеры

  2. Компилируемые глобальные стили:


    1. анимации keyframes
    2. типографика
    3. базовая нормализация основных HTML-элементов
    4. сетки
    5. утилитарные классы-помощники для разметки


В папки @/src/scss/project и @/src/scss/libraries вы можете добавлять файлы по необходимости.


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


У меня вот, например, можно посмотреть — есть различные такие заготовки-«болванки» для быстрого старта на разных комбинациях актуальных технологий:



Читать книжку дальше можно пройдя по ссылке: Как верстать веб-интерфейсы быстро, качественно и интересно.

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 60

    +6

    Из написанного я понял, что ответа на вопрос так и не найдено.

      –1
      В любом случае, спасибо за то что читали и даже за критический камментарий. ) А вы считаете можно отыскать какой-то единственно правильный однозначный ответ на этот практически риторический вопрос, универсальное решение пригодное на все времена и случаи жизни? Произведение вроде не ставит такой унылой и порочной цели… Оно обобщает достаточно уже продолжительный опыт, представляет несколько достаточно спорных идей, но рассматривает и альтернативные и подходы — старается возбудить интерес, прежде всего и в конце концов, к тому что происходит по теме в отрасли… Не думаю, что в принципе возможно написать по что-нибудь по данной теме, что уже очень скоро не окажется неактуальным. И да — я сам собираюсь «еще искать дальше», не останавливаться на достигнутом, пробовать что-то новое и так далее… Разве не в этом смысл и кайф?
        0

        А почему вы считаете, что это невозможно?
        Вы пробовали действительно другие подходы? Например, такие, где верстальщик вообще не пишет селекторы руками? Или такие, где typescript проверяет все значения, свойства, селекторы?

          0

          А вы прочитали мой текст по ссылке в конце статьи здесь на Хабре хотя бы почти до конца первой из двух частей? Там есть ссылки на примеры моих проектов, например, с TypeScript и/или Styled Components, вроде?..


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


          А найти "окончательное решение", подробный точный рецепт — на все времена и все случаи жизни я правда считаю что совершенно невозможно, да и не нужно — фронтенд это невероятно быстро развивающаяся среда, проекты, задачи, системы бывают самые разные — об этом всем упомянуто в моем тексте, и об этом, я считаю, точно бессмысленно дискутировать. Кроме того, мы все разные, у нас разные склонности-привычки, характеры, жизненный опыт, обстоятельства, и так далее — и это замечательно… Если вы считаете иначе — напишите об этом тоже — я с удовольствием ознакомлюсь с вашим мнением.

            +2

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


            Ну то есть вы убеждены, что такого решения быть не может, поэтому его быть не может? Ок, у меня больше нет вопросов. С убеждениями дискутировать бессмысленно.


            styled-components, если что, ничего из мною перечисленного не проверяет. К чему это вы о нём?

              –2

              Я не огрызаюсь совсем, подробно вам ответил, хотя, правда, некогда совсем. И, видимо — зря. И я не стану сообщать вам о том, как выглядят советы незнакомым людям в интернете о том, как им нужно или не нужно себя вести, навешивание неприятных эпитетов на основе вашей субъективной рефлексии статьи и пары комментариев… Уверен — бесполезно и только раззадорит...) Общение, имхо — должно строиться на уважении к собеседнику, взаимном интересе и прочих приятных плюшках… А если всего этого нет — стоит стараться избегать.


              Если вы считаете что, например, "на лыжах летом по асфальту бегать эффективно, и достаточно быстро, удобно", ну или вам "просто это нравится" — пожалуйста — бегайте-резвитесь, развлекайтесь. Можете даже попробовать проповедовать это, только не стоит навязывать — я вот предпочту хотя бы велосипед, смотря, опять же, какие цели и обстоятельства, необходимость… Риторика построенная на банальном передергивании и примитивных манипуляциях — тоже вас не красит в качестве достойного собеседника. Да — одна одежда нужна для зимы, другая для лета. Хотите щеголять в скафандре круглый год — может он у вас с терморегуляцией даже, но вряд ли в нем будет удобно, например — плавать или загорать.) Если у вас есть "универсальное решение" — покажите его, а не передергивайте на пустом месте.


              Styled Components были упомянуты в общем контексте в ответ на заданный вами изначально вопрос: "Вы пробовали действительно другие подходы?" — тут вы тоже передергиваете откровенно и троллите, кажется. В контексте предложенного в моей работе основного подхода с "глобальным препроцессором для компонентности" — CSS-in-JS — как раз выглядит альтернативой. И с ней я тоже ответственно экспериментировал. Повторюсь, в моем тексте об этом есть, но вы, видимо, его не прочитали толком, но комментируете.

                0

                То есть вы попробовали пару вариантов и уже делаете выводы о том, что возможно, а что нет. Понятно.


                Вам не говорили, что вы слишком много произносите слов и слишком мало вкладываете в них смысла?

                  –4

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

                    0

                    Ничего я не прячу: https://youtu.be/FMNLN5YIE_M?t=5556

                      0

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

                        0

                        Значит вам не составит труда назвать такой случай, где не годится?

                          0

                          Конечно не составит. В коммерческом аутсорсе, например, верстальщикам приходится иногда верстать лэндинги с "шикарным" адаптивным и сложным дизайном, но практически без какой-либо функциональности, и при этом — очень-очень быстро — прямо нереально быстро. И при этом критично сделать так чтобы "через пару дней" все было идеально "внешне" и было именно в срок. Или часто встречаются игры-презентации, где некоторый нетривиальный кастомный функционал-поведение присутствует, но шаблоны все равно будут отдаваться с сервера, верстка нужна для интеграции на бэкенде. Не только TypeScript "будет мешать" — просто фреймворк и компонентность на таких проектах это совершенно неадекватно и вы просто прогорите и не впишетесь в дедлайн если будете усложнять и не будете более гибким. Это очевидные вещи для любого человека который хоть немного действительно "нюхал порох" в настоящей индустрии, побывал в пекле… И это далеко от многих "красивых теорий" и идеализма. Я то как раз пытаюсь дать внятный концепт как в таких жарких ситуациях делать хорошо и красиво, но не усложнять и не наворачивать лишнего.


                          Ну или более сомнительный пример, но такое тоже случается в реальной практике сплошь и рядом: гибкий "долгостой", возможно, с сомнительным будущим и не очень внятным настоящим, на котором нет дизайнера или они меняются, макет только для десктопа и только на одну страницу), от менеджмента часто приходят прототипы на новые фичи и шаблоны "на коленке"… В этом случае нам также нужна больше нужна максимальные гибкость и скорость, но "в гайде", а вот строгая типизация того, что практике практически точно — очень скоро отправиться "в корзину" — мне непонятно зачем?


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

                            0
                            1. Для сильно кастомных лендингов вполне себе годится. В них тоже много повторяющихся вещей, нужна адаптивность и тд.
                            2. typescript не мешает а помогает. Не надо проецировать свой опыт работы с Реактом на нормальные фреймворки.
                            3. Если у вас нет дизайнера, значит вам не нужен и кастомный дизайн. А со стоковым дизайном вы на нормальном фреймворке можете сделать production ready приложение за пару часов. Опять же это не про Реакты и прочий Boilerplate Driven Development.
                              0

                              Во-первых чисто рамочный вопрос — если ваша такая замечательная метода "вообще для всего годиться" — почему ее тогда практически никто кроме вас не использует? Все дураки, вы один знаете как надо? Происки рептилоидов?


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


                              2. Я вроде знаю где именно "typescript не мешает а помогает." — энтерпрайз, спокойные продукты-долгострои — и вот поэтому там именно его большинство и использует, и то не всегда. А на аутсорсе, и особенно супербыстрой верстке крафтовых лендингов — меня просто заклюют коллеги/работодатели если что-то то такое начну предлагать и внедрять, вместо того чтобы быстро нормально сесть и написать на HTML/препроцессоре/JS — без фреймворка. В чем выгода от ts и фреймворка? Проблема же не только во мне — пока что почему то практически никто не мотивирован перенимать ваши подходы? Мотивируйте нас? Пока — ничего и почти никому, видимо, не понятно.


                              3. Я сам себе дизайнер и много раз "делал все сразу в браузере, без макетов" если мой заказчик/работодатель соглашался на такой подход. Тут, чаще всего, речь не о "крафтовом custom дизайне", а о быстрых casual-прототипах — в случае сервиса-долгостроя или были, например, сайты-каталоги — в частной практике… Стоковый дизайн никогда не использовал, так же как и "готовые библиотеки для GUI", кроме Бутсрапа еще 3его когда-то — ковырял такое ответственно, встречались на проектах, но ничего кроме ужаса такой "подход к дизайну" не вызывает — в книге об этом есть в конце первой части. И речь не только о том как это выглядит, а о очень многих печальных аспектах таких подходов.



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

                                0
                                1. У людей нет времени изучать что-то новое ибо сроки горят, а бойлерплейта написать надо ещё много.


                                2. Ну, приведите пример такого лендинга, где мало чего повторяется.


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


                                4. https://nin-jin.github.io/slides/mol/


                                  0
                                  1. Ну вот сейчас мы наконец-таки в этом топике — ударимся в политэкономию...)) Да, именно так — капитализм и одна из его основных "плеток" — экономическое рабство, принуждает бесправное и обреченное на прозябание абсолютное большинство к постоянному рутинному и однообразному труду в интересах капиталов. И, чаще всего — качество условий этого труда, его стандарты — низкие, так как капитал стремиться оптимизировать издержки и выжимать как можно больше из имеющихся ресурсов в максимально сжатые сроки — "конкуренция свободного рынка" же (а точнее — только ее видимость, на самом то деле)… Айтишники сейчас находятся к достаточно привилегированном положении, так как мы можем рассчитывать на лучшие условия и компенсацию чем большинство, а при наличии опыта и/или специфических скилов — на действительно творческие интересные задачи и тд… И на самом деле любой специалист каждый день с этим сталкивается — что надо "баги фиксить / таски наворачивать" — "как можно быстрее" — рутина-текучка, а хотелось бы спокойно и основательно пробовать-изучать что-то передовое-интересное, творить прекрасное и прочие радости. Но на самом деле — это тоже вид лени — мы — часть общества и взаимодействие с ним "до результата который всех устраивает" — формирует настоящий профессиональный фундамент. Хорошая глубокая теория — это важно, но без реальной практики — она ничто — в коммерческом дизайне и программировании. А практики почти никогда не бывает "только на условиях исполнителя". Вы, похоже — чисто теоретик, такой проповедник-прогрессист — забавно, конечно...


                                  2. Вот тут "не буду играть по вашим правилам" — вы мне "зубы не заговаривайте". Мне уже абсолютно очевидно что вы, видимо, не работали в боевом адовом аутсорсе и вообще не понимаете толком о чем речь. Любой "крафтовый кастомный лендинг" — это куча кастомной и не повторяющейся инфорграфики, деталей, необычных блоков и повторяется только "общий подходы к адаптивности" — "внутри" и, разве что "типографика — снаружи". На стоковых дизайнах, шаблонных и даже касуальных лендосах какие-то паттерны могут повторяться, да. Но не на "шикарных-крафтовых". Не говоря уже о играх-презентациях — там так каждый раз "полный полет фантазии дизайнеров", интересные пространства, сложное поведение и прочее — именно потому такие проекты действительно интересно делать. Чего-то не знать, не уметь, это не стыдно — всего сейчас не успеть — не попеределать, ни даже "изучить по верхам" — как быстро вы бы ни систематизировали — новое будет возникать еще быстрее в пост-истории. Но вы видимо с этим не хотите мириться и не согласны ))) — вы радикально замахиваетесь на фундаментальность, в том, в чем, кажется — фундаментальность в любом случае окажется жалкой бренной и выхолощенной пародией. Хотя это правда очень оригинально и фриково, крайне зачетно в современной убогой однотипной штампованной реальности из "выучившихся на быстрых курсах сразу на сеньера" и ничего кроме как "собирать-разбирать кубик-рубика (у вас — "бойлерплейт")" и "побеждать в хакатонах с такими же как они" на самом деле, в результате не умеющих, миллениалов — без единственной собственной мысли в голове, зато с понтами и самомнением до небес… А вам — уважуха, я такое очень ценю. Вы мне напоминаете математиков преподавателей из ЛМШ из детства, только еще радикальнее и фриковее — это сейчас изумительная редкость.


                                  3. Я фреймворками сравнительно недавно занимаюсь — и, прежде всего, из чисто по практической, вполне мейнстримной необходимости и мотивации. В команде, работодатели от меня ждут, прежде всего Реакт и Вью — это востребованно и продается — другой вопрос "почему", это да. Я вот всю жизнь — с 14ти лет (уже 38) занимаюсь авангардным андеграундным творчеством — играю психоделический экспериментальный краутрок с очень старыми друзьями юности раз в неделю на репточке. То что мы делаем сейчас — достаточно продвинуто и сложно в каком-то музыкальном смысле — спонтанная импровизация, сложные размеры и полиритмия, полигармония-хроматизм, дрон — нетональная музыка, одновременная запись и сведение неизолированного живого звука — много всего, не важно… Сейчас — когда большинство слушает практически только один рэп, ну и еще попсу из двух-трех стандартных нот и аккордов с примитивным биточком — такое наше странное творчество вообще никому почти не нужно не интересно, не понятно (кроме нескольких фриков-меломанов), и я трачу средства на свое хобби, а не зарабатываю. Но мне это нравиться и простым образом нужно самому, дает энергетическую подпитку, психологический выход и так далее… Сравнение технологии и искусства, конечно, не совсем корректно, но когда речь заходит об идеях, теориях, философии — вполне, кажется, допустимо — как "сфер передового человеческого опыта". К чему я так пространно веду: субкультура, андеграунд, фундаментальные и радикальные фрики которые их создают, особенно во времена тотального капиталистического варварства и торжества-засилья массовой псевдокультуры миллениалов — это очень важно, очень! Да — очень важно что вы такой такой есть у нас в индустрии — "всегда против"! )) Еще раз — уважуха! Я совершенно искренне и серьезно, без всяких подколов и иронии!


                                  4. Взглянул, позже ознакомлюсь подробнее — спасибо!.. Сейчас как раз самое время для "чего-то такого", так как я окончательно стал чувствовать себя "монстром" в Вуе и Реакте и заскучал, соответственно. Свитл, насколько я понимаю ничего принципиального нового в мою жизнь и практику не привнесет. Посмотрим...



                                  Мемчик нарисовал чуть больше года назад — он о миллениале от которого тогда — как теперь понинаю — впервые слышал о вас — зацените:


                                  image

              –2
              я вполне внутренне готов к тому, что меня здесь многие будут топить в фекалиях — да пожалуйста — если кому-то делать нечего… К сожалению, у меня вот прямо сейчас, честное слово, нет времени на холивары и прочее бессмысленное самоутверждение

              Самоутверждение совсем не бессмысленное, лёгкое или быстрое занятие. Потому как если ни вы самоутвердитесь, то это сделает за вас кто-то другой, затопив вашу полянку своими фекалиями и парадигмами безо всякого к вам уважения. Мы живем в эпоху UFC в широком смысле. Рейтинг это бабло. А с ним приходит и уважение и советы, что делать чтобы достичь того же самого. Весь интернет построен на советах. СССР сгинул, а система советов жива и процветает.


              Ну то есть вы убеждены, что такого решения быть не может, поэтому его быть не может? Ок, у меня больше нет вопросов. С убеждениями дискутировать бессмысленно.

              Всегда думал, что дискуссия это инструмент для расшатывания и смены убеждений.

        0
        Мне всегда, когда я начинаю проект, хочется писать красивый код. Но когда пробую написать красивый CSS, это оказывается просто невозможно. Да, в каких-то частных случаях, описанный подход будет работать. Но вот попадает в руки реальный макет…
        Каждый элемент со своими параметрами, что они в переменных, что не в переменных, все равно они жестко привязаны друг к другу и будут встречаться один раз. А следовать макету нужно, Pixel Perfect и все такое.
        Хочется задать зависимости явно, но сделать это как правило невозможно. Если изначально доступны параметры размера – хорошо, а если нет? Если это текстовый блок произвольной длины? А если все параметры меняются за счет адаптивности?
        Выделить несколько ключевых цветов – хорошо, но их будет в макете явно не один и не два, а потом возникнет ситуация, когда часть компонентов надо будет сделать еще другим цветом и все равно придется править все вручную. Так какая разница в таком случае, править вручную названия переменных или конкретных цвета?
        Часто понимаешь, что повторяешь одни и те же действия, но как от этого уйти? Нету никакой возможности создать переиспользуемые инкапсулированные компоненты. Всегда найдется вариант внешней разметки, при которой внутренняя разметка компонента сломается. Мы не знаем, чего захочет клиент такой библиотеки, какой модификации. При использовании любой готовой библиотеки довольно быстро возникает ситуация, когда возможностей не хватает и приходится писать все самостоятельно.
        Что касается CSS-in-JS, то с таким подходом, как правило, получаются сайты, плохо работающие в относительно старых браузерах, чего только стоит JS-скролл. Кроме того, JS-код не владеет объектами на странице, а является лишь довеском к документу, со слабой сетью может и не загрузиться. Никогда не хочется пользоваться сайтом, на котором подача статической информации зависит от JS.
        Вообще, хотелось бы видеть примеры хорошей абстрактной разметки на рабочих проектах, сделанных по макету. Потому что когда сталкиваешься со всеми этими проблемами, просто руки опускаются что-то делать красиво.
          0

          Спасибо за интерес к моему тексту и такой пространный комментарий. К сожалению, у меня вот прямо сейчас нет времени на то, чтобы ответить также подробно. Скажу только многие описанные мною подходы на практике хорошо годятся и для того и другого — проверено. Как и для быстрого проектирования и, например, поиска стилевых и интерфейсных решений, вариаций на гибких прототипах, так и для pixel to pixel реализации точных сложных графических макетов. У меня было уже очень много и того и другого разнообразного опыта и это всегда хорошо работало, вполне. Конечно, не бывает универсальной системы пригодной в одном и том же неизменном виде абсолютно во всех случаях. Чтобы добиться успеха, всегда нужно думать, менять, искать, улучшать… Простите, но хочется дать вам простой совет: попробуйте для любой задачи которая кажется вам подходящей просто взять любой мой стартовый шаблон — в тексте есть ссылки, разобраться с ним и двигаться в этом направлении. Я уверен что верстка и интерфейс это глубоко практическая дисциплина, полезно, конечно, читать книжки-статьи, обсуждать подходы, но чтобы начать чувствовать себя действительно уверено — нужно именно делать. Много и по-разному.

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

          Был ли у вас опыт переживания многочисленных редизайнов одного проекта на протяжении нескольких лет?
          Я к тому, насколько рекомендации в статье подходят к случаям, когда на проекте примерно раз в 8 месяцев разгоняется отдел маркетинга и нанимается новый? Когда меняются дизайнеры.
          Просто по опыту, в этом случае, все эти чрезмерные sass-абстракции превращаются в тыкву)
            0

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


            Еще, кажется, что некоторые программисты "дорвавшиеся до полной компонентности", и решившие "что проблем с версткой больше никогда у них не будет" — просто нифига не поняли, и "прячутся" в это, вместо того чтобы наконец разобраться для чего нужен один полезный инструмент и для чего — другой. Как пример, вот прямо сегодня угорел: там где раньше был один простой и точно также, именно — "переиспользуемый" — класс-утилита для разметки — минимальная рамочная абстракция дизайн-макета — "контейнер для контента" — некоторые теперь пишут "целый компонент" (какое отношение "рамочка" ограничивающая контент на экране имеет к функциональности системы?), кладут его — реально!!! — в @/src/containers — "это же контейнер!!!"))), и до кучи еще спускают ему стили через модные CSS Modules (это в совсем крошечном проекте из нескольких простеньких страниц с несколькими элементами) — (((((… Там где раньше был один класс CSS и один HTML-элемент с ним — теперь целая тусовка модных технологий и концепций.))) Новые технологии и концепции — нужно применять по делу и к месту, а не потому-что "так модно", или "Левон в книжке написал", тут я не спорю, как раз "о том и пишу", во многом… Главное — понимать что и зачем делаешь и, еще неплохо — "быть готовым ко всему"...)

            0
            А что с редактированием у такого подхода?
            То есть, пример из жизни: надо переделать размер шрифта. На проекте, который был написан в схожем с вами стиле я правил 4 места, потому что селектор такой, селектор другой и селектор третий. Потом я плюнул, откатил изменения, добавил пятый селектор и завел тикет на технический долг. У проектов в БЭМ подобной архитектурой мне обычно нужно изменить одно конкретное место, которое отвечает за один конкретный элемент. Как в вашем случае это делается?
              0

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


              Реальный жизненный кейс: будучи начинающим специалистом я работал удаленно в одном приятном стартапе. Когда проект запустили, после презентации многие присутствовавшие на ней высказались о том, что кегль основного текста и полей ввода в интерфейсе — мелковат. Получив задачу в трекере, я потратил всего пару минут, поправив одну переменную своей системы — чтобы поднять кегль на всех нужных полях и контролах, и еще 15 минут чтобы удостовериться что ничего действительно не сломалось ни на одном шаблоне...

              Перечитайте еще раз раздел про типографику — там как раз все для того, и о том, чтобы "поравить в одном месте и ничего не сломалось". Кроме того, хочется понять, что это у вас за типографика такая — везде разная чтоле? (((( Типографика — это глобально раздаваемое свойство "гайдлайна" и "стилевой базы", а не частное — "каждого конкретного элемента, вьюхи"… Именно поэтому "нам все это и нужно глобально" — чтобы у вас, упрощая, "все параграфы были с одинаковым шрифтом"...


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

                0
                Вот точно так же была одна переменная на все места с текстом. После правки всплыла другая переменная на хедеры. Потом появилась еще одна переменная на интервал…

                Просто в конце концов такие системы начинают перерастать во что-то подобное бутстрапу, при всем моем уважении к нему. И нужно вникать в каждый класс, наследование и вот это вот все. В то время как плоские системы минимизируют мои трудозатраты как программиста до минимума.
                Все просто: одно место — один компонент. И это круто просто потому что тут сложно что-то сломать. Я могу менять разметку так, как хочу без оглядки на другие компоненты. И любой джун пришедший на проект и залезший в разметку сломает только один компонент в худшем случае, а не весь проект. А когда вся завязано на глобальные правила необходимо проверять все места, где эти глобальные правила используются. И это нужно делать при каждом коммите.
                  0

                  Ну понеслась. ))


                  Во-первых, если у вас нет глобальной типографики — вам вот в таком случае как описан в моей мотивирующей истории придется поправить значение вообще ВО ВСЕХ местах? Ничего не забыть и все протестировать. А если у вас стопитцот компонентов? А если у вас несколько проектов на одной библиотеке (было в реальной практике)?


                  При моем подходе — как раз нет никакой "другой переменной в другом месте" и быть не может, нет никакого другого способа раздавать типографику — кроме единой стандартной примеси для вообще всех мест и компонентов, или даже — всех проектов использующий одну библу. Оно везде просто, единообразно и полностью контролируемо. И толковому джуну объяснить как при таком подходе, отдать куда-то стандартную типографику по гайдлайну — нужно не больше 5 минут — тем более, что везде в коде оно уже видно что только так, да и пользоваться удобно — копипастой ))) — там объяснять нечего и ошибиться он в дальнейшем нигде и никак не сможет — ни с фонтом, ни с кеглем, ни с высотой строки, ни с межбуквенным разбежкой… А столько вы времени потратите чтобы объяснить джуну про все свои стопятсот компонентов в нескольких проектах с разными решениями и тд? Ну серьезно, по честноку — "типографика должна быть везде одинаковая, но надежнее если в каждом месте это будет отдельно", так чтоле?


                  У меня нет цели вам что-то доказать и я работал с достаточным количеством программистов-манагеров которые не понимали и принимали моих методов (хоть и использовали меня для своих целей когда это было выгодно ))) ), не любили, не умели и боялись верстать или "вцеплялисьь в компонентность, CSS-in-JS" как в панацею "от всех проблем со стилями"… Я пишу в тексте что существуют ситуации, проекты на которых это будет даже удобнее и надежнее, проще… Но кроме таких случаев — существует намного больше задач на которых вы просто утоните с подобными "изолированными" подходами. Тут спорить не о чем.

                    +1
                    Оно везде просто, единообразно и полностью контролируемо.

                    Сколько я видел таких систем на проектах покрупнее — это anything but. Пока с этим работает один человек — да, всё хорошо. Когда работают несколько — стили со временем «расползаются», так как никаких хороших средств контроля за соблюдением всех рамок системы — нет. Кроме полностью ручного код ревью, разумеется. Которое рано или поздно будет пропускать задвоения, лишние переменные, и вообще всякий «мох», по мере роста системы. И со временем это всё точно так же становится грудой легаси, в которой мало кто мало что понимает. А с типичными энтерпрайзными плясками в виде смены команд на продукте и вообще перебросе специалистов туда-сюда — это еще и довольно быстро происходит.

                    Ваша статья выглядит попыткой выдать желаемое за действительное. Я работал с такими подходами и с их последователями — и на мой собственный опыт ни разу ничего особо хорошего от них не получал. Структурированная свалка css — в конечном счете даже еще хуже, чем неструктурированная (от этой сразу никто ничего не ждет).

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

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

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


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


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


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

                        0
                        Может, дело не в подходах, на самом деле?) Нафиг соглашения, тоесть, они все равно не работают? Про линтеры тоже не понял, с препроцессором линтер не работает у вас?

                        Соглашения работают, до определенной степени. Но не все отклонения от соглашений можно отследить. Со временем они накапливаются. В некоторых случаях, типа замены команды или замены тех специалистов, которые и следили за чистотой стилей — это происходит не просто «со временем», а крайне быстро.
                        Про линтеры вы не поняли, да. Линтеры css следят за стилями (ни за чем другим они следить, собственно, не могут), в то время как следить тут нужно за структурой. Через один только линтер это конечно не работает, но линтер (по коду, не по css) позволяет автоматически обнаружить много «уловок», явно или неявно могущих ухудшить структуру приложения. В отношении css ничего подобного нет. Я уж не говорю про строгую типизацию а-ля TS, которая еще больше проблем позволяет отловить еще до запуска приложения. И про тесты. Всего этого для css нет — даже попытки тестировать css через какие-нибудь там скриншоты — невероятно бесполезны.

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

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

                        И на самом деле — с CSS-in-JS, например, все тоже самое же — вашему джуну нужно также знать в каком компоненте лежит контейнер для контента чтобы он не написал новый, это мало что меняет...

                        Контейнер для контента (да и любой другой компонент) — это сущность, сохраняемая на всех этапах жизни приложения, от исходного кода до рантайма. Она гораздо более постоянная и видимая.
                        Структура css, сделанная через препроцессор — штука, которая в рантайме вообще не существует.
                          –1

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

                            0
                            Нет, я мыслю как человек, который приходил в проекты на самых разных этапах жизненного цикла — и с чистого листа начинал писать, и приходил уже на всё написанное и отлаженное (чтоб пост-релизные доделки минимумом усилий провести), и всё между этим.
                            И лично видел, во что превращались благие намеренья «нам нужно просто следить за чистотой и правильной структурой css, и всё будет хорошо». Инструменты поддержки чистоты проекта — работают. Хотя бы потому, что их не сократят, не перекинут на другой проект, и вообще они (в рамках своих задач) не ошибаются. Люди, следящие за чистотой проекта — работают вот только до тех пор, пока их не сократили, не перекинули на другой проект, или просто они сами не забили за этим следить.

                            На короткострое — когда проекты не предполагают особо длительного ЖЦ, а то и вообще делаются как товар (продали-забыли) — подход с людьми скорее всего отработает нормально. На долгострое — SaaS, долгоиграющих продуктах, всём том, что требует пост-релизного сопровождения и тому подобном — подход с людьми не работает практически никогда. Работает только инструментальный контроль, когда всё по максимуму обмазано линтерами, типами, тестами, и вообще «само» начинает кричать при попытке что-то поломать.
                              –1

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


                              Цель моей писанины, на самом деле, в этом контексте понятная — дать простое уверенное понимание гибких подходов к препроцессору и препроцессору с популярными фреймворками? Там во вступлении даже уже это все изложено — для кого и зачем?


                              1) Много-много лет назад, когда я был начинающим веб-дизайнером и только освоил HTML и CSS, начал верстать, брат программист с которым мы делали иногда сайты для друзей и так далее — скинул мне ссылку на простой туториал по LESS — и это, как я сейчас уже окончательно понимаю — просто перевернуло мою жизнь, это захватило меня с головой, стало главным увлечением и, очень скоро — хорошим источником дохода. Как человек крайне упрямый и с детства увлекающийся и техническими и гуманитарными вещами — склонный к творчеству, но не приемлющий мейнстрим — я действовал, мыслил и экспериментировал самостоятельно, никаких "курсов" и "академий" не кончал — и у меня за плечами уже много самых разных проектов. Вероятно, многим начинающим нужен вот такой просто самый минимальный идейный "толчек", интенсивный, системный и структуированный подход, чтобы снять оцепенение которое, вероятно, вызывает разнообразие и сложность современных подходов и технологий — для того что просто "начать писать, творить". И это — самая главная цель текста.


                              2) Также удобно — начиная проект с уже устоявшимся специалистом — иметь возможно просто сразу показать гайд и предложить его принять как соглашение, предложить "попробовать" вот так. На некоторых проектах это может быть крайне эффективно против любых других подходов. Если человек пишет бесконечную колбасу несвязных стилей или "пишет компоненты-"контейнеры" с CSS Modules" там где достаточно класса с элементом, но при этом, на самом деле — хороший программист — это может хорошо сработать и быть полезно всем. Хорошие программисты, как показала практика — очень быстро оценивают пользу от описанных подходов в определенных адекватных ситуациях.


                              3) Я встречал, например, опытных дизайнеров которым "все надоело". Профессиональное выгорание — это очень серьезная тяжелая проблема, если вы с этим уже сталкивались. Естественным направлением развития для таки специалистов будет верстка. Уверен, что для дизайнеров — начать верстать с помощью моего пособия будет эффективнее всего, так как я сам так двигался.


                              Как-то так.

              0
              Просмотрел.
              С одной стороны — однозначный плюс за попытку серьезного и системного подхода.
              С другой — довольно много спорных моментов, а местами даже явных антипаттернов.

              P.S. В слове «breackpoint» нет буквы «c» :)
                0

                Спасибо! Очень адекватный и лаконичный каммент! ) Ну я не спорю и не скрываю даже что спорно, но иногда "оно работает", если совсем кратко. Да и с одними известными бесспорными паттернами и "бестпрактиками" будет совсем уныло и скучно, нет? Ну и вообще — "что с дизайнера взять?"..))) breackpoint исправил, да...

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

                  .block.--fade-on
                  Я понимаю, заманчиво так писать модификаторы, но начинать имя класса с двух дефисов нельзя. Это не работает в IE и просто визуально путается с CSS-переменными.

                  @supports not (display: grid)
                  Эта конструкция неверная. Нужно идти от обратного, потому что браузерная поддержка директивы supports даже хуже, чем у самой проверяемой фичи.

                    –2

                    Ну вы, кажется, тут несколько придираетесь и вырываете из контекста. В случае модификатора — если мы не поддерживаем осла и не используем CSS-переменные тоже нельзя?.. Но ок — уберу дефисы, или лучше подпишу про осла и переменные чтобы было не придраться)). А вот про суппорт — ок, только, справедливости ради, оно там вообще до кучи и понтов и на суть темы и остального примера не влияет — там дергадация целевая через модификаторы, но поправлю завтра, да. Еще оплошности есть?

                      +1
                      В случае модификатора — если мы не поддерживаем осла и не используем CSS-переменные тоже нельзя?
                      Вы же излагаете некую систему соглашений. Соглашения — по определению — для коммуникаций с другими людьми. Так вот для других людей нецелевое использование двух дефисов контринтуитивно. Или вы собираетесь за каждым ходить и лично объяснять, мол, вот это хоть и похоже на переменную, но на самом деле не переменная, имей в ввиду — так?
                        –4

                        Ну где переменные и где классы, но ок, спать хочу, а завтра пахать… Спасибо за интерес к моей работе и критику.

                0

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


                С другой стороны, если уже на уровне дизайна есть порядок, структура, то css естественным образом будет следовать этой структуре, и ничего изобретать не надо. Причем уже даже не так важно, будет ли это компонентный подход с css modules, какой-нибудь css-in-js или просто глобальные стили.


                Что я подразумеваю по структурой в дизайне. Вот есть набор базовых примитивов (типографика, цвета), вот простейшие компоненты, построенные на их основе (кнопки там, поля ввода), вот более сложные композиты типа карточек, менюшек.
                В итоге я смотрю на картинку дизайна и могу соотнести каждый элемент картинки с элементом дизайн-системы.
                Да, это все равно 100% юз-кейзов проекта не покроет — всегда есть какие-то разовые решения для уникальной фичи, которая больше в проекте не повторится. Но если хотя бы на 3/4 дизайн будет построен из таких кирпичиков — то помойки css уже не будет.

                  0
                  Мне кажется, что органиция css сильно вторична по отношению к организации исходного дизайна.

                  Да нет, вам не кажется, так и есть. Организация css как-то иначе, чем организация дизайна — это всегда море головной боли. Если дизайнер представляет свой дизайн как коллекцию абсолютных отступов от левого верхнего угла макета, а контора требует pixel-perfect — поддержание css в приемлемом виде очень быстро превращается в личную головную боль программиста, и не все выдерживают необходимость сидеть и пересчитывать размеры за дизайнером, а не влепить везде «position: absolute» и сказать «вы сами этого хотели».
                    0

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

                  +1
                  Интересно читать комментарии от человека, у которого ну вот совсем нет времени отвечать…
                  Заранее извиняюсь за офф-топ.
                    –1

                    )))) Ну вот такой характер, что поделать — все равно "руки чешутся", ну и если "есть что ответить" — нужно отвечать… Но — правда некогда, надеюсь, вы не мой проджект-менеджер. )))

                    0
                    Ну, не знаю.
                    Задача: сменить цвет у элемента #el1
                    «Old style» — object inspector — #el1 — styles.css line 112234 — сменил — commit
                    «Modern style» — найти файл с элементом — найти имя цвета — найти где этот цвет определяется — найти переменную со значением этого цвета — проверить где еще используется переменная и цвет — изменить — commit — ой, где-то еще изменилось — завел новую переменную…
                      0

                      Вы не правы. Можно сколько угодно защищать свои вредные привычки, лень и невежество такими некорректными и якобы красноречивыми-убедительными примерами, но, на самом деле, все это перепевы одной и той же очень старой песни: "Зачем мне препроцессор, если есть поиск в текстовом редакторе?". И со становлением компонентности и CSS-in-JS для нее в качестве мейнстрима данный избитый шлягер становиться снова популярным, топовым. Но, по сути, это риторика уровня: "Зачем мне автомобиль, если уже есть велосипед — он и для здоровья, геморроя, извините,) полезнее?", или "Зачем мне мобильный телефон, я все равно из дома очень редко выхожу?" — ну, то есть, некоторый солипсизм в восприятии, если утрировать. Крайне субъективно. Действительно — если кажется что не сильно нужно, не возникает мощного запроса, нет задач которые это требуют — не надо и использовать, конечно! Это важный принцип — используйте только те инструменты которые вам подходят и необходимы. Я и сам редкий консерватор-ретроград, в каком-то смысле, например, завел смартфон, кажется, только лет 5 назад, когда уже вовсю делал суперадаптивные дизайны для браузера с помощью инспектора — до этого юзал кнопочный.


                      Конкретно по вашему примеру: вы ошибаетесь. В хороших дизайнах для веба, особенно — интерфейсных, ну просто не может быть "очень много" разных цветов. Вы правда уже много верстали? Хороший гайдлайн обычно содержит — "основной-брендовый", "дополнительный", от силы еще парочку вспомогательных и "набор серых" — все. Ну и по функциональным ролям: цвет текста, светлый текст, цвет бордера, может — плейсхолдеры в контролах… Всякое бывает, встречаются исключения, но в основном это так. И меня как раз обычно дико бесит когда я нахожу в макетах "чуть-чуть другие значения" — особенно с серыми это часто бывает… Нужно мыслить правильно, прежде всего — цветов в хорошем интерфейсе должно быть очень немного и они должны быть точно "одни и те же". Если вы абстрагируете их — вы сможете легко их менять (например — переиспользуя компоненты на новом проекте).

                        0
                        Мы же сейчас не о макетах и дизайне говорим, а о верстке, верно?
                        Да, для верстальщика «не может быть чуть-чуть других цветов», но у дизайнера, поверьте, есть причины использовать небольшие отклонения от точного цвета (на темном и светлом фоне, разной толщины, разного объема один и тот же цвет воспринимается по-разному и там, где у Вас в верстке все будет точно, визуально будет отличаться). А уж маркетологу вообще невозможно объяснить почему здесь не может быть красным — «по A/B тестам красным +100% прибыли» — делай.
                        А по сути обсуждения, хотелось бы узнать опыт старших товарищей уменьшения длины пути в описанном мною примере. Т.е. у нас десятки файлов .scss, один в другой и т.д. инклюдятся, где-то там переменные инициализируются — как быстро «сменить цвет элементу», т.е. зная конечный результат, дойти до точки изменения значения? А если еще эти файлы разбиты по компонентам, разделам и пр. «радостям программного подхода»?

                        Спасибо.
                          0

                          Ну я дизайном достаточно долго занимался, с этой стороны и пришел во фронтенд. Для таких "небольших отклонений" в препроцессорах как есть очень удобные встроенные "функции для работы со цветом" — https://sass-scss.ru/documentation/sassscript/tsvetovie_operatsii/, https://stylus-lang.com/docs/bifs.html — и это кажется более грамотным, точным в плане теории цвета и практичным чем "тыкать наугад по наитию", я так вижу, что такие дизайнеры, конечно, очень любят...


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

                            +1
                            в препроцессорах как есть очень удобные встроенные «функции для работы со цветом» [...] и это кажется более грамотным, точным в плане теории цвета и практичным чем «тыкать наугад по наитию»
                            Это только кажется.
                              0

                              Именно потому что нам всем очень многое и по-разному "кажется" [особенно на неоткаллиброванных мониторах] — лучше использовать точные инструменты. Но по сути разве это не тоже самое что и "открыть в графическом редакторе паллитру и натыкать", просто так вы это делаете прямо в коде и на экране просмотрщика, вы же сами говорили чуть выше:


                              на темном и светлом фоне, разной толщины, разного объема один и тот же цвет воспринимается по-разному и там, где у Вас в верстке все будет точно, визуально будет отличаться

                              Противоречите сами себе? Может лучше крутить на конкретных элементах в их контексте — именно там где проблема, а не просто "в кубики играть"?

                                +1
                                Это не я говорил, но я соглашусь с теми словами.

                                Препроцессорные функции для манипуляции цветом (вот эти все lighten, darken и тп) не могут дать качественный результат. Они годятся для экспериментов, прототипирования, черновиков, но не более.

                                И да, натыкать вручную по палитре лучше. При условии, конечно, что тыкальщик имеет насмотренный глаз и набитую руку.
                                  0

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


                                  Можете объяснить чем результат работы функций "менее качественный" чем "в ручную"?


                                  Чем то что должен делать и как все обязан воспринимать профессиональный дизайнер [прочитавший, например, Дэна Маргулиса] отличается от подхода с функциями?


                                  Также непонятно c какими словами вы согласны? Которые сами себе противоречат? Вроде "слова" и говорят о том что корректировать цвет проблемных элементов стоит и надежнее "в контексте", прямо в браузере?

                                    +1
                                    Согласен с тем, что один цвет может восприниматься по-разному в зависимости от контекста.

                                    Функции плохи тем, чем манипулируют цветами в модели rgb, которая не является перцептивно-равномерной (а равно как и все её производные типа hsl)
                                    github.com/sass/dart-sass/blob/1fd8eb1a8d22ca7f2708dd790dc5f7463d62f964/lib/src/functions/color.dart#L134
                                    И если у меня есть условно красная и зеленая кнопки, и я хочу их затемнять по hover — я не могу просто сказать им darken(10%). Ну то есть могу, но результат в общем случае будет не очень консистентный.

                                    И уж тем более нельзя функциями препроцессора смешивать цвета, потому что они не учитывают гамма-коррекцию.
                                    github.com/sass/dart-sass/blob/1fd8eb1a8d22ca7f2708dd790dc5f7463d62f964/lib/src/functions/color.dart#L719

                                    Ну в общем, эти функции — такой программистский фастфуд. Годятся для быстрого перекуса, но если вас заботит качество, то лучше не надо.
                                      0

                                      Ответ хороший, но мне кажется вы отчаянно "выдаете желаемое за действительное" — "чтобы не сдаваться".) Вы думаете в большинстве реальных ситуаций некий среднестатический десигнер пойдет в LAB (вот как раз — "по Маргулису") подбирать hover для кнопки? Да ну? ))) Наверное где-то они есть такие, бывают, да, но чаще всего — не на реальном проекте. По опыту — откроет — Фотошоп, сейчас — Фигму и в этом же HEX/RGB/HSL — быстро натыкает на глаз на неоткалиброванном мониторе, разве нет? По опыту — большинство не используют сетки (или часто вижу — кинут сверху слой с "какой-то сеткой" которая вообще ни к чему отношения не имеет — "для виду-галочки") — а гайд по цветам, типографике и поведению основных элементов — нужно специально вытягивать пытками на старте. И чаще всего я услышу — "ну просто сделай темнее" — и да — просто сделаю функцией на 10% — "перцептивно-неравномерно". Это если про жизнь, без философии и сложных концепций восприятия цвета.

                                        0
                                        Поэтому я и написал про «насмотренный глаз и набитую руку» — они вполне могут заменить собой Lab. Это ведь Lab придуман для имитации свойств зрения, а не наоборот. Но лично я сочетаю и то, и другое.
                                0
                                Вы отвечаете разным людям ;)
                                Когда дизайнер и верстальщик — один человек, несомненно, проще и быстрее использовать функции. А когда верстальщику пришел запрос сменить #F843A2 на #F8489F, подобрать функцию будет сложно. Верстальщик не тыкает по наитию, а берет «пипетку» и вставляет цвет в код. Ну, и про цвет, это я в качестве примера. Заменяете цвет на «размер», «толщина линии», «размер шрифта» и получаете еще больший бардак (как по мне) в коде. Я просто не знаю, возможно, каких-то классных инструментов, которые позволяют сделать инверс-инженеринг скомпилированного в css кода обратно в scss, чтобы быстро найти в исходнике место правки. И как определить используется ли еще где-то и где именно исправляемое значение переменной?
                                  0

                                  Ой, ну вы совсем усложняете и передергиваете, не надо так. Если мне придет запрос поменять одно конкретное значение на другое — я именно так и сделаю, без всякой философии и продвинутых технологий. Функцию я использую если меня попросят, например, "сделать что-то чуть-чуть темнее".

                                    0
                                    Где именно Вы меняете цвет?
                                    Значение переменно, используемой в описании нужного класса? Как определяете на что еще в проекте повлияет изменение этого значения? Или прямо в описании класса, заменяя переменную на нужное значение? Заводите новую переменную, которая возможно будет использоваться только в этом месте? Так делаете всегда без исключений?
                                      –1

                                      Извините — работать надо, честное слово. Тут уже просто игра в слова у нас получается, практически бессодержательная и крайне выматывающая. Если есть что-то возразить или добавить конкретно по тексту — давайте. А как "правильнее перекрасить элемент" — ну это уныло. Есть 2 варианта — или это "дополнение к гайдлайну", которое в дальнейшем будет переиспользоваться — тогда вводим переменную на уровне стилевой базы, или "частный локальный кряк" — тогда вводим переменную на уровне компонента. Кажется это очевидно.

                      0
                      Я не фронтендер, но просто интересно — ваш подход противоположен utility-first CSS (как у Tailwind)?
                        0

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

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое