Smashing Podcast Episode 19 With Andy Bell: Что такое CUBE CSS?

Сегодня мы говорим о CUBE CSS. Что это такое и чем оно отличается от таких подходов, как BEM, SMACSS и OOCSS? Я поговорил с его создателем Энди Беллом, чтобы выяснить это.

Показать примечания

• КУБ CSS
• Острые пикули с пряностями
• Изучите Eleventy с нуля - сэкономьте 40%!
• Энди Белл и Пиккалилли в Твиттере

Примечание . Слушатели подкаста Smashing могут сэкономить колоссальные 40% на курсе Энди «Учись одиннадцать с нуля», используя код SMASHINGPOD .

Еженедельное обновление

• «Чему Vitruvius может научить нас в веб-дизайне»
  Фредерик О'Брайен
• «Введение в SWR: React Hooks для удаленной выборки данных»
  Ибрахима Ндав
• «Как веб-дизайнеры могут помочь ресторанам перейти на цифровые технологии»
  Сюзанна Скакка
• «Практическое руководство по тестированию приложений React с помощью Jest»
  Аденай Дэвид Абиодун
• «Основные моменты Django: работа со статическими активами и медиафайлами (часть 4)»
  Филип Кили

Стенограмма

Дрю Маклеллан: он является преподавателем и внештатным веб-дизайнером из Великобритании и работает в сфере веб-дизайна более десяти лет. За это время он работал с некоторыми из крупнейших организаций мира, такими как Harley-Davidson, BSkyB, Unilever, Oracle и NHS. Вместе с Хейдоном Пикерингом он является соавтором Every Layout, а также руководит клубом Front-End Challenges Club, который сосредоточен на обучении передовым методам разработки интерфейса с помощью коротких веселых задач.

Дрю: Его последнее начинание — Piccalilli, информационный бюллетень веб-сайта с учебными пособиями и курсами, которые помогут вам повысить свой уровень в качестве фронтенд-разработчика и дизайнера. Итак, мы знаем, что он опытный разработчик и педагог, но знаете ли вы, что он был первым человеком, которому разрешили соревноваться на Крафте с пандой?

Дрю: Друзья мои Smashing, пожалуйста, поприветствуйте, Энди Белл. Привет, Энди, как дела?

Энди Белл: Я в восторге, спасибо. Как твои дела?

Дрю: Я очень хорошо, большое спасибо. Сегодня я хотел поговорить с вами о том, что вы разместили на своем сайте Piccalilli, о методологии CSS, которую вы разработали для себя за последние годы. Прежде всего, я думаю, нам следует изучить, что мы подразумеваем под методологией CSS, потому что это может означать разные вещи для разных людей. Итак, когда вы думаете о методологии CSS, что она для вас значит?

Энди: Это хороший, сложный вопрос для начала, Дрю. Цените это, спасибо!

Дрю: Добро пожаловать!

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

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

Дрю: Так что это приложение процесса для того, как вы создаете архитектуру и пишете CSS, и это не столько что-то, что основано на инструментах или каких-либо других технологиях, это просто своего рода рабочий процесс. Итак, существует множество различных подходов. Вы упомянули БЭМ. Есть SMACSS, OOCSS, атомарный CSS. А еще у вас есть такие необычные детские подходы, как ABEM. Вы видели это?

Энди: Да.

Дрю: Зачем публиковать свои собственные?

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

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

Энди: Так что я оказался на таких должностях, когда работал с разными типами людей, над разными типами проектов, где одна методология не совсем работала. На протяжении многих лет я просто играл с этой идеей о том, как идут дела, а затем есть то, что мы с Хейдоном сделали, Every Layout, которое как бы усилило большую часть этого, то есть C, часть композиции. , а затем я очень быстро развил его за последние шесть месяцев.

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

Дрю: Значит, материал курса, который вы собираете, на самом деле использует CUBE CSS в качестве методологии, не так ли?

