Ранний взгляд на WordPress 5.9: путь к более глубокому адаптивному дизайну блоков

Руководитель проекта Gutenberg Матиас Вентура объявил о предварительном пути к 5.9 в блоге Make Core ранее сегодня. Он затронул несколько общих вопросов, включая несколько подпунктов для каждого. Он также связался с проблемой GitHub с конкретными задачами и билетами, которые требуют доработки.

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

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

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

Внутренний веб-дизайн с блоками

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

Слишком часто то, что мы видели с запросами и даже сторонними плагинами, – это использование медиа-запросов на основе области просмотра для управления тем, как блоки реагируют на различные устройства (например, настольный компьютер, планшет и мобильное устройство). Хотя такие элементы управления иногда могут быть правильным инструментом для работы, они не всегда являются правильным путем для компонентного проектирования.

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

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

Простой пример – основной блок столбцов WordPress. Мы могли бы легко добавить параметры медиа-запроса, когда каждый внутренний блок Column разрывается. Однако как типографика должна реагировать на три столбца против четырех и разной ширины? Это функция размера контейнера, а не области просмотра.

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

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

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

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

Запросы к контейнерам – это своего рода Святой Грааль для дизайнеров. Как писал веб-дизайнер Итан Маркотт четыре года назад:

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

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

Звучит знакомо? Да, блочная система WordPress построена на той же основе небольших компонентов макета.

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

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

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