Как бы мне ни нравился CSS за его творческий потенциал, мне кажется невозможным не чувствовать боли, когда дело доходит до его масштабирования. В carwow в настоящее время более 40 инженеров ежедневно работают над нашим онлайн-приложением, и все мы в конечном итоге пишем CSS. Как бы мы ни старались держать вещи в порядке и использовать нашу систему дизайна, мы неизбежно сталкиваемся с типичными проблемами, связанными с поддержанием большой базы кода CSS: несогласованность, избыточность, чрезмерные сложности и частые регрессы нашего пользовательского интерфейса. .
Я слежу за многими разговорами о том, как решать эти проблемы, и, похоже, существуют разные школы мысли. Один состоит в обеспечении более строгого использования CSS с помощью линтеров и соглашений об именах (объектно-ориентированный CSS, SMACSS, BEM и т. Д.). Другой - это переосмысление того, как мы управляем стилями, и отказ от прямого написания CSS. Это можно сделать либо с помощью функционального инструментария, такого как Atomic CSS или Tachyons, либо с помощью управления стилями в JavaScript (см. JSS, CSS-модули или стилизованные компоненты).
Обычно меня озадачивает идея управления CSS в JavaScript. Мы уже перегружаем пользователей большим количеством JavaScript - будь то для обильной интерактивности или для маркетинговых трекеров. Обрабатывая как HTML, так и CSS в JavaScript, я прихожу к выводу, что действительно ли мы решаем проблемы или просто объединяем более тяжелые, медленные и более навязчивые веб-сайты. Как справедливо выразился Гарри Роберт:
Между тем, я недавно наткнулся на эту ветку об итогах создания нового прогрессивного веб-приложения Twitter и генерации CSS по запросу с помощью JS-фреймворка.
Следующий абзац особенно привлек мое внимание, так как я мог полностью относиться к описанным вопросам.
Вскоре после этого я также посмотрел выступление Мэтью Гриффита на elm-conf 2018 о его наборе инструментов для дизайна Elm UI.
Я проработал с Эльмом больше года, и этот разговор многое мне сказал. Мне очень нравится Elm за его предсказуемость, цикл обратной связи при работе с компилятором и уверенность в отсутствии ошибок времени выполнения. Более того, Elm изначально создавался как графическая библиотека, и кажется, что он естественным образом подходит для DOM. Также имеет смысл использовать его для объявления макета и внешнего вида создаваемых нами приложений.
Я смотрел этот разговор с волнением и скептицизмом. С одной стороны, мне очень нравится подход переосмысления стилей для веб-сайтов, а не использование функций Elm, которые как таковые реплицируют свойства CSS. Похоже, что мы много думали о том, чтобы сделать создание макета более простым и интуитивно понятным с помощью Elm UI. Один из недостатков CSS - его очень трудно читать. Просмотр списка свойств в селекторе никогда не дает полного представления о том, как элемент будет выглядеть в браузере. С пользовательским интерфейсом Elm макет и стили кажутся намного проще для чтения и, соответственно, быстрее для изучения.
Другой элемент, который мне действительно понравился в разговоре, - это взаимосвязь между пользовательским интерфейсом Elm и системами дизайна. Я активно работаю над созданием и поддержанием руководства по стилю и с энтузиазмом отношусь к созданию библиотеки пользовательского интерфейса, которая была бы гибкой, модульной и работала как для разработчиков, так и для дизайнеров. Опять же, проблемы с масштабированием CSS мешают достижению этой цели. Мне нравится возможность собирать части пользовательского интерфейса, как набор блоков LEGO. Инкапсуляция стилей в компонентах и возможность простого объявления макетов были бы ключом к достижению этого состояния.
Между тем, я скептически относился к возможностям, предлагаемым Elm UI. Добавляя уровень абстракции поверх CSS, нет ли риска ограничить его возможности? Примеры, представленные в докладе, а также некоторые демонстрации, которые я видел в Интернете, довольно упрощены, и мне интересно, сможем ли мы достичь сложных дизайнов с помощью Elm UI. Можем ли мы накладывать элементы? Анимировать и преобразовывать элементы с помощью изящных переходов? Использовать единицы просмотра или вычисления размеров? Эти вопросы кажутся мне важными, чтобы иметь возможность использовать Elm UI в производственной среде, при этом оставаясь довольной командой дизайнеров.
Затем я решил противостоять своему скептицизму и опробовать библиотеку с несколькими вариантами использования и лично убедиться в этом. Одной из моих попыток было воссоздать модальный компонент нашего руководства по стилю с помощью пользовательского интерфейса Elm. Некоторые из спецификаций, которые я хотел воспроизвести здесь, - это наложение, охватывающее всю область просмотра и блокирующее прокрутку пользователя, а также общий модальный экран с гибкой высотой до 65vh
. В теле модального окна при необходимости должна отображаться внутренняя полоса прокрутки. Наконец, компонент открывается и закрывается с быстрым изменением прозрачности наложения и размера модального окна, чтобы передать эффект всплывающего окна.
Создавая основы модального окна, я быстро натолкнулся на несколько проблем с переполнением, которые я интерпретировал как напоминание о том, что в глубине души я все еще пишу CSS. Я надеялся, что пользовательский интерфейс Elm предотвратит это, но я полагаю, что существуют пределы надежности атомарного инструментария CSS.
В целом, мне понравился опыт изучения пользовательского интерфейса Elm, а некоторые способы объявления макета и стилей намного элегантнее, чем в CSS.
Например, установка элемента в качестве наложения перед остальной частью страницы выполняется с помощью:
Element.layout [ inFront modalOverlay ] pageContent
Мы также извлекаем выгоду из синтаксиса Elm, который может быть удобен, например, для установки значений отступа или ширины границы:
paddingEach { edges | top = 24, left = 32 }
Вместо того, чтобы устанавливать все 4 ребра и следовать произвольному порядку:
padding: 24px 0 0 32px
Довольно быстро мне удалось собрать весь компонент:
Однако я не смог выполнить следующие требования:
- Я не мог установить максимальную высоту в единицах просмотра. Вместо этого мне пришлось установить его в пикселях.
- Я не мог найти способ установить переходы при открытии и закрытии модального окна. Я предполагаю, что переходы и анимация - это функции, которые Elm UI сможет обрабатывать в будущих версиях.
- В нашем руководстве по стилю есть набор размеров шрифта, которые адаптируются к 3 размерам экрана. Похоже, я не смог сделать это здесь, и, как правило, он не применяет медиа-запросы через интерфейс Elm.
- Есть некоторые мелкие проблемы, которые я тоже не мог решить. Например,
Element.textColumn
по умолчанию имеет минимальную ширину500px
, что для меня не имеет особого смысла, и его нелегко переопределить. У меня также были проблемы с вертикальным выравниванием текстовых элементов в строке, что обычно просто с помощью Flexbox. Хотя, эти проблемы могут быть просто из-за моего отсутствия опыта работы с инструментарием.
В конце концов, мне очень понравилось опробовать Elm UI. Это хорошо продуманная, простая в освоении и интересная в использовании библиотека. Я думаю, что на данный момент он слишком ограничен, чтобы иметь возможность использовать его в производстве и выполнять обычные требования к дизайну. Есть и другие проблемы, которые необходимо устранить, например, насколько хорошо он обрабатывает особенности браузера и поддерживает устаревшие браузеры.
Я надеюсь, что эти ограничения связаны только с новизной Elm UI, и что вскоре он продолжит развиваться и предлагать более широкие возможности.
PS: Кроме того, что с flex-grow: 100000
?