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

Подожди, нет style.css файл? У нас все еще есть это. Фактически, style.css is еще нужный файл в блочных темах, хотя его роль значительно сводится к метаинформации, используемой для регистрации темы. Тем не менее, факт в том, что theme.json все еще находится в активной разработке, то есть мы находимся в переходном периоде, когда вы можете найти стили, определенные там, в styles.css или даже на уровне блоков.

Итак, как на самом деле выглядит стиль в эти дни WordPress FSE? Это то, что я хочу осветить в этой статье. Отсутствует документация по стилизации тем блоков в Справочник разработчика темы WordPress, так что все, что мы здесь освещаем, — это то, что я собрал о том, как обстоят дела в настоящее время, а также обсуждения о будущем тематики WordPress.

Эволюция стилей WordPress

Новые возможности развития, включенные в WordPress 6.1 приближают нас к системе стилей, которые полностью определены в theme.json, но предстоит еще много работы, прежде чем мы сможем полностью положиться на него. Один из способов получить представление о том, что будет в будущих выпусках, — это использовать Плагин Гутенберга. Именно здесь экспериментальные функции часто тестируются.

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

Но не начинайте торговать CSS style.css для пар свойство-значение JSON в theme.json только пока. Все еще существуют правила стилей CSS, которые необходимо поддерживать в theme.json прежде чем мы подумаем об этом. Оставшиеся существенные вопросы в настоящее время обсуждаются с целью полного переноса всех стилевых правил CSS в theme.json и объединить различные источники theme.json в Пользовательский интерфейс для установки глобальных стилей непосредственно в Редактор сайтов WordPress.

Это ставит нас в относительно сложное положение. Не только есть нет четкого пути для переопределения стилей темы, но неясно, откуда вообще берутся источники этих стилей — из разных слоев theme.json файлы, style.css, плагин Гутенберга или где-то еще?

почему theme.json вместо style.css?

Вам может быть интересно, почему WordPress движется к определению стилей на основе JSON вместо традиционного файла CSS. Бен Дуайер из команды разработчиков Gutenberg красноречиво объясняет, почему theme.json подход является преимуществом для разработчиков тем.

Пост Бена стоит прочитать, но суть в этой цитате:

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

Поощряя авторов тем использовать theme.json API, где это возможно, иерархия определенных стилей «база > тема > пользователь» может быть разрешена правильно.

Одним из основных преимуществ переноса CSS на JSON является то, что JSON является машиночитаемым форматом, что означает, что он может быть представлен в пользовательском интерфейсе редактора сайта WordPress путем получения API, что позволяет пользователям изменять значения по умолчанию и настраивать внешний вид сайта без писать любой CSS вообще. Он также предоставляет способ согласованного стиля блоков, предоставляя при этом структуру, которая создает слои специфичности, так что пользовательские настройки имеют наивысший приоритет над теми, которые определены в theme.json. Это взаимодействие между стилями на уровне темы в theme.json а определяемые пользователем стили в пользовательском интерфейсе Global Styles — это то, что делает подход JSON таким привлекательным.

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

Наверняка есть и другие преимущества Майк Макалистер из WP Engine перечисляет несколько в этой ветке Твиттера.. Вы можете найти еще больше преимуществ в этом углубленное обсуждение в блоге Make WordPress Core. И как только вы прочитали это, сравните преимущества подхода JSON с доступные способы определения и переопределения стилей в классических темах.

Определение стилей с элементами JSON

Мы уже видели большой прогресс в том, какие части темы theme.json умеет стилизовать. До WordPress 6.1 все, что мы могли сделать, — это стилизовать заголовки и ссылки. Теперь, с WordPress 6.1, мы можем добавить кнопки, подписи, цитаты и заголовки к смеси.

И мы делаем это, определяя JSON-элементы. Думайте об элементах как об отдельных компонентах, которые находятся в блоке WordPress. Скажем, у нас есть блок, содержащий заголовок, абзац и кнопку. Эти отдельные части являются элементами, и есть elements объект в theme.json где мы определяем их стили:

{
  "version": 2,
  "settings": {},
  // etc.
  "styles": {
    // etc.
    "elements": {
        "button": { ... },
        "h1": { ... },
        "heading": { ... },
    },
  },
  "templateParts": {}
}

Лучший способ описать элементы JSON — это низкоуровневые компоненты для тем и блоков, которым не нужна сложность блоков. Они представляют собой примитивы HTML. которые не определены в блоке, но могут использоваться между блоками. Как они поддерживаются в WordPress (и плагине Gutenberg) описано в Справочник редактора блоков и это Полное руководство по редактированию сайта Каролина Наймарк.

