Gutenberg: Agregar bloque: sección

¡Realmente me gusta esta idea! También me gusta el hecho de que tiene una configuración de fondo.

¡Agradable! ¿Y si el bloqueo permitiera las siguientes tres configuraciones 'avanzadas':

• Defina un nombre de clase que se serializará en los hijos .child_class, .child_class_1
• Agregue una primera clase para niños opcional .child_class, .child_class_1, .child_class_first
• Agregar una última clase secundaria opcional .child_class, .child_class_n, .child_class_last

:nth-child selectores

Amo esta idea. Si se pueden alterar los colores del fondo y del texto, también podría tener sentido agregar colores de enlace.

Excelente idea. Esto literalmente agregará mucho valor a Gutenberg Editor.

Mucho mejor que solo el bloque Columns, que tiene muchos problemas. ¡Frio!

Esto es lo primero que me propuse crear cuando vi que el anidamiento estaba disponible. Mi versión es similar, excepto que imaginé que agregaría el bloque de columnas.

¿Tiene un código para esto disponible?

Si este bloque tiene "columnas", deberíamos simplemente actualizar el bloque "columnas". Pero aún es posible usar un bloque de columnas dentro de un bloque de sección y mantener el bloque de sección sin columnas.

Siempre que no pueda poner bloques de columnas dentro de bloques de columnas 😉

Muchas páginas del sitio están divididas en secciones que tienen contenido mixto con varias filas de columnas y, a menudo, columnas anidadas dentro de otras más grandes. Este es un ejemplo rápido:

Un bloque de sección que actúa como un simple contenedor, creo que sería el más flexible. (¡como si pudiera anidar bloques de columnas!)

Lanzamos un nuevo proyecto de sitio esta semana. Normalmente se construiría con diseños de contenido flexibles de Campos personalizados avanzados, pero voy a ver hasta dónde podemos llegar usando Gutenberg solo.

Sí, creo que las secciones de varias columnas como el ejemplo anterior de @jvisick no son infrecuentes. Un contenedor con opciones de fondo / texto que anida bloques sería el enfoque más flexible. Dado que ahora tenemos un bloque de columnas en funcionamiento, incluso podríamos considerar eliminar la opción de columna de este.

Sería genial si hubiera un contenedor interno (div) en este bloque que luego contiene todos los bloques secundarios. A este contenedor se le podría aplicar estilo con max-width y margin-left / right: auto para centrar los bloques secundarios y tener un fondo de ancho completo.

Tener una sección de ancho completo con el contenido contenido en un diseño más estrecho es un patrón de diseño común. Me pregunto si sería mejor controlado por los bloques anidados en lugar de hornear en el bloque de la sección principal.

Creo que un bloque de sección sería muy útil para ... bueno, secciones en una página, y estoy de acuerdo en que las columnas deben ser un bloque separado (como el que existe ahora) que se puede anidar en un bloque de sección. Creo que esto es algo que, junto con el bloque Columns, debería incluirse en la versión de Gutenberg que se fusiona con WordPress 5.0. Si observa los complementos de creación de páginas existentes, las secciones se usan mucho, al igual que las columnas (obviamente), por lo que incluirlas en la versión principal inicial es esencial en mi opinión.

(También creo que es importante que el bloque de columnas obtenga características como columnas de ancho variable y columnas receptivas, tanto por el bien de la experiencia central como para facilitar que los creadores de páginas existentes se vuelvan a basar en Gutenberg, pero ese es un tema aparte.)

Habiéndolo pensado un poco más, creo que tendría más sentido que el bloque Sección y Columnas fueran lo mismo. Simplemente agregue la capacidad de tener solo una columna en el bloque Columnas en lugar de un mínimo de dos. Luego agregue la configuración de fondo de este bloque de Sección propuesto al bloque de Columnas.

Creo que tener un solo bloque de Sección / Columnas reduciría la cantidad de anidamiento que tendría que hacer. En este momento, el bloque de sección propuesto no es más que un área con opciones de fondo y ancho. Ambos podrían agregarse al bloque Columns, y si el bloque Columns permitiera tener solo una columna, no habría necesidad de un bloque de Sección.

Además, si desea una sección de ancho completo con contenido de ancho estándar, esto se puede lograr anidando otro bloque de Sección / Columnas en otro que esté configurado en ancho completo. Se puede hacer con una configuración en el inspector para cambiar el ancho del contenido del bloque independientemente del ancho de todo el bloque .; esto también podría agregarse como controles de cambio de tamaño visibles, similar a cómo funcionan las filas / columnas de Beaver Builder, o cómo funciona el bloque de imagen en Gutenberg.

En cuanto a lo que llamaría este bloque combinado, creo que simplemente mantener el nombre "Columnas" funciona, ya que esa es la función más obvia que la gente estaría buscando. No debería ser difícil encontrar la configuración de fondo en el inspector (e imagino que sería donde algunas personas buscarían en primer lugar de todos modos si hubiera un bloque de Sección separado y no lo supieran), y usando las Columnas block como contenedor de una sola columna no debería ser difícil de descubrir, ya que el control deslizante para cambiar el número de columnas debería hacer que sea bastante obvio cómo hacerlo ... simplemente arrástrelo hacia la izquierda.

He cambiado de opinión acerca de la fusión de los bloques Sección y Columnas. Para obtener la mayor flexibilidad con las columnas, lo más lógico sería que cada columna sea su propio bloque: un bloque de columnas. Esto permitiría controlar fácilmente la configuración de una columna individual, así como arrastrar una columna de una fila a otra. Por supuesto, dado que las columnas van de izquierda a derecha (y se ajustan en la mayoría de los sistemas de diseño), necesitaría que su bloque principal sea uno que inserte contenido en esa dirección horizontal y tenga un ajuste (en lugar de la dirección vertical estándar) y esto El bloque padre probablemente solo permitiría insertar bloques de columna en él. Este bloque sería una Fila. Estos 2 bloques reemplazarían al bloque Columnas. Pero no cubren la situación en la que desea que varias filas (a menudo con diferentes números de columnas dentro de ellas) estén en el mismo fondo / contenedor, que es lo que haría el bloque Sección. Por supuesto, el bloque de sección no sería más que un contenedor con opciones de fondo, relleno y ancho, y cualquier bloque podría insertarse en él. Y para diseños más complejos, los bloques de sección se pueden insertar en bloques de columna.

Ver # 6461.

De hecho, creo que la idea de un mínimo de 1 columna no es una mala solución. De hecho, si usa su inspector para cambiar el atributo "min" del control deslizante a 1 y selecciona uno, funciona de manera muy similar a lo esperado.

Sin embargo, semánticamente, un bloque de sección tiene más sentido de todos modos. El contenido interno (es decir, una sección de ancho máximo dentro de una sección completa con) podría lograrse anidando dos secciones: un ancho de contenido dentro de un ancho completo.

La idea del color de fondo es agradable, pero ... tal vez un poco más específica. Creo que un enfoque más genérico sería usar clases personalizadas en la sección. El CSS de front-end podría captar eso y cualquier niño directamente.

Después de un poco de discusión en el # 6461, he decidido que mi idea de Bloque de fila + bloque de columna no es el camino correcto. Un bloque de diseño similar al del # 5351 (comentario) probablemente sería mucho menos confuso y mucho más flexible. En cualquier caso, definitivamente debería haber un bloque de sección, y creo que definitivamente debería agregarse antes del lanzamiento de WordPress 5.0.

En cuanto a las opciones de color de fondo, creo que tiene mucho sentido tener opciones de fondo en una sección. Tener solo opciones de clase parece un poco restrictivo. A menudo, el objetivo de anidar en un bloque de sección sería que varias cosas compartieran un fondo. Además, preferiría que se implementaran otras opciones de fondo como imágenes de fondo y fondos degradados, ya que a menudo se desean en lugar de fondos de colores sólidos. Los bloques de sección anidada incluso permitirían aplicar colores de fondo a un solo bloque, lo que significa que es posible que las opciones de color de fondo en el bloque de párrafo ya no sean necesarias.

En cuanto a anidar bloques de sección en lugar de tener 2 configuraciones de ancho separadas, creo que podría funcionar. La mayor preocupación que tendría es sobre la cantidad de relleno adicional que se agregaría al anidar bloques de sección, lo que conduce a opciones de relleno.

Creo que es esencial que el bloque Sección tenga la capacidad de personalizar la cantidad de relleno que usa, o al menos eliminar el relleno predeterminado. Por supuesto, esto plantea preguntas sobre cómo seleccionaría el bloque Sección cuando otro bloque está anidado en él. Creo que este problema se resolverá con mejoras como # 6471 y las cosas en las que se está trabajando en la rama try/alternate-hover-approach .

: +1:

Realmente necesitamos un bloque genérico de fila / contenedor, especialmente con configuraciones de ancho.

Idealmente, creo que otras configuraciones como "Color de fondo" y "Color de texto" deberían vivir en alguna pestaña de configuración "adicional" en cada bloque (además de varias otras configuraciones CSS generalmente aplicables).

En cuanto a la capacidad de respuesta, creo que deberíamos agregar un bloque "Responsive" .

El problema con el color de fondo y el color del texto es simplemente: ¿dónde termina? Ya en este hilo solo tienes a alguien sugiriendo el color del enlace. ¿Por qué no el color, el grosor y el estilo del borde? Para ser honesto, el relleno y el margen tienen más sentido. ¿Qué pasa con la sombra paralela, las imágenes de fondo, las opciones de posicionamiento y los modos de visualización? ¿Estilo y tamaño de fuente, altura de línea y altura mínima? Hay cientos de propiedades CSS y las que necesite variarán según su diseño.

Debería ser una clase, que luego puede usar para diseñar cualquier cosa, incluidos los elementos descendientes, o una lista filtrable de propiedades CSS para que el div del tema pueda conectarse y agregar las que desee.

@tmdesigned Termina con un control WYSYWIG intuitivo y con todas las funciones sobre el estilo, el formato y el diseño de una página web. ¿No es este el objetivo de Gutenberg?

Gutenberg está proporcionando al mundo un contenido web nuevo, bien planificado, de vanguardia, adaptable y ampliable WYSYWIG ... deberíamos averiguar cuánto queremos utilizar eso ahora o perderemos el barco.

La idea al final es reducir la cantidad de trabajo que estamos haciendo ahora, ya sea escribiendo CSS, escribiendo anulaciones de CSS hacky o realizando tareas de contenido repetitivas.

No todo puede o debe definirse con clases, especialmente si son clases mal dirigidas o atributos no reemplazables.

Tome una configuración numérica definida por el usuario, por ejemplo. Sería complicado definir una clase para cada valor y un desarrollador de bloques podría tener la tentación de simplemente inyectar el valor directamente en el atributo style .

Si existe como un bloque y puede tener aplicados estilos CSS definidos por el usuario, entonces idealmente debería haber un medio unificado y estandarizado para hacerlo, incluso si es un panel de cuadros de texto de pares clave / valor.

Si lo desea, puede leer mi método sugerido para hacer esto de una manera que aborde sus inquietudes.

Leí su sugerencia para una API y no está muy lejos de lo que estaba diciendo sobre un gancho agregado para permitir que se agreguen pares de valores clave.

Sin embargo, creo que mi punto original sigue siendo válido. Como dije, hay cientos de propiedades y, aunque algunas son más comunes, esa lista crecerá rápidamente. Podemos ir por ese camino e intentar encontrar un "buen compromiso" como con las características de TinyMCE que se incluyeron frente a las que se eliminaron en Classic. Pero hay muchas más propiedades en juego aquí, por lo que sería un desafío.

Pero lo que es más importante, la idea de agregar un estilo de nivel de bloque directo se rompe cuando se aleja un poco y no solo considera un solo bloque. Cuando tiene varios bloques similares, en una página o en varias páginas, no querrá volver a ingresar todos esos valores. Vas a querer una abstracción ... como una clase de CSS.