Энди: Да. Таким образом, хорошие 50% курса на самом деле являются предварительными, хотя это курс без ограничений. Это так, так глубоко переплелось с тем, как мы строим внешний интерфейс, что я не мог просто сказать: «О, кстати, вот как я пишу хороший CSS», а затем оставить это. Я знаю, что людям нравится вдаваться в подробности, поэтому я подумал: я напишу этот пост, который будет очень длинным и очень подробным, а затем, если кто-то захочет набраться опыта и действительно понять, что мы делаем , то могут сделать, а остальное оттуда. И вот мы сегодня, Дрю, сидим и болтаем об этом.

Дрю: Итак, если кто-то уже понимает БЭМ и, возможно, уже использует БЭМ, например, потому что это, вероятно, одна из самых широко распространенных методологий, не так ли? Итак, если у них уже есть понимание БЭМ, и они переходят к CUBE, будет ли им легко это принять? Есть ли много общего или это совершенно разные?

Энди: Да. Я бы сказал, что переход от BEM к CUBE, вероятно, является плавным переходом, особенно с учетом того, что мне все еще нравится писать CSS для CUBE. Так что большинство вещей происходит на более высоком уровне. Так что это происходит на каскадном уровне, и это происходит на глобальном CSS, используя утилиты для выполнения многих вещей. Но когда вы вникаете в суть, это очень похоже на БЭМ-компоненты, блоки и элементы. Единственное, что немного отличается от БЭМ, это то, что вместо модификаторов мы используем то, что называется исключениями, то есть вместо использования классов CSS мы обращаемся к атрибутам данных, что, как мне кажется, дает хорошее разделение и реальную исключение, которым должен быть модификатор.

Энди: Одной из причин, по которой я как бы отошел от БЭМ, было то, что я обнаружил способ работы с ним, особенно в дизайн-системах, где доминировали модификаторы, и это стало проблемой, потому что это было похоже на то, что такое роль моего блока в этот момент? Потому что, если я регулярно изменяю его до неузнаваемости, тогда эта методология все еще работает так, как должна работать?

Энди: Еще есть вся эта штука с жетонами дизайна, штука, которую Джина сделала с Lightning Design System, которую мы все сейчас начали внедрять. При таком подходе служебные классы действительно начали обретать смысл. Так что я просто как бы раздавил все, что мне нравится в работах других людей, и вместо этого втиснул их в свои собственные.

Дрю: Вы говорите о БЭМ, о своего рода модификаторе, который выходит из-под контроля. Было ли это одной из основных болевых точек БЭМ, которую CUBE пытается решить?

Энди: Да, абсолютно. Мне нравится модификаторный подход с БЭМ, он имеет смысл. Что мне нравится в БЭМ, так это то, что я делаю до сих пор: двойное подчеркивание для элемента и двойное тире для модификатора. Мне нравится такой способ организации вещей. Это был просто случай, ну, ну, многие модификаторы, которые я на самом деле могу объяснить с помощью служебных классов, а затем другие биты…

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

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

Дрю: Тогда давайте перейдем к CUBE. Таким образом, CUBE означает исключение Composition Utility Block Exception. Это правильно?

Энди: Да. Это тот.

Дрю: Что это значит?

Энди: О, приятель, ты должен был услышать это раньше! Я делал доклад в прошлом году. Я выступил с докладом, и он назывался «Простота с CSS, который масштабируется», и там я как бы представил более раннюю версию под названием CBEUT, которая была служебным токеном Cascade Block Element. Это был вздор. Я ненавидел это название. Я делал это пару раз, это выступление в прошлом году, и мне действительно не понравилось это имя. Затем, когда я начал заниматься этим в этом году, я подумал: «Мне действительно нужно подумать о том, что это на самом деле и как это называется». Я думаю, что CUBE немного меньше мусора. Думаю, это лучший способ описать это.

Энди: Но ведь имена всегда ерунда для таких вещей, не так ли? Я имею в виду, как и БЭМ, какое это дерьмовое имя! Но мы все это делаем. Посмотрите на Jamstack: это тоже ужасное имя, не так ли?

Дрю: Мои губы сомкнуты!

Энди: Твой босс спрашивает: «Что?» Это верно. Это просто так, не так ли, в нашей отрасли.