Например, ссылки оформлены в стиле elements объект, но не являются блоком сами по себе. Но ссылку можно использовать в блоке, и она унаследует стили, определенные в блоке. elements.link объект в theme.json. Однако это не полностью инкапсулирует определение элемента, поскольку некоторые элементы также регистрируются как блоки, например блоки «Заголовок» и «Кнопка», но эти блоки по-прежнему можно использовать в других блоках.

Вот таблица элементов, которые в настоящее время доступны для стиля в theme.json, любезно предоставлено Каролиной:

Как видите, пока еще рано, и многое еще предстоит перейти от плагина Gutenberg к WordPress Core. Но вы можете видеть, как быстро было бы сделать что-то вроде глобального стиля для всех заголовков в теме, не ища селекторов в файлах CSS или DevTools.

Кроме того, вы также можете начать видеть, как структура theme.json своего рода формирует слои специфичности, идущие от глобальных элементов (например, headings) на отдельные элементы (например, h1) и блочные стили (например, h1 содержится в блоке).

Дополнительная информация об элементах JSON доступна в это Сделать предложение WordPress и этот открытый билет в репозитории плагина Gutenberg на GitHub.

Специфика JSON и CSS

Продолжаем говорить о специфике CSS. Ранее я упоминал, что подход JSON к стилю устанавливает иерархию. И это правда. Стили, определенные для элементов JSON в theme.json считаются стилями темы по умолчанию. И все, что установлено пользователем в пользовательском интерфейсе глобальных стилей, переопределит значения по умолчанию.

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

я использую Пустая тема, пустая тема WordPress без стилей CSS. Я собираюсь добавить блок кнопок на новую страницу.

Хорошо, мы знаем, что WordPress Core поставляется с легким стилем. Теперь я собираюсь переключиться на тему TT3 по умолчанию из WordPress 6.1 и активировать ее. Если я обновлю свою страницу с помощью кнопки, кнопка изменит стили.

Вы можете видеть точно откуда берутся эти новые стили в ТТ3 theme.json файл. Это говорит нам о том, что стили элементов JSON имеют приоритет над стилями ядра WordPress.

Теперь я собираюсь изменить TT3, переопределив его с помощью theme.json файл в дочерней теме, где цвет фона блока Button по умолчанию установлен на красный.

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

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

Двигатель стиля

Это очень быстрое, но хорошее представление о том, как специфичность CSS управляется в блочных темах WordPress. Но это не полная картина, потому что все еще неясно в котором эти стили генерируются. WordPress имеет свои собственные стили по умолчанию, которые откуда-то берутся, потребляют данные в theme.json для дополнительных правил стиля и переопределяет те, которые установлены в глобальных стилях.

Эти стили встроены? Они находятся в отдельной таблице стилей? Может быть, они вставлены на страницу в ?

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

Мы только впервые взглянем на Style Engine. Собственно, вот что сделано на данный момент по билету:

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

По сути, это основа для создания единого API, содержащего все правила стиля CSS для темы, откуда бы они ни пошли. Это очищает способ, которым WordPress вводил встроенные стили до 6.1, и устанавливает систему для семантических имен классов.

Более подробную информацию о долгосрочных и краткосрочных целях Style Engine можно найти в этом Обсуждение ядра WordPress. Вы также можете следить за проблема с отслеживанием и проектная доска для большего количества обновлений.

Работа с JSON-элементами.

Мы немного говорили об элементах JSON в theme.json файл и как они в основном являются примитивами HTML для определения стилей по умолчанию для таких вещей, как заголовки, кнопки и ссылки, среди прочего. А теперь посмотрим на самом деле через элемент JSON и его поведение в различных контекстах стиля.

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

Глобальные стили для элементов JSON

Давайте посмотрим на новую тему TT3 по умолчанию и посмотрим, как оформлены ее кнопки. Ниже приведена сокращенная копия-вставка ТТ3. theme.json файл (вот полный код), показывающий раздел глобальных стилей, но вы можете найти исходный код здесь.