Permitir, o alentar, el estilo de nivel de bloque individual no es ideal porque no es reutilizable. Tienes razón al decir que no todo debería abstraerse en una clase, pero CSS se desarrolló por una razón y no debería tirarse al viento tan rápido.

@tmdesigned Agradezco sus comentarios. Creo que entiendo la confusión, así que intentaré aclararlo.

El objetivo no es eliminar ni reducir la cantidad de clases de CSS.

El objetivo es, muy específicamente, unificar la configuración de estilo de bloque

Los desarrolladores web, los desarrolladores de bloques, los desarrolladores de temas seguirán escribiendo código CSS para diseñar bloques y los bloques seguirán teniendo clases, atributos e ID para que los desarrolladores puedan diseñarlos.

Tendrán exactamente las mismas clases que tienen ahora y tendrán exactamente el mismo diseño que tienen ahora.

PERO

En el momento en que el desarrollador de bloques se da cuenta de que tiene propiedades CSS que el usuario podría / debería configurar ... es entonces cuando Gutenberg toma el control y decide cómo se inyectan (y potencialmente controlan) esos estilos.

Esto dará como resultado una única interfaz común (tanto para desarrolladores como para usuarios) cuando se trata de controlar de forma no programática configuraciones comunes basadas en estilos del contenido de la página web.

Esto les brinda a los usuarios y desarrolladores un medio único y consistente de ver, agregar, eliminar, modificar y anular estilos de bloque que, al final del día, se reducen a propiedades CSS simples.

Lamento causar tanto ruido en este hilo. Probablemente deberíamos seguir discutiendo el tema relacionado.

Editar nota:

Olvidé abordar el punto sobre la abstracción.

El momento en el que el usuario necesita aplicar exactamente el mismo estilo al mismo bloque dos veces es el momento exacto en el que la configuración de estilo definida por el usuario debe abandonarse para las clases CSS (para ese bloque).

En otras palabras, la configuración de estilo definida por el usuario proporciona un mecanismo consistente para que el usuario personalice los bloques a su gusto, ya sea que sea una única vez (como debería ser) o 100 veces en cada página, y cómo elige estructurar todavía depende completamente de usted.

Creo que en general estamos de acuerdo. Mi sugerencia en la primera publicación fue tener un gancho para agregar / eliminar controles. No estoy en contra de que el usuario personalice los estilos a nivel de bloque, simplemente es difícil elegir "los que valen la pena tener por defecto en un bloque de sección genérico" sin que la lista crezca exponencialmente. Tener unos pocos está bien, especialmente si se permite la adición de otros controles. En cualquier caso, me sorprende que el margen y el relleno no sean más útiles que el color de fondo para un bloque de sección.

FWIW, me gusta su idea de que las clases generadas sean la salida, de modo que aún sea anulable sin tener que usar! Important.

@rchipka @tmdesigned Sé que esto fue hace más de dos semanas, pero ¿estaría interesado en aclarar algunos de esos detalles en otro número? Creo que sería beneficioso tener más ojos en esta conversación.

Eché otro vistazo a este bloque basado en las conversaciones anteriores.

La forma más sencilla de compartir mis ideas es a través de un prototipo: https://wp.invisionapp.com/share/PQJPPAX4JZW

Algunas notas:

• Basado en una encuesta rápida: https://wordpress.slack.com/archives/C02QB2JS7/p1527283199000343 He cambiado el nombre de _Section_ a _Container_.
• Eliminé la configuración de la columna, ya que es razonable que la gente quiera mezclar y combinar diseños de columna dentro de una sección en particular, como lo ilustra @jvisick.
• Además del color de fondo, he agregado compatibilidad con imágenes de fondo. La configuración se basa en la función de imagen de fondo existente del núcleo.
• ¿Deberíamos dejar que la gente anide un bloque contenedor en un bloque contenedor?

@melchoyce ¡Se ve genial!

Una característica interesante que me gustaría ver es una selección en el inspector para cambiar el elemento HTML del bloque entre <aside> , <div> y <section> .

La capacidad de anidar contenedores definitivamente debería permitirse, en mi opinión. No solo sería útil en el contexto de tener diferentes áreas de colores dentro de una sola sección semántica utilizando la sugerencia de elemento HTML sugerida anteriormente, sino que también sería útil en situaciones en las que desea dar un fondo a un solo bloque cuando no tiene opción de color de fondo en sí.

Otra buena característica serían los fondos degradados, ya que parecen ser bastante populares en algunos diseños.

@melchoyce +1 por poder anidar contenedores.

@SuperGeniusZeb también ha estado en mi mente el poder cambiar el elemento HTML. ¿Quizás un menú desplegable para las opciones de elementos semánticos?

@jvisick Sí, eso era en lo que estaba pensando. Beaver Builder y Elementor tienen configuraciones como esa para sus filas / secciones.

@melchoyce Creo que los contenedores deberían ser infinitamente encajables. Esto permitirá a los usuarios envolver una clase personalizada (o CSS personalizado) alrededor de cualquier bloque, incluidos otros contenedores.

No hay razón para agregar limitaciones de anidamiento a un bloque contenedor genérico.

Entiendo el valor de los elementos HTML semánticos, pero también me pregunto si hay alguna manera de delegar esa funcionalidad a los complementos de alguna manera para que esté disponible como una opción para usuarios avanzados, pero los usuarios promedio no necesitan pensar en ello. Porque en el momento en que agrega eso, no solo asume la responsabilidad de proporcionar la funcionalidad, sino también la responsabilidad de educar a los usuarios sobre las implicaciones semánticas ... que a menudo son muy situacionales.

@chriskmnds Buen punto. Creo que este es el lugar equivocado para configurar etiquetas de contenedor.

El bloque contenedor debería funcionar como un contenedor genérico sin significado semántico.

El significado semántico debe ser proporcionado por la funcionalidad de la plantilla de bloque (futura), de modo que el contenido <aside> pueda ser una parte de una plantilla y <section> otra.

De esta manera, los usuarios pueden organizar el contenido en contenedores como quieran (en cualquier nivel de profundidad), sin afectar el significado semántico.

Estoy de acuerdo en que poder intercambiar elementos HTML parece un poco avanzado para la mayoría de las personas, y probablemente no pertenezca como una configuración básica de Gutenberg.

El significado semántico debe ser proporcionado por la funcionalidad de la plantilla de bloque (futura), de modo que el contenido <aside> pueda ser una parte de una plantilla y <section> otra.

Definitivamente sería bueno explorar esto.

No estoy en desacuerdo con los puntos hechos para mantener la UX base simple, pero luego preguntaría dónde agregaría <section> , <nav> , <header> , etc. Un bloque contenedor genérico, que es esencialmente un elemento contenedor, parece una elección natural. Eso puede ser preferible a un bloque duplicado para cada uno de estos casos. El valor predeterminado puede ser <div> y un usuario nunca tiene que tocar la configuración a menos que sea necesario.

¿Qué pasaría si las opciones para los elementos HTML funcionaran de manera similar a la configuración de alineación completa / amplia donde se puede configurar una matriz de elementos compatibles desde el tema o complemento?

@jvisick Idealmente, estos elementos de envoltura se crearían con una "plantilla de diseño de bloque" de una página / publicación.

Usando una plantilla de diseño de bloque, puede configurar un grupo de bloques contenedores predeterminados y proporcionar una configuración (en el código) para el nombre de la etiqueta generada del bloque contenedor.

@rchipka Veo de dónde viene al usar plantillas de diseño que brindan a los usuarios áreas predefinidas para administrar el contenido. Estoy viendo esto más desde la perspectiva del uso de Gutenberg como creador de páginas para páginas que no están definidas y en las que sería útil poder establecer qué tipo de elemento HTML se usa desde el editor. Creo que ambos escenarios son importantes.

Dicho esto, estoy de acuerdo con @melchoyce en que la configuración de elementos HTML no es necesaria para una ejecución inicial del bloque contenedor, pero creo que es algo que vale la pena explorar en la siguiente fase del 'generador de páginas'.

Las secciones son esencialmente de 1 columna ... bueno, columnas.

Estoy notando que el bloque 3.0.0 Columns (beta) no permite 1 columna en su control deslizante.

No estoy seguro de si sería mejor quedarse solo con el bloque Columna y combinar estas implementaciones. Cual es la desventaja?

