Au fur et à mesure que je déboguais les problèmes avec la nouvelle fonctionnalité d’écart de bloc ajoutée dans Gutenberg 11.4 la semaine dernière, j’ai trouvé le billet le présentant. Et, il y avait déjà un nouveau billet pour un problème que j’avais touché. Cependant, il y a eu une discussion sur la question de savoir si les thèmes devraient être autorisés à se retirer, en déployant leur propre solution. Il n’y avait aucun moyen de le faire à l’époque.
C’était comme une évidence, quelque chose auquel je n’aurais pas réfléchi à deux fois. je rapidement a sonné:
Les auteurs de thèmes devraient-ils pouvoir se retirer ? Si jamais c’est une question qui revient, la réponse est toujours : Absolument, 100%, oui !
La partie frontale d’un site est le domaine de l’auteur du thème. En fin de compte, ils définissent comment les choses fonctionnent là-bas. Du moins, c’est comme ça depuis toujours. Avant l’avènement du système de blocs, il y avait des cas où WordPress ajoutait sa propre rotation aux fonctionnalités frontales, telles que les styles pour le shortcode de la galerie et le remplacement de l’image JavaScript emoji. Les thèmes ont toujours eu des méthodes pour les désactiver.
Avec l’introduction du projet Gutenberg et de son ensemble de fonctionnalités évolutives, WordPress continue de se lancer dans la conception frontale. Cela présente l’avantage de standardiser la relation entre la plate-forme, les thèmes et les utilisateurs. Cela rend des choses comme les modèles de blocs universels, et cela continuera à mesure que nous accéderons à des outils de mise en page plus avancés. C’est un avenir dont j’ai hâte d’être témoin car cela facilitera grandement la thématisation.
Cependant, au cours de la discussion sur le ticket, je suis tombé sur l’un des fossés fondamentaux entre certaines personnes travaillant sur Gutenberg et les développeurs tiers :
Je ne suis pas d’accord avec cette prise. Cela signifie que tout devrait être facultatif dans WordPress et va à l’encontre des décisions et non des options. certaines choses doivent être des options mais pas tout… Je ne pense pas que cela devrait être une règle d’avoir une option de retrait pour tout personnellement. Par exemple, pour les styles structurels, je préfère que les thèmes s’appuient toujours sur Core au lieu de réinventer les leurs. Les thèmes sont là pour apporter de la personnalité et du design mais pas pour définir ce que signifie « alignement horizontal » par exemple.
Si une telle position devient l’une des pierres angulaires du développement de thèmes de blocs, elle détournera de nombreux thémes traditionnels.
Je suis d’accord avec le principe selon lequel cela devrait être la base, la façon dont le thème par défaut fonctionne dans WordPress à l’avenir. Plus nous pouvons standardiser de pièces, mieux c’est. Mais, en règle générale, les auteurs de thèmes devraient pouvoir désactiver toute fonctionnalité liée à la conception. Ensuite, nous faisons de rares exceptions à cette règle lorsque le besoin s’en fait sentir.
Indépendamment de ce que font Gutenberg et, finalement, WordPress, les auteurs de thèmes trouveront un moyen de le contourner. Imaginons que « l’alignement horizontal » est défini par CSS flexbox dans le noyau. Je vous garantis que quelqu’un viendra et utilisera la grille CSS.
Dans le cas de la fonctionnalité « block gap » introduite dans Gutenberg 11.4, il s’agit essentiellement d’un nom fantaisiste pour une marge supérieure globale qui s’applique aux blocs (à ne pas confondre avec le CSS réel gap biens). Il s’agit essentiellement d’un système permettant de définir une partie du rythme vertical par défaut.
Cette fonctionnalité est depuis longtemps sur ma liste de souhaits, mais l’idée de la rendre obligatoire ne m’a jamais traversé l’esprit. Si vous voulez assister à une discussion animée, envoyez une poignée de concepteurs de sites Web dans une pièce et demandez-leur de discuter des innombrables façons de gérer l’espacement vertical entre les éléments. Je suis dans le camp des marges supérieures.
Heureusement, les auteurs de thèmes pourront activer ou désactiver la fonction d’écart de bloc. Mais, ce n’est qu’une bataille.
J’avais prévu de répondre par ticket, mais je ne voulais pas m’éloigner trop du sujet. Je voulais aussi réfléchir à l’autre côté. Cependant, je pouvais penser à quelques cas où WordPress devrait toujours être le facteur décisif de la conception frontale.
À partir de cette position, j’envisage un peu plus que des auteurs de thèmes créant des solutions de contournement pour ce qu’ils verront comme un système défectueux. Il n’y a rien de mal à ce que WordPress définisse les valeurs par défaut. Cependant, cela devrait toujours être de l’état d’esprit que les développeurs voudront s’aventurer. La meilleure façon de les garder heureux est de ne pas les gêner. Construire un système qu’ils vouloir à utiliser, pas qu’ils doit utilisation. Et, pour ceux qui décident d’emprunter une voie différente, facilitez-vous la tâche. Même si nous pensons que ces concepteurs rebelles créent une expérience utilisateur cassée, ce n’est pas grave. C’est leur projet de faire ou de casser.
Ce qui rend WordPress si unique à WordPress, c’est que la plate-forme a toujours répondu à ceux qui souhaitent l’étendre de n’importe quelle manière imaginable. S’il commence à créer des pierres d’achoppement qui n’ont pas besoin d’être là, nous avons fait un mauvais travail en tant que gardiens du logiciel.
Source link