{
  "version": 2,
  "settings": {},
    // ...
  "styles": {
    // ...
    "elements": {
      "button": {
        "border": {
          "radius": "0"
        },
        "color": {
          "background": "var(--wp--preset--color--primary)",
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":focus": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":active": {
          "color": {
            "background": "var(--wp--preset--color--secondary)",
            "text": "var(--wp--preset--color--base)"
          }
        }
      },
      "h1": {
        "typography": { }
      },
      // ...
      "heading": {
        "typography": {
          "fontWeight": "400",
          "lineHeight": "1.4"
      }
      },
      "link": {
        "color": {
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "typography": {
            "textDecoration": "none"
          }
        },
        ":focus": {
          "typography": {
            "textDecoration": "underline dashed"
          }
        },
        ":active": {
          "color": {
            "text": "var(--wp--preset--color--secondary)"
          },
          "typography": {
            "textDecoration": "none"
          }
        },
        "typography": {
          "textDecoration": "underline"
        }
      }
     },
    // ...
  },
  "templateParts": {}
}

Все кнопки стилизованы на глобальном уровне (styles.elements.button).

Мы можем подтвердить это и в DevTools. Обратите внимание, что класс, называемый .wp-element-button является селектором. Тот же класс используется для стилизации интерактивных состояний.

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

Кроме того, WordPress 6.1 добавил поддержка стилизации интерактивных состояний для определенных элементов, таких как кнопки и ссылки, используя псевдоклассы в theme.json - в том числе :hover, :focusи :active — или пользовательский интерфейс глобальных стилей. Инженер-автомат Дэйв Смит демонстрирует эта особенность в видео на YouTube.

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

Но тогда кнопки изменятся все сразу. Что, если мы хотим переопределить цвет фона, когда кнопка является частью определенного блока? Вот где в игру вступают блочные стили.

Блочные стили для элементов

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

Для этого мы определяем стили на styles.blocks объект в theme.json. Правильно, если мы определим глобальные стили для всех кнопок на styles.elements, мы можем определить специфичные для блока стили для кнопок на styles.block, который следует аналогичной структуре:

{
  "version": 2,
  // ...
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": {
      "core/search": {
        "elements": {
          "button": {
            "color": {
              "background": "var(--wp--preset--color--quaternary)",
              "text": "var(--wp--preset--color--base)"
            }
          }
        },
        // ...
      }
    }
  }
}

Видеть, что? я установил background и text недвижимость на styles.blocks.core/search.elements.button с двумя переменными CSS, предустановленными в WordPress.

Результат? Кнопка поиска теперь красная (--wp--preset--color--quaternary), а блок Button по умолчанию сохраняет ярко-зеленый фон.

Мы также видим изменения в DevTools.

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

Пример: стилизация заголовков на каждом уровне

Давайте разберем всю эту информацию на примере. На этот раз мы:

• Глобально стилизовать все заголовки
• Стиль всех элементов заголовка 2
• Элементы Style Heading 2 в блоке Query Loop

Во-первых, давайте начнем с базовой структуры для theme.json:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": { }
  }
}

Это устанавливает схему для наших глобальных и блочных стилей.

Глобально стилизовать все заголовки

Давайте добавим headings возражайте против наших глобальных стилей и примените некоторые стили:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
    },
    // Block-level styles
    "blocks": { }
  }
}

Это устанавливает цвет для всех заголовков на предустановленный базовый цвет в WordPress. Давайте также изменим цвет и размер шрифта элементов Заголовка 2 на глобальном уровне:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": { }
  }
}

Теперь все элементы Заголовка 2 настроены на основной предустановленный цвет с плавный размер шрифта. Но, может быть, мы хотим фиксированную fontSize для элемента Заголовок 2, когда он используется в блоке Query Look:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": {
      "core/query": {
        "elements": {
          "h2": {
            "typography": {
              "fontSize": 3.25rem
            }
          }
        }
      }
    }
  }
}

Теперь у нас есть три уровня стилей для элементов «Заголовок 2»: все заголовки, все элементы «Заголовок 2» и элементы «Заголовок 2», которые используются в блоке цикла запросов.

Примеры существующих тем

Хотя в этой статье мы рассмотрели только примеры стилей для кнопок и заголовков, WordPress 6.1 поддерживает стилизацию дополнительных элементов. В таблице есть их описание «Определение стилей с элементами JSON» .

Вам, вероятно, интересно, какие элементы JSON поддерживают какие свойства CSS, не говоря уже о том, как их объявить. Пока мы ждем официальной документации, лучшими ресурсами, которые у нас есть, будут theme.json файлы для существующих тем. Я собираюсь предоставить ссылки на темы на основе элементов, которые они настраивают, и указать, какие свойства настраиваются.

Обязательно дайте каждому theme.json файл хороший внешний вид, потому что эти темы включают отличные примеры стилей на уровне блоков на styles.blocks объект.

Подведение итогов

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

Относительно Предложение GitHub переоформить редактор сайта в новый режим браузера, Сара Гудинг пишет в посте WP Tavern:

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

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

Рекомендации

Я перечисляю все ресурсы, которые я использовал при поиске информации для этой статьи.

JSON-элементы

Глобальные стили

Движок стиля

Спасибо за чтение! Я хотел бы услышать ваши собственные размышления об использовании тем блоков и о том, как вы управляете своим CSS.