Una cosa que sería bueno agregar es alternar si el contenedor (sección) debe ser de ancho completo o contenido. Si está contenido, debe respetar el content_width establecido en el tema (# 5650); de lo contrario, debe ser de ancho completo. Creo que la mayoría de los creadores de páginas tienen esta función.

Sí, eso está incluido en la barra de herramientas rápida en mi última maqueta.

@melchoyce Tenga en cuenta que habrá situaciones en las que el bloque de sección / contenedor en sí debería ser de ancho completo, pero el contenido dentro del bloque de sección / contenedor no debería. ¿Cómo se manejaría esto?

Supuse que, de forma predeterminada, el contenedor en sí podría convertirse en ancho completo, pero cualquier contenido dentro de él que no admita de forma nativa el ancho completo (como imágenes / bloques de portada) aún estaría restringido al ancho del editor.

@melchoyce Suponiendo que te entiendo correctamente, eso significa que los controles de ancho en el bloque Contenedor solo afectarían el fondo del contenedor y nunca el contenido. Eso tiene sentido. Gracias por aclararlo. : +1:

¡Sí, eso es lo que estoy pensando!

No estoy seguro si se discutió, pero una sección podría ser un elemento HTML de "sección" y también un "artículo", "div" o algo más, ¿verdad? Sería bueno tenerlo como seleccionable
Esto también podría hacer que el bloque "fila" sea innecesario, creo

Implementé esto en un complemento

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 Esto se discutió: https://github.com/WordPress/gutenberg/issues/4900#issuecomment -392925877

Sigo pensando que un menú desplegable para seleccionar la etiqueta HTML utilizada es una buena idea. Se siente como la forma más fácil de integrar elementos HTML semánticos como <aside> y <section> sin crear un montón de bloques demasiado similares.

@nbrummerstedt Buena implementación básica inicial, pero el bloque ahora se llama bloque Container y debería usar un <div> como elemento, aunque idealmente (como se mencionó anteriormente y en comentarios anteriores), podría cambiar el HTML elemento usado desde <div> a <section> , <aside> , y tal vez incluso <article> .

Aquí hay una versión revisada de su implementación:

( ( 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 );

¿Por qué se eliminó esto del hito de WordPress 5.0, @mtias? Esto parece algo que probablemente debería incluirse en la versión inicial, simplemente por lo útil y simple que es. Muchos bloques no tienen configuraciones de fondo porque se asumió que usarías el bloque Container para eso. Ni siquiera es tan difícil implementar este bloque, ¿verdad? No veo por qué esto debería retrasarse a una versión posterior a WordPress 5.0.

En otra nota, recientemente revisé Oxygen y me impresionó su sistema de diseño basado en flexbox. ¿Y si el bloque Container implementara algunas de estas características? Apuesto a que podría ser realmente poderoso y proporcionar una forma alternativa de tener diseños distintos al bloque de Columnas ... ¿tal vez incluso podría hacer que el bloque de Columnas sea innecesario?

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

Recomiendo encarecidamente revisar esto. En realidad, recomiendo echar un vistazo a Oxygen por completo. Es muy diferente de todos los demás complementos de creación de páginas, y creo que hay muchas buenas ideas que Gutenberg podría usar.

Definitivamente estoy de acuerdo, esto debería ser en la versión 5.0, necesita un contenedor para evitar cualquier solución pirata que use el bloque de columnas.

También creo que este bloque debe estar disponible más pronto que tarde. Muchas agencias de desarrollo de WordPress están esperando este bloque antes de construir con Gutenberg.

@ dingo-d y @ericvalois Sí, me he abstenido de usar Gutenberg para cualquier cosa que no sean publicaciones de blog precisamente por la falta de 3 cosas: columnas receptivas, columnas de ancho no igual y un bloque contenedor.

Para desarrollar lo que dije antes sobre el bloque Container adoptando cosas que hace Oxygen, creo que el bloque Container podría tener una opción para cambiar la dirección de flujo de sus bloques anidados de la vertical predeterminada a la horizontal. También podría haber opciones de alineación vertical y horizontal como las que tiene Oxygen. Estos serían realmente poderosos, especialmente si se combinan con la capacidad de cambiar estas opciones de manera receptiva, como lo permiten la mayoría de los complementos de creación de páginas.

Por supuesto, existe el problema notable de que un bloque Contenedor que usa alineación / diseño basado en Flexbox no permitiría que los bloques alineados con flotadores se aniden directamente en él. Pero creo que hay una solución simple para eso: agregue la capacidad de que un contenedor use el diseño CSS estándar display: block o el diseño Flexbox. El modo estándar display: block sería el predeterminado, ya que eso es lo que usaría el documento raíz. Habilitar el modo de visualización de caja flexible haría que todas las opciones de alineación ordenadas aparezcan en el inspector. Además, obviamente querrá dar a los 2 modos de diseño un nombre diferente en el inspector para que sea más fácil de usar. Sin embargo, no estoy seguro de cómo los llamaría. ¿Quizás "estándar" y "flexible"?

Sería realmente útil permitir que los bloques Container usen el modo que admite flotadores o el modo con mejores opciones de alineación / diseño. Puede anidar bloques de contenedor para usar ambos tipos de diseño cuando sea necesario. Agregue esto a las otras capacidades que podría tener el bloque Container (opciones de fondo, capacidad de elegir etiqueta HTML para agregar significado semántico sin tener que recurrir a bloques HTML personalizados, etc.) y el bloque Container terminaría siendo uno de los más importantes y bloques útiles en el núcleo de WordPress.

En particular, si el bloque Container que tiene dos modos de diseño suena como demasiadas funciones (y realmente no creo que sea un problema), entonces podría haber dos bloques separados:

• un bloque contenedor estándar que admite flotadores pero no tiene todas las opciones avanzadas de alineación / diseño
• un bloque de contenedor avanzado (o diseño avanzado o diseño flexible o como lo llame) que utiliza el diseño de Flexbox y proporciona todas las opciones ordenadas

Recomiendo ver este video de documentación de Oxygen para ver cómo funciona su sistema de diseño. Es realmente impresionante:

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

Creo que hay mucho potencial aquí para hacer que Gutenberg sea muy poderoso . Por supuesto, para una implementación inicial, solo esperaría que el bloque Container tuviera opciones de fondo, la capacidad de cambiar el elemento HTML utilizado y la opción de hacer que el Container sea de ancho completo (pero no el contenido dentro de él). Quizás incluso solo las opciones de fondo.

En realidad, tener un bloque de contenedor que ni siquiera tiene opciones sigue siendo útil, porque facilita el estilo de un grupo de bloques a través de CSS.

Es importante pensar en Gutenberg no solo como en detenerse después de 5.0. Este es un bloque realmente útil y será explorado, pero para la fase uno, enfocarse en editarlo no es realmente necesario. Cuando el proyecto se expande más allá de la simple edición en diseño, no hay duda de que se necesita una solución allí. Nadie está diciendo que esto no se creará, es una cuestión de priorizar qué es el editor y qué lleva a la fase dos.

Pero la cuestión es que la mayoría de las personas utilizan Gutenberg con fines de diseño, no para escribir publicaciones.

Las personas están acostumbradas a escribir publicaciones como un documento de Word, por lo que están deshabilitando Gutenberg en las páginas de publicaciones.

Pero la cuestión es que la mayoría de las personas utilizan Gutenberg con fines de diseño, no para escribir publicaciones.

¿En qué fuente de datos basa esta suposición?

He hablado con varias personas durante la WCEU en Belgrado, todos están de acuerdo en que les resulta extraño escribir publicaciones con Gutenberg y, por lo tanto, lo están deshabilitando en las publicaciones.

A diferencia de lo que ha visto @ dingo-d, solo uso Gutenberg para publicaciones. De hecho, encuentro la experiencia de hacer publicaciones mucho mejor en Gutenberg que en el Editor clásico. En parte debido a la naturaleza más modular y los controles contextuales, y en parte porque no hay más etiquetas invisibles <p> insertadas en todas partes. Eso siempre me molestó.

Necesito un bloque de contenedor (incluso uno sin opciones) y un bloque de columnas decente (o algún otro bloque de diseño) para usar Gutenberg para la creación de páginas uniformes. Parece que el bloque Columns obtendrá algún tipo de capacidad de respuesta básica (ver # 6048), lo que significa que es solo la falta de un bloque Container lo que me impide usar Gutenberg en más contextos.

Sé que el bloque Container obviamente se agregará en algún momento (probablemente a más tardar en WordPress 5.1), pero creo firmemente que debería agregarse antes de que WordPress 5.0 salga. Incluso en el contexto de escribir publicaciones, un contenedor podría ser útil para algo como <aside> (si tuviera la función desplegable de selección de elementos HTML) para agregar semántica. En este momento, si desea ajustar algo en otro elemento HTML para agregar semántica, debe usar el bloque HTML personalizado, lo que significa que no puede aprovechar las funciones del bloque Párrafo para ningún párrafo en ese bloque HTML personalizado, o cualquier característica del bloque de imagen para cualquier imagen en ese bloque HTML personalizado, y etc.

@karmatosed

Nadie está diciendo que esto no se creará, es una cuestión de priorizar qué es el editor y qué lleva a la fase dos.

En mi opinión, el bloque Container es absolutamente algo que pertenece a la fase uno.

Lo que encuentro un poco extraño es que el bloque Columns parece que se convertirá en WordPress 5.0 (posiblemente todavía con esa etiqueta "(Beta)", pero el bloque Container puede que no lo haga. publicaciones, entonces ¿por qué se ha agregado un bloque de columnas pero no un bloque de contenedor? El bloque de contenedor, en mi opinión, es mucho más útil en el contexto de publicaciones que el bloque de columnas. Y, por supuesto, también tiene muchos beneficios en el contexto de creación de páginas también.

Si el bloque Container no llega a WordPress 5.0, eso significa que no saldrá hasta la versión 5.1, lo que retrasa durante meses su uso por parte de la mayoría de las personas. Quiero que Gutenberg tenga éxito, y siento que no hay razón para retener el lanzamiento de algo básico como un bloque de contenedores hasta WordPress 5.1. En aras de las buenas primeras impresiones, incluso recomendaría que se agregue antes de la llamada de WordPress 4.9.8.

No espero que tenga todas las características que la gente ha sugerido; su mera existencia es suficiente para resolver muchos casos de uso comunes que actualmente no están cubiertos, excepto a través de una solución bastante hacky de usar un bloque de Columnas con el control deslizante de Columnas configurado manualmente en 1. Y luego, solo tener una opción como opciones de color de fondo lo haría mucho más útil.

Estoy de acuerdo en que este es un bloque interesante y útil, pero siempre se ha tratado más de la fase 2 del proyecto y realmente debemos concentrarnos o nunca lo enviaremos. Creamos la infraestructura de bloques anidados porque era importante obtener las abstracciones correctas y permitir que las personas construyeran sus bloques de diseño personalizados para que un bloque central real como este sea menos crítico. El objetivo es conseguir que la IU anidada y secundaria sea correcta en general (utilizando _Columns_ como conejillo de indias).

Este problema también ha estado abierto al público durante cinco meses y no ha habido propuestas de implementación sólidas que incluyan cosas como colores, anchos, dirección de bloques frente a columnas anidadas, superposición con imagen de portada, etc. Tal como está, podemos No le dé prioridad a otros trabajos de propósito general que tenemos que hacer, y el aviso de "prueba" inminente en WordPress. Eso no significa que no pasará el corte, especialmente si alguien quiere presentar sugerencias en el código.

Además, el mayor problema para mí es que no está claro, visible solo en la conversación aquí, cuál debería ser la experiencia de usuario ideal para comprometerse con una implementación. Cosas como exponer etiquetas html parecen abiertamente complejas y poco intuitivas para un usuario regular. La misma noción de contenedor es algo que necesita pruebas más amplias para ver si es la mejor abstracción de diseño, que, de nuevo, se suponía que era algo que había que averiguar en la siguiente fase de enfoque. También hay algunas incógnitas sobre cómo un bloque de este tipo distribuiría estilos en cascada hasta bloques arbitrarios dentro; es relativamente sencillo tener en cuenta los bloques centrales, pero no cualquier bloque arbitrario.

Al mismo tiempo, un desarrollador que desee ofrecer un bloque personalizado debería tener facilidad para armarlo (como el fragmento que se muestra arriba) con la etiqueta que desee mediante el uso de InnerBlocks y recopilar comentarios de los usuarios. Por lo tanto, hay menos presión sobre el núcleo al tener tal bloqueo (y tener que mantenerlo). Dicho todo esto, cualquiera debe sentirse libre de hacer una sugerencia a través de relaciones públicas y ayudar a los usuarios a probarlo. Estaría bien con agregarlo al complemento como "experimental" con la idea de que podría eliminarse para 5.0.

@SuperGeniusZeb ¡El oxígeno es genial! Definitivamente debería ser considerado para algunas de estas exploraciones.

Por curiosidad, ¿qué sucede si los temas y complementos agregan sus propios bloques de sección y el usuario desactiva el complemento o cambia los temas? ¿Existe algún tipo de respaldo en su lugar? ¿O el usuario pierde su contenido?

@tomusborne Hay un problema sobre ese tipo de situación: # 7811.

¡Ah! No sabía que esto se discutía aquí. Así que también hice un complemento porque lo necesitaba.

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

He estado viendo este hilo y aprecio todo lo que pensé. Recientemente lancé un bloque contenedor en el complemento Atomic Blocks que tiene márgenes, rellenos, ancho del contenedor e imagen de fondo y opciones de color. ¡Espero que esto sea útil y pueda detenernos hasta que llegue un bloque central en una fecha posterior!

A raíz de este problema ... he creado un bloque "Contenedor" que permite elegir la estructura de las columnas, y otras opciones.
Si puede ayudar a mejorar el bloque "Columnas" o crear uno nuevo en el núcleo, está aquí: https://github.com/MarieComet/WP-container-block/

@MarieComet Eso está bien, pero creo que su bloque debería dividirse en 2 bloques diferentes. El primero debería ser un bloque de columnas con todas las opciones de diseño de estructura basadas en columnas. El segundo sería un bloque de contenedor que tiene opciones de fondo y opciones de diseño que no están basadas en columnas, como la capacidad de usar flex para diseñar los niños horizontalmente en lugar de verticalmente y alinearlos y justificarlos usando opciones que corresponden a las propiedades de CSS Flex.

Probablemente también podría usar el bloque Contenedor para reemplazar los bloques de Columna individuales, aunque puede haber algunas opciones que le gustaría tener en una Columna que no tienen sentido en una Sección.

Me he dado cuenta de que el futuro de hacer diseños con HTML y CSS no es usar siempre columnas como la mayoría de los creadores de páginas, sino también usar CSS Flex y Grid para mostrar contenido usando menos <div> s en el marcado y tener un estilo más flexible y limpio. Me inspira principalmente lo que está haciendo Oxygen. Hablé de oxígeno en este comentario .

Este problema no se trata de reemplazar el bloque de columnas en este momento. Es importante concentrarse en el tema de este tema, un bloque de sección.

@karmatosed @melchoyce Hablando de eso, ¿no debería cambiarse el nombre de este problema? Dejamos de llamarlo "Sección" y cambiamos a "Contenedor" para evitar confusiones con los elementos <section> .

El nombre no ha sido decidido, así que estamos bien dejándonos como está por un tiempo.

Por el momento estoy intentando implementar un tema junto con el editor de Gutenberg.

El diseño del sitio web tiene diferentes áreas con diferentes fondos, que contienen varios elementos como párrafos o listas. Esto es para propósitos de diseño y navegación. Los bloques de sección / contenedor deberían funcionar como anclajes / deberían tener ID de CSS únicos.

No puedo terminar este tema sin "hackear Gutenberg" creando bloques propios. En su lugar, podría hacerse con este como bloque principal. No usaría el editor de Gutenberg solo para texto sin formato y diseños simples; mi diseño / diseño futuro debería hacerse junto con el tema y el sistema de bloques de Gutenberg.

Realmente espero que este tema reciba una mayor prioridad.

Estoy usando bloques de contenedores de terceros en todo el lugar (por ejemplo, bloques atómicos), en combinación con el bloque de columnas. Han sido super útiles y mi bloque más popular. Me parece extraño que se considere más adelante en el futuro o como un complemento; debe estar en el núcleo.

De lo contrario, simplemente construiría manualmente los contenedores en la vista HTML, sin embargo, eso es molesto / ineficiente porque la vista HTML está a un clic de menú adicional. Hay un atajo de teclado para la vista HTML ... shift + option + cmd + M ... yeesh. Y ni siquiera cambia de un lado a otro. Volver a presionar el atajo no hace nada. Para volver a la vista WYSIWYG, debe recorrer los menús. Un interruptor de palanca grande y grueso en la barra de herramientas principal sería grandioso.

¿Alguien ha catalogado / mantiene una lista de implementación actualmente en estado salvaje? Creo que también necesitaría algún tipo de matriz de parámetros de "cosas hechas bien y mal". Por ejemplo, especificar unidades codificadas (px) para rellenos / márgenes asociados (incorrecto), cuando las unidades probablemente deberían ser una opción que se deja al usuario (derecha), etc.

https://editorblockswp.com/library/ tiene algunos en el catálogo, pero para impulsar este problema, parece que debe suceder algo específico para Secciones / Contenedores.

En mi opinión, un bloque Container básico tendría al menos las siguientes opciones:

• imagen de fondo
• color de fondo
• capacidad de superponer el color de fondo en la imagen y controlar la opacidad
• opciones de relleno y margen para las 4 direcciones, con la capacidad de cambiar las unidades utilizadas individualmente para cada valor
• soporte para alineaciones flotantes a la izquierda, flotantes a la derecha, anchas y completas
• capacidad para controlar el ancho máximo de los bloques contenidos de alguna manera
• capacidad de elegir el elemento html utilizado por el contenedor

Además, preferiría tener también lo siguiente:

• Opciones de diseño flexible de CSS: capacidad para establecer la dirección del flujo de contenido de arriba a abajo a izquierda-derecha, derecha-izquierda y de abajo a arriba; y capacidad para establecer la alineación vertical y horizontal del contenido
• por supuesto, el uso de opciones flexibles es incompatible con las alineaciones flotantes, por lo que el bloque tendría que tener al menos 2 modos de diseño: estándar y flexible, o de lo contrario tendría que haber un bloque de contenedor flexible separado
• opciones de tamaño y color de fuente para establecer los valores predeterminados para el contenido en el contenedor y evitar tener que configurarlo para cada bloque contenido individualmente

Felix Arntz acaba de publicar una publicación de blog sobre la implementación de su bloque de sección.
me gusta la imagen de fondo sensible.
https://felix-arntz.me/blog/building-a-reusable-gutenberg-section-block/

En las últimas semanas he estado experimentando con la implementación de Marc Lacroix, que funciona bien, pero parece fallar en gutenberg 3.9.0 https://github.com/marcusig/gutenberg-section-block

He estado pensando en este durante algún tiempo. El hecho de que hayan surgido tantas implementaciones significa que es bastante valioso y probablemente sea mejor para el núcleo ofrecer un mecanismo consistente para evitar la fragmentación. Mi principal preocupación es la complejidad de un bloque de "sección" para un usuario.

Propongo comenzar de manera muy simple, con solo un contenedor (un área única de InnerBlocks), alineaciones amplias y completas, y una configuración para el color de fondo (sin imagen, etc., tenemos "Cover" para eso).

No tenemos mucho tiempo para hacerlo si lo queremos en 5.0.

@mtias Si exponer un bloque de contenedor al usuario final es una preocupación, entonces quizás cada bloque debería tener una configuración de contenedor o contenedor de forma predeterminada.

Entonces no tenemos que preocuparnos por enseñarle al usuario final que necesita envolver algo en un contenedor para que tenga ciertas cosas como una imagen de fondo.

Creo que esto es realmente una buena idea porque entonces las personas que quieran extender o ajustar bloques arbitrarios tendrán un lugar claro para hacerlo, y los usuarios finales estarán familiarizados con él porque está en cada bloque.

Quizás "Configuración de contenedor" podría ser una pestaña junto a "Configuración de bloque". Este sería un lugar (extensible) para que los desarrolladores ingresen (o filtren) cosas como configuraciones de imagen de fondo, configuraciones de ancho, etc.

Esto también les daría a los desarrolladores un lugar para colocar configuraciones más complejas que se pueden aplicar a casi cualquier bloque, como controles de respuesta / punto de interrupción.

@rchipka Técnicamente, la mayoría de los bloques están empaquetados con un div principal y el tipo de configuración a nivel de bloque que está describiendo es lo que los bloques pueden hacer ahora.

El poder de un contenedor no reside exactamente en un solo bloque, sino que le permite agregar otros bloques dentro del contenedor, creando diseños, secciones y estructuras de página más complejas.

@mikemcalister Buen punto, el usuario final aún necesitaría una forma de agrupar / organizar visualmente el árbol de bloques.

Sin embargo, creo que la filosofía sigue siendo la misma. Si el editor tuviera un mecanismo de agrupación de bloques en forma de árbol (es decir, sin una interfaz de "Bloque contenedor"), entonces la "Configuración del contenedor" para cualquier bloque secundario reflejaría la configuración de ese grupo (es decir, ese nivel en el árbol).

Nuevamente, el único punto de esta idea es reducir el número de pasos involucrados para el usuario final y, por lo tanto, también reducir la curva de aprendizaje y aumentar la capacidad de descubrimiento.

Creo que el problema principal es que actualmente Gutenberg está muy limitado al contenido estándar de publicaciones / páginas. Sin un bloque de sección / contenedor, no tenemos forma de permitir a los usuarios crear portadas con secciones de ancho completo (con fondo de color sólido / degradado o imagen de fondo de ancho completo) con todo tipo de contenido adentro (con suerte a través de bloques anidados).

Un bloque de sección / contenedor sería perfecto aquí. Incluso uno básico que podría ampliarse con más controles por temas / complementos. Me encantaría tener más configuraciones de alineación allí también. Ya estamos haciendo algo con CMB para tener un constructor de pseudopáginas directamente en las páginas, pero realmente esperamos que Gutenberg pueda hacer que todo esto sea más flexible para todos.

@JiveDig No creo que nadie, incluido el equipo de Gutenberg, se oponga a algún tipo de mecanismo de contenedor de bloques.

La principal duda del equipo de Gutenberg (en este caso y en muchos otros) es mantener la interfaz central en un nivel de complejidad de Squarespace desde el punto de vista de UI / UX.

Para que esto se implemente en el núcleo, parece que el problema principal es encontrar una manera de representarlo sin imponer una carga adicional a los usuarios finales.

Aunque, en mi opinión, no parece gran cosa, un "Bloque contenedor" supone una pequeña carga para el usuario final al requerir conocimiento de su propósito y uso.

Por eso propuse el concepto de "agrupación" como una analogía más accesible de "contenedores" para los usuarios finales.

El usuario final no pensaría en términos de envolver bloques en contenedores, sino en términos de agrupar bloques, lo que parece más intuitivo.

De esta manera, el usuario final no necesita saber nada de antemano para agrupar bloques y aplicar configuraciones a ese grupo.

Por supuesto, estos "grupos" funcionarían exactamente como un bloque contenedor internamente, es solo una interfaz de usuario más integrada e intuitiva.

@rchipka Una manera muy fácil de abordar eso sería la capacidad de seleccionar uno o más bloques y hacer clic en la opción "Mover bloque (s) seleccionado (s) al bloque contenedor" en el menú "más". De esta manera, los bloques no necesitan un panel de configuración _additional_.

Sí, un bloque de sección debe estar en el núcleo. Representar un div simple en HTML es suficiente. Pero dado que hay literalmente cientos de atributos que podrían ofrecerse, sugiero encarecidamente en su lugar que los dos atributos que se deberían ofrecer son CLASE e ID (siendo ID el menos crítico). De esa manera, los elementos se pueden diseñar en CSS donde deberían estar.

-
Modos Wes
Una historia secreta de los habitantes de los ríos estadounidenses
http://peoplesriverhistory.us

Enviado desde mi Apple] [e

El 12 de octubre de 2018, a las 8:09 a.m., Matias Ventura [email protected] escribió:

He estado pensando en este durante algún tiempo. El hecho de que hayan surgido tantas implementaciones significa que es bastante valioso y probablemente sea mejor para el núcleo ofrecer un mecanismo consistente para evitar la fragmentación. Mi principal preocupación es la complejidad de un bloque de "sección" para un usuario.

Propongo comenzar de manera muy simple, con solo un contenedor y una configuración para el color de fondo (sin imagen, etc., tenemos "Cubierta" para eso).

No tenemos mucho tiempo para hacerlo si lo queremos en 5.0.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

Una vez más, cada bloque debe tener la capacidad de establecer su atributo de clase. Independientemente del tipo.

-
Modos Wes
Una historia secreta de los habitantes de los ríos estadounidenses
http://peoplesriverhistory.us

Enviado desde mi Apple] [e

El 12 de octubre de 2018, a las 8:40 a.m., Robbie Chipka [email protected] escribió:

@mtias Si exponer un bloque de contenedor al usuario final es una preocupación, entonces quizás cada bloque debería tener una configuración de contenedor o contenedor de forma predeterminada.

Entonces no tenemos que preocuparnos por enseñarle al usuario final que necesita envolver algo en un contenedor para que tenga ciertas cosas como una imagen de fondo.

Creo que esto es realmente una buena idea porque entonces las personas que quieran extender o ajustar bloques arbitrarios tendrán un lugar claro para hacerlo, y los usuarios finales estarán familiarizados con él porque está en cada bloque.

Quizás "Configuración de contenedor" podría ser una pestaña junto a "Configuración de bloque". Este sería un lugar (extensible) para que los desarrolladores ingresen (o filtren) cosas como configuraciones de imagen de fondo, configuraciones de ancho, etc.

Esto también les daría a los desarrolladores un lugar para colocar configuraciones más complejas que se pueden aplicar a casi cualquier bloque, como controles de respuesta / punto de interrupción.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

No me opongo al método de agrupación (siempre que pueda asignar atributos de clase), aunque sería delicioso si TAMBIÉN hubiera un bloque contenedor si quisiera construir de esa manera.

-
Modos Wes
Una historia secreta de los habitantes de los ríos estadounidenses
http://peoplesriverhistory.us

Enviado desde mi Apple] [e

El 12 de octubre de 2018, a las 10:50 a.m., Chris Van Patten [email protected] escribió:

@rchipka Una manera muy fácil de abordar eso sería la capacidad de seleccionar uno o más bloques y hacer clic en la opción "Mover bloque (s) seleccionado (s) al bloque contenedor" en el menú "más". De esta manera, los bloques no necesitan un panel de configuración adicional.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

@chrisvanpatten Estoy de acuerdo, sin embargo, esta solución no aborda adecuadamente la preocupación original de @mtias de exponer el concepto de un contenedor o sección al usuario final.

El problema, como lo planteó @mtias , no se trata de la logística de colocar bloques en un contenedor, sino de presentar intuitivamente esa interfaz al usuario final (sin exponer tipos de bloques adicionales).

La discusión de "cómo colocamos bloques en un contenedor" es necesaria. Sin embargo, no necesariamente veo que sea demasiado complejo para un usuario. Muchos usuarios no lo usarán, o al menos no lo usarán fuera de su página de inicio. Muchos de nuestros clientes y clientes temáticos expresan sus deseos / necesidades de sitios web en términos visuales que se ajustan a un bloque de sección. Dicen cosas como, "Quiero una {barra / área / sección / bloque / panel / span} de ancho completo con una imagen bonita" seguida de "y {insertar solicitudes de contenido aquí} en esa sección". Entienden visualmente que la sección en sí (el contenedor) está separada del contenido que contiene.

Por supuesto, cómo hacerlo a través de la interfaz de usuario debe resolverse, pero espero que mi punto anterior tenga sentido.

@chrisvanpatten Mi declaración anterior se basa únicamente en la semántica de los tipos de bloque.

La única razón por la que estoy discutiendo la semántica aquí es en nombre de @mtias , ya que se planteó un problema con la complejidad que expone esta semántica en primer lugar.

Me gusta tu sugerencia, pero si sigo mi analogía, tal vez cambiaría la semántica "Agrupar bloques seleccionados".

@rchipka no es así como interpreté su comentario;

Dicho esto, estoy más que feliz de estar equivocado :)

@JiveDig Estoy muy de acuerdo ...

Sin embargo, el equipo de Gutenberg parece ser muy sensible a exponer estas cosas al usuario final en el núcleo de Gutenberg.

Ésta es mi única base para plantear estos argumentos y presentar estas ideas.

Nuevamente, si fuera yo, tendríamos el maldito bloque de contenedores.

No creo que un bloque contenedor realmente tenga sentido, ya que saturaría la interfaz de usuario. Preferiría ver algo como el marcador "Salto de sección" que se ve en línea en Microsoft Word. Agregar un salto de sección ofrecería algunas opciones de estilo en el inspector como un nombre de clase para la sección, color de fondo, color de texto, sombra, lo que sea que defina estilísticamente su sección. Podría insertarse como cualquier bloque y moverse como cualquier bloque.

@rwrobe Esa idea no funciona para contenedores anidados.

Actualmente estoy construyendo un sitio con Gutenberg y he hecho un uso intensivo de una versión modificada del bloque de sección de

• "Sección" es el mejor nombre para el bloque. Su significado es claro para los desarrolladores y los usuarios finales, y evita complicar el marcado / opciones usando lógicamente el bloque <section>.

• Las únicas opciones del menú contextual necesarias son alignnormal / wide / full (y de hecho solo uso alignfull). La alineación no afecta a los bloques internos, que permanecen dentro de la alineación normal a menos que tengan sus propias opciones de alineación. El caso de uso principal ha sido la creación de un color de fondo alineado que contiene un bloque de texto alineado de forma normal, un patrón de diseño muy común que actualmente no es posible.

• Las únicas configuraciones de bloque de la barra lateral necesarias son Color de fondo e Imagen de fondo (con opciones de opacidad / fija asociadas). Cualquier personalización adicional se puede manejar con la clase CSS personalizada. (Incluir la opción Imagen de fondo también tiene el efecto secundario de convertir esto en una versión mucho más útil del Bloque de portada). (Pero: si @mtias tiene razón, evitar esa conversación al incluir solo la opción Color de fondo sacaría esto puerta más rápido, entonces estoy totalmente de acuerdo).

• La usabilidad ha sido simple. Más fácil que las columnas, que existen desde hace un tiempo. El único problema potencial es que cuando se agrega la sección por primera vez, el foco se cambia a un párrafo dentro de la sección, por lo que puede ser difícil saber que la sección se acaba de agregar hasta que pase el mouse sobre ella. Una posible solución para eso es establecer de forma predeterminada un color de fondo gris claro.

@ZebulanStanphill ¿Estás hablando de columnas? Pude ver bloques de "sección" haciendo el trabajo para el contenido separado verticalmente; incluso podría haber una palanca para heredar estilos de la sección anterior, lo que le permite "anidar" variaciones de estilo dentro de una sección.

La composición horizontal, como en columnas, parece necesariamente más difícil debido a la forma en que Gutenberg construye la página de arriba a abajo en bloques de ancho completo.

@mikedance Creo que eso es exactamente lo que se necesita. Una opción de imagen de fondo sería importante aunque en mi opinión. Tal vez este bloque pueda reemplazar al Bloque de portada en ese momento, aunque el nombre puede no ser propicio para las personas que _sólo_ quieren una imagen de fondo con texto básico encima. Aunque existe cierta superposición en la funcionalidad, eliminaría un gran porcentaje de casos de uso para el bloque de sección sin agregar soporte de imagen bg.

@rwrobe Cabe señalar que puede tener bloques dispuestos horizontalmente. Los bloques Column (tenga en cuenta la falta de "s") son solo eso. El bloque Columnas las coloca horizontalmente. La interfaz de usuario probablemente podría mejorarse en algunas áreas, pero los bloques no se limitan a ser de ancho completo o distribuidos verticalmente.

@mikedance

"Sección" es el mejor nombre para el bloque. Su significado es claro para los desarrolladores y los usuarios finales, y evita complicar el marcado / opciones usando lógicamente el

bloquear.

Debido a que el elemento <section> tiene semántica adjunta, sería mejor si pudiera optar por usar <div> lugar de <section> , ya que en muchos casos desea ajustar varios bloques, pero no son semánticamente parte de una sección. De hecho, sería aún mejor si también pudiera optar por usar elementos como <aside> o <header> , siendo este último particularmente útil para agregar semántica a los encabezados con fondos en la construcción de páginas.

En otra nota, creo que tener opciones de imagen de fondo disponibles para un bloque de contenedor sería bastante útil. Por supuesto, la superposición con el concepto de bloque de cubierta se vuelve bastante evidente. Si hace que el bloque de cubierta sea más flexible, básicamente se convierte en un bloque de contenedor de todos modos, por lo que tal vez el concepto de bloque de cubierta no tenga por qué existir. Un bloque contenedor podría hacer casi todo lo que hace. El concepto de portada podría ser simplemente una plantilla de bloque reutilizable.

@ZebulanStanphill Estoy de acuerdo. Que sería útil una configuración avanzada que le permita seleccionar si es una sección, encabezado, aparte o div (predeterminado). Sí, es posible que la mayoría de los usuarios no utilicen esa opción, pero es una opción que admite un buen desarrollo web.

¿Cómo se puede integrar un tema? ¿Puede un tema agregar "variaciones" a un bloque, en este caso
el bloque de sección y el usuario puede elegir directamente uno de un ilst y ver los estilos resultantes aplicados?
También puede ser muy útil agregar un filtro o un gancho al bloque de sección para permitir
un tema agrega envoltorio y otros elementos que a veces se requieren para diseñar.

@ZebulanStanphill @wmodes Dudo que incluir una opción para seleccionar el elemento contenedor alguna vez supere a los desarrolladores principales. Es una complicación excesiva. Desde cierto punto de vista, el elemento <section> es tan semántico como puede ser porque el usuario ya lo está definiendo como una "Sección" en virtud de la creación del bloque. Depende de ellos usarlo de manera responsable, al igual que los títulos. Pero si evitaría el argumento de la semántica, no tengo problemas con el uso de <div>.

@mikedance De acuerdo, probablemente deberíamos usar <div> . Si el diseño semántico es una preocupación, entonces sería mejor manejarlo como una extensión del bloque contenedor.

@strarsis Themes puede usar la API de estilos de bloque existente para agregar estilos a los bloques. (El bloque principal de Botones y Citas incluye múltiples variantes de estilo de forma predeterminada). Desafortunadamente, no puedo encontrar ninguna documentación sobre esta funcionalidad. (Existen varios problemas para rastrear la falta actual de documentos: https://github.com/WordPress/gutenberg/milestone/500)

@mikedance

Desde cierto punto de vista el

elemento es tan semántico como puede ser porque el usuario ya lo está definiendo como una "Sección" en virtud de la creación del bloque.

Creo que entiendo lo que estás diciendo, pero no estoy de acuerdo. En muchos casos, un bloque de contenedor se usaría simplemente para agregar un color de fondo a un par o incluso solo a un bloque que no tiene sus propias opciones de fondo (u otras opciones de estilo). Un bloque de lista envuelto en un contenedor para darle un color de fondo y resaltarlo no significa que la lista esté en su propia sección.

Pero sí, <div> es la opción más neutral ya que no tiene un significado semántico. Si nunca habrá una opción en el núcleo para cambiar el elemento HTML, entonces <div> es la mejor opción.

La razón principal por la que quiero tener la capacidad de elegir la etiqueta HTML es porque te permite crear más fácilmente páginas semánticas y publicaciones sin tener que recurrir al bloque HTML personalizado o complementos que agregan bloques personalizados. Si desea usar una etiqueta <section> en Gutenberg en este momento, termina teniendo que poner todo en esa sección en un bloque HTML personalizado, perdiendo las capacidades de edición visual para cosas como Párrafos, Listas, etc. habría de otra manera. ¿Quizás el conmutador de etiquetas podría mostrarse en el grupo Avanzado en el inspector?

@strarsis @ZebulanStanphill

Puede encontrar documentos para agregar Block Styles en el manual en extensibilidad https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#block -style-variaciones

@ajitbohra ¡Gracias! Revisé esa página varias veces, pero seguía perdiendo esa sección de alguna manera. : riendo:

@ajitbohra : ¡Gracias! ¿Hay una demostración para las variaciones de estilo de bloques de Gutenberg por cierto?

@strarsis

Sí, verifique el bloque principal button y 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 Los pullquote , table y separator también tienen variaciones de estilo:
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

Realmente me gustaría ver algunos bloques organizativos creados. El problema actual con las columnas es que la creación de un bloque de una sola columna para agrupar el contenido (por ejemplo, con el propósito de compartir el color de fondo, el video o la imagen) no es intuitivo. Idealmente, me gustaría ver al editor llegar a la etapa en la que fuera capaz de crear contenido como este casi estrictamente dentro del editor.

Moviendo esto tentativamente para una versión 5.1 para que tengamos un poco más de tiempo para definir cómo se debe presentar este bloque.

Mientras lo pienso ... dado que hay una superposición entre esto y el bloque de Cubierta, ¿qué pasaría si el bloque de Cubierta fuera más una "configuración" en el sentido de que cuando agrega ese bloque, realmente agrega un bloque de Sección preconfigurado con un Encabezado? o bloque de texto / párrafo anidado dentro de él?

@JiveDig

¿Qué pasa si el bloque Cover fuera más una "configuración" en el sentido de que cuando agrega ese bloque, realmente agrega un bloque de sección preconfigurado con un bloque de encabezado o texto / párrafo anidado dentro de él?

Eso me suena mucho a un bloque reutilizable que se inserta como un bloque independiente para mí. Quizás el núcleo podría incluir varias plantillas de bloques reutilizables de forma predeterminada como esa. La interfaz de usuario debería mejorarse para facilitar la inserción de un bloque reutilizable como independiente. Ver # 8403.

¿Habrá una bifurcación para probar la nueva sección / bloque de contenedores? Me interesa jugar con él y ayudar a probarlo.

Un bloque de contenedor / sección es muy útil, tuve que usar el
Bloque contenedor de bloques Gutenberg avanzado por ahora.
Y es importante hacer que el bloque de sección / contenedor sea fácilmente visible y seleccionable.

En parte comentando para tener en cuenta que un bloque de sección sería increíblemente útil para el desarrollo de plantillas.

Acabamos de crear un bloque de sección personalizado en lugar de que esté en el núcleo y detectamos un problema en el que los atributos del bloque no se actualizaban si el bloque seguía siendo el mismo pero los atributos cambiaban.

Esto se ha resuelto en PR # 12406 (arriba)

¿Se sigue considerando el bloque de sección para 5.1 (previsto para el 21 de febrero de 2019) o posterior?

Escribí un complemento de bloque de sección, que he usado en un par de proyectos y espero lanzarlo como algo más genérico para el repositorio de complementos. Permite establecer colores de fondo e imágenes o video, así como una clase definida por tema para formatear los elementos contenidos dentro del área innerblocks .

En mis casos de uso, era más fácil para el cliente tener campos de título y descripción predefinidos (opcionales) sobre un área de bloques internos donde podían apilar "elementos", que, en mi caso de uso, eran pseudo-widgets que creé con otro bloque. tipo. Pero esto podría ser fácilmente secciones anidadas simples, donde el primer bloque de sección contenía un encabezado, párrafo y luego otro bloque de sección, que a su vez contenía los elementos ...

Las secciones significan que gutenberg _ debe_ poder manejar adecuadamente las secciones que tienen su visualización configurada en flex y representar correctamente las propiedades flex los niños inmediatos.

Represento mis secciones en JS pero el código tiene una serie de lo que considero hacks. Renderizarlos en PHP sería pan comido ... excepto que enviar contenido de innerblocks a PHP aún no está resuelto, ¿no es así?

Las columnas, tal como las implementa el bloque de columnas, es una solución completamente inviable porque requiere la curación manual de las columnas, lo cual no es algo compatible con dispositivos móviles y hace que agregar o eliminar otro elemento de un conjunto sea una molestia enorme y frustrante.

Las "columnas" en una sección son simplemente una declaración de base flexible y podrían, y deberían, ser fácilmente filas, y no son contenedores reales para elementos, sino simplemente una definición de cómo fluyen. Por favor, no estropee el concepto de secciones con algo parecido a columnas como contenedor (s) para los elementos que contiene.

Las propiedades establecidas en una sección deben ser descubiertas fácilmente por los bloques contenidos dentro de esa sección. Debería poder crear un tipo de bloque que pueda responder de manera inteligente a las elecciones realizadas en el padre, si tiene un padre. Tal como están las cosas, es difícil descubrir algo sobre los atributos de un padre sin escribir lo que parecen 1400 líneas de código.

Los bloques están anidados porque el contexto padre / hijo de esos bloques es esencial para cómo se muestran y editan. Fingir que el contexto no existe es idealismo en su peor momento.

Los bloques anidados deberían poder hacer referencia a los atributos principales fácilmente y de forma predeterminada. Si su objetivo es que los bloques no se procesen en el lado del servidor, excepto en raras ocasiones, ese paso de información de contexto _ tiene que suceder_, de lo contrario render() será un páramo de return null como nuevo y útil pero aparecen bloques complicados.

(Creo que el bloque columns sería más útil si implementara la propiedad CSS columns [aún experimental]. Básicamente sería un tipo especial de section , tomando todo los elementos dentro de él y fluirlos a través de las propiedades de columna definidas en el inspector: column-width , column-count , column-rule , etc.)

¿Hay alguna fecha de lanzamiento para este tipo de bloque (Agregar bloque: sección)?

@JQOz No. Este problema está en la hoja de ruta para las próximas versiones principales, pero no hay solicitudes de extracción abiertas en las que la gente esté trabajando. Si tiene ideas o características para este bloque, puede comenzar a agregarlas aquí.

Hola,

Lo pienso no solo una vez. Una sección debe ser un contenedor de ancho completo. ¿Podemos simplemente agregar un canalón al contenedor dentro de una sección y mantenerlos funcionando como add_theme_support('alignwide') o no?

Para un caso:

https://tech.cornell.edu/

Tenemos muchas secciones diferentes. Algunos de ellos están vivos en un contenedor. Algunos no lo son. Pero todos necesitan un solo recipiente.

Los bloques de columnas de Gutenberg son una clase demasiado anidada y no ayudan mucho. Debe seguir una estructura de cuadrícula y usar la clase padre> hijo para mantenerlos funcionando.

Cuando hago un desarrollo https://www.luminasolar.com/ , debo envolverlos dentro de una clave template para mantener una estructura.

Sugiero que, como parte de la estrategia para el diseño de la página, se piense en proporcionar un gancho / API para que los desarrolladores de complementos y temas de terceros agreguen sus propias interfaces y campanas y silbidos.

Después de este artículo en WPTavern , parece que los usuarios están comenzando a ver un problema con la estandarización y se bloquean en bloques específicos para que el diseño vuelva a la vieja casta de un problema que ha sido un problema durante muchos años: cambiar el tema o el generador de páginas y el diseño desaparece o, en el caso del nuevo editor de bloques, aparentemente, código que no se puede alterar porque está grabado en piedra.

Tener un diseño estándar común que CoBlocks, Kadence (o lo que sea que tenga usted mismo) puede anular, resolvería esto. Cambie el complemento o el tema y al menos su contenido conservará el mismo diseño básico.

Esta es básicamente la única característica que falta que me hace mantener elementor en mis sitios ...

Después de este artículo en WPTavern , parece que los usuarios están comenzando a ver un problema con la estandarización y se bloquean en bloques específicos para que el diseño vuelva a la vieja casta de un problema que ha sido un problema durante muchos años: cambiar el tema o el generador de páginas y el diseño desaparece o, en el caso del nuevo editor de bloques, aparentemente, código que no se puede alterar porque está grabado en piedra.

Tener un diseño estándar común que CoBlocks, Kadence (o lo que sea que tenga usted mismo) puede anular, resolvería esto. Cambie el complemento o el tema y al menos su contenido conservará el mismo diseño básico.

¡Si si si! Creo que un bloque de sección flexible es la mayor característica que falta en Gutenberg. Me alegra saber que está planeado para un lanzamiento futuro, pero me decepciona que nadie esté trabajando en él ahora. Sin esto, los usuarios aún no pueden diseñar formatos de página comunes y los desarrolladores de temas aún deben recurrir a técnicas propietarias para que el usuario pueda crear un diseño de página razonablemente común.

El bloque de sección DEBE estar en el núcleo de Gutenberg (y configurable y extensible por temas) para finalmente resolver los problemas de poder diseñar páginas más complejas y aún poder cambiar de tema.

Claro, como diseñador de temas, voy a agregar mi propia paleta de colores, controlar los márgenes y el relleno para que coincidan con mis temas, dar formato a las imágenes para que coincidan y todo ese tipo de cosas de "diseño" específicas del tema ... debería poder cambiar a cualquier tema de WordPress y al menos conservar su contenido, esencialmente en el mismo diseño (secciones agrupadas, columnas, etc.), y ser editable como un Bloque de Gutenberg (sin tener que cambiar al bloque HTML personalizado).

Tengo un complemento de bloque de sección que tengo una versión inicial de funcionamiento, y espero actualizarlo más adelante esta semana y enviarlo al repositorio. Permite el anidamiento infinito del bloque (quiero decir, dentro de lo razonable, supongo). El complemento también permite que los temas o complementos definan sus propios estilos de sección si lo desean, que luego puede elegir el usuario. Planeo incluir solo algunos estilos predeterminados, que se pueden deshabilitar por temas, si lo desea.

Paneles de inspector

• _Background._ Mi complemento permite configurar el color de fondo y / o la imagen si se desea, con controles para la ubicación de la imagen, fusión, desaturación e incluso superposición de un color.
• _Dimensiones, Relleno, Márgenes._ De forma predeterminada, las secciones se ajustan automáticamente al contenido y obedecen las alineaciones completa, ancha y central, con izquierda y derecha al 45%. Dicho esto, agregaré controles para permitir un ancho y / o alto específico, rellenando los InnerBlocks y el margen alrededor del bloque. _Pero consulte a continuación los problemas con Gutenberg._
• _Columnas ... y filas ._ Después de mucha experimentación con flex, CSS _grid_ para los hijos inmediatos es el mejor método a utilizar si lo que busca es un diseño basado en columnas. El uso de la cuadrícula es una palanca; de lo contrario, los niños son bloques normales. (Honestamente, aunque las filas son factibles, agregan mucha complejidad a la interfaz de edición, lo que podría manejarse mejor agregando una nueva sección debajo de la que está trabajando cuando necesite comenzar una nueva fila). Grid es superior a flex, incluso si solo está haciendo columnas, porque flex _requiere_ que se establezca una altura específica, sin porcentaje, en el contenedor o en los elementos secundarios, lo que elimina mucha flexibilidad.

Móvil
Un problema con cualquier complemento de sección que use cuadrícula es lo que le sucede a la cuadrícula en puntos de interrupción móviles definidos. Los usuarios (o autores de temas) deberían poder definir cuándo una sección pasa de mostrar 3 elementos a 2 elementos a 1 elemento a lo ancho.

Los puntos de interrupción deben poder definirse por el tema y no se sienten realmente como si pertenecieran al bloque, ya que agrega otro gran conjunto de opciones de inspector, y probablemente desee que sus puntos de interrupción sean consistentes en todas las publicaciones y páginas. . Pero cuando se usa la opción de cuadrícula, el bloque necesita conocer los puntos de interrupción y debe permitir que el usuario (o el tema) especifique cómo se adapta el diseño de la sección a ellos.

Estoy seguro de que hay una manera elegante de hacer esto, pero en el corto plazo por conveniencia, simplemente estoy permitiendo que el bloque "aprenda" sobre los puntos de interrupción a través de la configuración y luego usando una lista de valores separados por comas para el definido puntos de interrupción (imagina una captura de pantalla aquí):

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

Etc. (Obviamente, las columnas individuales son 100% y no es necesario especificarlas).

Consideraciones sobre temas y complementos
Un tema (o complemento) puede definir una sección, con todos sus atributos, y ocultar todos esos atributos al usuario, salvándolos de una posible confusión, o el tema puede exponer solo aquellas cosas que quieren que el usuario pueda modificar. (por ejemplo, la imagen de fondo real elegida). Los temas o complementos también son libres de agregar florituras usando su hoja de estilo para especificar tipos de sección ... de hecho, en teoría, podría ignorar todos mis cuadros de inspector, ocultar todos los paneles de inspector del usuario y diseñar cosas por completo con su hoja. Sin embargo, eso elimina la posibilidad de que los usuarios sobrevivan a un movimiento de tema con sus secciones intactas.

Consideraciones del usuario
Suponiendo que el tema ha funcionado bien y ha utilizado las diversas rutas disponibles dentro de mi bloque para definir una sección y sus atributos "correctamente", si se cambia el tema, todos esos atributos sobreviven, y si el tema hasta ahora los ocultaba al usuario, " re expuesto. Esto se debe a que la primera opción en el selector de "sección prediseñada" es "personalizado", que permite al usuario modificar todo, y que es lo que el bloque tomará por defecto si el estilo elegido previamente ya no está disponible. Todas las configuraciones que hizo el tema que NO fueron opciones directas de la hoja de estilo seguirán ahí.

Esto no garantiza que su sección sobreviva de una manera que se vea bien (es posible que haya tenido un tema con un diseño súper ancho y se haya movido a uno con un diseño estrecho, por lo que una sección de seis columnas puede que ya no sea la mejor opción ... pero seguirá allí intacto. Los usuarios pueden guardar ese diseño como un bloque reutilizable.

Al elegir estilos de sección, si pasa de una sección predefinida a una personalizada, siguen los atributos del inspector de la sección predefinida, por lo que es una forma de que los usuarios modifiquen una sección predefinida sin tener que modificar la definición de esa sección en el tema o enchufar.

Problemas de Gutenberg
Entonces, Gutenberg hace mal lo siguiente:

• Bloques que deben unirse verticalmente, lo que a veces es necesario hacer en las secciones de imagen.
• Cualquier tipo de llamada para mostrar algo como flex o grid. Debido a la sopa div del editor, debe desarmar su llamada CSS a grid o flex en el contenedor de innerblocks y restablecerlo en uno de los bloques del editor.
• Alinear a la izquierda y alinear a la derecha. Presenté un error sobre esto, pero debido a que Gutenberg no limita el flotador de un bloque izquierdo o derecho solo al hijo inmediato del bloque que tiene el atributo de datos de izquierda o derecha (o centro), todos los bloques anidados posteriores flotan a la izquierda o derecho.
• Agregar nuevos bloques es a menudo un completo misterio dónde se insertarán ... crees que estás en la parte inferior de tu sección, queriendo un nuevo bloque interno, y en su lugar, el editor insertará uno en la parte inferior de tu documento.
• El modelo de arrastrar / soltar de Gutenberg para mover bloques no funciona de manera confiable con bloques que pueden tener una posición horizontal

Probándolo
Publicaré un enlace en este hilo cuando publique una versión en github que creo que vale la pena ver, si alguien está interesado. He pasado un par de meses en esto y probablemente aún no sea genial, pero es algo.

Debo agregar que creo firmemente que cosas como las fuentes, el tamaño de los encabezados, etc., no son cosas sobre las que el bloque de sección debería tener algo que decir directamente. Los atributos del inspector que estoy configurando me parecen los básicos necesarios para preservar los atributos de "panorama general" de una sección de un tema a otro, o para evitar que la eliminación de un complemento arruine completamente la apariencia de un sitio.

@rogerlos Deberías considerar echar un vistazo a Kadence Blocks . Parece que manejan bastante bien las columnas basadas en flexbox.

Debo agregar que creo firmemente que cosas como las fuentes, el tamaño de los encabezados, etc., no son cosas sobre las que el bloque de sección debería tener algo que decir directamente.

Estoy completamente de acuerdo con esto. La única excepción sería una configuración de "color de fuente" a nivel de sección. Esto es necesario porque un sitio cuyas fuentes son principalmente oscuras no contrastará lo suficiente dentro de una sección que tiene una imagen de fondo / superposición oscura.

Aquí hay una demostración de cómo el bloque de diseño de filas de Kadence reutiliza los "modos de alineación" en la barra de herramientas del bloque para permitir tres anchos de contenido interno diferentes, anchos de columna ajustables, márgenes de fila superior / inferior ajustables, así como configuraciones de color de fondo y texto.

Estas configuraciones de "ancho máximo de la sección de contenido" son casi los únicos patrones repetidos globalmente (y por lo tanto definidos por tema) que un bloque de sección debe tener en cuenta (aparte de las restricciones de componentes heredadas globalmente, como colores de fuente permitidos, tamaños de medianil de columna, etc. )

Partiendo de la experiencia de una agencia web, no hay más de tres anchos de sección de contenido diferentes en cualquier diseño que he recibido. Todo lo que esté fuera de estos tres anchos tiende a ser una variación específica del contenido que se aleja intencionalmente de los patrones de diseño del tema de una manera no repetitiva.

Un buen bloque de sección dirigirá a los usuarios hacia valores predeterminados definidos por temas (siguiendo los patrones del diseño original), pero ocasionalmente les permitirá romper con esos patrones de una manera razonable.

Con el fin de imponer un diseño coherente y predecible en todos los tamaños de pantalla, no se permiten bloques "orientados a texto" en el nivel raíz de nuestra configuración.

Todos los bloques que no son de imagen / incrustados deben estar contenidos en una "sección" (Diseño de fila Kadence) en el nivel de la raíz, que refuerza los anchos de sección de contenido de nuestro tema, al tiempo que permite filas totalmente personalizables con cualquier número de columnas, así como un fondo de ancho completo. opciones, etc.

Los elementos de contenedor también deben permitir que los elementos de capa se apilen (índice z).
Esto permite, por ejemplo, un elemento de vídeo o un control deslizante como fondo o un efecto de paralaje.

@strarsis Buena idea.

Idealmente, un bloque de sección usaría z-index para proporcionar un modo de edición de primer plano / fondo conmutable.

De esta manera, el bloque de sección en sí no reinventa la imagen de fondo / superposición, que está disponible en el bloque de imagen de portada incorporado.

El contenido de fondo no estaría restringido por el ancho y, por lo tanto, los desarrolladores de temas deberían tener la capacidad de definir qué bloques pueden ir al fondo de una sección. El ancho del contenido de primer plano estaría restringido a un cierto número de anchos máximos proporcionados por el tema.

Si el usuario necesita alejarse de un ancho predeterminado dado un contenido específico, puede elegir una sección con el siguiente ancho más grande y rellenar los lados en consecuencia.

Las instancias en las que el contenido en primer plano debe romperse visualmente fuera del ancho máximo de una sección deben registrarse como una variación de estilo que ajusta un margen negativo en ese bloque específico.

La razón de esto es que, si bien los usuarios estarán bastante seguros ajustando los valores de relleno, definitivamente no queremos que los márgenes negativos sean algo definido por el usuario.

Permitir los márgenes negativos de la definición en el editor sería un lío al responder a diferentes tamaños de pantalla, relleno lateral de la sección de contenido, anchos de canal en ciertos puntos de interrupción, etc. y, por lo tanto, debería estar estrechamente acoplado con el tema / código y expuesto como abstracciones de nivel superior al usuario final.

Con respecto al control del desarrollador: existe el complemento Mesh que proporciona contenedores "duros",
que debe ser forzado por el tema.
A veces, un tema debe restringir las áreas disponibles, como solo la esquina superior izquierda de toda la página.
Gutenberg debería proporcionar un mecanismo para que los temas establezcan estos contenedores "duros" dentro de su editor de páginas.

@strarsis En mi opinión, cualquier cosa que suceda fuera del área the_content() no tiene nada que ver con el editor de Gutenberg.

Estas "áreas" son parte de la plantilla de la página y no el contenido de la página y deben manejarse en otro lugar.

Contenido de la página frente a la plantilla de la página (/ Diseño)

El contenido / secciones dentro del editor debe asumir que el diseño circundante no existe (durante la edición) y, en cambio, debe estar equipado para responder apropiadamente cuando se coloca dentro de un diseño en particular (en la parte frontal).

Un elemento es parte de una plantilla de página ( y no contenido de página ), si:

1. el elemento define o depende de la estructura, los límites o la posición del área the_content() en su conjunto , y
2. el elemento es parte de un patrón repetido (es decir, podría verse potencialmente en dos o más enlaces permanentes)

Algunos antecedentes basados ​​en la experiencia

Los elementos de plantilla / diseño repetidos suelen ser específicos de un tipo de publicación personalizada e incluyen heros de contenido, barras laterales de contenido y pies de página de contenido.

En todos y cada uno de los casos, descubrí que el contenido de estos elementos de diseño se deriva suficientemente de la información ubicada en campos personalizados, taxonomías u otras configuraciones ubicadas en el nivel de publicación y no en el nivel de bloque.

Y, en todos los casos, he reforzado mi creencia de que sería una empresa increíble modificar en bloque o cambiar el estilo de estas secciones si se hubieran implementado como bloques dentro del editor de Gutenberg.

Así que finalmente

La definición (y eventual implementación) de una Sección solo debe extenderse lo suficiente para manejar las necesidades de los patrones de diseño del tema en lo que respecta a the_content() .

Todo lo que se encuentre en "plantilla" y no en "contenido" debe manejarse fuera de cualquier bloque de sección y fuera del editor de Gutenberg (por ahora).

Quiero que Gutenberg pueda hacer plantillas en línea con el contenido tanto como todos los demás, pero parece que todavía no lo hemos logrado, y definitivamente deberíamos concretar este bloque de sección antes de que podamos manejar las plantillas de manera adecuada.

Hace un par de días quería crear un diseño básico y necesitaba esto. Así que comencé instalando el complemento A, lo probé, tenía errores. Desinstalado, encontré el complemento B, instalado, probé su bloque de sección, estaba mal. El siguiente complemento C con errores, el complemento D lo llamó contenedor y era meh. Siguiente complemento E, F .........
Puedo asegurarles que el "ecosistema" actual de Gutenberg es muy, muy frustrante si quiere crear una página y escribir contenido.
El hecho de que la gente aquí siga diciendo "mira el complemento X", "si quieres esta característica, instala el complemento Y", etc. es una clara indicación de que la gente lo necesita. No lo quieren, lo necesitan . En este momento hay una docena de complementos, todos con su propia implementación de un contenedor / sección / lo que quieras llamarlo.
No estoy diciendo que Gutenberg deba agregar todas las funciones bajo el sol, pero esta es una básica. Necesita estar ahí. No necesita tener todas las opciones imaginables, pero lo básico debería estar ahí y los desarrolladores pueden ampliarlo si es necesario.
Estamos llegando a un punto en el que habrá 20 implementaciones diferentes para un contenedor básico y ninguna de ellas funcionará como debería (opinión personal, por supuesto).

Como alternativa fácil, simplemente utilicé un bloque de columnas y establecí el número de columnas en 1 (el control deslizante está limitado entre 2 y 6, pero puede ingresar 1 en el campo de entrada). Después de eso, necesita corregir CSS en el administrador:

//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
}

Y, por supuesto, también debe establecer lo mismo en su interfaz, pero ese es un problema de tema. Creo que permitir un diseño de una sola columna sería suficiente para una opción de contenedor básica, que generalmente se necesita para fines de estilo de todos modos. Cualquier otra cosa (como configurar un fondo, índice z, paralaje, etc.) debe hacerse con complementos en mi opinión.

Y agregue un medio para que el tema (desarrolladores) controle cuántos y qué envoltorios se utilizan.
Algunos diseños solo necesitan más de un elemento. Actualmente tengo que usar otro complemento para un elemento de contenedor y luego analizar todo el contenido usando un analizador PHP para envolver el contenido del contenedor en elementos de contenedor adicionales para diseñar.

@strarsis Esto es definitivamente algo que debería haberse hecho desde el principio.

Para hacer un estilo decente del contenido de la publicación, cada hijo de nivel raíz debe colocarse en una fila / sección coherente.

Por ejemplo, sin envolver cada fila, es difícil y complicado hacer secciones de diferentes anchos (especialmente secciones de ancho completo).

También consideré la opción de análisis de PHP, pero me di cuenta de que no le da al editor de contenido ningún control sobre en qué tipo de sección se encuentra un contenido en particular.

En cambio, en nuestra configuración, forzamos todas las instancias del editor de Gutenberg para que solo permitan un único bloque de contenedor en el nivel raíz para cualquier publicación / página / tipo de publicación.

El bloque contenedor raíz impone un subconjunto limitado de bloques que se pueden agregar dentro.

Para agregar texto o bloques que no sean de ancho completo, primero debe insertar un diseño de fila Kadence, que en este caso actúa como nuestro elemento contenedor de la sección principal.

Un bloque contenedor extensible simple es todo lo que se debe requerir dentro del núcleo. La extensión de este bloque con respecto al estilo debe dejarse a los desarrolladores de complementos / temas. También debería proporcionar un estado de transformación de reserva para los desarrolladores que deseen crear sus propios bloques de contenedores.

Todos los complementos de terceros existentes que proporcionan contenedores / secciones / filas que he probado están sujetos a un problema importante con respecto al bloqueo de contenido. Tras la desactivación de estos complementos, el contenido del bloque interno ya no es accesible desde el editor y convertirlos elimina el HTML. Algo de lo que los usuarios deben ser plenamente conscientes.

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

Okay. He probado Gutengerg, es bueno, pero sí, definitivamente carece de la sección.
Para ser verdad, muchos bloques tienen su contenedor al que podemos agregar una clase css y su estilo. Pero, el contenido principal está escrito sin un contenedor, por lo tanto, sin ninguna clase, por lo que no podemos diseñarlo. Y dado que el contenido principal está escrito en la misma etapa que todos los demás bloques, esto hace que sea extremadamente difícil encuadrarlo de manera diferente a los demás.

En otras palabras, volveré al clásico y esperaré hasta que nos des Secciones.

Gracias Saludos.

Sí, eso es absolutamente cierto. Creo que es incluso más importante que todos los demás bloques que se están desarrollando actualmente. @youknowriad ¿No puedes darle más prioridad?

Ya está en el alcance de la fase 2 https://github.com/WordPress/gutenberg/issues/13113 si alguien está dispuesto a intentarlo, hágalo.

@youknowriad Me temo que no soy desarrollador. Pero recuerdo que el desarrollo ya estaba en marcha. Poco antes del lanzamiento de Wordpress 5 había un PR que ya estaba muy avanzado. Aún quedaban detalles por aclarar, pero estaba casi listo. Desafortunadamente ya no puedo encontrar el PR. ¿Alguien tiene una idea de dónde está?

Sí, no te preocupes, lo entiendo.

Aquí está el PR. https://github.com/WordPress/gutenberg/pull/10562

Quería aclarar que es un proyecto de código abierto y se basa en el voluntariado. Puedo dar una dirección global, pedir ayuda pero no asignar personas. La gente tiende a pensar de otra manera.

Reitero que si hay desarrolladores que quieran ver que esto suceda más rápidamente y quieren ayudar, son bienvenidos a las reuniones semanales en el canal (y reuniones) de Core Slack # core-editor y discuten / colaboran / piden ayuda.

Ahhh si eso es todo! ¡Excelente! Tienes una visión general !!!

Sí, es cierto y no debería ser un reproche. Lo que simplemente me pregunté: ¿no hay tareas importantes y aún más importantes? Si 50 personas necesitan un bloque RSS, pero 1000 necesitan un bloque contenedor, tendría sentido enfocar todo de manera más específica. El bloque de contenedores no es nada exótico ahora. Creo que esta es la base de todo diseño.

Por favor, no lo malinterprete: está haciendo un gran trabajo. Y usted, como líder de la Fase 2, está haciendo un trabajo de primera clase. Se trata de la cuestión del enfoque. Brindaré por eso en la próxima charla floja ... ;-)

¡Muchas gracias de nuevo!

Gracias y feliz de aclarar. Les doy personalmente la misma importancia. Un paso intermedio para la fase 2 es usar bloques en la pantalla de widgets. Entonces, incluso si las personas no están solicitando un bloqueo RSS, una vez que la pantalla de widgets (que es un paso importante para la fase 2) vaya a usar bloques, si las personas no encuentran el widget RSS que están acostumbrados a usar, lo harán quejarse de ello.

Ambas estas dos tareas son tareas "medianas" en términos de complejidad, son importantes en cuanto a características, pero no son importantes en cuanto al marco. Mi alta prioridad personal en este momento son las cosas del marco que permitirían los objetivos de la fase 2 (bloques en la pantalla de widgets, editor fuera de post_content), ya que es importante experimentar y aclarar estos problemas contemporáneos más temprano que tarde.

Okay. He probado Gutengerg, es bueno, pero sí, definitivamente carece de la sección.
Para ser verdad, muchos bloques tienen su contenedor al que podemos agregar una clase css y su estilo. Pero, el contenido principal está escrito sin un contenedor, por lo tanto, sin ninguna clase, por lo que no podemos diseñarlo. Y dado que el contenido principal está escrito en la misma etapa que todos los demás bloques, esto hace que sea extremadamente difícil encuadrarlo de manera diferente a los demás.

En otras palabras, volveré al clásico y esperaré hasta que nos des Secciones.

Gracias Saludos.

Esta es la postura que estoy adoptando sobre esta y otras deficiencias del nuevo editor de bloques hasta que tome forma. Es de esperar que esto suceda ya que hay algunos aspectos agradables del nuevo editor.

Un bloque de sección sería genial, ¿qué puedo hacer para ayudar aunque carezco de habilidades de desarrollo de backend?

Ahora hay muchos complementos de bloque, pero el único bloque de ellos que quiero es una sección o un bloque contenedor, así que me encantaría ver uno agregado.

El núcleo de WordPress debe incluir su propia implementación de una sección, fila, estructura de diseño de columnas para el editor de bloques, algo que sea estándar y que pueda ser utilizado por todos los complementos, temas y creadores de páginas de terceros. Se debe proporcionar una API, como he mencionado muchas veces antes, para que puedan agregar sus propias interfaces, campanas y silbidos. Apague cualquiera de estas soluciones de terceros y la estructura de su página permanecerá intacta.

Ya que hay soluciones de terceros para secciones / filas que provienen de todas las direcciones, pero una vez que comienza a mezclar bloques de núcleo nativo y bloques de terceros, comienza a ver muchas inconsistencias y bloques que fallan y necesitan ser resueltos. No es que quiera criticar los esfuerzos de quienes brindan estas soluciones para el diseño, están completando una característica muy necesaria. Muchos de ellos son buenos, pero algo no está del todo bien en la experiencia general.

Estoy a favor de mantener simple el editor de bloques centrales, permitiendo que terceros agreguen funcionalidad y sofisticación adicionales, pero realmente necesita ser reforzado, de lo contrario, obtener algo de tracción en su aceptación no se logrará muy fácilmente.

La gran pregunta aquí es quién se encarga de ello. ¿No hay algunos desarrolladores que tengan el tiempo y la energía para hacerlo?

¡Si si si! Creo que un bloque de sección flexible es la mayor característica que falta en Gutenberg.

Ni siquiera puedo creer que aún no exista ...

Una alternativa sería permitir que el bloque de columnas tenga solo una columna y también permitir la configuración de colores de fondo para las columnas. TA-DA: bloque de sección.

Bueno, si ayuda a alguien: escribimos un bloque de sección para nuestros proyectos hace algún tiempo. Estoy seguro de que se puede embellecer en algunos puntos, pero podría ser un buen punto de partida:

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

Voy a levantar la mano para trabajar en esto. Podré empezar a trabajar desde mediados de la próxima semana.

@chrisvanpatten : parece que hiciste un muy buen progreso en esto antes, solo quería comprobar si estás de acuerdo con que lo haga.

He usado algunos bloques de contenedores de complementos. Creo que los requisitos principales son admitir una alineación amplia y completa, flotadores y controles para cambiar el fondo del contenedor. El objetivo de enviarlo en una primera versión proporcionará una buena base para futuras mejoras.

Creo que la primera mejora es agregar más envoltorio fuera de cualquier bloque.

Por ejemplo:

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

Ahora mismo, muchos de los elementos se insertan directamente, impiden que apliquemos estilo para hacer un envoltorio.

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

Se puede agregar envoltorio a eso:

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

Luego podemos aplicar el conjunto de contenedores para mantenerlos coincidentes:

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

@talldan, ¿le importaría
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

Los bloques de sección serían increíbles, ¡pero hazlo solo con marcas semánticas! Mantener las cosas en la estructura semántica de HTML crearía la base de código más agnóstica.
<section>, <article>, <header> es mucho mejor <div class="wp-section"> o lo que sea.

@talldan Lo siento, me perdí tu comentario, pero estoy 100% de acuerdo con que aceptes esto 🙌 ¡Estoy seguro de que lo harás genial!

También sería genial poder usar el punto focal del bloque de texto y medios # 10925. Por supuesto, esto solo tiene sentido si tiene una imagen de fondo.

Una gran cosa, que, por cierto, muchos creadores de páginas también tienen. O al menos algo así:

Acordé que un selector de puntos focales sería genial aquí. ¡Funciona muy bien en el bloque de cubierta!

Con eso en mente, he actualizado mis maquetas anteriores para un bloque de sección. Actúa puramente como un elemento contenedor con una imagen y un color de fondo ajustables.

Vista previa :

Puedes ver el prototipo aquí .

Algunas notas adicionales:

• Creo que deberíamos lanzarlo sin imagen de fondo para comenzar, solo color de fondo / texto. Una vez que lo sacamos, podemos construir una imagen de fondo a continuación. Esto lo consigue rápidamente, utilizando patrones existentes, y aún debería cubrir una gran cantidad de casos de uso.
  
  
  
  • Una vez que fusionamos la primera versión, podríamos desaprobar el fondo y el color del texto del bloque de texto. En cambio, podríamos tener opciones de color en línea / opciones de resaltado en el bloque de párrafo. Este parece ser un patrón general mejor para el párrafo.
  
  
• Este bloque no contendría ninguna configuración de respuesta, ya que siempre sería solo un contenedor. El contenido dentro del contenedor (como un bloque de columnas) proporcionaría el comportamiento de respuesta.

Estoy de acuerdo, la imagen de fondo se puede agregar usando css si es necesario por el momento: +1:

Una vez que fusionamos la primera versión, podríamos desaprobar el fondo y el color del texto del bloque de texto. En cambio, podríamos tener opciones de color en línea / opciones de resaltado en el bloque de párrafo. Este parece ser un patrón general mejor para el párrafo.

Una de las razones para considerar el bloque de sección como el lugar correcto para los colores de nivel de bloque es que, de lo contrario, tenemos que responder por qué la lista, el encabezado y otros bloques de texto básicos no tienen esas opciones de color. Y dado que están divididos a nivel de bloque, nunca podrá tener una imagen de fondo que abarque todos ellos continuamente, mientras que un bloque de sección lo corrige.

La forma de desaprobar estos colores podría ser simplemente eliminar la interfaz de usuario, pero dejar que los bloques existentes permanezcan con el estilo que están.

¡Agradable! Sería útil tener clases pequeñas / medianas / grandes para el relleno vertical.

¡Agradable! Sería útil tener clases pequeñas / medianas / grandes para el relleno vertical.

Esto se sumerge en el nivel de tema / marco, y no estoy seguro de si el núcleo tiene un lugar para algo como https://cdn.vaadin.com/vaadin-lumo-styles/1.4.1/demo/sizing-and-spacing .html

Creo que deberíamos lanzarlo sin imagen de fondo para comenzar.

No podría estar más de acuerdo. Obtenga un v1 y luego v2 puede agregar la funcionalidad más compleja.

Este bloque no contendría ninguna configuración de respuesta

De acuerdo, este bloque debe ser lo más simple y sin opiniones posible.

Creo que deberíamos fusionar este RP si es posible.

Le di un golpe a algo como esto ... lanzado como un complemento:

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

Por favor, no más complementos que dejarán a la gente dependiendo de él. Solo suelta el maldito bloque.

@webdados Yo

No para disminuir el trabajo de nadie, pero realmente necesitamos que esto esté integrado en algún nivel.

Especialmente en un mundo donde existe este problema .

Si se encuentra una solución adecuada para # 13391, entonces la existencia de innumerables implementaciones de bloques de contenedores probablemente estaría bien.

Hasta que el nuevo constructor de bloques no tenga una base estándar para los elementos de diseño (contenedores, secciones, filas, columnas) que los complementos de terceros pueden extender, entonces no servirá de nada y perpetuará el lío de encender y apagar bloques, temas y constructores de terceros ( aquellos que intentan abordar el problema del diseño) y terminan perdiendo el contenido y el diseño de la página.

¿Cuándo podemos esperar esta característica?

Ya debería estar en la última versión:
https://github.com/WordPress/gutenberg/releases/tag/v5.5.0

@ksere : Me lo perdí probablemente porque el registro de cambios para v5.5.0 del complemento está vacío .

Realmente investigando la implementación en esto hasta ahora. Entiendo que acaba de ser lanzado en 5.5, pero me pregunto cuándo podríamos esperar adiciones para imágenes de fondo (y su posición), opacidad del color de fondo, etc. ¿Es esto algo que deberíamos esperar antes de finales de 2019, o estamos hablando más tiempo? -término que ese?

@nathansnelgrove Gracias por los comentarios. Definitivamente hay algunas mejoras en el bloque de grupo, aquí hay dos que ya están en progreso:

• Agregar un contenedor interno para facilitar el peinado: https://github.com/WordPress/gutenberg/pull/15210
• Agregar opciones de editor para agrupar / desagrupar una selección de bloques: https://github.com/WordPress/gutenberg/pull/14908

No he visto los problemas que mencionó sobre el seguimiento de las imágenes de fondo y la opacidad en ningún lugar, podría valer la pena crear un problema separado para eso si tiene tiempo, ya que este problema ya está cerrado.

Las imágenes de fondo / colores / opacidad son de la propuesta original; haré un nuevo número para ellos.

Acabo de instalar WordPress 5.2.4 y no puedo encontrar ningún bloque de "Sección" o "Grupo". ¿Que está pasando aqui?

@patrikhuber : Esto se incluirá en WordPress 5.3, que actualmente está previsto que se publique el 12 de noviembre.

@noisysocks Ya veo, ¡muchas gracias!