Гутенберг уважает поддержку редактора, заявленную CPT, и не загрузится, если она не поддерживается.

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

• Новым пользователям придется изучить основные и тонкие способы, которыми отличаются эти два типа интерфейсов. Такие простые действия, как публикация сообщения или переход к текстовому представлению, работают по-разному в редакторах Gutenberg и Classic.

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

• Разработчики новых плагинов, начинающие разработку WordPress, должны будут научиться создавать плагины двумя разными способами. Предполагая, что они охватывают блоки Гутенберга, их функции плагина могут быть недоступны даже в типах сообщений, использующих классический редактор.

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

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

В тех случаях, когда CPT вообще не хочет включать редактор, это кажется лучшим путем вперед. Это просто другой вид администратора, оптимизированный для другого опыта. (Например, представление «заказы» от Woo.) Никому не поможет попытаться отобразить их в контексте Гутенберга.

Это похоже на появление Настройщика - это была новая парадигма интерфейса, которая делала то же самое в другом контексте. Нам всегда понадобится интерфейс «управления» и интерфейс «редактирования». Частично это то, как мы движемся вперед, разъясняя различные цели интерфейсов.

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

Нам всегда понадобится интерфейс «управления» и интерфейс «редактирования».

Это как раз те роли, которые сегодня выполняют редактор и мета-боксы. Это не изолированные переживания. Они работают вместе.

тогда, возможно, следует решить проблему ползучести, и Гутенберг должен быть ограничен областью, заполненной wp_editor() . Это определенно решило бы многие проблемы совместимости.

Ползучесть прицела

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

Включение Гутенберга для каждого типа сообщения

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

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

• Вы, как разработчик, пишете пользовательский интерфейс своего плагина в виде блока или метабокса? Если вы хотите поддерживать все типы сообщений, вам нужно будет написать оба типа.
• Когда пользователь ищет плагины, знают ли они, что функциональность, которую вы обещаете на своей странице плагина, работает только с типами сообщений с поддержкой Гутенберга? Будут ли они разочарованы, когда узнают, что не могут использовать его вместе с классическим редактором?
• Когда этот же пользователь обращается к вам за поддержкой, знаете ли вы, спрашивают ли они, как ваш плагин работает в классическом редакторе или редакторе Гутенберга. Этот покупатель вообще знает разницу?
• Если вы хотите добавить функциональность через несколько месяцев после запуска, готовы ли вы увеличить время разработки, чтобы встроить эту функциональность как в мета-поле PHP, так и в блок JS?

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

show_in_rest

Тот факт, что сообщения не могут использовать Gutenberg, когда show_in_rest не установлен, - это просто еще один пример несвязанных функций, влияющих на процесс редактирования. Нет причин, по которым мои предпочтения в отношении видимости общедоступных сообщений в REST API должны влиять на то, какой интерфейс я использую при редактировании. Я понимаю технические причины, но логики здесь нет, и я подозреваю, что многие разработчики даже не осознают, что это ограничение на данный момент.

Как Гутенберг вообще вышел за рамки параметров wp_editor (), до сих пор меня озадачивает. Если «редактор» Гутенберга будет ограничен wp_editor (), тогда «включение в качестве опции» для каждого типа сообщения станет реальностью и станет гораздо более управляемой и расширяемой в будущем. Я до сих пор не нашел рационального объяснения того, почему ползучесть области видимости Гутенберга не может быть уменьшена и просто включена в wp_editor ().

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

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

Например, на сайте автора, над которым я работал, есть CPT для «Книг» и «Ссылки на магазины». Совершенно разумно иметь Гутенберга в качестве редактора страниц со списком книг. Но «Ссылки на магазины» не имеют собственных сообщений или страниц, а используются для обеспечения логики ссылок на книжные онлайн-магазины на каждой странице «Книги». Шаблон страницы «Книги» отображает ссылки магазина на страницы продуктов, которые соответствуют региону (например, Великобритания, США) и формату (например, электронная книга, печать), вставляя ISBN, хранящийся в мета-поле сообщения, в структуру URL-адресов каждого интернет-магазина - см. Снимки экрана.

