La façon dont nous écrivons le CSS pour les thèmes WordPress est en pleine mutation. J'ai récemment partagé une technique pour ajout de la prise en charge du type de fluide dans WordPress à titre d' theme.json, un nouveau fichier qui WordPress a poussé fort pour devenir une source centrale de vérité pour la définition des styles dans les thèmes WordPress qui prennent en charge les fonctionnalités d'édition de site complet (FSE).

Attends, non style.css dossier? Nous avons encore cela. En réalité, style.css is encore un fichier requis dans les thèmes de bloc, bien que son rôle soit fortement réduit aux méta-informations utilisées pour enregistrer le thème. Cela dit, le fait est que theme.json est toujours en développement actif, ce qui signifie que nous sommes dans une période de transition où vous pourriez trouver des styles définis là-bas, dans styles.css ou même au niveau du bloc.

Alors, à quoi ressemble réellement le style en ces jours WordPress FSE ? C'est ce que je veux couvrir dans cet article. Il y a un manque de documentation pour styliser les thèmes de bloc dans le Manuel du développeur de thèmes WordPress, donc tout ce que nous couvrons ici est ce que j'ai recueilli sur l'état actuel des choses ainsi que sur les discussions sur l'avenir des thèmes WordPress.

L'évolution des styles WordPress

Les nouvelles fonctionnalités de développement incluses dans WordPress 6.1 nous rapprochent d'un système de styles complètement défini dans theme.json, mais il reste encore beaucoup de travail à faire avant de pouvoir s'y appuyer pleinement. Une façon d'avoir une idée de ce qui arrivera dans les futures versions est d'utiliser le Plugin Gutenberg. C'est là que les fonctionnalités expérimentales sont souvent mises à l'essai.

Une autre façon de se faire une idée de l'endroit où nous en sommes est d'examiner l'évolution de thèmes WordPress par défaut. À ce jour, il existe trois thèmes par défaut qui prennent en charge l'édition complète du site :

Mais ne commencez pas à échanger le CSS style.css pour les paires propriété-valeur JSON dans theme.json à l'instant. Il existe encore des règles de style CSS qui doivent être prises en charge dans theme.json avant de penser à le faire. Les questions importantes restantes sont actuellement en cours de discussion dans le but de déplacer entièrement toutes les règles de style CSS dans theme.json et regrouper différentes sources de theme.json en Interface utilisateur pour définir des styles globaux directement dans le Éditeur de sites WordPress.

Cela nous laisse dans une situation relativement difficile. Non seulement il y a pas de chemin clair pour remplacer les styles de thème, mais on ne sait pas d'où vient même la source de ces styles - est-ce de différentes couches de theme.json fichiers, style.css, le plugin Gutenberg, ou ailleurs ?

Constat theme.json au lieu de style.css?

Vous vous demandez peut-être pourquoi WordPress s'oriente vers une définition des styles basée sur JSON au lieu d'un fichier CSS traditionnel. Ben Dwyer de l'équipe de développement de Gutenberg explique avec éloquence pourquoi le theme.json l'approche est un avantage pour les développeurs de thèmes.

Cela vaut la peine de lire le post de Ben, mais la viande est dans cette citation :

Remplacer le CSS, qu'il s'agisse de styles de mise en page, de préréglages ou de blocs, présente un obstacle à l'intégration et à l'interopérabilité : la parité visuelle entre l'interface et l'éditeur devient plus difficile à maintenir, les mises à niveau pour bloquer les éléments internes peuvent entrer en conflit avec les remplacements. Le CSS personnalisé est, en outre, moins portable sur d'autres thèmes de blocs.

En encourageant les auteurs de thèmes à utiliser theme.json API dans la mesure du possible, la hiérarchie des styles définis "base> thème> utilisateur" peut être résolue correctement.

