Те, як ми пишемо 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, плагін Gutenberg чи десь ще?

Чому 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 перераховує кілька у цій темі Twitter. Ви можете знайти в цьому ще більше переваг поглиблене обговорення у блозі 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. Однак це не повністю інкапсулює визначення елемента, оскільки деякі елементи також зареєстровані як блоки, наприклад блоки Heading і Button — але ці блоки все одно можна використовувати в інших блоках.

Ось таблиця елементів, які зараз доступні для стилізації theme.json, люб'язно надано Кароліною:

Як ви бачите, це ще ранній період, і ще багато чого потрібно перейти від плагіна Gutenberg до WordPress Core. Але ви бачите, як швидко було б створити щось на зразок глобального стилізації всіх заголовків у темі, не шукаючи селекторів у файлах CSS чи DevTools.

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

Додаткова інформація про елементи JSON доступна в ця пропозиція Make WordPress та цей відкритий квиток у сховищі GitHub плагіна Gutenberg.

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

Давайте продовжимо говорити про специфіку CSS. Раніше я згадував, що підхід JSON до стилізації встановлює ієрархію. І це правда. Стилі, визначені в елементах JSON у theme.json вважаються стилями теми за замовчуванням. І все, що встановлює користувач у інтерфейсі користувача Global Styles, замінить значення за замовчуванням.

Іншими словами: стилі користувача містять більше конкретності, ніж стилі теми за замовчуванням. Давайте подивимося на блок кнопок, щоб зрозуміти, як це працює.

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

Гаразд, ми знаємо, що WordPress Core поставляється з легким стилем. Тепер я перейду на стандартну тему TT3 з WordPress 6.1 і активую її. Якщо я оновлю свою сторінку за допомогою кнопки, кнопка змінює стилі.

Ви точно бачите звідки походять ці нові стилі у ТТ3 theme.json файл. Це говорить нам про те, що стилі елементів JSON мають перевагу над стилями WordPress Core.

Тепер я збираюся змінити TT3, замінивши його на a theme.json файл у дочірній темі, де типовим кольором тла блоку кнопок є червоний.

Але зверніть увагу на кнопку пошуку на останньому знімку екрана. Він теж повинен бути червоним, чи не так? Це має означати, що його стилізовано на іншому рівні, якщо я вніс зміни на глобальному рівні. Якщо ми хочемо змінитися обидва кнопки, ми могли б зробити це на рівні користувача за допомогою інтерфейсу користувача Global Styles у редакторі сайту.

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

Двигун стилю

Це дуже швидка, але хороша ідея того, як специфіка CSS керується в блокових темах WordPress. Але це не повна картина, тому що вона ще незрозуміла де ці стилі генеруються. WordPress має власні стилі за замовчуванням, які звідкись надходять, споживають дані theme.json для більшої кількості правил стилю та замінює ті, які встановлено в Global Styles.

Ці стилі вбудовані? Чи є вони в окремій таблиці стилів? Можливо, вони введені на сторінку в a ?

Ось що нового Двигун стилю сподіваємось, вирішить. Механізм стилю — це новий 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 за замовчуванням і розглянемо стиль її кнопок. Нижче наведено скорочене копіювання та вставлення TT3 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 — або інтерфейс користувача Global Styles. Інженер-автоматика Дейв Сміт демонструє ця функція у відео YouTube.

Ми можемо замінити фоновий колір кнопки будь-яким theme.json (бажано в дочірній темі, оскільки ми використовуємо тему WordPress за замовчуванням) або в налаштуваннях Global Styles у редакторі сайту (дочірня тема не потрібна, оскільки вона не потребує зміни коду).

Але тоді всі кнопки зміняться відразу. Що, якщо ми хочемо змінити колір фону, коли кнопка є частиною певного блоку? Ось тут і вступають у гру стилі на рівні блоків.

Стилі на рівні блоку для елементів

Щоб зрозуміти, як ми можемо використовувати та налаштовувати стилі на рівні блоку, давайте змінимо колір фону кнопки, яка міститься в блоці пошуку. Пам’ятайте, що є блок Button, але те, що ми робимо, це заміна кольору фону на рівні блоку Search. Таким чином, ми застосовуємо новий колір лише там, а не застосовуємо його глобально до всіх кнопок.

Для цього ми визначаємо стилі на 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), а стандартний блок кнопок зберігає свій яскраво-зелений фон.

Ми також бачимо зміни в 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. Давайте також змінимо колір і розмір шрифту елементів Heading 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 встановлено основний попередньо встановлений колір за допомогою a плавний розмір шрифту. Але, можливо, ми хочемо виправити fontSize для елемента Heading 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
            }
          }
        }
      }
    }
  }
}

Тепер у нас є три рівні стилів для елементів Heading 2: усі заголовки, усі елементи Heading 2 і елементи Heading 2, які використовуються в блоці циклу запитів.

Існуючі приклади тем

Хоча в цій статті ми розглядали лише приклади стилів для кнопок і заголовків, WordPress 6.1 підтримує стилі додаткових елементів. Там є таблиця з їх описом «Визначення стилів за допомогою елементів JSON» .

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

Обов'язково віддайте кожному theme.json файл добре виглядати, оскільки ці теми включають чудові приклади стилю блокового рівня на styles.blocks об'єкт

Підводячи підсумок

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

Щодо а Пропозиція GitHub змінити дизайн редактора сайту в новому режимі браузера, Сара Гудінг пише у дописі WP Tavern:

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

Навіть будучи завзятим учасником світу редактора блоків Гутенберга та тем блокового ока, у мене є маса власних розчарувань. Проте я налаштований оптимістично і очікую, що після завершення редактор сайту стане революційним інструментом як для користувачів, так і для технічно підкованих розробників тем. Це обнадійливий твіт вже це підтверджує. Тим часом, схоже, нам слід готуватися до нових змін і, можливо, навіть до нерівної їзди.

посилання

Я перелічую всі ресурси, які використовував під час пошуку інформації для цієї статті.

Елементи JSON

Глобальні стилі

Двигун стилю

Дякуємо за читання! Мені хотілося б почути ваші власні міркування щодо використання блокових тем і того, як ви керуєте своїм CSS.