Дрю: Кажется, что многие методологии CSS пытаются обойти некоторые особенности CSS, такие как каскад. Из того, что я прочитал, я понял, что CUBE пытается использовать такие функции и свойства CSS.

Энди: Да. Хорошая аналогия: SCSS, как и Sass, является расширением естественного языка CSS, не так ли? Вы все еще правы в CSS. Итак, CUBE CSS такой. Итак, это расширение CSS. Так что мы все равно должны писать CSS, как и должен CSS… ну, он должен быть написан. Давайте будем честными, то, как это должно быть написано, это название выдает: Каскадные таблицы стилей. Так что это снова охватывает это, потому что я обнаружил, что я прошел весь путь до уровня микрооптимизации. Я был на пути, по которому я вижу много людей, идущих в последнее время, куда… и я также упомянул об этом в статье, где я вижу… недавно появились некоторые свидетельства этого. Я заметил, что люди создают компоненты для проставок и тому подобное, и я понимаю эту проблему, я был в такой ситуации.

Энди: Я исправил это следующим образом: вместо того, чтобы детализировать и пытаться микрооптимизировать, я начал думать о вещах на композиционном уровне, потому что неважно, насколько малы ваши компоненты, в какой-то момент они чтобы быть страницами, они будут просмотрами. Этого не избежать, так оно и будет. Таким образом, вместо того, чтобы пытаться сказать: «Хорошо, мне нужны эти маленькие помощники, чтобы сделать этот макет», вы говорите: «Хорошо, у меня есть просмотр страницы контактов или просмотр страницы продукта, и это скелетная композиция макета. Затем внутрь этого я могу вставить любые компоненты, которые захочу». Теперь у нас есть такие вещи, как Grid и Flexbox, которые делают это гораздо более достижимым, и вы можете, по сути, поместить все, что хотите, внутрь скелетного макета, это не имеет значения. Затем компоненты должны вести себя так, как вы хотите, с контейнерными запросами или без них.

Дрю: Это составная часть CUBE, где вы смотрите на вещи на более макроуровне, смотрите, как компоненты могут быть объединены в представление для создания страниц, которые вам нужно создать для сайта или приложения. или что у тебя.

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

Энди: Итак, хороший пример: мы делаем макет в Every Layout, называемый переключателем, который, по сути, будет располагать элементы в строке до определенного момента, когда вычисление, которое определяет, насколько широким он должен быть, просто укладывает их друг на друга. . Но поскольку мы добавляем поля к строке и блоку, он работает, независимо от его состояния, он все еще выглядит нормально. Идея заключается в том, что мы не говорим браузеру сказать: «Вы должны наслоить эту сетку из трех столбцов». Мы говорим: «Если вы можете создать сетку из трех столбцов, сделайте это. В противном случае просто стек и пространство вместо этого ». Так что это своего рода методология, позволяющая браузеру действительно делать свою работу.

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

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

Энди: Я подчеркиваю в статье, что к тому времени, когда вы переходите на уровень блока, большая часть вашего стиля уже сделана, и на самом деле то, что делает ваш компонент, — это расставлять точки над буквами «I», пересекать буквы «Т» и говорить: «Правильно, в этом контексте…» Итак, для карты, например, сделайте изображение минимальной высоты X и добавьте здесь немного отступа. Делай то, то и другое. Поставь сюда кнопку. Это просто дополнительные правила поверх того, что уже унаследовано от остальной части CSS. Думаю, это лучший способ описать это.

Энди: В то время как в БЭМ компонент является источником истины. Пока вы не поместите этот класс в элемент, в этот момент ничего не было применено, и этот метод работает. Я просто обнаружил, что написал больше CSS, делая это, и больше повторяющегося CSS, что мне не нравится делать.

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