L'un des principaux avantages du déplacement de CSS vers JSON est que JSON est un format lisible par machine, ce qui signifie qu'il peut être exposé dans l'interface utilisateur de WordPress Site Editor en récupérant une API, permettant ainsi aux utilisateurs de modifier les valeurs par défaut et de personnaliser l'apparence d'un site sans écrire n'importe quel CSS. Il fournit également un moyen de styliser les blocs de manière cohérente, tout en fournissant une structure qui crée des couches de spécificité de sorte que les paramètres de l'utilisateur aient la priorité la plus élevée sur ceux définis dans theme.json. Cette interaction entre les styles au niveau du thème dans theme.json et les styles définis par l'utilisateur dans l'interface utilisateur des styles globaux sont ce qui rend l'approche JSON si attrayante.

Les développeurs maintiennent la cohérence dans JSON et les utilisateurs gagnent en flexibilité grâce aux personnalisations sans code. C'est un gagnant-gagnant.

Il y a bien sûr d'autres avantages, et Mike McAlister de WP Engine en énumère plusieurs dans ce fil Twitter. Vous pouvez trouver encore plus d'avantages dans ce discussion approfondie sur le blog Make WordPress Core. Et une fois que vous avez lu cela, comparez les avantages de l'approche JSON avec les moyens disponibles pour définir et remplacer les styles dans les thèmes classiques.

Définir des styles avec des éléments JSON

Nous avons déjà vu beaucoup de progrès en ce qui concerne les parties d'un thème theme.json est capable de coiffer. Avant WordPress 6.1, tout ce que nous pouvions vraiment faire était de styliser les en-têtes et les liens. Maintenant, avec WordPress 6.1, nous pouvons ajouter des boutons, des légendes, des citations et des titres au mix.

Et nous le faisons en définissant Éléments JSON. Considérez les éléments comme des composants individuels qui vivent dans un bloc WordPress. Supposons que nous ayons un bloc contenant un titre, un paragraphe et un bouton. Ces pièces individuelles sont des éléments, et il y a un elements objet dans theme.json où nous définissons leurs styles :

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

Une meilleure façon de décrire les éléments JSON consiste à utiliser des composants de bas niveau pour les thèmes et les blocs qui n'ont pas besoin de la complexité des blocs. Ce sont des représentations de primitives HTML qui ne sont pas définis dans un bloc mais qui peuvent être utilisés dans plusieurs blocs. La manière dont ils sont pris en charge dans WordPress (et le plugin Gutenberg) est décrite dans le Manuel de l'éditeur de blocs et cette Tutoriel d'édition de site complet par Caroline Nymark.

Par exemple, les liens sont stylisés dans le elements objet mais ne constituent pas un bloc à part entière. Mais un lien peut être utilisé dans un bloc et il héritera des styles définis sur le elements.link objet dans theme.json. Cependant, cela n'encapsule pas complètement la définition d'un élément, car certains éléments sont également enregistrés en tant que blocs, tels que les blocs Heading et Button - mais ces blocs peuvent toujours être utilisés dans d'autres blocs.

Voici un tableau des éléments qui sont actuellement disponibles pour le style dans theme.json, courtoisie de Caroline:

Comme vous pouvez le voir, il est encore tôt et il reste encore beaucoup à faire pour passer du plugin Gutenberg à WordPress Core. Mais vous pouvez voir à quel point il serait rapide de faire quelque chose comme styliser globalement tous les titres d'un thème sans rechercher de sélecteurs dans les fichiers CSS ou DevTools.

De plus, vous pouvez également commencer à voir comment la structure de theme.json forme en quelque sorte des couches de spécificité, partant d'éléments globaux (ex. headings) à des éléments individuels (par exemple h1) et les styles au niveau du bloc (par exemple h1 contenu dans un bloc).

Des informations supplémentaires sur les éléments JSON sont disponibles dans cette Faire une proposition WordPress ainsi que ce billet ouvert dans le référentiel GitHub du plugin Gutenberg.

Spécificité JSON et CSS

