Каталог RSS-каналов
Статистика

RSS-каналов в каталоге: 3390

Добавлено сегодня: 0

Добавлено вчера: 0

Hi-Tech / Интернет

На пути к отзывчивым элементам

CSS-LIVE 16.02.2020 в 15:37

Жизнь во фронтенде

Перевод статьи Towards Responsive Elements с сайта bkardell.com, опубликован на CSS-live.ru с разрешения автора — Брайана Карделла

В этой статье я расскажу о проблеме «выражений от контейнера», попытаюсь пролить свет на некоторые заблуждения, и ввести вас в курс состояния дел.

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

Как это так? Почему Рабочая группа по CSS как будто не прислушивается к нам? Почему за все эти годы не появилась хоть какая-нибудь официальная CSS-спецификация — в конце-то концов?

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

N проблем

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

Немалая часть трудности — то, что в зависимости от того, как вы выделяете проблему, некоторые из этих запросов могут потребовать фундаментальных изменений в архитектуре браузерных движков. Хуже того: мы даже не знаем, каких именно. К сожалению, очень трудно осознать, что это значит на практике, поскольку такие изменения затрагивают массу всего, повторюсь, во многом скрытого от большинства веб-разработчиков. Достаточно будет сказать, что любая такая переделка архитектуры может вылиться в полностью непредсказуемый (в годах) объем работы для воплощения и проверки подобной идеи — а затем еще больше лет разработки для каждого движка. Хуже того, всё это время оно будет так же невидимо для разработчиков. Например, вы знали, что много лет уже идет напряженная работа, чтобы открыть нам много новых возможностей в CSS? А она идет — и говорю не о Houdini!

Хорошо, но что насчет выражений от контейнера…

Что сейчас происходит в этой области?

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

Но со временем многие из них превратились в «Как нам сделать из этого более решаемую задачу?» и «Как нам на самом деле куда-то продвинуться, минимизировать риски, предпринять шаги и наконец дать что-то разработчикам?»

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

Просто космическая скорость прогресса…

Стандарты развиваются со скоростью, непривычной для большинства из нас. Только представьте: мы переломили застой в обсуждениях и ResizeObserver был придуман, доведен до ума, специфицирован, протестирован, утвержден, причем не с первого раза (у нас бывали ошибки!), и реализован во всех браузерах примерно за 2 года (последняя реализация в WebKit — заслуга Igalia и спонсорства AMP). CSS-изоляция работает в 2 движках из трех.

Это стандартизация и нормализация чего-то совсем нового для разработчиков просто со скоростью света.

Но… этого мало.

Да, это так.

В анонсе по поводу реализации ResizeObserver в WebKit силами Igalia у меня был простейший пример, как можно создавать отзывчивые компоненты считанными строчками кода, который работал независимо от того, как и почему меняется размер элементов. Но… никто не хочет, чтобы нам обязательно приходилось писать JavaScript для этого… Буквально никто из тех, кого я знаю — так как же быть?

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

Мы определенно думаем о дальнейших шагах!

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

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

Но мы также разговаривали с людьми из Google, Mozilla и Apple, и они были всегда готовы помочь и не против пообщаться — и генерируя новые идеи в дискуссиях, и комментируя их. Не знаю, как еще отметить пользу этих обсуждений и то, с какой охотой все члены Рабочей группы по CSS, представляющие браузерные компании, тратили на это свое время. Лишь за недавнюю поездку на очную встречу Рабочей группы по CSS у меня было множество прорывных дискуссий — многие часы для обмена идеями между Igalia-нцами и браузероделами.

Жаль, что я пока не могу сказать, что мы уже «закончили».

Похоже на то, что есть некие «отличные идеи», которые вроде бы могут к чему-то привести — но пока нет согласия, за какую из них (или вообще за обе сразу) стоит взяться в первую очередь.

Текущие идеи…

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

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

Прокладывать небольшие, очень оптимизированные маршруты в CSS

Одна из замечательных идей, порожденных в дискуссиях со множеством людей в ходе встреч Рабочей группы по CSS, возникла из мысли Иэна Килпатрика из Google…

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

Главное в этой мысли то, что, похоже, есть одна «почти естественная» область, открывающая возможность для массы практических применений, что реально встретились нам в ходе исследований. Некоторые участники сообщества пришли к не сильно отличающимся идеям: создать что-то вроде условия ‘if’ с помощью выражений в calc(), чтобы выразить разные значения для свойств. Идея предполагает что-то типа такого:

Представьте себе, что мы добавили функцию, назовем ее «switch», которая позволяет выражать что-то «наподобие медиавыражения» с несколькими возможными значениями для свойства. Они основываются на доступной ширине по строчной оси на этапе построения макета. Что-то наподобие…

.foo { display: grid; grid-template-columns: switch( (available-inline-size > 1024px) 1fr 4fr 1fr; (available-inline-size > 400px) 2fr 1fr; (available-inline-size > 100px) 1fr; default 1fr; ); }

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

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

Еще лучшая изоляция и…

Есть еще одна интересная идея, в основном принадлежащая Дэвиду Барону из Mozilla. У Дэвида есть целая серия предложений, призванная охватить весь путь к решению одним взглядом. Она еще уточняется и конкретизируется, наверняка он что-то дописывает прямо сейчас, пока я пишу эту статью.

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

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

Пока не на все вопросы есть ясный ответ, но Дэвид — один из самых компетентных людей, которых я знаю, и в этом предложении масса плюсов, так что я жду не дождусь новых подробностей!

Попробовать что-то новое?

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

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

Что же дальше?

В ближайшие месяцы я надеюсь и дальше обдумывать и изучать эту область и продолжить обсуждения с другими. Буду счастлив опубликовать кое-какие исследования и, может быть, новые (работающие) эксперименты с JS, целью которых будет лучше нащупать путь, который можно будет взять за основу. У нас есть сырые заготовки и достаточно информации, чтобы понять, где между нашими запросами и практическими аспектами того, что мы хотим проверить, есть нестыковки.

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

А пока давайте порадуемся, что мы уже неплохо сдвинулись с мертвой точки, и будем работать, чтобы достичь еще большего!

Другие записи ленты

CSS-2020: очередной «снимок состояния» или спецификация №1 современного CSS? 06.02.2020 в 15:03

Веб в 2020 году: расширяемость и совместимость 29.01.2020 в 12:28

Новые математические функции в модуле единиц и значений CSS 4 уровня – еще один шаг к полноценному программированию на CSS 27.01.2020 в 14:48

Стандарт CSS для Masonry-раскладки: от идеи — к первым конкретным наработкам 09.01.2020 в 13:35

CSS-модуль режимов письма (Writing Modes) 3 уровня официально стал стандартом W3C 17.12.2019 в 21:13

CSS4 не будет… потому что он давно прошел. Встречайте CSS8! 15.11.2019 в 20:29

Маленькие хитрости кастомных свойств (CSS-переменных) 25.10.2019 в 02:49

Смогут ли React-хуки заменить компоненты высшего порядка (HOC)? 29.08.2019 в 12:25

Смогут ли React-хуки заменить Redux? 26.08.2019 в 13:47

Пользовательские CSS-атрибуты как механизм передачи данных из JavaScript в CSS 08.08.2019 в 11:22