Responsive-стилі та псевдостани в theme.json: практичний гайд для WordPress 7.1

WordPress 7.1 додав responsive-стилі для блоків і стандартизовані псевдостани в Global Styles та theme.json. Це важлива зміна для розробників блокових тем: частину адаптивної логіки, яку раніше доводилося підтримувати в окремому CSS, тепер можна описати в системі стилів WordPress.

Нижче розберемо, як працюють @mobile, @tablet, :hover, :focus і :focus-visible, де проходять межі нової API та як впроваджувати її без хаосу в уже готовій темі.

Що змінилося у WordPress 7.1

Responsive-стилі можна задавати на трьох рівнях:

• у theme.json для всіх блоків певного типу;
• у Global Styles через інтерфейс редактора;
• для окремого екземпляра блока через його атрибут style.

Базовий стиль працює як desktop-версія. Значення в @tablet і @mobile перевизначають лише потрібні властивості. Якщо мобільний стан не задає, наприклад, колір, блок продовжує використовувати базовий колір.

Функція працює з блоками, які використовують стандартні block supports: типографіку, колір, фон, межі, розміри, відступи й layout. Деталі описані в офіційній нотатці Responsive block styles and configurable viewports in WordPress 7.1.

Базовий приклад responsive-стилів

Нехай Group block має великі відступи на широкому екрані та компактні — на смартфоні:

{
  "version": 3,
  "styles": {
    "blocks": {
      "core/group": {
        "spacing": {
          "padding": {
            "top": "3rem",
            "right": "3rem",
            "bottom": "3rem",
            "left": "3rem"
          }
        },
        "@mobile": {
          "spacing": {
            "padding": {
              "top": "1rem",
              "right": "1rem",
              "bottom": "1rem",
              "left": "1rem"
            }
          }
        }
      }
    }
  }
}

WordPress генерує media-query і стабільний клас для блока. Не потрібно дублювати селектор у style.css або вручну синхронізувати його з редактором.

Налаштування breakpoint-ів

За замовчуванням WordPress використовує:

• @mobile: ширина до 480px;
• @tablet: ширина від 480px до 782px.

У темі можна задати власні значення через top-level властивість settings.viewport:

{
  "version": 3,
  "settings": {
    "viewport": {
      "mobile": "30rem",
      "tablet": "45rem"
    }
  }
}

Підтримуються невід’ємні числові значення в px, em і rem. Відсотки, CSS-функції та значення без одиниць ігноруються. Окремого ключа @desktop немає: desktop — це базовий стиль.

Псевдостани без окремого CSS

WordPress 7.1 дозволяє описувати :hover, :focus, :focus-visible і :active безпосередньо в об’єкті блока. На старті інтерфейс редагування цих станів доступний для Button і Navigation Link.

{
  "styles": {
    "blocks": {
      "core/button": {
        "color": {
          "background": "var:preset|color|contrast",
          "text": "var:preset|color|base"
        },
        ":hover": {
          "color": {
            "background": "var:preset|color|accent-2"
          }
        },
        ":focus-visible": {
          "border": {
            "color": "var:preset|color|accent-1",
            "width": "2px"
          }
        }
      }
    }
  }
}

Псевдостан можна вкладати всередину responsive-стану. Наприклад, мобільний hover може мати іншу контрастність, ніж базовий:

"core/button": {
  "@mobile": {
    ":hover": {
      "color": {
        "background": "var:preset|color|contrast",
        "text": "var:preset|color|base"
      }
    }
  }
}

Повна модель псевдо- й custom states описана в офіційній Dev Note для WordPress 7.1.

Поточний пункт меню через custom state

Для Navigation Link з’явився custom state -current. Він відповідає посиланню поточної сторінки та може містити вкладений hover:

"core/navigation-link": {
  "-current": {
    "color": {
      "text": "var:preset|color|contrast"
    },
    ":hover": {
      "color": {
        "text": "var:preset|color|accent-1"
      }
    }
  }
}

Це прибирає частину специфічного CSS для .current-menu-item і робить стан частиною дизайн-системи теми.

Коли варто обмежити інтерфейс

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

add_filter( 'block_editor_settings_all', function ( $settings ) {
    $settings['blockStatesEditingEnabled'] = false;
    $settings['responsiveEditingEnabled']  = false;
    return $settings;
} );

Цей фільтр лише прибирає елементи керування з UI. Стилі з theme.json, Global Styles і атрибутів блоків продовжують працювати.

Практичний процес впровадження

1. Зробіть аудит CSS. Знайдіть media queries для типографіки, spacing, layout і станів кнопок.
2. Переносьте тільки системні правила. Унікальні складні компоненти не обов’язково виграють від міграції в theme.json.
3. Визначте breakpoint-и один раз. Не копіюйте різні значення між CSS, JavaScript і JSON.
4. Тестуйте editor і frontend. Обидва середовища мають показувати однакову ієрархію відступів і станів.
5. Перевірте клавіатурну навігацію. Hover без виразного :focus-visible погіршує доступність.
6. Перевірте схему. Після релізу WordPress 7.1 частина schema-валідації responsive і pseudo states уточнювалася в Gutenberg 23.8.

Типові помилки

• намагатися створити @desktop замість базового стилю;
• використовувати відсотки або calc() у settings.viewport;
• міняти hover, але забувати про focus і focus-visible;
• дублювати однакове правило в CSS і theme.json;
• давати редакторам повний доступ до states без редакційних обмежень;
• тестувати тільки device preview, а не реальний браузер і сенсорний пристрій.

Висновок

Responsive- і pseudo-state API у WordPress 7.1 не скасовує CSS, але переносить типові дизайн-рішення в єдину систему. Для блокових тем це означає менше дублювання, кращу відповідність редактора фронтенду й зрозуміліші правила для команди. Починайте з spacing, typography та кнопок — саме там ефект помітний найшвидше.

Матеріал актуальний станом на 24 вересня 2026 року.