Continuons à parler de spécificité CSS. J'ai mentionné plus tôt que l'approche JSON du style établit une hiérarchie. Et c'est vrai. Styles définis sur les éléments JSON dans theme.json sont considérés comme des styles de thème par défaut. Et tout ce qui est défini par l'utilisateur dans l'interface utilisateur des styles globaux remplacera les valeurs par défaut.

En d'autres termes: les styles utilisateur sont plus spécifiques que les styles de thème par défaut. Jetons un coup d'œil au bloc Button pour avoir une idée de son fonctionnement.

j'utilise Thème vide, un thème WordPress vierge sans style CSS. Je vais ajouter un bloc Button sur une nouvelle page.

OK, nous savons que WordPress Core est livré avec un style léger. Maintenant, je vais passer au thème TT3 par défaut de WordPress 6.1 et l'activer. Si j'actualise ma page avec le bouton, le bouton change de style.

Vous pouvez voir exactement d'où viennent ces nouveaux styles dans les TT3 theme.json dossier. Cela nous indique que les styles d'éléments JSON ont priorité sur les styles WordPress Core.

Maintenant, je vais modifier TT3 en le remplaçant par un theme.json fichier dans un thème enfant, où la couleur d'arrière-plan par défaut du bloc Bouton est définie sur rouge.

Mais remarquez le bouton de recherche dans cette dernière capture d'écran. Ça devrait être rouge aussi, non ? Cela doit signifier qu'il est stylisé à un autre niveau si le changement que j'ai apporté est au niveau global. Si nous voulons changer tous les deux boutons, nous pourrions le faire au niveau de l'utilisateur en utilisant l'interface utilisateur des styles globaux dans l'éditeur de site.

Nous avons changé la couleur d'arrière-plan des deux boutons en bleu et modifié le texte à l'aide de l'interface utilisateur des styles globaux. Remarquez que le bleu à partir de là a pris le pas sur les styles de thèmes !

Le moteur de style

C'est une idée très rapide, mais bonne, de la façon dont la spécificité CSS est gérée dans les thèmes de blocs WordPress. Mais ce n'est pas l'image complète parce que ce n'est toujours pas clair De ces styles sont générés. WordPress a ses propres styles par défaut qui viennent de quelque part, consomment les données dans theme.json pour plus de règles de style, et remplace celles avec tout ce qui est défini dans les styles globaux.

Ces styles sont-ils en ligne ? Sont-ils dans une feuille de style séparée ? Peut-être qu'ils sont injectés sur la page dans un ?

C'est ce que le nouveau Moteur de styles va, espérons-le, résoudre. Le moteur de style est une nouvelle API dans WordPress 6.1 qui vise à apporter de la cohérence à la façon dont les styles sont générés et où les styles sont appliqués. En d'autres termes, il prend toutes les sources possibles de style et est seul responsable de la génération correcte des styles de bloc. Je sais je sais. Encore une autre abstraction au-dessus d'autres abstractions juste pour créer des styles. Mais avoir une API centralisée pour les styles est probablement la solution la plus élégante étant donné que les styles peuvent provenir de plusieurs endroits.

Nous n'avons qu'un premier aperçu du moteur de style. En fait, voici ce qui a été réalisé jusqu'à présent, selon le billet:

• Auditez et consolidez où le code génère la prise en charge des blocs CSS dans le back-end afin qu'ils soient livrés à partir du même endroit (par opposition à plusieurs endroits). Cela couvre les règles CSS telles que la marge, le remplissage, la typographie, les couleurs et les bordures.
• Supprimez les styles répétitifs spécifiques à la mise en page et générez des noms de classe sémantiques.
• Réduisez le nombre de balises de style en ligne que nous imprimons sur la page pour la prise en charge des blocs, de la mise en page et des éléments.

Fondamentalement, c'est la base pour établir une API unique qui contient toutes les règles de style CSS pour un thème, d'où qu'elles viennent. Il nettoie la façon dont WordPress injecterait des styles en ligne pré-6.1 et établit un système pour les noms de classe sémantiques.