Энди: Да. В глобальном CSS да, абсолютно. Особенно вертикальный ритм и флоу. Мы сделали статью об этом на 24 дорогах, не так ли, пару лет назад, о флоу и ритме. Это также было своего рода абстракцией от этого подхода, когда вы устанавливаете базовый компонент, который по существу использует селектор лоботомированной совы. Я не знаю, как я опишу это по радио, но мы это сделаем. Мы просто поместим, я думаю, в шоу заметки о статье Хейдона или что-то в этом роде. Но, по сути, он выбирает дочерние элементы… извините, родственные элементы.

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

Дрю: Итак, это С, Композиция. Далее у нас есть U, то есть полезность. Итак, что мы подразумеваем под полезностью?

Энди: Так что это класс, который выполняет одну работу, и делает это очень хорошо. Это может быть реализация токена дизайна, который… представляет собой абстракцию свойств. Обычно это цвета или стили типографики, размеры и подобные правила. Идея в том, что вы создаете служебные классы, которые их применяют. Итак, у вас есть утилита, которая будет применять основной фон, который похож на основной цвет, а затем основной цвет, который является цветом текста. Затем вы можете сгенерировать несколько токенов пробелов для маргинального заполнения и тому подобного. Они просто делают одну работу. Они просто добавляют одно правило интервала, одно правило цвета, и все.

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

Энди: Итак, у вас есть свои глобальные стили, вы сделали много настроек типографики и много места на полу. Затем ваша композиция дает контекст и макет. Затем утилиты применяют токены непосредственно к элементам, чтобы придать им тот стиль, который вам нужен. Так, например, в заголовке вы говорите: «Я хочу, чтобы это было такого размера, и я хочу, чтобы оно имело этот ввод, и я хочу, чтобы оно имело этот размер». Затем в этот момент… это то, что я говорил о блоках… затем вы идете дальше по стеку, и вы уже сделали большую часть работы в этой точке.

Энди: Таким образом, они дают вам действительно эффективный способ работы, и, поскольку HTML также как бы течет вниз по трубе, я обнаружил, что действительно приятно абстрагировать рабочую нагрузку на HTML, а не на CSS. Раньше я действительно попадал в служебные классы, как в этом старом стиле скряги: «О, разделение задач», но я на самом деле думаю, что это действительно достойный способ работы. Я упоминаю в статье, что мне действительно нравится Tailwind CSS. Я думаю, что это работает, и мне очень нравится использовать его для типирования продукта, потому что я действительно могу очень быстро что-то написать. Но я думаю, что это заходит слишком далеко, как Tailwind, в то время как мне нравится лить дождь, когда дело выходит за рамки простого применения одного правила к классу. Вот и все, я думаю. Ты?

Дрю: Итак, да, вы много говорите в статье о токенах дизайна, о чем мы говорили в подкасте Smashing с Джиной Энн еще в третьем эпизоде, я думаю, это было. Таким образом, похоже, что дизайнерские токены — действительно фундаментальный аспект.

Энди: Да. О, Боже, да. Я очень хорошо помню, как Джина занималась Lightning Design System, потому что в то время я создавал систему дизайна или что-то похожее на систему дизайна, и мы изо всех сил пытались получить одобрение руководства. Когда вышла Lightning Design System, я буквально отправлял им ссылку за ссылкой и говорил: «Вот что мы делаем. Мы создаем дизайн-систему. Это то, для чего Salesforce в настоящее время использует его». Я помню, как ее работа в то время действительно помогала мне доставлять вещи через дверь.

Энди: Тогда дизайн-токен всегда запомнился мне как действительно хороший способ применения этих правил. Поскольку я дизайнер по профессии, я могу просто увидеть, что организация и способность организовать и создать единый источник правды действительно полезны, потому что это то, чего у нас на самом деле не было в цифровом дизайне, особенно в Adobe. эра работы с Photoshop и прочим, у нас просто не было такой роскоши. У нас он был в печатном виде с Книгой Pantone, но у нас не было его в цифровом виде со случайными шестнадцатеричными кодами по всему магазину.

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

Дрю: Важна ли реализация этих токенов дизайна в подходе? Всегда ли это настраиваемые свойства CSS?

