Le chef du projet Gutenberg, Matías Ventura, a annoncé la Route préliminaire à 5.9 sur le blog Make Core plus tôt dans la journée. Il a couvert plusieurs grande image éléments, y compris plusieurs sous-points pour chacun. Il est également lié à un Problème GitHub avec des tâches et des tickets spécifiques qui nécessitent du travail.
L’article couvre des notes sur les modèles de blocs, les menus de navigation, le theme.json l’interface (styles globaux), les outils de conception et les flux d’édition pour les thèmes de bloc. Il y a beaucoup d’informations à prendre et suffisamment de domaines pour couvrir divers intérêts.
L’objectif le plus passionnant de 5.9 pourrait simplement être d’approfondir la conception réactive au niveau du bloc, qu’il s’agisse de code sous le capot ou d’options de bloc disponibles via l’interface utilisateur.
« L’un des plus gros points de friction pour les créateurs de motifs et de thèmes est le manque d’outils réactifs disponibles au niveau du bloc », a écrit Ventura. « Cela doit être résolu d’une manière qui n’augmente pas de manière disproportionnée la complexité de l’interface. »
Conception Web intrinsèque avec des blocs
Il est facile d’être mécontent de la lenteur des progrès vers les options de blocs réactifs au cours des dernières années. Je n’en suis pas entièrement mécontent car je veux que l’équipe soit méthodique et aborde cela de manière pérenne, du moins dans la mesure où elle le peut.
Bien trop souvent, ce que nous avons vu avec les requêtes et même les plugins tiers, c’est l’utilisation de requêtes multimédias basées sur des fenêtres pour contrôler la façon dont les blocs répondent à différents appareils (par exemple, ordinateur de bureau, tablette et mobile). Bien que ces contrôles puissent parfois être le bon outil pour le travail, ils ne sont pas toujours le bon chemin pour la conception basée sur les composants.
Les requêtes médiatiques ont tendance à favoriser les méthodologies de conception holistiques. Cependant, la conception basée sur les composants est le visage moderne du Web. Les blocs ne sont qu’un autre composant, et parce que les développeurs ou même les utilisateurs peuvent les placer n’importe où dans la conception globale, nous devons aborder la façon dont ils réagissent à leur environnement plus que la fenêtre du navigateur.
« Le modèle de bloc est un bon cas pour appliquer certains principes de conception intrinsèques, car un bloc peut occuper une place dans de nombreuses mises en page et conteneurs différents, pour lesquels les requêtes de médias prescriptives qui ne tiennent pas compte du contexte sont inflexibles », a écrit Ventura.
Un exemple simple à regarder est le bloc principal des colonnes WordPress. Nous pourrions facilement ajouter des options de requête multimédia lorsque chaque bloc de colonne interne se rompt. Cependant, comment la typographie devrait-elle répondre pour trois colonnes contre quatre et à des largeurs différentes ? C’est une fonction de la taille du conteneur plutôt que de la fenêtre d’affichage.
Et comment fonctionnent de telles requêtes multimédias lorsque les colonnes sont imbriquées dans une autre colonne ? Cela devient un problème plus complexe à résoudre si vous mettez les contrôles de mise en page entre les mains des utilisateurs. Appuyer sur le bouton d’avance rapide sur les options de bloc réactif peut sembler bien pour le moment, mais cela pourrait également créer un bagage hérité qui sera difficile à déposer lorsqu’une meilleure solution sera disponible.
Même quelque chose d’aussi simple qu’un en-tête de site Web de base peut devenir complexe lors de la conception pour la saisie de l’utilisateur. Pour les concepteurs de thèmes, il n’y a aucun moyen de savoir combien de caractères se trouvent dans le titre du site, par exemple, ou combien d’éléments se trouvent dans le menu de navigation. Le système de blocage peut compliquer encore plus la situation en permettant aux utilisateurs finaux de laisser tomber d’autres inconnues.
« Chaque zone de bloc doit être intrinsèquement réactive, permettant aux blocs de se composer, de s’envelopper, de s’empiler et de s’organiser pour s’adapter aux différents espaces et écrans », a écrit Ventura. « Pour que cela fonctionne bien, les blocs de conteneurs doivent absorber plus de contrôles de mise en page. »
Il a également mentionné requêtes de conteneur comme point d’extension possible lorsqu’ils seront entièrement pris en charge par les navigateurs à l’avenir. Chrome Canary dispose actuellement d’un indicateur de prise en charge pour activer la fonctionnalité.
Les requêtes de conteneurs sont un peu un Saint Graal pour les concepteurs. En tant que web designer Ethan Marcotte écrivait il y a quatre ans :
Je vais peut-être commencer ici : ces dernières années, mon travail de conception s’est beaucoup plus concentré sur les motifs et moins sur les « pages ». Au lieu de traiter une conception réactive comme une chose holistique et unifiée, où chaque partie de la mise en page change et s’adapte au même rythme, il est plus utile de diviser une mise en page réactive en morceaux de conception plus petits et réutilisables, y compris des choses comme « masthead, » « pied de page », « légende de l’image », etc.
En d’autres termes, mon processus de conception consiste à considérer une conception réactive comme un réseau de petits systèmes de mise en page. Chacun de ces composants sont fondamentalement de petits designs réactifs eux-mêmes, avec leurs propres ensembles de points d’arrêt.
Semble familier? Oui, le système de blocs WordPress est construit sur la même base de petits composants de mise en page.
Tout ce que WordPress fait aujourd’hui au niveau de l’interface utilisateur doit tenir compte des requêtes de conteneur du futur. Ou, au moins, utilisez des outils existants qui pourraient reproduire la fonctionnalité d’une certaine manière, comme le min(), max(), et clamp() Fonctions CSS.
Le problème est de déterminer quelles fonctionnalités doivent être exposées en tant qu’options de bloc plutôt que d’être traitées sous le capot. L’équipe de développement doit trouver un équilibre entre l’expérience utilisateur et la flexibilité pour les concepteurs. Certaines choses devraient « fonctionner » immédiatement, et d’autres devraient être configurables au cas par cas.
Cela devrait être l’un des problèmes les plus intéressants, complexes, frustrants et gratifiants à résoudre dans le cycle WordPress 5.9. Pour ceux qui recherchent un défi, ce pourrait être le point d’entrée parfait.
Source link