Vous trouverez plus de détails sur les objectifs à long et à court terme de Style Engine dans ce Faire de WordPress Core une discussion. Vous pouvez également suivre le problème de suivi ainsi que comité de projet pour plus de mises à jour.

Travailler avec des éléments JSON

Nous avons parlé un peu des éléments JSON dans le theme.json file et comment ils sont essentiellement des primitives HTML pour définir des styles par défaut pour des éléments tels que les en-têtes, les boutons et les liens, entre autres. Maintenant, regardons en fait en utilisant un élément JSON et comment il se comporte dans divers contextes de style.

Les éléments JSON ont généralement deux contextes : le niveau mondial et par niveau bloc. Les styles de niveau global sont définis avec moins de spécificité qu'ils ne le sont au niveau du bloc pour garantir que les styles spécifiques au bloc prévalent pour la cohérence partout où des blocs sont utilisés.

Styles globaux pour les éléments JSON

Examinons le nouveau thème TT3 par défaut et examinons le style de ses boutons. Ce qui suit est un copier-coller abrégé du TT3 theme.json fichier (voici le code complet) montrant la section des styles globaux, mais vous pouvez trouver le code original ici.

{
  "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": {}
}

Tous les boutons sont stylés au niveau global (styles.elements.button).

Nous pouvons également le confirmer dans DevTools. Notez qu'une classe appelée .wp-element-button est le sélecteur. La même classe est également utilisée pour styliser les états interactifs.

Encore une fois, ce style se produit au niveau mondial, venant de theme.json. Chaque fois que nous utilisons un bouton, il aura le même arrière-plan car ils partagent le même sélecteur et aucune autre règle de style ne le remplace.

En passant, WordPress 6.1 a ajouté prise en charge du style des états interactifs pour certains éléments, comme les boutons et les liens, en utilisant des pseudo-classes dans theme.json - comprenant :hover, :focuset une :active — ou l'interface utilisateur des styles globaux. Ingénieur automatique Frank J démontre cette fonctionnalité dans une vidéo YouTube.

Nous pourrions remplacer la couleur d'arrière-plan du bouton soit dans theme.json (de préférence dans un thème enfant puisque nous utilisons un thème WordPress par défaut) ou dans les paramètres Styles globaux de l'éditeur de site (pas de thème enfant nécessaire car il ne nécessite pas de changement de code).

Mais alors les boutons changeront tous d'un coup. Que se passe-t-il si nous voulons remplacer la couleur d'arrière-plan lorsque le bouton fait partie d'un certain bloc ? C'est là que les styles au niveau des blocs entrent en jeu.

Styles de niveau bloc pour les éléments

Pour comprendre comment nous pouvons utiliser et personnaliser les styles au niveau du bloc, changeons la couleur d'arrière-plan du bouton contenu dans le bloc de recherche. N'oubliez pas qu'il existe un bloc Bouton, mais ce que nous faisons, c'est remplacer la couleur d'arrière-plan au niveau du bloc du bloc Recherche. De cette façon, nous appliquons uniquement la nouvelle couleur là-bas au lieu de l'appliquer globalement à tous les boutons.

Pour ce faire, nous définissons les styles sur le styles.blocks objet dans theme.json. C'est vrai, si nous définissons les styles globaux pour tous les boutons sur styles.elements, nous pouvons définir les styles spécifiques au bloc pour les éléments de bouton sur styles.block, qui suit une structure similaire :

{
  "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)"
            }
          }
        },
        // ...
      }
    }
  }
}

Regarde ça? j'ai mis le background ainsi que text propriétés sur styles.blocks.core/search.elements.button avec deux variables CSS prédéfinies dans WordPress.

Le résultat? Le bouton de recherche est maintenant rouge (--wp--preset--color--quaternary), et le bloc Bouton par défaut conserve son arrière-plan vert vif.

Nous pouvons également voir le changement dans DevTools.