Энди: Я думаю, что это очень важный момент для CUBE. Некоторые из ответов, которые я получил, люди немного боролись с этим. В нем нет ни слова о технике. Единственная непротиворечивая технология — это CSS. Вы можете сделать это, как хотите. Вы могли бы сделать все это с помощью любых CSS и JS вещей, которые люди делают сейчас, или вы могли бы сделать это только с помощью Vanilla CSS. Вы могли бы сделать это с Sass. Я делаю это с Сассом. Меньше, если это то, чем вы все еще занимаетесь. Все эти доступные технологии, post CSS и все такое. Вы можете делать как хотите, это не имеет значения.

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

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

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

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

Дрю: Так что это может быть всего лишь гиперссылка.

Энди: Да.

Дрю: Но это может быть и составной набор других блоков?

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

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

Дрю: Мне определенно нужно много прощения за мой CSS!

Энди: Я знаю!

Дрю: Привет! Так что это B. Последнее, что E: E Исключение. Теперь мы не говорим о сообщениях об ошибках, не так ли?

Энди: Нет, нет. Это своего рода-

Дрю: Мы не говорим об исключениях JavaScript.

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

Энди: Причина, по которой я делаю это с атрибутами данных, а не с классами, и причина, по которой это происходит, заключается в том, что а) я думаю, что хорошо иметь различие. Поэтому, когда вы сканируете большое количество HTML-кода, вы можете увидеть данные, прочеркнуть что-то и сказать: «Хорошо, хорошо, в этом элементе определенно что-то изменилось». Другое дело, что очень удобно предоставлять JavaScript доступ к этому состоянию и наоборот. Так что мне очень нравится применять состояние с атрибутами данных в JavaScript. Я думаю, для этого они и нужны, своего рода коммуникационный слой. Гармония между ними, кажется, работает очень хорошо.

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

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

Энди: Да. Это хороший способ сказать это, да. Я обнаружил, что очень полезно работать таким образом.

Дрю: Это довольно интересно. Я не думаю, что видел какие-либо другие методологии, использующие такой подход. Это совершенно уникально для CUBE?

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

Энди: CUBE — это мыслящая штука, это структура. Вы применяете эту структуру так, как хотите, с помощью того инструментария, который вам нужен, или любой технологии, которую вы хотите. Пока вы держите вещи последовательными, это важно.

Дрю: Значит, чистого КУБА не существует?

Энди: То, как я это пишу, чисто CUBE, Дрю. Все остальные просто подделка, это просто слабая имитация.

Дрю: Никто, кроме тебя, не может сказать: «Это не учебник CUBE».

Энди: Нет, это все. Никто не может оспорить это на самом деле, не так ли? Так что да, я пойду с этим. Дает вам немного влияния или что-то, я думаю, что-то в этом роде.

Дрю: Можете ли вы сочетать подход CUBE с другими методологиями? Можно ли использовать биты БЭМ?

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

Энди: Итак, есть два противоположных конца шкалы. Хороший вопрос, который задают люди: «Как это работает с каждым макетом и другими вещами?» По сути, каждый макет — это C. Вот что такое каждый макет, это композиционный слой. Затем кто-то еще спросил: «Ну, а как это будет работать с чем-то вроде Atomic Web Design, вроде того, что сделал Брэд Фрост? Это как, ну, вы можете разбить эти части и применить их на каждом уровне. Атомарный дизайн полностью проработан до микродеталей. Это абстрагирование в использование, да, хорошо, я могу применить это с утилитами, так что молекулы, я думаю. Я могу применить это к утилитам, и это переводит то, что вы уже знаете, в немного другую структуру работы.

Энди: На самом деле, это переименование многих вещей. Я тут ничего не выдумывал, я как бы, как говорится, просто украл то, что мне нравится. Мне нравится, как обдумываются некоторые вещи, связанные с атомарным дизайном. Это действительно умная работа. И БЭМ. То, что сделал Гарри, CSS с перевернутым треугольником, я думаю, было действительно круто. Так что я просто вырезал кусочки, которые мне нравятся, из каждого из них, и вроде как сшил их все вместе в другой гибридный подход. Я думаю, это еще не все.

