Gutenberg: Ajouter un bloc: section

J'aime vraiment cette idée! J'aime aussi le fait qu'il ait un paramètre d'arrière-plan.

Agréable! Et si le bloc autorisait les trois paramètres `` avancés '' suivants:

• Définissez un nom de classe à sérialiser sur les enfants .child_class, .child_class_1
• Ajouter une première classe enfant facultative .child_class, .child_class_1, .child_class_first
• Ajouter une dernière classe enfant facultative .child_class, .child_class_n, .child_class_last

:nth-child sélecteurs

J'adore cette idée. Si les couleurs d'arrière-plan et de texte peuvent être modifiées, il peut être judicieux d'ajouter également des couleurs de lien.

Excellente idée. Cela ajoutera littéralement beaucoup de valeur à l'éditeur Gutenberg.

Bien mieux que le bloc Colonnes, qui pose de nombreux problèmes. Cool!

C'est la première chose que j'ai entrepris de créer lorsque j'ai vu que l'imbrication était disponible. Ma version est similaire, sauf que j'ai envisagé d'ajouter le bloc de colonnes.

Avez-vous un code pour cela disponible?

Si ce bloc a des "colonnes", nous devons simplement mettre à jour le bloc "colonnes". Mais il est toujours possible d'utiliser un bloc de colonnes à l'intérieur d'un bloc de section et de garder le bloc de section sans colonne.

Tant que vous ne pouvez pas mettre de blocs de colonnes à l'intérieur de blocs de colonnes 😉

De nombreuses pages de site sont divisées en sections qui ont un contenu mixte avec plusieurs lignes de colonnes et souvent des colonnes imbriquées dans des plus grandes. Voici un exemple rapide:

Un bloc de section qui agit juste comme un wrapper nu, je pense, serait le plus flexible. (tout comme la possibilité d'imbriquer des blocs de colonnes!)

Nous avons lancé un nouveau projet de site cette semaine. Normalement, il serait construit avec des mises en page de contenu flexibles avec Advanced Custom Fields, mais je vais voir jusqu'où nous pouvons aller en utilisant Gutenberg seul.

Ouais, je pense que les sections multi-colonnes comme l'exemple ci-dessus de @jvisick ne sont pas rares. Un conteneur avec des options d'arrière-plan / texte qui imbrique les blocs serait l'approche la plus flexible. Puisque nous avons maintenant un bloc de colonnes fonctionnel, nous pourrions même envisager de supprimer l'option de colonne de celui-ci.

Ce serait génial s'il y a un conteneur interne (div) dans ce bloc qui contient alors tous les blocs enfants. Ce conteneur pourrait alors être stylisé avec max-width et margin-left / right: auto pour centrer les blocs enfants et avoir un arrière-plan pleine largeur.

Avoir une section pleine largeur avec le contenu contenu dans une mise en page plus étroite est un modèle de conception courant. Je me demande s'il serait mieux contrôlé par les blocs imbriqués plutôt que cuit dans le bloc de section parent?

Je pense qu'un bloc de section serait très utile pour ... eh bien, des sections sur une page, et je suis d'accord que les colonnes devraient être un bloc séparé (comme celui qui existe maintenant) qui peut être imbriqué dans un bloc de section. Je pense que c'est quelque chose qui, avec le bloc Colonnes, devrait être inclus dans la version de Gutenberg qui est fusionnée dans WordPress 5.0. Si vous regardez les plugins de création de pages existants, les sections sont beaucoup utilisées, tout comme les colonnes (évidemment), donc les inclure dans la version initiale de base est essentiel à mon avis.

(Je pense également qu'il est important que le bloc de colonnes obtienne des fonctionnalités telles que des colonnes à largeur variable et des colonnes réactives, à la fois pour le bien de l'expérience de base et pour permettre aux constructeurs de pages existants de se recentrer sur Gutenberg, mais c'est une question distincte.)

Après y avoir réfléchi un peu plus, je pense qu'il serait plus logique que le bloc Section et Colonnes soit la même chose. Ajoutez simplement la possibilité d'avoir une seule colonne dans le bloc Colonnes au lieu d'un minimum de deux. Ajoutez ensuite les paramètres d'arrière-plan de ce bloc Section proposé au bloc Colonnes.

Je pense qu'avoir un seul bloc Section / Colonnes réduirait la quantité d'imbrication que vous auriez à faire. Pour le moment, le bloc Section proposé n'est en réalité rien de plus qu'une zone avec un arrière-plan et des options de largeur. Ces deux éléments pourraient être ajoutés au bloc Colonnes, et si le bloc Colonnes permettait de n'avoir qu'une seule colonne, il n'y aurait pas besoin d'un bloc Section.

En outre, si vous voulez une section pleine largeur avec un contenu de largeur standard, cela peut être accompli en imbriquant un autre bloc Section / Colonnes dans un autre qui est défini sur pleine largeur. Cela pourrait être fait avec un paramètre dans l'inspecteur pour changer la largeur du contenu du bloc indépendamment de la largeur du bloc entier. cela pourrait également être ajouté en tant que poignées de redimensionnement visibles, comme le fonctionnement des lignes / colonnes de Beaver Builder ou du fonctionnement du bloc Image dans Gutenberg.

Quant à ce que vous appelleriez ce bloc combiné, je pense que le simple fait de conserver le nom "Colonnes" fonctionne, car c'est la fonction la plus évidente que les gens recherchent. Il ne devrait pas être difficile de trouver les paramètres d'arrière-plan dans l'inspecteur (et j'imagine que ce serait là que certaines personnes regarderaient en premier lieu de toute façon s'il y avait un bloc de section séparé et qu'ils n'en étaient pas conscients), et en utilisant les colonnes block en tant que conteneur à une seule colonne ne devrait pas être difficile à découvrir car le curseur pour changer le nombre de colonnes devrait rendre assez évident comment le faire ... faites-le simplement glisser complètement vers la gauche.

J'ai changé d'avis sur la fusion des blocs Section et Colonnes. Afin d'obtenir le plus de flexibilité avec les colonnes, il serait plus judicieux que chaque colonne soit son propre bloc: un bloc Colonne. Cela permettrait de contrôler facilement les paramètres d'une colonne individuelle, ainsi que de faire glisser une colonne d'une ligne à une autre. Bien sûr, puisque les colonnes vont de gauche à droite (et s'enroulent dans la plupart des systèmes de mise en page), vous auriez besoin que leur bloc parent soit celui qui insère le contenu dans cette direction horizontale et a un wrapping (plutôt que la direction verticale standard) et ceci Le bloc parent ne permettrait probablement que des blocs de colonne à y être insérés. Ce bloc serait une ligne. Ces 2 blocs remplaceraient le bloc Colonnes. Mais ils ne couvrent pas la situation où vous voulez que plusieurs lignes (souvent avec différents nombres de colonnes à l'intérieur) soient dans le même arrière-plan / conteneur, ce que ferait le bloc Section. Bien sûr, le bloc Section ne serait rien de plus qu'un conteneur avec des options d'arrière-plan, de remplissage et de largeur, et n'importe quel bloc pourrait y être inséré. Et pour les mises en page plus complexes, des blocs de section peuvent être insérés dans des blocs de colonne.

Voir # 6461.

Je pense en fait que l'idée d'une colonne au minimum n'est pas une mauvaise solution. En fait, si vous utilisez votre inspecteur pour changer l'attribut "min" du curseur sur 1 et en sélectionner un, cela fonctionne à peu près comme vous vous en doutez.

Cependant, sémantiquement, un bloc de section a de toute façon plus de sens. Le contenu interne (c'est-à-dire une section de largeur maximale dans un plein avec section) pourrait être obtenu en imbriquant deux sections - une largeur de contenu à l'intérieur d'une pleine largeur.

L'idée de la couleur de fond est sympa, mais ... peut-être un peu plus spécifique. Je pense qu'une approche plus générique consisterait simplement à utiliser des classes personnalisées sur la section. Le CSS frontal pourrait attraper cela et tous les enfants directement.

Après quelques discussions dans # 6461, j'ai décidé que mon idée de bloc de lignes + de bloc de colonnes n'était pas la bonne voie à suivre. Un bloc de mise en page similaire à celui de # 5351 (commentaire) serait probablement beaucoup moins déroutant et beaucoup plus flexible. Quoi qu'il en soit, il devrait certainement y avoir un bloc Section, et je pense qu'il devrait certainement être ajouté avant la sortie de WordPress 5.0.

En ce qui concerne les options de couleur d'arrière-plan, je pense qu'il est parfaitement logique d'avoir des options d'arrière-plan sur une section. Le fait de n'avoir que des options de classe semble un peu restrictif. Souvent, tout l'intérêt de l'imbrication dans un bloc de section serait de faire partager un arrière-plan à plusieurs éléments. De plus, je préférerais que d'autres options d'arrière-plan telles que les images d'arrière-plan et les arrière-plans dégradés soient implémentées, car elles sont souvent souhaitées au lieu d'arrière-plans de couleur unie. Les blocs de section imbriqués permettraient même d'appliquer des couleurs d'arrière-plan à un seul bloc, ce qui signifie que les options de couleur d'arrière-plan dans le bloc de paragraphe peuvent ne plus être nécessaires.

En ce qui concerne l'imbrication des blocs de section au lieu d'avoir 2 paramètres de largeur séparés, je pense que cela pourrait fonctionner. La plus grande préoccupation que j'aurais concerne la quantité de rembourrage supplémentaire qui serait ajouté en imbriquant des blocs de section, ce qui conduit à des options de remplissage.

Je pense qu'il est essentiel que le bloc Section ait la possibilité de personnaliser la quantité de remplissage qu'il utilise, ou du moins de supprimer le remplissage par défaut. Bien sûr, cela soulève des questions sur la manière dont vous sélectionneriez le bloc Section lorsqu'un autre bloc y est imbriqué. Je pense que ce problème sera résolu par des améliorations telles que # 6471 et les choses en cours de travail dans la branche try/alternate-hover-approach .

: +1:

Nous avons vraiment besoin d'un bloc de ligne / conteneur générique, en particulier avec des paramètres de largeur.

Idéalement, je pense que d'autres paramètres comme "Couleur d'arrière-plan" et "Couleur du texte" devraient vivre sous certains onglets de paramètres "supplémentaires" sur chaque bloc (en plus de plusieurs autres paramètres CSS généralement applicables).

En ce qui concerne la réactivité, je pense que nous devrions ajouter un bloc "Responsive" .

Le problème avec la couleur d'arrière-plan et la couleur du texte est simplement: où se termine-t-il? Déjà dans ce fil, vous avez quelqu'un qui suggère la couleur du lien. Pourquoi pas la couleur, l'épaisseur et le style des bordures? Le rembourrage et la marge ont le plus de sens, pour être honnête. Qu'en est-il des ombres portées, des images d'arrière-plan, des options de positionnement et des modes d'affichage? Style et taille de police, hauteur de ligne et hauteur minimale? Il existe des centaines de propriétés CSS et celles dont vous avez besoin varient en fonction de votre conception.

Il doit s'agir soit d'une classe, que vous pouvez ensuite utiliser pour styliser tout ce qui comprend des éléments descendants, soit d'une liste filtrable de propriétés CSS afin que le div de thème puisse se connecter et ajouter ceux qu'il ou elle veut.

@tmdesigned Il se termine par un contrôle WYSYWIG intuitif et complet sur le style, le formatage et la mise en page d'une page Web. N'est-ce pas le but de Gutenberg?

Gutenberg fournit au monde un contenu Web WYSYWIG frais, bien planifié, de pointe, modélisé et extensible ... nous devrions déterminer à quel point nous voulons l'utiliser maintenant, sinon nous allons rater le bateau.

L'idée en fin de compte est de réduire la quantité de travail que nous faisons maintenant, qu'il s'agisse d'écrire du CSS, d'écrire des remplacements de CSS hacky ou de faire des tâches de contenu répétitives.

Tout ne peut pas ou ne doit pas être défini avec des classes, surtout si ce sont des classes mal ciblées ou des attributs non remplaçables.

Prenons par exemple un paramètre numérique défini par l'utilisateur. Ce serait pénible de définir une classe pour chaque valeur et un développeur de bloc pourrait être tenté de simplement injecter la valeur directement dans l'attribut style .

S'il existe en tant que bloc et qu'il peut avoir des styles CSS définis par l'utilisateur, alors il devrait idéalement y avoir un moyen unifié et normalisé pour le faire, même s'il s'agit d'un panneau de zones de texte de paires clé / valeur.

Si vous le souhaitez, vous pouvez lire ma méthode suggérée pour le faire d'une manière qui répond à vos préoccupations.

J'ai lu votre suggestion pour une API et ce n'est pas loin de ce que je disais à propos d'un hook ajouté pour permettre l'ajout de paires valeur / clé.

Cependant, je pense que mon point initial est toujours valable. Comme je l'ai dit, il existe des centaines de propriétés et bien que certaines soient plus courantes, une telle liste va s'allonger rapidement. Nous pouvons emprunter cette voie et essayer de trouver un «bon compromis» comme avec les fonctionnalités TinyMCE qui ont été incluses ou supprimées dans Classic. Mais il y a beaucoup plus de propriétés en jeu ici, donc ce serait un défi.

Mais plus important encore, l'idée d'ajouter un style direct au niveau du bloc se décompose lorsque vous effectuez un zoom arrière et ne considérez pas qu'un seul bloc. Lorsque vous avez plusieurs blocs similaires, sur une page ou sur plusieurs pages, vous ne voudrez pas ressaisir toutes ces valeurs. Vous allez vouloir une abstraction ... comme une classe CSS.

Autoriser - ou encourager - le style de niveau de bloc individuel n'est pas idéal car il n'est pas réutilisable. Vous avez raison de dire que tout ne devrait pas être résumé dans une classe, mais CSS a été développé pour une raison et ne devrait pas être jeté au vent si rapidement.

@tmdesigned J'apprécie vos commentaires. Je pense que je comprends la confusion, alors je vais essayer de clarifier.

Le but n'est pas d'éliminer ou même de réduire le nombre de classes CSS.

L'objectif est, très précisément, d'unifier les paramètres de style de bloc

Les développeurs Web, les développeurs de blocs, les développeurs de thèmes continueront tous à écrire du code CSS dans des blocs de style et les blocs auront toujours des classes, des attributs et des ID afin que les développeurs puissent les styliser.

Ils auront exactement les mêmes classes que maintenant et ils auront exactement la même disposition qu'ils ont maintenant.

MAIS

Au moment où le développeur de blocs se rend compte qu'il a des propriétés CSS qui pourraient / devraient être configurées par l'utilisateur ... c'est alors que Gutenberg prend le relais et décide de la manière dont ces styles sont injectés (et potentiellement contrôlés).

Il en résultera une interface commune unique (pour les développeurs et les utilisateurs) lorsqu'il s'agit de contrôler de manière non programmée les configurations communes basées sur le style du contenu des pages Web.

Cela donne aux utilisateurs et aux développeurs un moyen unique et cohérent de visualiser, d'ajouter, de supprimer, de modifier et de remplacer les styles de bloc qui, en fin de compte, se résument tous à de simples propriétés CSS.

Désolé de causer autant de bruit sur ce fil. Nous devrions probablement poursuivre la discussion sur la question connexe.

Note éditée:

J'ai oublié d'aborder le point sur l'abstraction.

La minute où l'utilisateur a besoin d'appliquer exactement le même style au même bloc exactement deux fois est le moment exact où les paramètres de style définis par l'utilisateur doivent être abandonnés pour les classes CSS (pour ce bloc).

En d'autres termes, les paramètres de style définis par l'utilisateur fournissent un mécanisme cohérent permettant à l'utilisateur de personnaliser les blocs à son goût, qu'il s'agisse d'une chose unique (comme il se doit) ou 100 fois sur chaque page, et comment vous choisissez de structurer cela dépend toujours de vous.

Je pense que nous sommes généralement d'accord. Ma suggestion dans le premier article était d'avoir un crochet pour ajouter / supprimer des contrôles. Je ne suis pas contre la personnalisation des styles par l'utilisateur au niveau du bloc, il est juste difficile de choisir "ceux qui valent la peine d'être installés par défaut sur un bloc de section générique" sans que la liste ne croisse de façon exponentielle. En avoir un minimum, c'est bien, surtout si vous autorisez l'ajout d'autres contrôles. Dans tous les cas, je suis surpris que la marge et le remplissage ne soient pas plus universellement utiles que la couleur d'arrière-plan pour un bloc de section.

FWIW, j'aime bien votre idée d'avoir des classes générées comme sortie, de sorte qu'elle soit toujours remplaçable sans avoir à utiliser! Important.

@rchipka @tmdesigned Je sais que c'était il y a plus de deux semaines, mais seriez-vous intéressé à trouver plus de détails dans un autre numéro? Je pense qu'il serait bénéfique d'avoir plus d'yeux sur cette convo.

J'ai jeté un autre regard sur ce bloc en fonction des conversations précédentes.

Le moyen le plus simple de partager mes idées est d'utiliser un prototype: https://wp.invisionapp.com/share/PQJPPAX4JZW

Quelques notes:

• Basé sur un sondage rapide: https://wordpress.slack.com/archives/C02QB2JS7/p1527283199000343 J'ai changé le nom de _Section_ à _Container_.
• J'ai supprimé les paramètres de colonne, car il est raisonnable que les gens veuillent mélanger et assortir les dispositions de colonne dans une section particulière, comme illustré par @jvisick.
• En plus de la couleur d'arrière-plan, j'ai ajouté la prise en charge des images d'arrière-plan. Les paramètres sont basés sur la fonction Image d'arrière-plan existante du noyau.
• Devrions-nous laisser les gens imbriquer un bloc conteneur dans un bloc conteneur?

@melchoyce a l'air génial!

Une fonctionnalité intéressante que j'aimerais voir est une sélection dans l'inspecteur pour basculer l'élément HTML du bloc entre <aside> , <div> et <section> .

À mon avis, la possibilité d'emboîter des conteneurs devrait certainement être autorisée. Non seulement cela serait utile dans le contexte d'avoir différentes zones colorées dans une seule section sémantique en utilisant la suggestion d'élément HTML suggérée ci-dessus, mais cela serait également utile dans les situations où vous souhaitez donner à un seul bloc un arrière-plan alors qu'il n'a pas option de couleur d'arrière-plan elle-même.

Une autre fonctionnalité intéressante serait les arrière-plans dégradés, car ceux-ci semblent être très populaires dans certains modèles.

@melchoyce +1 pour pouvoir imbriquer des conteneurs.

@SuperGeniusZeb pouvoir changer l'élément HTML a également été dans mon esprit. Peut-être une liste déroulante pour les choix d'éléments sémantiques?

@jvisick Ouais, c'est ce à quoi je pensais. Beaver Builder et Elementor ont tous deux des paramètres similaires pour leurs lignes / sections.

@melchoyce Je pense que les conteneurs devraient être emboîtables à l'infini. Cela permettra aux utilisateurs d'encapsuler une classe personnalisée (ou CSS personnalisé) autour de n'importe quel bloc, y compris d'autres conteneurs.

Il n'y a aucune raison d'ajouter des limitations d'imbrication à un bloc de conteneur générique.

Je comprends la valeur des éléments HTML sémantiques, mais je me demande également s'il existe un moyen de déléguer cette fonctionnalité aux plugins d'une manière ou d'une autre afin qu'elle soit disponible en option pour les utilisateurs avancés, mais les utilisateurs moyens n'ont pas besoin d'y penser. Parce qu'à la minute où vous ajoutez cela, vous assumez non seulement la responsabilité de fournir la fonctionnalité, mais aussi la responsabilité d'éduquer les utilisateurs sur les implications sémantiques… qui sont souvent très situationnelles.

@chriskmnds Bon point. Je pense que ce n'est pas le bon endroit pour définir des balises de conteneur.

Le bloc conteneur doit fonctionner comme un conteneur générique sans signification sémantique.

La signification sémantique devrait être fournie par la (future) fonctionnalité de modèle de bloc, de sorte que le contenu <aside> puisse être une partie d'un modèle et <section> une autre.

De cette façon, les utilisateurs peuvent organiser le contenu dans des conteneurs comme ils le souhaitent (à n'importe quel niveau de profondeur), sans affecter la signification sémantique.

Je suis d'accord que pouvoir échanger un élément HTML semble un peu avancé pour la plupart des gens, et n'appartient probablement pas à un paramètre de base de Gutenberg.

La signification sémantique devrait être fournie par la (future) fonctionnalité de modèle de bloc, de sorte que le contenu <aside> puisse faire partie d'un modèle et <section> une autre.

Ce serait certainement bon à explorer.

Je ne suis pas en désaccord avec les points faits pour garder l'UX de base simple mais je demanderais alors où ajouteriez-vous <section> , <nav> , <header> , etc. Un bloc conteneur générique, qui est essentiellement un élément wrapper, semble être un choix naturel. Cela peut être préférable à un bloc dupliqué pour chacun de ces cas. La valeur par défaut peut être <div> et un utilisateur n'a jamais à toucher le paramètre sauf si nécessaire.

Et si les options des éléments HTML fonctionnaient de la même manière que les paramètres alignwide / full où un tableau d'éléments pris en charge peut être défini à partir du thème ou du plugin?

@jvisick Idéalement, ces éléments d'

En utilisant un modèle de disposition de bloc, vous pouvez configurer un tas de blocs de conteneur par défaut et fournir un paramètre (dans le code) pour ce que le nom de balise généré par le bloc de conteneur devrait être.

@rchipka Je vois d'où vous venez en utilisant des modèles de mise en page qui donnent aux utilisateurs des zones prédéfinies pour gérer le contenu. Je regarde cela davantage dans une perspective d'utilisation de Gutenberg en tant que constructeur de pages pour des pages qui ne sont pas définies et dans lesquelles il serait utile de pouvoir définir le type d'élément HTML utilisé à partir de l'éditeur. Je pense que les deux scénarios sont importants.

Cela dit, je suis d'accord avec @melchoyce pour

Les sections sont essentiellement à 1 colonne ... enfin, des colonnes.

Je remarque que le bloc Colonnes 3.0.0 (bêta) n'autorise pas 1 colonne sur son curseur.

Je ne sais pas s'il vaudrait mieux s'en tenir au bloc Column tout autour et combiner ces implémentations. Quel est l'inconvénient?

Une chose qu'il serait bon d'ajouter est de choisir si le conteneur (section) doit être pleine largeur ou contenu. S'il est contenu, il doit respecter le content_width défini dans le thème (# 5650), sinon, il doit être en pleine largeur. Je pense que la majorité des constructeurs de pages ont cette fonctionnalité.

Oui, c'est inclus dans la barre d'outils rapide dans ma dernière maquette.

@melchoyce Gardez à l'esprit qu'il y aura des situations où le bloc section / conteneur lui-même devrait être pleine largeur, mais pas le contenu à l'intérieur du bloc section / conteneur. Comment cela serait-il géré?

J'ai pensé par défaut que le conteneur lui-même pouvait devenir pleine largeur, mais tout contenu qu'il contient qui ne prend pas en charge nativement la pleine largeur (comme les images / blocs de couverture) serait toujours limité à la largeur de l'éditeur.

@melchoyce En supposant que je vous comprends bien, cela signifie que les contrôles de largeur sur le bloc Container n'affecteraient que l'arrière-plan du conteneur, et jamais le contenu? Ça a du sens. Merci de clarifier. : +1:

Ouais, c'est ce que je pense!

Vous ne savez pas si cela a été discuté, mais une section peut être un élément HTML "section" et également être un "article", "div" ou autre chose, non? Ce serait bien de l'avoir comme sélectionnable
Cela peut également rendre le bloc "ligne" inutile, je pense

Implémenté ceci dans un plugin

var el = wp.element.createElement,
    registerBlockType = wp.blocks.registerBlockType,
    InnerBlocks = wp.editor.InnerBlocks;

registerBlockType( 'nbrummerstedt/section', {
    title: 'Section',
    icon: 'universal-access-alt',
    category: 'layout',
    attributes: {},
    edit: function( props ) {   
        return el( 'section', {className: props.className},
            el( InnerBlocks )
        );
    },
    save: function( props ) {
        return el( 'section', {className: props.className }, 
            el( InnerBlocks.Content )
        );
    }
} );

@eddr Cela a été discuté: https://github.com/WordPress/gutenberg/issues/4900#issuecomment -392925877

Je pense toujours qu'une liste déroulante pour sélectionner la balise HTML utilisée est une bonne idée. Cela semble être le moyen le plus simple d'intégrer des éléments HTML sémantiques comme <aside> et <section> sans créer tout un tas de blocs trop similaires.

@nbrummerstedt Belle implémentation initiale de base, mais le bloc s'appelle maintenant un bloc Container et devrait utiliser un <div> comme élément, bien que idéalement (comme mentionné ci-dessus et dans les commentaires précédents), vous puissiez changer le HTML élément utilisé de <div> à <section> , <aside> , et peut-être même <article> .

Voici une version révisée de votre implémentation:

( ( blocks, editor, element ) => {
    const el = element.createElement,
        { registerBlockType } = blocks,
        { InnerBlocks } = editor;

    registerBlockType( 'nbrummerstedt/container', {
        title: 'Container',
        icon: 'universal-access-alt',
        category: 'layout',
        attributes: {},
        edit: ( props ) => {    
            return el( 'div', {className: props.className},
                el( InnerBlocks )
            );
        },
        save: ( props ) => {
            return el( 'div', {className: props.className }, 
                el( InnerBlocks.Content )
            );
        }
    } );
} )( window.wp.blocks, window.wp.editor, window.wp.element );

Pourquoi cela a-t-il été supprimé du jalon WordPress 5.0, @mtias? Cela semble être quelque chose qui devrait probablement en faire la version initiale, simplement en raison de son utilité et de sa simplicité. De nombreux blocs n'ont pas de paramètres d'arrière-plan car il a été supposé que vous utiliseriez le bloc Conteneur pour cela. Ce n'est même pas si difficile de mettre en œuvre ce bloc, n'est-ce pas? Je ne vois pas pourquoi cela devrait être repoussé à une version post-WordPress 5.0.

Sur une autre note, j'ai récemment vérifié Oxygen et j'ai été impressionné par son système de mise en page basé sur flexbox. Et si le bloc Container implémentait certaines de ces fonctionnalités? Je parie que cela pourrait être vraiment puissant et fournir un moyen alternatif d'avoir des mises en page autres que le bloc Colonnes ... peut-être que cela pourrait même rendre le bloc Colonnes inutile?

https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/
https://oxygenbuilder.com/documentation/visual-editing/responsive-controls/

Je recommande vivement de vérifier cela. En fait, je recommande de jeter un coup d'œil à Oxygen entièrement. C'est très différent de tous les autres plugins de création de pages, et je pense qu'il y a beaucoup de bonnes idées que Gutenberg pourrait utiliser.

Je suis tout à fait d'accord, cela devrait être dans la version 5.0, vous avez besoin d'un conteneur pour éviter toute solution de piratage utilisant le bloc de colonnes.

Je pense aussi que ce bloc doit être disponible au plus tôt. De nombreuses agences de développement WordPress attendent ce bloc avant de construire avec Gutenberg.

@ dingo-d et @ericvalois Oui, je me suis abstenu d'utiliser Gutenberg pour autre chose que des articles de blog précisément à cause du manque de 3 choses: des colonnes responsives, des colonnes de largeur non égale et un bloc Container.

Pour développer ce que j'ai dit plus tôt à propos du bloc Container adoptant les choses qu'Oxygen fait, je pense que le bloc Container pourrait avoir une option pour changer la direction d'écoulement de ses blocs imbriqués de la verticale par défaut à l'horizontale. Il pourrait également y avoir des options d'alignement vertical et horizontal comme celles d'Oxygen. Celles-ci seraient vraiment puissantes, surtout si elles étaient combinées avec la possibilité de modifier ces options de manière réactive, comme le permettent la plupart des plugins de création de pages.

Bien sûr, il y a le problème notable qu'un bloc Container utilisant l'alignement / la mise en page basé sur Flexbox ne permettrait pas aux blocs alignés flottants d'être directement imbriqués dans celui-ci. Mais je pense qu'il y a une solution simple à cela: ajouter la possibilité qu'un conteneur utilise soit la mise en page CSS display: block soit la mise en page Flexbox. Le mode standard display: block serait le mode par défaut, puisque c'est ce que le document racine utiliserait. L'activation du mode d'affichage Flexbox ferait apparaître toutes les options d'alignement soignées dans l'inspecteur. De plus, vous voudrez évidemment donner aux 2 modes de mise en page un nom différent dans l'inspecteur pour le rendre plus convivial. Je ne sais pas trop comment vous les appelleriez. Peut-être «Standard» et «Flexible»?

Permettre aux blocs Container d'utiliser soit le mode qui prend en charge les flottants, soit le mode avec les meilleures options d'alignement / de mise en page serait vraiment utile. Vous pouvez imbriquer des blocs Container pour utiliser les deux types de disposition si nécessaire. Ajoutez cela aux autres capacités que le bloc Container pourrait avoir (options d'arrière-plan, possibilité de choisir une balise HTML pour ajouter une signification sémantique sans avoir à recourir à des blocs HTML personnalisés, etc.) et le bloc Container finirait par être l'un des plus importants et des blocs utiles dans le noyau de WordPress.

Notamment, si le bloc Container ayant deux modes de disposition sonne comme trop de fonctionnalités (et je ne pense pas vraiment que ce serait un problème), alors il pourrait juste y avoir deux blocs séparés:

• un bloc Container standard qui prend en charge les flottants mais ne dispose pas de toutes les options d'alignement / disposition avancées
• un bloc Advanced Container (ou Advanced Layout ou Flexible Layout ou peu importe comment vous l'appelez) qui utilise la disposition Flexbox et fournit toutes les options intéressantes

Je recommande de consulter cette vidéo de documentation Oxygen pour voir comment son système de mise en page fonctionne. C'est vraiment impressionnant:

https://www.youtube.com/watch?v=NnSfR-YFcQI

Je pense qu'il y a beaucoup de potentiel ici pour rendre Gutenberg très puissant . Bien sûr, pour une implémentation initiale, je m'attendrais uniquement à ce que le bloc Container ait des options d'arrière-plan, la possibilité de modifier l'élément HTML utilisé et la possibilité de faire en sorte que le conteneur soit pleine largeur (mais pas le contenu qu'il contient). Peut-être même juste les options d'arrière-plan.

En fait, il est toujours utile d'avoir un bloc Container qui n'a même pas d'options, car cela facilite le style d'un groupe de blocs via CSS.

Il est important de penser à Gutenberg pas seulement comme en s'arrêtant après 5.0. C'est un bloc vraiment utile et sera exploré, mais pour la première phase, se concentrer sur l'édition, ce n'est pas vraiment nécessaire. Lorsque le projet se développe au-delà de la simple modification de la mise en page, il ne fait aucun doute qu'une solution est nécessaire. Personne ne dit que cela ne sera pas créé, il s'agit de prioriser ce qui est éditeur et ce qui passe ensuite à la phase deux.

Mais le fait est que la majorité des gens utilisent Gutenberg à des fins de mise en page, pas pour écrire des articles.

Les gens ont l'habitude d'écrire des articles comme un document Word, ils désactivent donc le Gutenberg sur les pages des articles.

Mais le fait est que la majorité des gens utilisent Gutenberg à des fins de mise en page, pas pour écrire des articles.

Sur quelle source de données basez-vous cette hypothèse?

J'ai parlé à plusieurs personnes pendant le WCEU à Belgrade, ils conviennent tous qu'ils trouvent étrange d'écrire des messages avec Gutenberg et qu'ils le désactivent donc sur les messages.

Contrairement à ce que @ dingo-d a vu, je n'utilise Gutenberg que pour les messages. En fait, je trouve l'expérience de post-création beaucoup plus agréable dans Gutenberg que dans l'éditeur classique. En partie à cause de la nature plus modulaire et des contrôles contextuels, et en partie parce qu'il n'y a plus <p> balises invisibles

J'ai besoin d'un bloc Container (même un sans aucune option) et d'un bloc Columns décent (ou d'un autre bloc de mise en page) afin d'utiliser Gutenberg pour la construction de pages uniformes. Il semble que le bloc Columns obtiendra une sorte de réactivité de base (voir # 6048), ce qui signifie que c'est simplement l'absence d'un bloc Container qui m'empêche d'utiliser Gutenberg dans plus de contextes.

Je sais que le bloc Container sera évidemment ajouté à un moment donné (probablement pas plus tard que WordPress 5.1), mais je crois fermement qu'il devrait être ajouté avant la sortie de WordPress 5.0. Même dans le contexte de l'écriture d'articles, un conteneur pourrait être utile pour quelque chose comme un <aside> (s'il avait la fonction de liste déroulante de sélection d'élément HTML) pour une sémantique supplémentaire. Pour le moment, si vous souhaitez insérer quoi que ce soit dans un autre élément HTML pour ajouter de la sémantique, vous devez utiliser le bloc HTML personnalisé, ce qui signifie que vous ne pouvez pas profiter des fonctionnalités du bloc Paragraphe pour les paragraphes de ce bloc HTML personnalisé, ou toutes les fonctionnalités du bloc Image pour toutes les images de ce bloc HTML personnalisé, etc.

@karmatosed

Personne ne dit que cela ne sera pas créé, il s'agit de prioriser ce qui est éditeur et ce qui passe ensuite à la phase deux.

À mon avis, le bloc Container est absolument quelque chose qui appartient à la première phase.

Ce que je trouve un peu bizarre, c'est que le bloc Columns semble être intégré à WordPress 5.0 (peut-être toujours avec cette étiquette «(Beta)», mais le bloc Container n'est peut-être pas? Si l'accent est actuellement mis sur l'écriture messages, alors pourquoi un bloc Colonnes a-t-il été ajouté mais pas de bloc Conteneur? Le bloc Conteneur, à mon avis, est bien plus utile dans le contexte des publications que le bloc Colonnes. Et bien sûr, il présente également de nombreux avantages dans le contexte de création de page également.

Si le bloc Container ne parvient pas à entrer dans WordPress 5.0, cela signifie qu'il ne sortira pas avant la version 5.1, ce qui retarde son utilisation par la plupart des gens pendant des mois. Je veux que Gutenberg réussisse et je pense qu'il n'y a aucune raison de suspendre la publication de quelque chose de basique comme un bloc Container jusqu'à WordPress 5.1. Dans un souci de bonne première impression, je recommanderais même de l'ajouter avant l'appel de WordPress 4.9.8.

Je ne m'attends pas à ce qu'il ait toutes les fonctionnalités que les gens ont suggérées; sa simple existence est suffisante pour résoudre de nombreux cas d'utilisation courants qui ne sont actuellement pas couverts, sauf par une solution plutôt hacky consistant à utiliser un bloc Columns avec le curseur Columns réglé manuellement sur 1. Et puis, avoir juste une option comme les options de couleur d'arrière-plan le rendrait beaucoup plus utile.

Je conviens que c'est un bloc cool et utile, mais il a toujours été plus axé sur la phase 2 du projet et nous devons vraiment nous concentrer ou nous ne livrerons jamais. Nous avons construit l'infrastructure de blocs imbriqués car il était important d'obtenir les bonnes abstractions et de permettre aux gens de créer leurs blocs de mise en page personnalisés afin qu'un bloc de base réel comme celui-ci soit moins critique. L'objectif est d'obtenir la bonne interface utilisateur imbriquée et enfant en général (en utilisant _Columns_ comme cobaye).

Ce problème est également ouvert à la vente depuis cinq mois maintenant et il n'y a pas eu de propositions de mise en œuvre solides qui incluent des éléments tels que les couleurs, les largeurs, la direction des blocs par rapport aux colonnes d'imbrication, le chevauchement avec l'image de couverture, etc. En l'état, nous pouvons Ne lui donnez pas la priorité par rapport aux autres travaux à usage général que nous devons faire, et à l’avis imminent «d’essayer» dans WordPress. Cela ne veut pas dire qu'il ne fera pas la coupe, surtout si quelqu'un veut proposer des suggestions dans le code.

De plus, le plus gros problème pour moi est qu'il n'est pas clair - visible uniquement à partir de la conversation ici - quelle devrait être l'expérience utilisateur idéale pour s'engager dans une implémentation. Des choses comme l'exposition de balises html semblent ouvertement complexes et peu intuitives pour un utilisateur régulier. La notion même de conteneur nécessite des tests plus larges pour voir si c'est la meilleure abstraction de mise en page, ce qui, encore une fois, était censé être quelque chose à comprendre lors de la prochaine phase de mise au point. Il y a aussi des inconnues sur la façon dont un tel bloc ferait en cascade les styles vers des blocs arbitraires à l'intérieur - il est relativement simple de tenir compte des blocs de base, mais pas de tout bloc arbitraire.

Dans le même temps, un développeur souhaitant proposer un bloc personnalisé devrait avoir du mal à l'assembler (comme l'extrait de code ci-dessus) avec la balise de son choix en utilisant InnerBlocks et en recueillant les commentaires des utilisateurs. Il y a donc moins de pression sur le noyau ayant un tel bloc (et devant le maintenir). Cela dit, tout le monde devrait se sentir libre de faire une suggestion via PR et d'aider les utilisateurs à la tester. Je serais d'accord pour l'ajouter au plugin comme "expérimental" avec l'idée qu'il pourrait être retiré pour 5.0.

@SuperGeniusZeb Oxygen est plutôt cool! Devrait certainement être examiné pour certaines de ces explorations.

Par curiosité, que se passe-t-il si les thèmes et les plugins ajoutent leurs propres blocs de section et que l'utilisateur désactive le plugin ou change de thème? Y a-t-il une sorte de solution de secours en place? Ou l'utilisateur perd-il son contenu?

@tomusborne Il y a un problème dans ce genre de situation: # 7811.

Ah! Je ne savais pas que cela avait été discuté ici. J'ai donc également créé un plugin car j'en avais besoin.

https://github.com/marcusig/gutenberg-section-block

J'ai regardé ce fil et j'apprécie toutes les pensées qui y sont liées. J'ai récemment publié un bloc conteneur dans le plugin Atomic Blocks qui a des marges, des rembourrages, la largeur du conteneur et des options d'image et de couleur d'arrière-plan. J'espère que cela sera utile et pourra nous retarder jusqu'à ce qu'un bloc central arrive à une date ultérieure!

Suite à ce numéro, j'ai créé un bloc "Conteneur" qui permet de choisir la structure des colonnes, et d'autres options.
Si cela peut aider à améliorer le bloc "Colonnes" ou à en créer un nouveau dans le noyau, c'est ici: https://github.com/MarieComet/WP-container-block/

@MarieComet C'est bien, mais je pense que votre bloc devrait être divisé en 2 blocs différents. Le premier doit être un bloc Colonnes avec toutes les options de disposition de structure basées sur des colonnes. Le second serait un bloc Container qui a des options d'arrière-plan et des options de mise en page qui ne sont pas basées sur des colonnes, telles que la possibilité d'utiliser flex pour mettre en page les enfants horizontalement plutôt que verticalement et les aligner et les justifier à l'aide d'options qui correspondent aux propriétés CSS Flex.

Vous pouvez probablement également utiliser le bloc Container pour remplacer les blocs Column individuels, bien qu'il puisse y avoir des options que vous voudriez avoir sur une colonne qui n'ont pas de sens sur une section.

Je me suis rendu compte que l'avenir de la création de mises en page avec HTML et CSS n'est pas de toujours utiliser des colonnes comme la plupart des constructeurs de pages, mais aussi d'utiliser CSS Flex et Grid pour afficher du contenu en utilisant moins de <div> s dans le balisage et ont un style plus flexible et plus propre. Je suis principalement inspiré par ce que fait Oxygen. J'ai parlé d'oxygène dans ce commentaire .

Ce problème ne concerne pas le remplacement du bloc de colonnes pour le moment. Il est important de rester concentré sur le sujet de ce problème, un bloc de section.

@karmatosed @melchoyce En parlant de cela, ce problème ne devrait-il pas être renommé? Nous avons arrêté de l'appeler "Section" et sommes passés à "Container" pour éviter toute confusion avec les éléments <section> .

Le nom n'a pas été décidé, donc nous sommes tous bien partis comme ça pendant un petit moment.

En ce moment, j'essaye d'implémenter un thème avec l'éditeur Gutenberg.

La mise en page du site Web comporte différentes zones avec des arrière-plans différents, qui contiennent plusieurs éléments tels que des paragraphes ou des listes. Ceci est à des fins de mise en page et à des fins de navigation. Les blocs section / conteneur doivent fonctionner comme des ancres / doivent avoir des ID CSS uniques.

Je ne peux pas terminer ce thème sans "pirater Gutenberg" en créant ses propres blocs. Cela pourrait être fait avec celui-ci comme bloc de base à la place. Je n'utiliserais pas l'éditeur Gutenberg uniquement pour du texte brut et des mises en page simples - ma future mise en page / conception devrait être réalisée avec le thème et le système de blocs de Gutenberg.

J'espère vraiment que ce sujet recevra une priorité plus élevée.

J'utilise des blocs de conteneurs tiers partout (par exemple, des blocs atomiques), en combinaison avec le bloc Colonnes. Ils ont été super utiles et mon bloc le plus populaire. Je trouve étrange qu'elle soit considérée plus tard dans le futur ou comme un complément; doit être au cœur.

Sinon, je construirais simplement manuellement les conteneurs en vue HTML, mais c'est ennuyeux / inefficace car la vue HTML est un clic de menu supplémentaire. Il existe un raccourci clavier pour la vue HTML ... Maj + option + cmd + M ... yeesh. Et il ne bascule même pas d'avant en arrière. Appuyer à nouveau sur le raccourci ne fait rien. Pour revenir à la vue WYSIWYG, vous devez parcourir les menus. Un gros interrupteur à bascule dans la barre d'outils principale serait génial.

Quelqu'un a-t-il catalogué / tient-il à jour une liste de mise en œuvre actuellement dans la nature? Je pense qu'il faudrait aussi une sorte de matrice de paramètres des «choses bien et mal faites». Par exemple, spécifier des unités codées en dur (px) pour les rembourrages / marges associés (faux), lorsque les unités devraient probablement être un choix laissé à l'utilisateur (à droite), etc.

https://editorblockswp.com/library/ en a dans le catalogue, mais pour faire avancer ce problème, il semble que quelque chose de spécifique aux sections / conteneurs doit se produire.

À mon avis, un bloc Container de base aurait au moins les options suivantes:

• image de fond
• Couleur de l'arrière plan
• possibilité de superposer la couleur d'arrière-plan sur l'image et de contrôler l'opacité
• options de remplissage et de marge pour les 4 directions, avec la possibilité de changer les unités utilisées individuellement pour chaque valeur
• prise en charge des alignements flottant à gauche, flottant à droite, large et complet
• possibilité de contrôler d'une manière ou d'une autre la largeur maximale des blocs contenus
• possibilité de choisir l'élément html utilisé par le conteneur

De plus, je préférerais également avoir ce qui suit:

• Options de mise en page CSS flex: possibilité de définir la direction du flux de contenu de haut en bas à gauche à droite, de droite à gauche et de bas en haut; et possibilité de définir l'alignement vertical et horizontal du contenu
• bien sûr, l'utilisation des options flex est incompatible avec les alignements flottants, donc le bloc devrait avoir au moins 2 modes de disposition: standard et flex, ou bien il devrait y avoir un bloc Flex Container séparé
• options de taille de police et de couleur pour définir les valeurs par défaut du contenu dans le conteneur et éviter d'avoir à le définir individuellement pour chaque bloc contenu

Felix Arntz vient de publier un article de blog concernant l'implémentation de son bloc de section.
j'aime l'image de fond responsive.
https://felix-arntz.me/blog/building-a-reusable-gutenberg-section-block/

Au cours des dernières semaines, j'ai expérimenté la mise en œuvre de Marc Lacroix, qui fonctionne bien, mais semble casser dans gutenberg 3.9.0 https://github.com/marcusig/gutenberg-section-block

J'y pense depuis un certain temps. Le fait que de nombreuses implémentations aient émergé signifie que c'est assez précieux et qu'il est probablement préférable que le noyau offre un mécanisme cohérent pour éviter la fragmentation. Ma principale préoccupation concerne la complexité d'un bloc "section" pour un utilisateur.

Je propose de commencer très simple, avec juste un conteneur (une seule zone InnerBlocks), des alignements larges et complets, et un paramètre pour la couleur de fond (pas d'image, etc. - nous avons "Cover" pour cela).

Nous n'avons pas beaucoup de temps pour le faire si nous le voulons en 5.0.

@mtias Si exposer un bloc Container à l'utilisateur final est un problème, alors peut-être que chaque bloc devrait avoir juste un Container ou Container Settings par défaut.

Ensuite, nous n'avons pas à nous soucier d'apprendre à l'utilisateur final qu'il doit emballer quelque chose dans un conteneur pour qu'il ait certaines choses comme une image d'arrière-plan.

Je pense que c'est en fait une bonne idée, car les personnes qui souhaitent étendre ou encapsuler des blocs arbitraires auront une place claire pour le faire, et les utilisateurs finaux le connaîtront car c'est sur chaque bloc.

Peut-être que "Paramètres du conteneur" pourrait être un onglet à côté de "Paramètres de blocage". Ce serait un endroit (extensible) pour les développeurs pour insérer (ou filtrer) des éléments tels que les paramètres d'image d'arrière-plan, les paramètres de largeur, etc.

Cela donnerait également aux développeurs un endroit pour mettre des paramètres plus complexes qui peuvent être appliqués à pratiquement n'importe quel bloc, comme les contrôles réactifs / de point d'arrêt.

@rchipka Techniquement, la plupart des blocs sont

La puissance d'un conteneur ne réside pas exactement dans un seul bloc, mais vous permet plutôt d'ajouter d'autres blocs à l'intérieur du conteneur, créant ainsi des mises en page, des sections et une structure de page plus complexes.

@mikemcalister Bon point, l'utilisateur final aurait encore besoin d'un moyen de regrouper / organiser visuellement l'arborescence des blocs.

Je pense que la philosophie reste la même. Si l'éditeur avait un mécanisme de regroupement de blocs de style arborescent (c'est-à-dire sans interface "Container Block"), alors les "Container Settings" de tout bloc enfant refléteraient les paramètres de ce groupe (c'est-à-dire ce niveau dans l'arborescence).

Là encore, le seul point de cette idée est de réduire le nombre d'étapes impliquées pour l'utilisateur final, et donc également de réduire la courbe d'apprentissage et d'augmenter la découvrabilité.

Je pense que le principal problème est qu'actuellement, Gutenberg est très limité au contenu standard des articles / pages. Sans un bloc Section / Container, nous n'avons aucun moyen de permettre aux utilisateurs de créer des pages de garde avec des sections pleine largeur (avec une couleur d'arrière-plan unie / dégradée ou une image d'arrière-plan pleine largeur) avec toutes sortes de contenu à l'intérieur (espérons-le via des blocs imbriqués).

Un bloc section / conteneur serait parfait ici. Même une version basique qui pourrait être étendue avec plus de contrôles par thèmes / plugins. J'aimerais aussi avoir plus de paramètres d'alignement. Nous faisons déjà quelque chose avec CMB pour avoir un générateur de pseudo-page directement sur les pages, mais espérons vraiment que Gutenberg pourra rendre tout cela plus flexible pour tout le monde.

@JiveDig Je ne pense pas que quiconque, y compris l'équipe de Gutenberg, soit opposé à une sorte de mécanisme de conteneur de bloc.

La principale hésitation de l'équipe Gutenberg (dans ce cas et bien d'autres) est de maintenir l'interface de base à un niveau de complexité Squarespace d'un point de vue UI / UX.

Pour que cela soit implémenté dans le noyau, il semble que le problème principal soit de trouver un moyen de le représenter sans mettre un fardeau supplémentaire sur les utilisateurs finaux.

Bien que, à mon avis, il ne semble pas une grosse affaire, un « bloc conteneur » ne place une petite charge sur l'utilisateur final en exigeant la connaissance de son objet et de son utilisation.

C'est pourquoi j'ai proposé le concept de «regroupement» comme une analogie plus accessible aux «conteneurs» pour les utilisateurs finaux.

L'utilisateur final ne penserait pas en termes d'emballage de blocs dans des conteneurs et penserait plutôt en termes de regroupement de blocs, ce qui semble plus intuitif.

De cette façon, l'utilisateur final n'a pas besoin de savoir quoi que ce soit à l'avance pour regrouper les blocs et appliquer les paramètres à ce groupe.

Bien sûr, ces "groupes" fonctionneraient exactement comme un bloc Container en interne, c'est juste une interface frontale plus intégrée et intuitive.

@rchipka Une manière très simple d'aborder ce serait la possibilité de sélectionner un ou plusieurs blocs et de cliquer sur une option "Déplacer le (s) bloc (s) sélectionné (s) dans le bloc Conteneur" dans le menu "plus". De cette façon, les blocs n'ont pas besoin d'un panneau de paramètres _additional_.

Oui, un bloc de section doit être dans le noyau. Le rendu d'un simple div dans le HTML est suffisant. Mais comme il y a littéralement des centaines d'attributs qui pourraient être offerts, je suggère fortement à la place que les deux attributs qui devraient être offerts sont CLASS et ID (avec ID étant le moins critique). De cette façon, les éléments peuvent être stylisés en CSS là où ils devraient être.

-
Modes Wes
Une histoire secrète des peuples des rivières américaines
http://peoplesriverhistory.us

Envoyé de mon Apple] [e

Le 12 octobre 2018 à 8h09, Matias Ventura [email protected] a écrit:

J'y pense depuis un certain temps. Le fait que de nombreuses implémentations aient émergé signifie que c'est assez précieux et qu'il est probablement préférable que le noyau offre un mécanisme cohérent pour éviter la fragmentation. Ma principale préoccupation concerne la complexité d'un bloc "section" pour un utilisateur.

Je propose de commencer très simple, avec juste un conteneur et un réglage pour la couleur de fond (pas d'image, etc. - nous avons "Cover" pour cela).

Nous n'avons pas beaucoup de temps pour le faire si nous le voulons en 5.0.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

Encore une fois, chaque bloc devrait avoir la possibilité de définir son attribut de classe. Quel que soit le type.

-
Modes Wes
Une histoire secrète des peuples des rivières américaines
http://peoplesriverhistory.us

Envoyé de mon Apple] [e

Le 12 octobre 2018 à 8h40, Robbie Chipka [email protected] a écrit:

@mtias Si exposer un bloc Container à l'utilisateur final est un problème, alors peut-être que chaque bloc devrait avoir juste un Container ou Container Settings par défaut.

Ensuite, nous n'avons pas à nous soucier d'apprendre à l'utilisateur final qu'il doit emballer quelque chose dans un conteneur pour qu'il ait certaines choses comme une image d'arrière-plan.

Je pense que c'est en fait une bonne idée, car les personnes qui souhaitent étendre ou encapsuler des blocs arbitraires auront une place claire pour le faire, et les utilisateurs finaux le connaîtront car c'est sur chaque bloc.

Peut-être que "Paramètres du conteneur" pourrait être un onglet à côté de "Paramètres de blocage". Ce serait un endroit (extensible) pour les développeurs pour insérer (ou filtrer) des éléments tels que les paramètres d'image d'arrière-plan, les paramètres de largeur, etc.

Cela donnerait également aux développeurs un endroit pour mettre des paramètres plus complexes qui peuvent être appliqués à pratiquement n'importe quel bloc, comme les contrôles réactifs / de point d'arrêt.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

Je ne m'oppose pas à la méthode de regroupement (tant que je pourrais attribuer des attributs de classe), bien que ce serait délicieux s'il y avait ÉGALEMENT un bloc de conteneur si vous vouliez construire de cette façon.

-
Modes Wes
Une histoire secrète des peuples des rivières américaines
http://peoplesriverhistory.us

Envoyé de mon Apple] [e

Le 12 octobre 2018, à 10 h 50, Chris Van Patten [email protected] a écrit:

@rchipka Une manière très simple d'aborder ce serait la possibilité de sélectionner un ou plusieurs blocs et de cliquer sur une option "Déplacer le (s) bloc (s) sélectionné (s) dans le bloc Conteneur" dans le menu "plus". De cette façon, les blocs n'ont pas besoin d'un panneau de paramètres supplémentaire.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

@chrisvanpatten Je suis d'accord, mais cette solution ne répond pas de manière adéquate à la préoccupation initiale de @mtias d'exposer le concept de conteneur ou de section à l'utilisateur final.

Le problème, tel que soulevé par @mtias , ne concerne pas la logistique de la mise des blocs dans un conteneur, mais plutôt la présentation intuitive de cette interface à l'utilisateur final (sans exposer des types de blocs supplémentaires).

La discussion sur "comment nous introduisons des blocs dans un conteneur" est nécessaire. Cependant, je ne le vois pas nécessairement trop complexe pour un utilisateur. De nombreux utilisateurs ne l'utiliseront pas, ou du moins ne l'utiliseront pas en dehors de leur page d'accueil. Beaucoup de nos clients et clients thématiques expriment leurs souhaits / besoins de sites Web en termes visuels adaptés à un bloc Section. Ils disent des choses comme: "Je veux une grande {bar / zone / section / block / panel / span} pleine largeur avec une jolie image" suivie de "et {insérer des demandes de contenu ici} dans cette section". Ils comprennent visuellement que la section elle-même (le conteneur) est distincte du contenu qu'elle contient.

Certes, la façon de le faire via l'interface utilisateur doit être réglée, mais j'espère que mon point ci-dessus a du sens.

@chrisvanpatten Ma déclaration précédente est basée uniquement sur la sémantique des types de blocs.

La seule raison pour laquelle je discute de la sémantique ici est au nom de

J'aime votre suggestion, mais si je suis mon analogie, je changerais peut-être la sémantique "Group selected block (s)".

@rchipka ce n'est pas ainsi que j'ai interprété son commentaire - j'ai

Cela dit, je suis plus qu'heureux de me tromper :)

@JiveDig Je suis tout à fait d'accord ....

Cependant, l'équipe de Gutenberg semble être très sensible à exposer ces choses à l'utilisateur final dans le noyau de Gutenberg.

C'est ma seule base pour soulever ces arguments et présenter ces idées.

Encore une fois, si c'était moi, nous aurions juste le putain de bloc de conteneurs.

Je ne pense pas qu'un bloc de conteneur ait vraiment du sens, car il encombrerait l'interface utilisateur. Je préférerais voir quelque chose comme le marqueur "Saut de section" que vous voyez en ligne sur Microsoft Word. L'ajout d'un saut de section offrirait des options de style dans l'inspecteur comme un nom de classe pour la section, la couleur d'arrière-plan, la couleur du texte, l'ombre portée, tout ce qui définit stylistiquement votre section. Il pourrait être inséré comme n'importe quel bloc et déplacé comme n'importe quel bloc.

@rwrobe Cette idée ne fonctionne pas pour les conteneurs imbriqués.

Je construis actuellement un site avec Gutenberg et j'ai beaucoup utilisé une version modifiée du bloc de section de

• "Section" est le meilleur nom pour le bloc. Sa signification est claire pour les développeurs et les utilisateurs finaux et évite de compliquer le balisage / les options en utilisant logiquement le bloc <section>.

• Les seules options de menu contextuel nécessaires sont alignnormal / wide / full (et en fait je n'utilise que alignfull). L'alignement n'affecte pas les blocs internes, qui restent dans l'alignement normal à moins qu'ils n'aient leurs propres options d'alignement. Le cas d'utilisation principal a été la création d'une couleur d'arrière-plan alignfull qui contient un bloc de texte aligné normalement - un modèle de conception très courant qui n'est actuellement pas possible.

• Les seuls paramètres de bloc de la barre latérale nécessaires sont la couleur d'arrière-plan et l'image d'arrière-plan (avec les options fixes / d'opacité associées). Toute personnalisation supplémentaire peut être gérée avec la classe CSS personnalisée. (L'inclusion de l'option Image d'arrière-plan a également pour effet secondaire de la transformer en une version beaucoup plus utile du bloc de couverture.) (Mais: si @mtias a raison, éviter cette conversation en

• La convivialité a été simple. Plus facile que les colonnes, qui existent depuis un certain temps maintenant. Le seul problème potentiel est que lorsque la section est ajoutée pour la première fois, le focus est basculé sur un paragraphe à l'intérieur de la section, il peut donc être difficile de dire que la section vient d'être ajoutée jusqu'à ce que vous la survoliez. Une solution possible pour cela consiste à utiliser par défaut une couleur de fond gris clair.

@ZebulanStanphill Parlez -vous de colonnes? Je pourrais voir des blocs de "section" faire le travail pour le contenu séparé verticalement - il pourrait même y avoir une bascule pour hériter des styles de la section précédente, ce qui vous permet en quelque sorte "d'imbriquer" des variations de style à l'intérieur d'une section.

La composition horizontale, comme dans les colonnes, semble nécessairement plus difficile en raison de la façon dont Gutenberg construit la page de haut en bas en blocs pleine largeur.

@mikedance Je pense que c'est exactement ce qu'il faut. Une option d'image d'arrière-plan serait importante si l'OMI. Peut-être que ce bloc pourrait remplacer le bloc de couverture alors, bien que la dénomination puisse ne pas être propice pour les personnes qui veulent _seulement_ une image de fond avec du texte de base dessus. Bien qu'il y ait un certain chevauchement dans les fonctionnalités, mais cela enlèverait un grand pourcentage de cas d'utilisation pour le bloc Section sans ajouter de support d'image bg.

@rwrobe Il convient de noter que vous pouvez avoir des blocs disposés horizontalement. Les blocs Column (notez le manque de "s") ne sont que cela. Le bloc Colonnes les dispose horizontalement. L'interface utilisateur pourrait probablement être améliorée dans certains domaines, mais les blocs ne se limitent pas à être pleine largeur ou disposés verticalement.

@mikedance

"Section" est le meilleur nom pour le bloc. Sa signification est claire pour les développeurs et les utilisateurs finaux et évite de compliquer le balisage / les options en utilisant logiquement le

bloquer.

Parce que l'élément <section> a une sémantique qui lui est attachée, il serait préférable que vous puissiez choisir d'utiliser un <div> plutôt qu'un <section> , car dans de nombreux cas, vous voulez envelopper plusieurs blocs, mais ils ne font pas sémantiquement partie d'une section. En fait, ce serait encore mieux si vous pouviez également choisir d'utiliser des éléments comme <aside> ou <header> , ce dernier étant particulièrement utile pour ajouter de la sémantique aux en-têtes avec arrière-plan dans la création de pages.

Sur une autre note, je pense que des options d'image d'arrière-plan disponibles pour un bloc Container seraient très utiles. Bien sûr, le chevauchement avec le concept de bloc de couverture devient tout à fait apparent. Si vous rendez le bloc Cover plus flexible, il se transforme de toute façon en bloc Container, alors peut-être que le concept de bloc Cover n'a pas besoin d'exister? Un bloc Container peut faire à peu près tout ce qu'il fait. Le concept de couverture pourrait simplement être un modèle de bloc réutilisable.

@ZebulanStanphill Je suis d'accord. Qu'une configuration avancée vous permettant de sélectionner s'il s'agit d'une section, d'un en-tête, d'un aparté ou d'un div (par défaut) serait utile. Oui, la plupart des utilisateurs n'utilisent peut-être pas cette option, mais c'est une option qui prend en charge de bons développeurs Web.

Comment un thème peut-il s'intégrer? Un thème peut-il ajouter des "variations" à un bloc, dans ce cas
le bloc de section et l'utilisateur peut directement en choisir un dans un ilst et voir les styles résultants appliqués?
En outre, il peut être très utile d'ajouter un filtre ou un crochet au bloc de section pour laisser
un thème ajoute un wrapper et d'autres éléments parfois requis pour le style.

@ZebulanStanphill @wmodes Je doute que l'inclusion d'une option pour sélectionner l'élément contenant puisse dépasser les développeurs principaux. C'est une complication excessive. D'un certain point de vue, l'élément <section> est aussi sémantique que possible parce que l'utilisateur le définit déjà comme une "Section" du fait de la création du bloc. C'est à eux de l'utiliser de manière responsable, tout comme les titres. Mais si cela évite l'argument sémantique, je n'ai pas de problème avec l'utilisation de <div>.

@mikedance D'accord, nous devrions probablement simplement utiliser <div> . Si la disposition sémantique est un problème, il serait préférable de la gérer comme une extension du bloc conteneur.

@strarsis Themes peut utiliser l'API de styles de bloc existante pour ajouter des styles aux blocs. (Le bloc principal Button et Quote inclut plusieurs variantes de style par défaut.) Malheureusement, je ne trouve aucune documentation sur cette fonctionnalité. (Il existe plusieurs problèmes de suivi du manque actuel de documents: https://github.com/WordPress/gutenberg/milestone/500)

@mikedance

D'un certain point de vue le

L'élément est aussi sémantique que possible parce que l'utilisateur le définit déjà comme une "Section" en raison de la création du bloc.

Je pense comprendre ce que vous dites, mais je ne suis pas d’accord. Dans de nombreux cas, un bloc Container serait utilisé simplement pour ajouter une couleur d'arrière-plan à un couple ou même à un seul bloc qui n'a pas ses propres options d'arrière-plan (ou d'autres styles). Un bloc de liste enveloppé dans un conteneur pour lui donner une couleur d'arrière-plan et le mettre en surbrillance ne signifie pas que la liste est dans sa propre section.

Mais oui, <div> est le choix le plus neutre car il n'a aucune signification sémantique. S'il n'y a jamais d'option dans le noyau pour changer l'élément HTML, alors <div> est le meilleur choix.

La principale raison pour laquelle je souhaite pouvoir choisir la balise HTML est qu'elle vous permet de créer plus facilement des pages et des articles sémantiques sans avoir à recourir au bloc HTML personnalisé ou aux plugins qui ajoutent des blocs personnalisés. Si vous voulez utiliser une balise <section> dans Gutenberg maintenant, vous finissez par devoir tout mettre dans cette section dans un bloc HTML personnalisé, perdant les capacités d'édition visuelle pour des éléments tels que les paragraphes, les listes, etc. aurait autrement. Peut-être que le sélecteur de balises pourrait être affiché sous le groupe Avancé de l'inspecteur?

@strarsis @ZebulanStanphill

Vous pouvez trouver des documents pour ajouter Block Styles dans le manuel sous extensibilité https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#block -style-variations

@ajitbohra Merci! J'ai vérifié cette page plusieurs fois mais j'ai continué à manquer cette section d'une manière ou d'une autre. :en riant:

@ajitbohra : Merci! Existe-t-il une démo pour les variations de style de bloc de Gutenberg btw.?

@strarsis

Oui, vérifiez les blocs core button et quote

https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/button
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/quote

@strarsis Les pullquote , table et separator ont également des variantes de style:
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/pullquote
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/separator
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/table

J'aimerais vraiment voir un bloc organisationnel créé. Le problème actuel avec les colonnes est que la création d'un seul bloc en colonnes pour regrouper le contenu (par exemple, à des fins de couleur d'arrière-plan, de vidéo ou d'image partagée) n'est pas intuitive. J'aimerais, idéalement, voir l'éditeur atteindre le stade où il était capable de créer un contenu comme celui- ci presque strictement dans l'éditeur.

Déplacer cela provisoirement pour une version 5.1 afin que nous ayons un peu plus de temps pour définir comment ce bloc doit être présenté.

Pendant que j'y pense ... comme il y a un chevauchement entre ceci et le bloc Cover, que se passe-t-il si le bloc Cover était plus une "configuration" en ce sens que lorsque vous ajoutez ce bloc, il ajoute vraiment un bock de section préconfiguré avec un titre ou Bloc de texte / paragraphe imbriqué à l'intérieur?

@JiveDig

Que se passe-t-il si le bloc Cover était plus une "configuration" en ce que lorsque vous ajoutez ce bloc, il ajoute vraiment un bock de section préconfiguré avec un bloc d'en-tête ou de texte / paragraphe imbriqué à l'intérieur?

Cela ressemble beaucoup à un bloc réutilisable inséré en tant que bloc autonome pour moi. Peut-être que le noyau pourrait inclure plusieurs modèles de blocs réutilisables par défaut comme ça. L'interface utilisateur devrait être améliorée pour faciliter l'insertion d'un bloc réutilisable en tant que bloc autonome. Voir # 8403.

Y aura-t-il une fourchette pour tester le nouveau bloc de section / conteneur? Je suis intéressé à jouer avec et à aider à le tester.

Un bloc conteneur / section est très utile, j'ai dû utiliser le
Advanced Gutenberg Blocks Container Block pour le moment.
Et il est important de rendre le bloc section / conteneur facilement visible et sélectionnable.

En partie commenter pour noter qu'un bloc de section serait incroyablement utile pour le développement de modèles.

Nous venons de créer un bloc de section personnalisé au lieu d'être dans le noyau et avons repéré un problème où les attributs de bloc ne se mettaient pas à jour si le bloc restait le même mais que les attributs changeaient.

Ce problème a été résolu dans le PR # 12406 (ci-dessus)

Le bloc de sections est-il toujours pris en compte pour la version 5.1 (prévue pour le 21 février 2019) ou une version ultérieure?

J'ai écrit un plugin de bloc de section, que j'ai utilisé sur quelques projets et j'espère le publier en tant que quelque chose de plus générique dans le référentiel de plugin. Il permet de définir les couleurs d'arrière-plan et les images ou la vidéo, ainsi qu'une classe définie par thème pour formater les éléments contenus dans la zone innerblocks .

Dans mes cas d'utilisation, il était plus facile pour le client d'avoir des champs de titre et de description prédéfinis (facultatifs) au-dessus d'une zone de blocs internes où ils pouvaient empiler des «éléments», qui, dans mon cas d'utilisation, étaient des pseudo-widgets que j'ai créés avec un autre bloc type. Mais cela pourrait tout aussi bien être de simples sections imbriquées, où le premier bloc de section contenait un en-tête, un paragraphe puis un autre bloc de section, qui à son tour contenait les éléments ...

Les sections signifient que gutenberg _doit_ être capable de traiter correctement les sections dont l'affichage est réglé sur flex et de rendre correctement les propriétés flex enfants immédiats.

Je rend mes sections dans JS mais le code contient un certain nombre de ce que je considère comme des hacks. Les rendre en PHP serait un jeu d'enfant ... sauf que l'envoi de contenu de blocs internes vers PHP n'est toujours pas résolu, n'est-ce pas?

Les colonnes, telles qu'implémentées par le bloc de colonnes, sont une solution totalement irréalisable car elles nécessitent une curation manuelle des colonnes, ce qui n'est pas une chose adaptée aux mobiles et rend l'ajout ou la suppression d'un autre élément dans un ensemble un problème énorme et frustrant.

Les "colonnes" dans une section sont simplement une déclaration de base flexible et pourraient, et devraient, tout aussi facilement être des lignes, et ne sont pas de véritables conteneurs pour les éléments, mais simplement une définition de leur flux. Veuillez ne pas gâcher le concept de sections avec quelque chose qui ressemble à des colonnes comme contenant (s) pour les éléments à l'intérieur.

Les propriétés définies dans une section doivent être facilement découvertes par les blocs contenus dans cette section. Je devrais être capable de créer un type de bloc qui peut répondre de manière intelligente aux choix faits dans le parent, s'il a un parent. Dans l'état actuel des choses, il est difficile de découvrir quoi que ce soit sur les attributs d'un parent sans écrire ce qui ressemble à 1400 lignes de code.

Les blocs sont imbriqués car le contexte parent / enfant de ces blocs est essentiel à la manière dont ils sont affichés et modifiés. Prétendre que le contexte n'existe pas est l'idéalisme à son pire.

Les blocs imbriqués doivent pouvoir référencer facilement les attributs parents, et par défaut. Si votre objectif est de ne pas rendre les blocs côté serveur sauf en de rares occasions, cette transmission d'informations de contexte _doit se produire_, sinon render() va être un terrain vague de return null comme nouveau et utile mais des blocs compliqués apparaissent.

(Je pense que le bloc columns serait plus utile s'il implémentait la propriété [encore expérimentale] CSS columns . Ce serait essentiellement un type spécial de section , prenant tout les éléments qu'il contient et les faisant passer via les propriétés de colonne définies dans l'inspecteur: column-width , column-count , column-rule , etc.)

y a-t-il une date de sortie pour ce type de bloc (Ajouter un bloc: section)?

@JQOz Non. Ce problème est sur la feuille de route pour les prochaines versions de mayor, mais il n'y a pas de demande de tirage ouverte sur laquelle les gens travaillent. Si vous avez des idées ou des fonctionnalités pour ce bloc, vous pouvez commencer à les ajouter ici.

Salut,

Je n'y pense pas qu'une seule fois. Une section doit être un conteneur pleine largeur. Pouvons-nous simplement ajouter une gouttière au conteneur dans une section et les faire fonctionner comme add_theme_support('alignwide') ou non.

Pour un cas:

https://tech.cornell.edu/

Nous avons de nombreuses sections différentes. Certains d'entre eux sont vivants dans un conteneur. Certains ne le sont pas. Mais tous ont besoin d'un seul conteneur.

Les blocs de colonnes Gutenberg sont une classe trop imbriquée et n'aident pas beaucoup. Il doit suivre une structure de grille et utiliser la classe parent> enfant pour continuer à fonctionner.

Quand je fais un développement https://www.luminasolar.com/ , je dois les envelopper dans une clé template pour garder une structure.

Je suggère que dans le cadre de la stratégie de mise en page de la page, une certaine réflexion consiste à fournir un hook / API pour les développeurs de thèmes et de plugins tiers des constructeurs de pages pour ajouter leurs propres interfaces et cloches et sifflets.

Suite à cet élément sur WPTavern, il semble que les utilisateurs commencent à voir un problème de standardisation et à se verrouiller sur des blocs spécifiques pour la mise en page retournant à l'ancien châtaigne d'un problème qui pose problème depuis de nombreuses années: changer de thème ou de constructeur de page et la mise en page disparaît ou dans le cas du nouvel éditeur de blocs, apparemment, du code qui ne peut pas être modifié car il est gravé dans la pierre.

Avoir une disposition standard commune que CoBlocks, Kadence (ou tout ce que vous avez vous-même) peut remplacer, résoudrait cela. Changez de plugin ou de thème et au moins votre contenu conserverait toujours la même mise en page de base.

C'est fondamentalement la seule fonctionnalité manquante qui me fait garder elementor sur mes sites ...

Suite à cet élément sur WPTavern, il semble que les utilisateurs commencent à voir un problème de standardisation et à se verrouiller sur des blocs spécifiques pour la mise en page retournant à l'ancien châtaigne d'un problème qui pose problème depuis de nombreuses années: changer de thème ou de constructeur de page et la mise en page disparaît ou dans le cas du nouvel éditeur de blocs, apparemment, du code qui ne peut pas être modifié car il est gravé dans la pierre.

Avoir une disposition standard commune que CoBlocks, Kadence (ou tout ce que vous avez vous-même) peut remplacer, résoudrait cela. Changez de plugin ou de thème et au moins votre contenu conserverait toujours la même mise en page de base.

Oui oui oui! Je crois qu'un bloc de section flexible est la principale caractéristique manquante de Gutenberg. Je suis heureux d'entendre qu'il est prévu pour une future version, mais déçu que personne ne travaille dessus pour le moment. Sans cela, les utilisateurs ne peuvent toujours pas mettre en page les formats de page courants et les développeurs de thèmes doivent toujours recourir à des techniques propriétaires pour les amener à un endroit où un utilisateur peut réellement créer une mise en page raisonnablement courante.

Le bloc de section DOIT être dans le noyau de Gutenberg (et configurable et extensible par thèmes) afin de résoudre enfin les problèmes de pouvoir mettre en page des pages plus complexes tout en étant capable de changer de thème.

Bien sûr, en tant que concepteur de thèmes, je vais ajouter ma propre palette de couleurs, contrôler les marges et le remplissage pour correspondre à mes thèmes, mettre en forme les images pour correspondre, et toutes ces sortes de choses de «conception» spécifiques au thème ... mais un utilisateur devrait pouvoir basculer vers n'importe quel thème WordPress et au moins avoir son contenu conservé, essentiellement dans la même mise en page (sections groupées, colonnes, etc.), et être modifiable en tant que bloc Gutenberg (ne pas avoir à passer au bloc HTML personnalisé).

J'ai un plugin de bloc de section dont j'ai une version précoce de travail, et j'espère mettre à jour plus tard cette semaine et le soumettre au référentiel. Cela permet une imbrication infinie du bloc (je veux dire, dans la limite du raisonnable, je suppose). Le plugin permet également aux thèmes ou aux plugins de définir leurs propres styles de section s'ils le souhaitent, qui peuvent ensuite être choisis par l'utilisateur. Je prévois d'inclure seulement quelques styles par défaut, qui peuvent être désactivés par thèmes, si vous le souhaitez.

Panneaux d'inspecteur

• _Background._ Mon plugin permet de définir la couleur d'arrière-plan et / ou l'image si vous le souhaitez, avec des contrôles pour le placement de l'image, le mélange, la désaturation et même la superposition d'une couleur.
• _Dimensions, Padding, Margins._ Par défaut, les sections s'alignent automatiquement sur le contenu et obéissent aux alignements complet, large et central, avec gauche et droite à 45%. Cela dit, j'ajouterai des contrôles pour autoriser une largeur et / ou une hauteur spécifiées, un remplissage autour des InnerBlocks et une marge autour du bloc. _Mais voir ci-dessous les problèmes avec Gutenberg._
• _Colonnes ... et lignes._ Après beaucoup d'expérimentation avec flex, CSS _grid_ pour les enfants immédiats est la meilleure méthode à utiliser si vous recherchez une mise en page basée sur des colonnes. L'utilisation de la grille est une bascule; sinon les enfants ne sont que des blocs normaux. (Honnêtement, bien que les lignes soient faisables, elles ajoutent beaucoup de complexité à l'interface d'édition, ce qui pourrait être mieux géré en ajoutant une nouvelle section sous celle sur laquelle vous travaillez lorsque vous devez commencer une nouvelle ligne.) La grille est supérieure à flex - même si vous ne faites que des colonnes - parce que flex _ nécessite_ une hauteur spécifique, sans pourcentage, à définir soit sur le conteneur soit sur les éléments enfants, ce qui supprime beaucoup de flexibilité.

Mobile
Un problème avec tout plugin de section utilisant une grille est ce qui arrive à la grille aux points d'arrêt mobiles définis. Les utilisateurs (ou les auteurs de thèmes) doivent être en mesure de définir quand une section passe de l'affichage de 3 éléments à 2 éléments à travers à 1 élément à travers.

Les points d'arrêt doivent pouvoir être définis par le thème et ne pas vraiment avoir l'impression d'appartenir au bloc eux-mêmes, car cela ajoute encore un autre grand ensemble de choix d'inspecteurs, et vous voulez probablement que vos points d'arrêt soient cohérents entre les articles et les pages. . Mais lors de l'utilisation de l'option de grille, le bloc doit connaître les points d'arrêt et doit permettre à l'utilisateur (ou au thème) de spécifier comment la disposition de la section s'y adapte.

Je suis sûr qu'il existe un moyen élégant de le faire, mais à court terme, pour des raisons de commodité, j'autorise simplement le bloc à "apprendre" les points d'arrêt via la configuration, puis à utiliser une liste de valeurs séparées par des virgules pour le défini points d'arrêt (imaginez une capture d'écran ici):

Columns:        3,2,1,1
Column 1 width: 70%,50% 

Etc. (Évidemment, les colonnes simples sont à 100% et n'ont pas besoin d'être spécifiées).

Considérations relatives au thème et au plugin
Un thème (ou plugin) peut définir une section, avec tous ses attributs, et masquer tous ces attributs à l'utilisateur, les épargnant d'une éventuelle confusion, ou le thème ne peut exposer que les éléments qu'il souhaite que l'utilisateur puisse modifier (par exemple, l'image d'arrière-plan réelle choisie). Les thèmes ou les plugins sont également libres d'ajouter des fioritures en utilisant leur feuille de style pour spécifier les types de section ... en effet, en théorie, pourraient ignorer toutes mes boîtes d'inspecteur, masquer tous les panneaux d'inspecteur à l'utilisateur et styliser les choses entièrement avec leur feuille. Cependant, cela supprime la possibilité pour les utilisateurs de survivre à un déplacement de thème avec leurs sections intactes.

Considérations utilisateur
En supposant que le thème a bien joué et a utilisé les différents chemins disponibles dans mon bloc pour définir une section et ses attributs "correctement", si le thème est changé, tous ces attributs survivent, et si le thème les cachait jusqu'ici à l'utilisateur, ils ' re exposé. Ceci est dû au fait que le premier choix dans le sélecteur de "section pré-stylée" est "personnalisé", ce qui permet à l'utilisateur de tout modifier, et c'est ce à quoi le bloc sera par défaut si le style précédemment choisi n'est plus disponible. Tous les paramètres définis par le thème qui n'étaient PAS des choix directs de feuille de style seront toujours là.

Cela ne garantit pas que votre section survit d'une manière qui semble bonne (vous avez peut-être eu un thème qui avait une mise en page super large et passer à un avec une mise en page étroite, donc une section à six colonnes peut ne plus être le meilleur choix ... mais il sera toujours là intact. Les utilisateurs peuvent enregistrer cette mise en page en tant que bloc réutilisable.

Lors du choix des styles de section, si vous passez d'une section prédéfinie à personnalisée, les attributs d'inspecteur de la section prédéfinie suivent, c'est donc un moyen pour les utilisateurs de modifier une section prédéfinie sans avoir à modifier la définition de cette section dans le thème ou brancher.

Problèmes de Gutenberg
Donc, Gutenberg fait mal ce qui suit:

• Blocs qui doivent être assemblés verticalement, ce que vous pouvez parfois représenter des sections.
• N'importe quel type d'appel pour afficher quelque chose sous forme de flex ou de grille. En raison de la soupe div de l'éditeur, vous devez annuler votre appel CSS à grid ou flex sur le wrapper des blocs internes et le réinitialiser sur l'un des blocs de l'éditeur.
• Aligner à gauche et aligner à droite. J'ai déposé un bug à ce sujet, mais comme Gutenberg ne limite pas le flottant d'un bloc gauche ou droit au seul enfant immédiat du bloc ayant l'attribut de données gauche ou droite (ou centre), tous les blocs imbriqués suivants sont flottants à gauche ou droite.
• L'ajout de nouveaux blocs est souvent un mystère complet où ils seront insérés ... vous pensez que vous êtes au bas de votre section, voulant un nouveau bloc interne, et à la place l'éditeur en insérera un au bas de votre document
• Le modèle glisser / déposer de Gutenberg pour déplacer des blocs ne fonctionne pas de manière fiable avec des blocs qui peuvent avoir une position horizontale

L'essayer
Je publierai un lien dans ce fil de discussion lorsque je déposerai une version sur github qui, je pense, vaut la peine d'être examinée, si quelqu'un est intéressé. J'ai passé quelques mois là-dessus, et ce n'est probablement toujours pas génial, mais c'est quelque chose.

Je dois ajouter que je crois fermement que des éléments tels que les polices, les tailles de titre, etc. Les attributs de l'inspecteur que je suis en train de définir me semblent être les bases nécessaires pour préserver les attributs «grande image» d'une section d'un thème à l'autre, ou pour empêcher la suppression d'un plugin de gâcher complètement l'apparence d'un site.

@rogerlos Vous devriez envisager de jeter un œil à Kadence Blocks . Ils semblent gérer assez bien les colonnes basées sur la flexbox.

Je dois ajouter que je crois fermement que des éléments tels que les polices, les tailles de titre, etc.

Je suis complètement d'accord avec ça. La seule exception serait un paramètre de "couleur de police" au niveau de la section. Cela est nécessaire car un site dont les polices sont principalement sombres ne contrastera pas suffisamment dans une section qui a une image / superposition de fond sombre.

Voici une démonstration de la façon dont le bloc de disposition des lignes de Kadence réutilise les «modes d'alignement» dans la barre d'outils du bloc pour permettre trois largeurs de contenu interne différentes, des largeurs de colonne ajustables, des marges de ligne supérieure / inférieure ajustables, ainsi que des paramètres de couleur d'arrière-plan et de texte.

Ces paramètres de "largeur maximale de la section de contenu" sont presque les seuls modèles à répétition globale (et donc définis par thème) qu'un bloc de section doit prendre en compte (autres que les restrictions de composants héritées globalement, telles que les couleurs de police autorisées, les tailles de gouttière de colonne, etc. )

Venant de l'expérience d'une agence Web, il n'y a pas plus de trois largeurs de section de contenu différentes dans n'importe quel design que j'ai reçu. Tout ce qui se trouve en dehors de ces trois largeurs a tendance à être une variation spécifique au contenu qui se détache intentionnellement des modèles de conception du thème de manière non répétitive.

Un bon bloc de section dirigera les utilisateurs vers les paramètres par défaut définis par thème (en suivant les modèles de la conception d'origine), mais leur permettra parfois de rompre avec ces modèles de manière raisonnable.

Afin de garantir une mise en page cohérente et prévisible sur toutes les tailles d'écran, aucun bloc «orienté texte» n'est autorisé au niveau racine dans notre configuration.

Tous les blocs non-image / incorporés doivent être contenus dans une "section" (Kadence Row Layout) au niveau de la racine, qui applique les largeurs de section de contenu de notre thème, tout en autorisant des lignes entièrement personnalisables avec un nombre quelconque de colonnes ainsi qu'un arrière-plan pleine largeur options, etc.

Les éléments de conteneur devraient également permettre l'empilement des éléments de couche (z-index).
Cela permet par exemple un élément vidéo ou un curseur comme arrière-plan ou un effet de parallaxe.

@strarsis Bonne idée.

Idéalement, un bloc de section utiliserait z-index pour fournir un mode d'édition de premier plan / arrière-plan basculable.

De cette façon, le bloc de section lui-même ne réinvente pas l'image d'arrière-plan / les éléments de superposition, qui sont tous disponibles sur le bloc d'image de couverture intégré.

Le contenu d'arrière-plan ne serait pas limité par la largeur et les développeurs de thèmes devraient donc avoir la possibilité de définir quels blocs peuvent entrer dans un arrière-plan de section. La largeur du contenu de premier plan serait limitée à un certain nombre de largeurs maximales fournies par le thème.

Si l'utilisateur a besoin de s'éloigner d'une largeur par défaut pour un contenu spécifique, il peut choisir une section avec la largeur suivante la plus grande et remplir les côtés en conséquence.

Les instances où le contenu de premier plan doit visuellement sortir de la largeur maximale d'une section doivent être enregistrées en tant que variation de style qui ajuste une marge négative sur ce bloc spécifique.

La raison en est que, bien que les utilisateurs puissent ajuster les valeurs de remplissage en toute sécurité, nous ne voulons certainement pas que les marges négatives soient définies par l'utilisateur.

Autoriser la définition des marges négatives dans l'éditeur serait un gâchis lors de la réponse à différentes tailles d'écran, rembourrages latéraux de section de contenu, largeurs de gouttière à certains points d'arrêt, etc. et devrait donc être étroitement associé au thème / code et exposé en tant qu'abstractions de niveau supérieur à l'utilisateur final.

Concernant le contrôle développeur: il existe le plugin Mesh qui fournit des conteneurs "durs",
qui devrait être forcé par le thème.
Un thème doit parfois contraindre les zones disponibles, comme uniquement le coin supérieur gauche de la page entière.
Gutenberg devrait fournir un mécanisme pour que les thèmes définissent ces conteneurs «durs» dans son éditeur de page.

@strarsis À mon avis, tout ce qui se passe en dehors de la zone the_content() n'a rien à voir avec l'éditeur Gutenberg.

Ces «zones» font partie du modèle de page et non du contenu de la page et doivent être traitées ailleurs.

Contenu de la page et modèle de page (/ mise en page)

Le contenu / les sections à l'intérieur de l'éditeur doivent supposer que la mise en page environnante n'existe pas (pendant l'édition), et à la place être équipés pour répondre de manière appropriée lorsqu'ils sont placés à l'intérieur d'une mise en page particulière (sur le front-end).

Un élément fait partie d'un modèle de page ( et non du contenu de la page ), si:

1. l'élément définit ou dépend de la structuration, des limites ou du positionnement de la zone the_content() dans son ensemble , et
2. l'élément fait partie d'un motif répétitif (c'est-à-dire qu'il peut potentiellement être vu sur deux ou plusieurs permaliens)

Certains antécédents basés sur l'expérience

Les éléments de modèle / mise en page répétés sont généralement spécifiques à un type de publication personnalisé et incluent des héros de contenu, des barres latérales de contenu et des pieds de page de contenu.

Dans chaque cas, j'ai constaté que le contenu de ces éléments de mise en page est suffisamment dérivé d'informations situées dans des champs personnalisés, des taxonomies ou d'autres paramètres situés au niveau de la publication et non au niveau du bloc.

Et, dans chaque cas, j'ai renforcé ma conviction que ce serait une entreprise incroyable de modifier ou de redéfinir en bloc ces sections si elles avaient été implémentées sous forme de blocs dans l'éditeur Gutenberg.

Alors enfin

La définition (et l'implémentation éventuelle) d'une Section ne devrait s'étendre que suffisamment pour gérer les besoins des modèles de conception du thème en ce qui concerne the_content() .

Tout ce qui relève du "modèle" et non du "contenu" doit être traité en dehors de tout bloc Section et en dehors de l'éditeur Gutenberg (pour le moment).

Je veux que Gutenberg soit capable de créer des modèles en ligne avec du contenu autant que tout le monde, mais nous ne semblons pas encore y être, et nous devrions définitivement clouer ce bloc de section avant de pouvoir gérer la création de modèles de manière appropriée.

Il y a quelques jours, je voulais créer une mise en page de base et j'en avais besoin. J'ai donc commencé par installer le plugin A, je l'ai essayé, c'était bogué. Désinstallé, trouvé le plugin B, installé, essayé son bloc de section, c'était baaad. Suivant le buggy du plugin C, le plugin D l'appelait un conteneur et c'était meh. Plugin suivant E, F .........
Je peux vous assurer que «l'écosystème» actuel de Gutenberg est très, très frustrant si vous voulez créer une page et écrire du contenu.
Le fait que les gens ici continuent de dire "regardez le plugin X", "si vous voulez cette fonctionnalité, installez le plugin Y", etc. est une indication claire que les gens en ont besoin. Ils ne le veulent pas, ils en ont besoin . À l'heure actuelle, il existe une douzaine de plugins, tous avec leur propre implémentation d'un conteneur / section / peu importe ce que vous voulez.
Je ne dis pas que Gutenberg devrait ajouter toutes les fonctionnalités sous le soleil, mais c'est une fonctionnalité basique. Il doit être là. Il n'a pas besoin d'avoir toutes les options imaginables, mais les bases devraient être là et les développeurs peuvent s'étendre si nécessaire.
Nous arrivons à un point où il y aura 20 implémentations différentes pour un conteneur de base et aucune d'entre elles ne fonctionnera comme elle le devrait (opinion personnelle bien sûr).

Comme alternative simple, j'ai simplement utilisé un bloc de colonnes et défini le nombre de colonnes sur 1 (le curseur est limité entre 2 et 6, mais vous pouvez entrer 1 dans le champ de saisie). Après cela, vous devez corriger CSS dans l'administrateur:

//Allow single columns
add_action('admin_head', 'gutenberg_allow_single_columns');
function gutenberg_allow_single_columns() {
    ?>
    <style type="text/css">
    <strong i="6">@media</strong> (min-width: 600px) {
        .wp-block-columns.has-1-columns > .editor-inner-blocks > .editor-block-list__layout > [data-type="core/column"] {
            flex-basis: 100% !important;
            flex-grow: 0; } }
    </style>
    <?php
}

Et bien sûr, vous devez définir la même chose dans votre frontend, mais c'est un problème de thème. Je pense qu'autoriser une disposition à une seule colonne suffirait pour une option de conteneur de base, qui est généralement nécessaire à des fins de style de toute façon. Tout le reste (comme définir un arrière-plan, un z-index, une parallaxe, etc.) doit être fait avec les plugins imo.

Et s'il vous plaît ajouter un moyen pour le thème (développeurs) de contrôler combien et quels wrappers sont utilisés.
Certains modèles ont juste besoin de plus d'un élément. Actuellement, je dois utiliser un autre plugin pour un élément conteneur, puis analyser tout le contenu à l'aide d'un analyseur PHP pour envelopper le contenu du conteneur dans des éléments wrapper supplémentaires pour le style.

@strarsis C'est certainement quelque chose qui aurait dû être fait depuis le début.

Afin de donner un style décent au contenu de l'article, chaque enfant de niveau racine doit être placé dans une ligne / section cohérente.

Par exemple, sans envelopper chaque ligne, il est difficile et piraté de faire des sections de largeurs différentes (en particulier des sections pleine largeur).

J'ai également envisagé l'option d'analyse PHP, mais j'ai réalisé qu'elle ne donne à l'éditeur de contenu aucun contrôle sur le type de section dans laquelle se trouve un élément de contenu particulier.

Au lieu de cela, dans notre configuration, nous forçons toutes les instances de l'éditeur Gutenberg à n'autoriser qu'un seul bloc Container au niveau racine pour tout type d'article / page / article.

Le bloc de conteneur racine applique un sous-ensemble limité de blocs qui peuvent être ajoutés à l'intérieur.

Pour ajouter du texte ou des blocs non pleine largeur, vous devez d'abord insérer une disposition de ligne Kadence, qui dans ce cas agit comme notre élément principal de wrapper de section.

Un simple bloc de conteneur extensible est tout ce qui devrait être requis dans le noyau. L'extension de ce bloc en ce qui concerne le style devrait être laissée aux développeurs de plugins / thèmes. Il doit également fournir un état de transformation de secours pour les développeurs souhaitant créer leurs propres blocs de conteneur.

Tous les plugins tiers existants fournissant des conteneurs / sections / lignes que j'ai testés sont soumis à un problème important en ce qui concerne le verrouillage du contenu. Lors de la désactivation de ces plugins, le contenu du bloc interne n'est plus accessible depuis l'éditeur et leur conversion supprime le HTML. Quelque chose dont les utilisateurs doivent être pleinement conscients.

Voir:
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

D'accord. J'ai testé Gutengerg, c'est bien, mais oui, il manque définitivement le truc Section.
Pour être vrai, beaucoup de blocs ont leur conteneur auquel nous pouvons ajouter une classe css et leur style. Mais, le contenu principal est écrit sans conteneur, donc ni aucune classe, et donc nous ne pouvons pas le styliser. Et comme le contenu principal est écrit au même stade que tous les autres blocs, cela rend extrêmement difficile de le boxer différemment des autres.

En d'autres termes, je vais revenir au classique et attendre que vous nous donniez des sections.

Merci, salutations.

Ouais, c'est absolument vrai. Je pense que c'est encore plus important que tous les autres blocs en cours de développement. @youknowriad Ne pouvez-vous pas lui donner plus de priorité?

C'est déjà sur la portée de la phase 2 https://github.com/WordPress/gutenberg/issues/13113 si quelqu'un est prêt à essayer, veuillez le faire.

@youknowriad J'ai bien peur de ne pas être un développeur. Mais je me souviens que le développement était déjà en cours. Peu de temps avant la sortie de Wordpress 5, il y avait un PR qui était déjà très avancé. Il y avait encore des détails à clarifier, mais c'était presque prêt. Malheureusement, je ne trouve plus le PR. Quelqu'un a-t-il une idée d'où cela se trouve?

Oui, ne t'inquiète pas, je comprends.

Voici le PR. https://github.com/WordPress/gutenberg/pull/10562

Je voulais préciser que c'est un projet open source et qu'il est basé sur le volontariat. Je peux donner une direction globale, demander de l'aide mais pas affecter des personnes. Les gens ont tendance à penser autrement.

Je répète que s'il y a des développeurs qui souhaitent voir cela se produire plus rapidement et qui souhaitent aider, ils sont les bienvenus aux réunions hebdomadaires dans le canal Core Slack # core-editor (et aux réunions) et discutent / collaborent / demandent de l'aide.

Ahhh oui c'est ça! Génial! Vous avez un aperçu !!!

Oui, c'est vrai et cela ne devrait pas être un reproche. Ce que je me suis simplement demandé: n'y a-t-il pas de tâches importantes et encore plus importantes? Si 50 personnes ont besoin d'un bloc RSS, mais que 1000 ont besoin d'un bloc conteneur, il serait logique de concentrer le tout plus spécifiquement. Le bloc de conteneurs n'a plus rien d'exotique maintenant. Je pense que c'est la _base pour chaque design_.

Ne vous méprenez pas: vous faites un excellent travail. Et vous, en tant que leader de la phase 2, faites un travail de première classe. Tout est question de concentration. Je porterai un toast à la prochaine discussion en mode mou ... ;-)

Merci encore!

Merci et heureux de clarifier. Je leur donne personnellement la même importance. Une étape intermédiaire pour la phase 2 consiste à utiliser des blocs dans l'écran des widgets. Donc, même si les gens ne demandent pas de bloc RSS, une fois que l'écran des widgets (ce qui est une étape importante pour la phase 2) va utiliser des blocs, si les gens ne trouvent pas le widget RSS qu'ils ont l'habitude d'utiliser, ils m'en plaindre.

Ces deux tâches sont des tâches «moyennes» en termes de complexité, elles sont importantes du point de vue des fonctionnalités, mais elles ne le sont pas du point de vue du cadre. Ma haute priorité personnelle pour le moment est les éléments de cadre qui permettraient les objectifs de la phase 2 (blocs dans l'écran des widgets, éditeur en dehors de post_content) car ces problèmes conceptuels sont importants à expérimenter et à clarifier le plus tôt possible.

D'accord. J'ai testé Gutengerg, c'est bien, mais oui, il manque définitivement le truc Section.
Pour être vrai, beaucoup de blocs ont leur conteneur auquel nous pouvons ajouter une classe css et leur style. Mais, le contenu principal est écrit sans conteneur, donc ni aucune classe, et donc nous ne pouvons pas le styliser. Et comme le contenu principal est écrit au même stade que tous les autres blocs, cela rend extrêmement difficile de le boxer différemment des autres.

En d'autres termes, je vais revenir au classique et attendre que vous nous donniez des sections.

Merci, salutations.

C'est la position que je prends sur cette et d'autres lacunes du nouvel éditeur de blocs jusqu'à ce qu'il se concrétise. Espérons que cela se produira car il y a quelques aspects intéressants dans le nouvel éditeur.

Un bloc de section serait génial, que puis-je faire pour aider même si je manque de compétences en développement backend.

Il y a maintenant beaucoup de plugins de bloc, mais le seul bloc que je veux est une section ou un bloc de conteneur, donc j'aimerais en voir un ajouté.

Le noyau de WordPress doit inclure sa propre implémentation d'une structure de disposition de sections, de lignes et de colonnes pour l'éditeur de blocs, quelque chose qui est standard et qui peut être utilisé par tous les plugins, thèmes et constructeurs de pages tiers. Une API doit être fournie, comme je l'ai déjà mentionné à plusieurs reprises, afin que ceux-ci puissent ajouter leurs propres interfaces, cloches et sifflets. Désactivez l'une de ces solutions tierces et la structure de votre page reste intacte.

Dans l'état actuel des choses, il existe des solutions tierces pour les sections / lignes provenant de toutes les directions, mais une fois que vous commencez à mélanger des blocs de base natifs et des blocs tiers, vous commencez à voir de nombreuses incohérences et blocs qui se bloquent et doivent être résolus. Non pas que je veuille critiquer les efforts de ceux qui fournissent ces solutions pour la mise en page, ils remplissent une fonctionnalité bien nécessaire. Beaucoup d'entre eux sont bons, mais quelque chose ne va pas dans l'expérience globale.

Je suis tout à fait favorable à la simplicité de l'éditeur de blocs de base, permettant à des tiers d'ajouter des fonctionnalités et de la sophistication supplémentaires, mais il doit vraiment être renforcé, sinon obtenir une certaine traction sur son acceptation ne se fera tout simplement pas très facilement.

La grande question ici est de savoir qui s'en occupe. N'y a-t-il pas quelques développeurs qui ont le temps et l'énergie de le faire?

Oui oui oui! Je crois qu'un bloc de section flexible est la principale caractéristique manquante de Gutenberg.

Je ne peux même pas croire que ça n'existe pas encore ...

Une alternative serait de permettre au bloc de colonnes de n'avoir qu'une seule colonne et de définir également les couleurs d'arrière-plan des colonnes. TA-DA: bloc de section.

Eh bien, si cela aide quelqu'un: nous avons écrit une section Block pour nos projets il y a quelque temps. Je suis sûr que cela peut être embelli à certains moments, mais cela pourrait être un bon point de départ:

https://github.com/Impuls-Werbeagentur/impuls-section-block

Je vais lever la main pour travailler là-dessus. Je pourrai commencer à partir du milieu de la semaine prochaine

@chrisvanpatten - il semble que vous ayez fait de très bons progrès auparavant, je voulais juste vérifier que vous êtes d'accord pour que je prenne ça?

J'ai utilisé des blocs conteneurs à partir de plugins. Je pense que les principales exigences sont de prendre en charge un alignement large et complet, des flotteurs et des contrôles pour modifier l'arrière-plan du conteneur. Viser à expédier cela dans une première version fournira une bonne base pour d'autres améliorations.

Je pense que la première amélioration consiste à ajouter plus de wrapper en dehors de tout bloc.

Par exemple:

<div class="wp-block-paragraph">
  <div class="wp-block-paragraph__container">
    <InnerContent />
  </div>
</div>

À l'heure actuelle, de nombreux éléments sont insérés directement, ce qui nous empêche d'appliquer un style pour créer un wrapper.

<ol>
  <li></li>
</ol>

Peut être ajouter un wrapper à cela:

<div class="wp-block-listing">
  <div class="wp-block-listing__container">
    <ol>
      <li></li>
    </ol>
  </div>
</div>

Ensuite, nous pouvons appliquer un ensemble de conteneurs pour les garder correspondants:

// Example
#content > * > * {
  max-width: 1280px;
  padding: 0 20px;
}

@talldan vous dérangerait de jeter un œil sur ce problème - il serait bon d'avoir votre avis sur la nécessité d'un bloc Core Container pour fournir un état de `` repli '' pour les blocs de conteneurs tiers.
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

Les blocs de section seraient géniaux, mais faites-en un balisage sémantique uniquement! Garder les choses dans une structure HTML sémantique créerait la base de code la plus agnostique.
<section>, <article>, <header> est bien meilleur <div class="wp-section"> ou peu importe.

@talldan Désolé, j'ai manqué votre commentaire, mais je suis à 100% d'accord pour que vous le preniez dessus 🙌 Je suis sûr que vous allez le bercer!

Ce serait également formidable de pouvoir utiliser le point focal du bloc texte et média # 10925. Bien sûr, cela n'a de sens que si vous avez un arrière-plan d'image.

Une grande chose, que, d'ailleurs, beaucoup de constructeurs de pages ont également. Ou du moins quelque chose comme ça:

A convenu qu'un sélecteur de point focal serait génial ici. Cela fonctionne vraiment bien dans le bloc de couverture!

Dans cet esprit, j'ai mis à jour mes maquettes précédentes pour un bloc de section. Il agit uniquement comme un élément de conteneur avec une couleur et une image d'arrière-plan réglables.

Aperçu :

Vous pouvez consulter le prototype ici .

Quelques remarques supplémentaires:

• Je pense que nous devrions le lancer sans image de fond pour commencer, seulement la couleur de fond / texte. Une fois que nous avons poussé cela, nous pouvons ensuite créer une image d'arrière-plan. Cela le sort rapidement, en utilisant les modèles existants, et devrait encore couvrir un grand nombre de cas d'utilisation.
  
  
  
  • Une fois que nous avons fusionné la première version, nous pourrions potentiellement désapprouver la couleur de fond et de texte du bloc de texte. Au lieu de cela, nous pourrions avoir des options de couleur en ligne / des options de surbrillance dans le bloc de paragraphe. Cela semble être un meilleur modèle global pour le paragraphe.
  
  
• Ce bloc ne contiendrait aucun paramètre réactif, car ce serait toujours juste un conteneur. Le contenu à l'intérieur du conteneur (comme un bloc de colonnes) fournirait le comportement réactif.

Je suis d'accord, l'image de fond peut être ajoutée en utilisant css si nécessaire pour le moment: +1:

Une fois que nous avons fusionné la première version, nous pourrions potentiellement désapprouver la couleur de fond et de texte du bloc de texte. Au lieu de cela, nous pourrions avoir des options de couleur en ligne / des options de surbrillance dans le bloc de paragraphe. Cela semble être un meilleur modèle global pour le paragraphe.

L'une des raisons pour lesquelles le bloc de section est le bon endroit pour les couleurs au niveau du bloc est que sinon, nous devons expliquer pourquoi la liste, l'en-tête et les autres blocs de texte de base n'ont pas ces options de couleur. Et comme ceux-ci sont divisés au niveau du bloc, vous ne pourrez jamais avoir une image d'arrière-plan qui couvre tous ceux-ci en continu, alors qu'un bloc de section corrige cela.

Le moyen de déprécier ces couleurs pourrait potentiellement être de simplement supprimer l'interface utilisateur, mais de laisser les blocs existants conserver leur style.

Agréable! Il serait utile d'avoir des classes petites / moyennes / grandes pour le remplissage vertical.

Agréable! Il serait utile d'avoir des classes petites / moyennes / grandes pour le remplissage vertical.

Cela plonge dans le niveau du thème / du cadre, et je ne suis pas sûr que le noyau ait une place pour quelque chose comme https://cdn.vaadin.com/vaadin-lumo-styles/1.4.1/demo/sizing-and-spacing .html

Je pense que nous devrions le lancer sans image de fond pour commencer

Je ne pourrais pas être plus d'accord. Sortez une v1, puis la v2 peut ajouter les fonctionnalités les plus complexes.

Ce bloc ne contiendrait aucun paramètre réactif

D'accord - ce bloc doit être aussi simple et sans opinion que possible.

Je pense que nous devrions fusionner ce PR si possible.

J'ai pris un coup à quelque chose comme ça ... publié sous forme de plugin:

https://wordpress.org/plugins/magic-block/

S'il vous plaît, plus de plugins qui laisseront les gens en dépendre. Relâchez juste le putain de bloc déjà.

@webdados J'appuie cela.

Pas pour diminuer le travail de qui que ce soit, mais nous avons vraiment besoin que cela soit intégré à un certain niveau.

Surtout dans un monde où il y a ce problème .

Si une solution adéquate était trouvée pour # 13391, alors l'existence d'innombrables implémentations de blocs de conteneurs serait probablement bien.

Jusqu'à ce que le nouveau générateur de blocs se fissure ayant une base standard pour les éléments de mise en page (conteneurs, sections, colonnes de lignes) que les plugins tiers peuvent étendre, alors cela ne sert à rien et perpétue le désordre de l'activation et de la désactivation de blocs tiers, de thèmes, de constructeurs ( ceux qui tentent de résoudre le problème de mise en page) et finissent par perdre le contenu et la mise en page.

Quand pouvons-nous nous attendre à cette fonctionnalité?

Devrait déjà être dans la dernière version:
https://github.com/WordPress/gutenberg/releases/tag/v5.5.0

@ksere : J'ai manqué cela probablement parce que le journal des modifications pour la v5.5.0 du plugin est vide .

Creuser vraiment la mise en œuvre à ce sujet jusqu'à présent. Je crois comprendre qu'il vient de sortir en 5.5, mais je me demande quand nous pourrions nous attendre à des ajouts pour les images d'arrière-plan (et leur positionnement), l'opacité de la couleur d'arrière-plan, etc. -term que ça?

@nathansnelgrove Merci pour vos commentaires. Il y a certainement des améliorations à venir dans le bloc de groupe, en voici deux déjà en cours:

• Ajout d'un conteneur interne pour faciliter le style - https://github.com/WordPress/gutenberg/pull/15210
• Ajout d'options d'édition pour regrouper / dégrouper une sélection de blocs - https://github.com/WordPress/gutenberg/pull/14908

Je n'ai pas vu les problèmes que vous avez mentionnés concernant le suivi des images d'arrière-plan et de l'opacité, cela pourrait valoir la peine de créer un problème distinct pour cela si vous avez le temps car ce problème est maintenant clos.

Les images d'arrière-plan / couleurs / opacité proviennent de la proposition originale - je leur ferai un nouveau numéro.

Je viens d'installer WordPress 5.2.4 et je ne trouve aucun bloc "Section" ou "Groupe". Que se passe t-il ici?

@patrikhuber : Cela sera inclus dans WordPress 5.3 dont la sortie est actuellement prévue pour le 12 novembre.

@noisysocks je vois, merci beaucoup!