CPT, возможно, не лучший способ управления такими данными и настройками, но есть множество веб-сайтов, которые объединили различные функции, используя CPT без редактора и настраиваемые мета-поля - я мог бы привести другие примеры такого использования. Было бы запутанным и контрпродуктивным принуждать редактора Гутенберга к CPT, которые вообще не используют редактор.

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

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

Например, представьте, что вы разработчик плагина и хотите, чтобы ваше мета-поле «Настройки ссылок в магазине» было доступно в одном типе публикации, который использует Gutenberg, а во втором типе публикации, который этого не делает. Когда вы распространяете плагин среди тысяч пользователей, которые ожидают, что он будет работать с любым типом сообщений, у вас нет роскоши выбора. Вот тогда в игру вступают вопросы, упомянутые в https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341867663.

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

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

Я предполагаю, что тогда возникает вопрос, как Гутенберг должен обрабатывать CPT, которые не поддерживают редактор - как Гутенберг функционирует в контекстах, где нет смысла строить страницу из блоков, где это просто мета-управление?

... как Гутенберг должен обрабатывать CPT, которые не поддерживают редактор - как Гутенберг функционирует в контекстах, где нет смысла строить страницу из блоков, где это просто мета-управление?

Если бы Гутенберг был сокращен и заменил только редактор, как в концепции Yoast, о которой я упоминал в https://github.com/WordPress/gutenberg/issues/3304#issuecomment -341474018, то включение или отключение Гутенберга становится довольно простым.

• Если editor включен, тогда присутствует редактор блоков, и мета-поля могут появляться над или под ним в зависимости от используемых хуков.
• Если editor отключено, тогда редактор блоков отсутствует, и мета-поля сдвигаются вверх, чтобы стать основным интерфейсом для типа сообщения.

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

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

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

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

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

Я не уверен, что WordPress будет востребован через пять лет , если проект в целом не предпримет смелых шагов для достижения будущего. Ядро JavaScript уже много лет рекламируется на конференции State of the Word. Имея это в виду, а также возможность радикально упростить создание богатого контента постов, рассмотрение всего процесса редактирования вместо крошечного окна - это не только возможность, но и, возможно, было бы небрежно проектировать в противном случае, несмотря на проблемы, которые он приносит. с этим.

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

Возможна загрузка одного компонента Gutenberg , просто холста редактора, в текущий экран редактирования. Это будет сильно скомпрометированный опыт и Франкенштейн пользовательского интерфейса, но это может быть один из способов, который следует изучить для обеспечения хорошего пути перехода с 4.9 на 5.0. Но следует прояснить, что это ни стандартный опыт, ни оптимальный вариант.

Я предполагаю, что тогда возникает вопрос, как Гутенберг должен обрабатывать CPT, которые не поддерживают редактор - как Гутенберг функционирует в контекстах, где нет смысла строить страницу из блоков, где это просто мета-управление?

@CalebWoodbridge, вот как это уже работает. См .: https://github.com/WordPress/gutenberg/blob/master/lib/register.php#L290

Во-вторых, я бы сказал, что использование термина «ползучесть» некорректно. Это термин, который определенно не относится к проекту, который призван делать то, что есть Гутенберг.

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

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

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

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

Гутенберг дал нам возможность удалить патчи, посмотреть, что у нас есть, и создать заново. Это дало нам начало сильному визуальному языку для перехода к настройке и за ее пределами. На самом деле иметь визуальный язык, который продвинет WordPress в следующие 10 лет. Да, мы должны думать так далеко вперед.

Я хочу также предостеречь от Frankendesigns. У каждого дизайнера в мире в какой-то момент кто-то предлагал «просто поставить x здесь или y там». Это не позволяет дизайнеру заниматься дизайном. Как проект, мы находимся на нисходящей спирали, если не позволяем дизайнерам проектировать. Говоря прямо, это такой процесс, который тушит огонь дизайнеров. Давайте поддерживать огонь.

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