Дрю: Можно ли применить подход CUBE к существующим проектам, в которых уже есть CSS, или это то, с чего вам действительно нужно начинать новый проект?

Энди: Это очень зависит. Так что, если у вас есть задание на загрузку, и у вас есть тысячи строк пользовательского CSS, в котором я определенно участвовал раньше, то я думаю, что вы, возможно, пытаетесь потушить огонь бутылкой воды в это время. точка. Но если вы… скажем, если у вас есть грубая настройка БЭМ, и она стала немного многослойной, вы можете использовать CUBE для рефакторинга и на самом деле снова привести ее в форму.

Andy: It depends, the answer to that one. But it's doable, as with everything. If you really want it to work, Drew, you can do it if you want, can't you? The world is our oyster!

Drew: Especially if your BEM site's gone layer-y.

Andy: Yeah. Nothing worse than a layer-y BEM site!

Drew: I've noticed in the examples that you've given… and I've got an eagle eye, I've seen you've been doing this for a while… a lot of your class values in the HTML attribute are wrapped in square brackets.

Andy: Oh, God, yeah. Tell you what, Drew-

Drew: What is that about? О чем это?

Andy: I'll tell you what, if there's ever one thing that I've done in my whole career that's just been absolutely outrageously controversial… and you follow me on Twitter, you've seen what comes out of my mouth… it's those bloody brackets! My, God! People either love them or hate them. They're Marmite, they are.

Andy: The reason I do them is a grouping mechanism. So if you look at the way that they're structured, the way I do it is, block at the start and then I'll do a utilities after that. Then what I might do is, in between a block group and a utility group, there might be another block class. So a good example of that would be… we'll go back to the card again. But then say that there's a specific block called a CTA, like a call to action. You might have that applied to the card as well, and then your utilities are enforcing the design attributes, so the colors and all that business. So then you've got three groups of stuff.

Andy: When you come to it, if you've got that order in your head each time, you know, okay, right, this first group's blocks. Oh, that's looks like another block. I've got that one. Then it's like, right, they're definitely utility classes. Then what I might even do is, if there's a lot of design token implementation, have that in a separate group. So it's just very clear what each group is doing, and there's a separation inside of the classes there as well. I've found it really helpful. Some people find it incredibly offensive. It's definitely a do it if you want to do it. Definitely you don't have to do it.

Andy: It's quite funny, when I published that article, so many people finished halfway through to ask me, “What is it with these brackets?” I was like, “Did you finish the article? Because there's a big section at the end where it explains exactly what they're doing,” to the point where I actually had to write a bit in the middle of the article of, “If the brackets are essentially doing your head in, click here and I'll skip you all the way down to that explanation bit so you can just read about them.” It can be quite controversial.

Andy: When I've worked on really, really complex front-ends… and we did a little bit of stuff together, didn't we, last year?

Дрю: Ага.

Andy: You've seen the sort of design implementation on that project that we were on. It requires that sort of grouping because there's just so much going on at the time, there's so much different stuff happening. I've just found it really, really useful over the years, and also get lots of questions about it, to the point where I was almost going to write just one page on my website that I could just fire people to to answer the question for them.

Drew: Slash, what's with the brackets?

Andy: Yeah. Slash, brackets. Have you seen that new Hey Email thing that's just come out? They've bought a domain of itsnotatypo.com, just to answer the whole Imbox, like im with an M rather than an in. Basically, I was like, “I think I need to do that,” like, whatswiththebrackets.com, and just do a one-pager about it.

Drew: It strikes me that the approach with brackets actually could be something that might be useful when using things like Tailwind or something that has a lot of classes because that can-

Andy: Yeah. Oh, God, yes.

Drew: You have classes that are addressing your break points and what have you, and then you'll have things that are for layout, things that are for color or type, or what have you. So it might also be a useful way of dealing in situations like that.

Andy: I'd definitely agree with that. A good analogy… not analogy. A good bit of info about Tailwind is that I actually quite like Tailwind. I've used that on very big projects. The one thing that really opened my eyes to Tailwind though was when I saw a junior developer try to work out what was going on, and it was really, really eye-opening because they just didn't have a clue what was happening.

