Write less CSS

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

Описание к видео

Это видео с конференции dotCSS 2017.

Рассказчик Adam Detrick 🐦 дизайнер и веб-программист в Meetup.

PERMISSIONS:

The original video was published with the Creative Commons Attribution license (reuse allowed). Credits:

Original video source: https://www.youtube.com/watch?v=5tvHS...

Additional material for CSS learners:

https://amzn.to/2Tk6kBZ CSS: The Definitive Guide: Visual Presentation for the Web

https://amzn.to/2FgQcMI A Smarter Way to Learn HTML & CSS: Learn it faster. Remember it longer

https://amzn.to/2Ffp1ll CSS in Depth

https://amzn.to/2FlKV6N CSS Secrets: Better Solutions to Everyday Web Design Problems

Общий смысл

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

Собственно, конспект

00:00 — Пример плохого CSS

Молоток хорош не для всего, вот пример молотка в CSS:

сильно хитрожопый селектор
куча !important

01:06 — Adding CSS loop

Типа чел видит сложный CSS, который не может использовать из коробки
Менять его он боится, чтобы чего не сломать
Адаптировать перегрузкой не может, потому что тот кусок слишком сложный
Чел его копипастит с изменениями: вот у нас ещё один кусок сложного неатаптируемого CSS.

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

Ну… маленько является, когда вам нужно какую-нибудь фигню поменять и вам приходится менять её во всех ста компонентах. Но, во-первых, всё-таки ста скопипащенных компонентов не бывает, бывает максимум 3. А во-вторых, в этом случае вы как правило можете взять себя в руки и немножко подрефакторить, выделить какой-нибудь утилитарный компонент, который потом сможете переиспользовать в остальных, комбинируя на уровне JS-кода.

Кароче, этого цикла нет либо это не проблема.

02:00 — Задаётся вопрсом, почему такая фигня происходит

Вроде бы CSS мощный язык со всякими там выразительными средствами, почему мы его так тупо используем? Ответ: потому что читать код всегда сложнее чем писать, а CSS — это особо сложный в чтении код. Типа, этот язык хорош для компа, а не для человека. Комп загружает всё в себя, строит дерево и правильно считает все каскады. Но вот человеку в голове всё это посчитать на лету сложновато.

04:00 — Структура компаний тоже способствем том, чтобы плодить новый и новый CSS

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

05:40 — В итоге они пришли к тому, чтобы писать меньше CSS

Описывает подход аналогичный бутстрапу.

10:00 — Немноко зачитывает критику и наинает на неё отвечать:

10:30 — Нужно выбрать подходящий уровень абстракции

Он не должен быть слишком низким, т. е. не должно быть такого класса: .border--top--black--4px, иначе вам придётся создать их слишком много и люди не будут ими пользоватсья. На правильном уровне абстракции классы отражают концепт: .text--display1, .media--x1.

12:30 — Текстовые утилиты цвета

C-textPrimary
C-textSecondary
C-textHint
C-textPrimary-inverted
C-textSecondary-inverted
C-textHint-inverted

12:30 — Автоматизация

Допустим есть у него есть утилиты цвета дла разных видов текста, те, что выше.

он их может транслировать в JS и переиспользовать в коде
также он может автоматически строить документацию с демонстрацией

13:34 — Автоматическая документация forever

Ручная документация — это отложенная ложь, которая когда-нибудь вылезет.

14:00 — Подытоживание

Чтобы писать меньше CSS, нужно:

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

Моё отношение

TLDR. Всё круто, когда библиотка CSS написана за тебя. Но неприменимо, если тебе такую библиотеку нужно сначала самому создать.

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

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

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

Когда такой библиотеки у вас ещё нет и вы начинаете проект, то при таком подходе вы превращаетесь в писателя CSS библиотеки, чьи фичи конкурируют с основными задачами проекта. И поскольку первичен именно проект, то вначале библиотека у вас получится так себе. Особенно, если вы раньше таких библиотек не писали (я не писал). Утилитные классы будут друг другу мешать, придётся лепить костыль на костыле.

В общем, такой подход требует компетентности. Если вы не умеете, то этот подход не для вас. Если вы ещё не знаете, умеете вы или нет, то значит вы не умеете. Конечно, этому можно научиться, но с первого раза точно не получится.

Поэтому в создании своих стилей я больше опираюсь на подход БЭМ:

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

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

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