Если говорить о том, что

Я хочу внести ясность, я не говорю, что Гутенберг «готов» или идеален как дизайн. Нам нужно повторить и протестировать. Нам не нужно возвращаться назад, отказываться от устоявшегося сильного языка дизайна. Нам не нужен Frankendesign. Что нам нужно, так это протестировать, получить обратную связь и позволить дизайнерам выполнить итерацию.

Одной из больших проблем WordPress в прошлом с точки зрения дизайна была спираль небольших итераций поверх небольших итераций. Несмотря на то, что он работает в течение первых нескольких, со временем он накапливает опыт, объединенный с исправлениями.

Попытка согласовать подобные утверждения с такими публичными заявлениями, как это http://matiasventura.com/post/gutenberg-or-the-ship-of-theseus/, очень затрудняет пользователям ощущение, что они получают честное сообщение о работе. делается. WordPress используется миллионами людей миллионами способов, и было совершенно ясно, что в отношении технических аспектов, таких как поддержка метабокса или формат хранения сообщений, требуется постепенный подход с минимально возможными поломками. Это решение усложнило несколько частей реализации и вынудило принять решения, которые не являются оптимальными, но лучше поддерживаются во многих отношениях.

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

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

Затем, предоставив хорошо документированный Fields API, вы можете преобразовать плагины и темы в менталитет блоков Гутенберга в течение следующего года, упростив и упростив создание того же интерфейса. Очень быстро метабоксы становятся старым способом ведения дел, и все ценные плагины переключаются на блоки ... опять же, это должно происходить органично. Принуждение людей к рукам путем отказа от функций или создания разделенного интерфейса, в котором авторы плагинов должны кодировать как для Gutenberg, так и для метабоксов, неприемлемо.