Andy: I think that's one problem I've found with these sort of over-engineered approaches, which I think it's fair to say Tailwind is, is that there's a certain skill level that is required to work with it. I know the industry tends to have an obsession with seniority now, but there's still people that are just getting into the game that we need to accommodate, and I think having stuff that's closer to the language itself is more helpful in those situations because they're probably learning material that is the language as it is. So I think it's just a bit more helpful. Especially having a diverse team of people as well. Just food for thought for everyone.

Drew: People might look at all the different methodologies that are out there and say, “This is evidence that CSS is terrible and broken, that we need… all these problems have to be solved by hacking stuff on top. We need tools to fix bits of CSS. We need strict procedures for how we implement it, just to get it to work.” Should the platform be adapting itself? Do we need new bits of CSS to try and solve these problems or are we all right just hacking around and making up funny acronyms?

Andy: I think the power of CSS, I think, is its flexibility. So if you're going to program CSS, a lot of the knowledge is less of the syntax and more of the workings of a browser and how it works. I think that might be a suggestion, that the problem is that people might not have learnt CSS quite as thoroughly as they thought they might have learnt it, who created these problems. I've seen that in evidence myself. I spotted a spacing mechanism that had been invested, which was very complicated, and I thought, “This person has not learnt what padding is because padding would actually fix this problem for them, understanding how padding works and the box model.” That's not to be snidey about it.

Andy: We work in an industry now that moves at an even faster pace than it has done previously and I think there's a lot less time for people to learn things in detail. But, on that front, I think CSS still does have work to do in terms of the working group, who I think do a bloody good job. A great, shining example of their work was the Grid spec which was just phenomenal. The way that rolled out in pretty much every browser on day one, I thought that was so good.

Andy: But we've got more work to do, I think, and I think maybe the pace might need to increase a little, especially with stuff like container queries, we all love talking about them. Stuff like that I think would help to put CSS in a different light with people, I think. But I think CSS is brilliant, I love it. I've never had a problem with it in lots of years really. I do find some of the solutions a bit odd, but there you go.

Drew: What's the response been like to CUBE since you published the article?

Andy: Mind-blowing. I honestly published it as just supporting material, and that's all I expected it to be, and it's just blown up all over the place. A lot of people have been reading it, asking about it, been really interested about it. There's definitely more to come on it.

Andy: I did say in the article, I said, “Look, if people are actually quite interested in this, I'll expand on this post and actually make some documentation.” I've got bits of documentation dotted around all over the place, but to sort of centralize that, and then I was thinking of doing some workshops and stuff. So there's stuff to go. It's how Every Layout started as well. We both had these scattered ideas about layout and then we sort of merged them together. So something like that, I suppose, will come in the future.

Drew: Are there any downsides that you're aware of to using CUBE? Are there problems that it doesn't attempt to solve?

Andy: Yeah. This accent, Drew, it just won't go way, no matter what I do! In all seriousness, I think CUBE's got as close as I can get to being happy with the front-end, which is saying a lot, I think. You never know, things might change again. This has evolved over more recent years. Give it another five years, I'll probably be struggling with this and trying something else. I think that's the key point, is to just keep working on yourself and working on what you know and how you approach things.

Andy: This definitely won't work for everyone as well, I know that for a fact. I know that from my comments. I don't expect it to work for everyone. I don't expect anything to work for everyone. It's the same with JavaScript stuff: some people like the reactive stuff and some people don't. It is what it is. We're all people at the end of the day, we all have different tastes. It's all about communicating with your teammates at the end of the day, that's the important thing.

Drew: I know you as a very talented designer and developer and you, like many of us, you're just working on real projects all day, every day. But you've recently started publishing on this site, Piccalilli, which is where the CUBE CSS introduction article was. So Piccalilli is kind of a new venture for you, isn't it? What's it all about?