Il en va de même si nous voulons styliser des boutons inclus dans d'autres blocs. Et les boutons ne sont qu'un exemple, alors regardons-en un autre.

Exemple : styliser les en-têtes à chaque niveau

Ramenons toutes ces informations à la maison avec un exemple. Cette fois, nous allons :

• Stylez tous les titres globalement
• Styliser tous les éléments Titre 2
• Style Heading 2 éléments dans le bloc Query Loop

Commençons d'abord par la structure de base de theme.json:

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

Cela établit les grandes lignes de nos styles globaux et au niveau des blocs.

Stylez tous les titres globalement

Ajoutons le headings objectez à nos styles globaux et appliquez certains styles :

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

Cela définit la couleur de tous les titres sur la couleur de base prédéfinie dans WordPress. Modifions également la couleur et la taille de la police des éléments Heading 2 au niveau global :

{
  "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": { }
  }
}

Désormais, tous les éléments de l'en-tête 2 sont définis pour être la couleur prédéfinie principale avec un taille de police fluide. Mais peut-être que nous voulons un fixe fontSize pour l'élément Heading 2 lorsqu'il est utilisé dans le bloc 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
            }
          }
        }
      }
    }
  }
}

Nous avons maintenant trois niveaux de styles pour les éléments Heading 2 : tous les titres, tous les éléments Heading 2 et Heading 2 éléments qui sont utilisés dans le bloc Query Loop.

Exemples de thèmes existants

Bien que nous n'ayons examiné que les exemples de style pour les boutons et les en-têtes dans cet article, WordPress 6.1 prend en charge le style d'éléments supplémentaires. Il y a un tableau qui les décrit dans le "Définir des styles avec des éléments JSON" .

Vous vous demandez probablement quels éléments JSON prennent en charge quelles propriétés CSS, sans parler de la manière dont vous les déclareriez. En attendant la documentation officielle, les meilleures ressources dont nous disposons seront les theme.json fichiers pour les thèmes existants. Je vais fournir des liens vers des thèmes en fonction des éléments qu'ils personnalisent et indiquer quelles propriétés sont personnalisées.

Assurez-vous de donner à chacun theme.json fichier un bon aperçu car ces thèmes incluent d'excellents exemples de style au niveau du bloc sur le styles.blocks objet.

Emballage en place

Les changements fréquents apportés à l'éditeur du site complet deviennent un principales sources d'irritation pour de nombreuses personnes, dont utilisateurs avertis de Gutenberg. Même les règles CSS très simples, qui fonctionnent bien avec les thèmes classiques, ne semblent pas fonctionner pour les thèmes de blocs à cause du nouvelles couches de spécificité nous avons couvert plus tôt.

Concernant un Proposition GitHub de re-designer l'éditeur du site dans un nouveau mode navigateur, Sara Gooding écrit dans un article de WP Tavern:

Il est facile de se perdre en essayant de contourner l'éditeur de site, sauf si vous travaillez jour et nuit à l'intérieur de l'outil. La navigation est saccadée et déroutante, en particulier lorsque l'on passe de la navigation dans les modèles à l'édition de modèles en passant par la modification de blocs individuels.

Même en tant que passionné de la première heure dans le monde de l'éditeur de blocs Gutenberg et des thèmes block-eye, j'ai des tonnes de mes propres frustrations. Je suis cependant optimiste et je prévois que l'éditeur de site, une fois terminé, sera un outil révolutionnaire pour les utilisateurs et les développeurs de thèmes technophiles. Cette tweet plein d'espoir le confirme déjà. En attendant, il semble que nous devrions nous préparer à d'autres changements, et peut-être même à un parcours cahoteux.

Bibliographie

J'énumère toutes les ressources que j'ai utilisées lors de la recherche d'informations pour cet article.

Éléments JSON

Styles globaux

Moteur de styles

Merci d'avoir lu! J'aimerais entendre vos propres réflexions sur l'utilisation des thèmes de blocs et sur la façon dont vous gérez votre CSS.