Хорошо, что вы упомянули капитальный ремонт СМИ как область, которая требует переделки ... это область, которая пострадала из-за неконтролируемого, негибкого капитального ремонта. Это был первый раздел WordPress, полностью включивший JS-фреймворк, и для разработчиков это был огромный шаг назад. Отсутствие настроек в медиа-библиотеке не является признаком ее совершенства, а скорее свидетельствует о том, что в ней отсутствует продуманный дизайн, учитывающий будущие и текущие варианты использования. Я много раз пытался изменить медиа-интерфейс, но обнаружил, что кто-то в какой-то момент решил, что основные компоненты должны быть жестко закодированы в базовых шаблонах. Буквально вчера я столкнулся с одним из таких случаев! (как вы можете видеть в седьмом абзаце здесь: https://gschoppe.com/wordpress/disable-attachment-pages/)

Масштабирование Гутенберга обратно к редактору, а не к странице редактирования, даст вам путь вперед, который не сломает все. Как только Гутенберг прочно укоренится в качестве основы для пользовательских пост-интерфейсов, тогда видение, основанное только на JavaScript, может перейти на остальную часть страницы редактирования. Подобная итерация абсолютно необходима для больших программных пакетов, если (как Мэтт утверждал, что это неприемлемо) вы не предлагаете выпуски LTS и не делаете каждую основную версию полным критическим изменением.

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

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

@gschoppe , спасибо, что

Во-первых, некоторая ясность. Я не согласен с тем, что мой комментарий противоречит сообщению Матиаса. Я полностью поддерживаю пост, который он написал, это тоже мое видение, и мы, как лидеры этого проекта, объединились в том, как мы видим направление. Ваше личное мнение принадлежит вам, так что давайте продолжим с этого момента.

Неразумно связывать разработку с одним стандартом, а дизайн - с другим.

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

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

Мне бы хотелось, чтобы СМИ с самого начала фокусировались на дизайнерах и разработчиках, но этого не произошло.

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

Интересно, что вы так говорите, ведь никто не отнимает никакой функциональности. Никакие дизайнерские предложения Гутенберга этого не сделали. Так или иначе, все существующие функции могут быть выполнены, даже если для этого используется классический плагин редактора.

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

Если бы долгосрочный план для Гутенберга был территорией надстройки, я бы сказал, экспериментируйте без ограничений. Но если ему не суждено стать плагином, который люди должны выбрать, а не отказываться от него, тогда он должен реалистично иметь дело с ядром и всем багажом, который он несет с собой.

мой комментарий не нацелен на то, чтобы дизайн был услышан больше

У каждого дизайнера в мире в какой-то момент кто-то предлагал «просто поставить x здесь или y там». Это не позволяет дизайнеру заниматься дизайном. Как проект, мы находимся на нисходящей спирали, если не позволяем дизайнерам проектировать. Говоря прямо, это такой процесс, который тушит огонь дизайнеров. Давайте поддерживать огонь.

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

Откровенно говоря ,

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

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

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

В настоящее время функция wp_editor() (которая является текущим лучшим способом реализации полнофункциональной копии опыта редактирования на страницах без редактирования) не предоставляет интерфейс Гутенберга, а это означает, что я не могу создавать пользовательские возможности редактирования на страницах, не предназначенных для публикации ... каков мой путь вперед, кроме предоставления пользователям разделенного UX?

Хотя плагин для удаления Gutenberg может решить некоторые проблемы, вы не можете отправить его в качестве решения для разработчиков плагинов. У них нет свободы сказать: «Если вам нужен последовательный и доступный пользовательский интерфейс для разных типов сообщений, вам необходимо отключить новый редактор».

Удаление функции НЕ является обратной совместимостью для стандартного рабочего процесса. Удаление функции - последнее средство для 1% пользователей, которым не может быть удобен первоклассный опыт. В этом случае ни один из приведенных мной примеров не соответствует 1%.

Чтобы добавить немного масла в огонь: буквально на прошлой неделе я столкнулся с серьезной проблемой с использованием iFrames, т.е. они могут хорошо работать на настольных системах, но в 90% протестированных случаев они сильно терпят неудачу на мобильных / адаптивных системах. Покопавшись в многочисленных обсуждениях на досках сообщений, статьях в сети и задавая вопросы о переполнении стека, я решил полностью отказаться от подхода iframe, потому что отзывчивость с ними ужасно усложняется ... тьфу. Некоторые задачи преобразования были выполнены довольно легко, например, «использовать перенаправление на фактический субдомен, где находится проект» вместо того, чтобы полагаться на iframe, чтобы разместить красивое украшение, то есть показывающее только предполагаемый основной домен, но другие были гораздо более удручающими.

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

Подводя итог, можно сказать, что хотя фреймы на первый взгляд кажутся легким выходом, они ОЧЕНЬ ПЛОХОЙ выбор дизайна не только из-за (множества) проблем с доступностью.

Только мои 0,02 цента,
cu, w0lf.

Спасибо @mtias за показ этой проблемы.
Ниже я публикую свои мысли о том, как Гутенберг может открыть двери для разработчиков плагинов WordPress.

Настраиваемый класс CSS для любого существующего блока

Требуется: класс CSS для каждой обертки блока и полный доступ для его настройки. Будет здорово, если Гутенберг потребует класс CSS на самом верхнем элементе даже от сторонних разработчиков.

Цель: таким образом мы можем добавлять пользовательские классы в блоки для расширенного стиля. Мы также можем использовать классы для добавления анимации или других дополнительных свойств блока.

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

Настраиваемые атрибуты данных для любого существующего блока

Требуется: возможность добавлять настраиваемые атрибуты данных для любой оболочки блока.

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

Пример использования:

• отзывчивые блоки : отметьте блок, который будет отображаться только на мобильных устройствах и компьютерах.
• условные блоки : пометьте блок для отображения / скрытия с помощью JS <div data-condition="if-adblock"... , <div data-condition="if-from-facebook"...
• анимация блока : отметьте блок для анимации <div data-animation="on-load animation-style-3"...
• конструкция блока : <div data-skin="dark"...