Andy: Very kind of you to say, Drew. You've actually worked with me, so that's high praise. But the Piccalilli thing is an evolution. So I'm a freelancer. I do client work, but I think this has become apparent with the pandemic, that that is not the most sustainable thing in the world in some industries. I think freelancing can be very, very tough, as a developer and designer. It's something that I've been doing it for so long now, 10 years… well, 12 years now actually.

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

Дрю: Так что будет дальше с Пиккалилли? У тебя есть что-нибудь, что у тебя выходит?

Энди: Спасибо, что открыл дверь, Дрю! К тому времени, когда эта запись выйдет, первый курс будет запущен: Learn Eleventy From Scratch, и именно здесь мы научимся создавать веб-сайт Gatsby! Нет, вы узнаете, как создать сайт Eleventy. Итак, вы начинаете с совершенно пустого каталога, в нем ничего нет, он пуст, а затем в конце вы заканчиваете этот действительно красивый сайт агентства. Мы узнаем все виды в нем. Вы узнаете, как по-настоящему отправиться в город с Eleventy. Мы извлекаем удаленные данные из разных мест. Мы используем CUBE CSS, чтобы создать для него действительно хороший интерфейс.

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

Энди: Так что покупайте, и я сделаю код скидки, например, smashingpod со скидкой 40%, и вы сможете получить его, когда он выйдет.

Дрю: Удивительно. Мы свяжем это. Вы уже выяснили, как правильно пишется пиккалилли?

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

Дрю: Ну, я все еще борюсь, вот что я тебе скажу!

Энди: Это сложно. О Боже. Я полностью сочувствую. Мне потребовалось много времени, чтобы научиться писать это слово, но это одно из тех слов в нашем лексиконе. В этом году я пытаюсь написать необходимое без орфографической ошибки!

Дрю: Итак, я узнал все о CUBE CSS. О чем ты узнал в последнее время, Энди?

Энди: Знаешь что? Это тебя удивит, Дрю. MySQL — это то, о чем я недавно узнал. Так что, по сути, Piccalilli полностью издается самостоятельно. Это сайт Eleventy, но за ним стоит API и база данных MySQL. Материал, который дает людям контент, который они купили, требует довольно серьезных запросов. Так что я только что как следует вложился в MySQL… особенно в разницу между соединениями, о которой я на самом деле не понимал, что между каждым типом соединения есть разница. Так что это было действительно полезно, и это привело к довольно быстрому взаимодействию с базой данных.

Энди: Раньше я запускал эту штуку под названием Front-End Challenges Club, и когда я впервые запустил ее, она просто рухнула и умерла сама по себе, потому что MySQL был дрянным, если не сказать больше. Так что я действительно научился это делать, потому что я вообще не специалист по бэкенду, я — пиксель-пушер. Так что это точно не в моей компетенции. Это больше твоя шея в лесу, не так ли? Я нахожу это действительно крутым, MySQL. Мне на самом деле очень нравится это писать. Это действительно хороший учебный язык, не так ли?

Дрю: Да, это здорово. Я изучал SQL в школе.

Энди: Вау!

Дрю: Мы говорим о том, что было 20 лет назад.

Энди: В то время у них были компьютеры?

Дрю: Были, да. Нам пришлось намотать-

Энди: Тебе приходилось писать это от руки?

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

Энди: Да. Для уверенности. Есть и действительно ощутимые различия. Вы действительно видите разницу в скорости. Мне очень нравится работать с Node, потому что это очень быстро, но Node и MySQL просто… не очень распространенный выбор, но я думаю, что это довольно хороший выбор. Я думаю, что это работает очень, очень хорошо. Так что я доволен этим. Как вы знаете, я не люблю писать на PHP. Так что это никогда не будет вариантом.

Дрю: Если вы, дорогой слушатель, хотели бы услышать больше от Энди, вы можете следить за ним в Твиттере, где он находится на hankchizljaw. Вы можете найти Piccalilli на piccalil.li, где вы также найдете статью, описывающую CUBE CSS, и мы, конечно же, добавим ссылки на все это в примечаниях к шоу.

Дрю: Спасибо, что присоединился к нам сегодня, Энди. Были ли у вас напутствия?

Энди: Берегите себя и носите маску.