Haciendo ping a @iseulde para los cambios del editor. Puedo agregar los cambios básicos.

Para el editor, los cambios (como yo los veo) serían:

• Agregue un atributo data-wp-attachment-id="1234" a todas las etiquetas <img> .
• Inserte siempre la imagen de tamaño "grande".
• Agregue el atributo srcset con los tamaños mediano, grande y xlarge (en breve agregaremos el tamaño de imagen xlarge a los tamaños predeterminados).
• Agregue el atributo sizes adecuado para el ancho de la imagen en el editor.
• Al guardar, quizás elimine tanto srcset como sizes ya que probablemente serían diferentes cuando se mostraran. Alternativamente, podemos anularlos en el filtro de visualización.
• Cuando establezca valores de píxeles para las dimensiones de la imagen, basarlos en el ancho del editor. No tendrá sentido tener imágenes más anchas de lo que es visible en el editor.

TODO: considere cuál sería la mejor manera de pasar el ancho porcentual al front-end.

¡Gracias por escribir esto, @azaozz! Feliz de ayudar con los cambios de editor necesarios. Me suenan bien.

Alternativamente, podemos establecer el ancho en porcentaje (estilo HTML 4.0) en el editor y luego reemplazarlos con píxeles en este punto.

Mi duda con esto es que si un tercero (por ejemplo, un complemento, un lector de RSS, un consumidor de API) usa post_content sin procesarlo, no tendrá un marcado HTML5 válido. "Honrar HTML" es uno de los requisitos de Gutenberg.

Pensando en voz alta: ¿podríamos usar los metadatos de Gutenberg para lograr algo de esto, por ejemplo, para almacenar el ID del archivo adjunto y el ancho porcentual?

<!-- wp:image {"attachmentId":123,"horizontalScale":0.25} -->
<img src="https://example.com/image.jpg" width="600" height="500" />
<!-- /wp:image -->

Sí, las imágenes son "bloques dinámicos" (así es como también se tratan en el editor clásico). Son el mejor tipo de bloques dinámicos, ya que tienen el "marcado alternativo" y se procesan en el
front-end para mejorarlos.

Tener ese marcado alternativo hace que las imágenes funcionen "en todas partes" incluso cuando los "filtros de visualización" no se han ejecutado (esto en realidad dejaría el contenido sin párrafos, así que no crea que ningún complemento lo haría).

Ciertamente podemos agregar los datos que necesitamos pasar al front-end al meta de bloques, sin embargo, pensamos que también necesitaremos los mismos datos en las etiquetas <img> . Una razón es que el análisis de los bloques en pantalla es lento y obtendremos fragmentos más grandes de HTML en lugar de la etiqueta img real (la figura con el título, etc.). Otra es que (quizás) no todas las imágenes estarán en bloques separados, pensando en imágenes en blockquotes, celdas de tabla, etc. Otra razón más es que si la publicación se edita en cualquier otro editor, los bloques pueden estar muy destrozados, pero el <img> etiquetas

Al final, esto se reduce a:

• Lo que es más fácil, rápido, simple, más legible / comprensible: analizar el bloque y luego procesar el fragmento de HTML (que puede contener varios elementos), o analizar las etiquetas <img> como lo hacemos actualmente.
• ¿Podemos garantizar que todas las imágenes utilizadas en el editor siempre estarán en bloques wp:image ? Eso incluye imágenes pegadas, imágenes en celdas de tabla, comillas y cualquier otra combinación de bloques y etiquetas que puedan surgir con los complementos.

En mi humilde opinión, deberíamos usar tanto el meta del bloque como los atributos de la etiqueta img, luego (un día) podremos elegir cuál usar al analizar el contenido en pantalla.

@azaozz Esta es una propuesta bien pensada. Sin embargo, no entiendo completamente por qué no usamos tamaños de imagen declarados por tema existentes. ¿Existe una discusión previa sobre esto?

Actualmente, hay un campo de porcentaje expuesto, pero no pude determinar si esto hace algo en la interfaz. https://github.com/WordPress/gutenberg/blob/master/blocks/library/image/block.js#L266

El enfoque porcentual es bueno, pero rompe la compatibilidad con la API del tema.

por qué no usamos tamaños de imagen declarados por tema existentes ...

Lo hacemos :) Usamos todos los tamaños disponibles (que tienen la misma proporción a / h) cuando agregamos el atributo srcset en el front-end. Luego, el navegador decide qué archivo de imagen usar.

@azaozz Creo que funcionaría un poco diferente al comportamiento actual. Los tamaños de imagen también se pueden utilizar para ofrecer estilos, no solo el recorte de imagen que se va a utilizar. También creo que los complementos de carga diferida existentes esperan que el src sea ​​del tamaño "correcto", por lo que no estoy seguro de que podamos confiar totalmente en srcset .

Editar: Este sería el filtro image_size_names_choose , creo.

@davisshaver He pasado por varios complementos de carga diferida la semana pasada. Muchos de ellos buscan los atributos src y srcset y simplemente los reemplazan con otro marcado en PHP usando un filtro the_content . El desafío aquí es cómo lograr que el núcleo genere los atributos srcset y sizes correctos, así como imágenes físicas en primer lugar.

Hay varios problemas relacionados con las imágenes receptivas que tendrán soluciones superpuestas. Propongo que consolidemos todo en este tema para evitar una mayor fractura de la discusión. Aquí hay una lista incompleta:

Asuntos relacionados:

• # 5674 Las imágenes de la galería no responden
• # 4505 Agregar clases y mecanismos 'has-wide-support'
• # 4342 El contenido se muestra incorrectamente al cambiar de tema
• # 6131 Permitir que el tema controle el atributo de tamaños para imágenes anchas / completas

Entradas principales:

• Reemplazar estática con tamaños de imagen dinámicos para imágenes insertadas
• Cómo eliminar la ruta de imagen de tamaño completo de srcset y opciones más inteligentes en la lista de candidatos de srcset
• Optimizar imágenes a tamaño completo

Al respecto, en la propuesta de @azaozz :

Agregue un nuevo tamaño predeterminado 2x grande, 2048px de ancho o alto máximo

¿Se ha considerado aumentar los tamaños de píxeles predeterminados actuales de "miniatura", "mediano" y "grande", que se definieron originalmente en 2008? Quizás con Gutenberg sea el momento perfecto para incrementarlos x2.

De lo contrario, los términos "mediano" y "grande" perderán su significado semántico.

También relacionado: # 5650 content_width y nuevos anchos de bloque

La misma causa del problema principal: el nuevo paradigma de ancho de contenido hace que las cosas que solían ser estándar no funcionen como se esperaba e introduce la necesidad de repensar cómo funciona el núcleo.

/ update / image-block es un "trabajo en progreso" :) Por favor, pruebe.

Cambios:

• Agregue srcset y sizes dentro del editor.
• Siempre inserte el tamaño de imagen large , o full si no existe el tamaño grande.
• Muestre un tamaño de imagen de Default , un Thumbnail , más cualquier sumador de tamaños por complementos y temas.
• Agregue data-wp-attachment-id y ata-wp-percent-width a la etiqueta img. Se utilizará en la interfaz para configurar correctamente srcset y sizes , y también img width y height donde falten.
• Mejora la configuración / restablecimiento de las dimensiones de la imagen.
• Agregue srcset a los datos adjuntos de la API y a los datos en el modal de medios.

QUE HACER:

• Agregue el código de front-end que manejará los nuevos atributos de etiqueta img.
• Se corrige la eliminación del enfoque de la imagen (y la ocultación de los controladores de cambio de tamaño) cuando el título está enfocado.
• Intente corregir el cambio de tamaño arrastrando. Actualmente, arrastrar las esquinas hacia la izquierda o hacia la derecha no hace nada, solo arrastrar hacia arriba o hacia abajo cambia el tamaño de la imagen (y es gruesa).

@azaozz, esto se ve muy bien hasta ahora. ¡Buen trabajo!

Algunas cosas que he notado al probar esto:

Primero, el ancho del editor probablemente no va a coincidir con el ancho de visualización previsto en la interfaz, por lo que guardar el atributo sizes basado en el atributo del editor es probablemente el enfoque incorrecto y hace que la imagen se limite al ancho del editor , en lugar del contenedor de contenido del tema. Necesitamos hacer uso del content_width establecido por el tema en la interfaz, o continuar configurando sizes en la interfaz, en lugar de guardarlo en el marcado de la imagen (que, Estoy seguro de que no le sorprenderá saber que todavía creo que es una mala idea).

Esta última sería mi sugerencia. Aquí ahora podemos aprovechar el analizador de bloques en WordPress para implementar una solución de imagen con mejor capacidad de respuesta, en lugar de un filtro en the_content . Actualmente, el bloque guarda datos de atributos duplicados en el delimitador de comentarios del bloque de imagen y en el marcado. Podríamos seguir guardando srcset y sizes como atributos de bloque sin agregarlos al marcado. Luego, podemos continuar usándolos en el componente editable como lo ha hecho ahora, y ponerlos a disposición del analizador de bloques. También podríamos limpiar varios de los otros duplicados en el proceso declarando source para los atributos que estamos guardando en el marcado.

I I los cambios en el menú desplegable de tamaño aquí. Tengo curiosidad si ha pensado en cómo podría extenderse esto para permitir tamaños de recorte personalizados, es decir, add_image_size() opciones que se incluirán aquí para que alguien pueda crear un conjunto de opciones recortadas para una imagen.

Un error que encontré fue insertar una imagen, configurar el tipo de fuente en miniatura, guardar un borrador y luego actualizar la página. En ese caso, el analizador de bloques responde con el clásico error "Este bloque parece haber sido modificado externamente". Parece que solo espera los atributos src y alt y se está ahogando con los atributos adicionales en el marcado.

Todavía hay algo de rareza con las imágenes alineadas a derecha / izquierda. Me pregunto si en estos casos deberíamos cambiar explícitamente el tamaño a un porcentaje del ancho del editor y actualizar el atributo de tamaños para que coincida.

Me sorprendió la opción de agregar un srcset específico de wp_prepare_attachment_for_js pero es un enfoque inteligente que nunca había considerado. Deberíamos abrir un ticket en el núcleo para esto para que podamos discutir los pros / contras de agregar explícitamente estos datos a esas respuestas en lugar de dejar esto en un filtro una vez que Gutenberg aterrice. Una pequeña nota, he visto algunos avisos en el filtro REST que a veces $response->data['media_type'] no existe y está lanzando avisos, lo cual es extraño porque siempre debe estar definido. Algo divertido para profundizar.

Voy a dejar esto por ahora y seguir probando. Bravo, señor.

@joemcgill gracias por echar un vistazo!

En primer lugar, es probable que el ancho del editor no coincida con el ancho de pantalla previsto en la parte frontal

Correcto. Esta es la razón para agregar el atributo data-wp-percent-width a la etiqueta img. Entonces podremos recalcular el ancho en el front-end y "hacer coincidir" lo que el usuario ve en el editor. Esto también lo hace compatible con la edición en un teléfono, y también admite los anchos wide y full cuando se configuran en el tema (deberíamos obtener los temas para agregarlos y comenzar a usarlos en el frente- fin).

... guardar el atributo de tamaños basado en el atributo del editor es probablemente el enfoque incorrecto

Sí, está destinado a ser anulado en el frente. Estaba pensando si deberíamos mantenerlo en la etiqueta de la imagen como un "respaldo" en caso de que algo salga mal. Sin embargo, pensar en dejar el srcset en la etiqueta, ya que la posibilidad de que cambie después de que se publique la publicación es muy pequeña (se podrá filtrar en el front-end, por supuesto). No es bueno tener solo srcset y ningún tamaño, por lo que veo, el navegador parece descargar la imagen más grande posible (probablemente otra alternativa) :)

ahora podemos aprovechar el analizador de bloques en WordPress ...

Posiblemente, pero eso será bastante lento. Por ahora, ejecutar el analizador de bloques en la interfaz no es algo que podamos hacer.

Actualmente, el bloque guarda datos de atributos duplicados en el delimitador de comentarios del bloque de imagen y en el marcado.

Así es como funcionan las propiedades de los bloques. Alternativamente, podemos "extraer" los bloques de imagen con algunas expresiones regulares y analizar el HTML en ellos buscando la etiqueta de la imagen. Aún así ... analizar incluso un poco de HTML con expresiones regulares parece algo que deberíamos evitar. Entonces, por ahora, está pensando en agregar todo el contexto necesario del editor en la etiqueta img real.

Tengo curiosidad por saber si ha pensado en cómo podría ampliarse esto para permitir tamaños de cultivos personalizados (el menú desplegable de tamaño)

Esto debería funcionar en la actualidad. Solo los tamaños que coinciden con la proporción de la imagen original se eliminan del menú desplegable, el resto (más la miniatura) se muestran. Entonces, todos los cultivos personalizados agregados por temas y complementos están en él.

Un error que encontré fue insertar una imagen, configurar el tipo de fuente en miniatura, guardar un borrador y luego actualizar la página.

Uh, lo comprobaré de nuevo. Pensé que capté todos estos ... Esto también me impulsó a mirar la validación de bloques y por qué los bloques fallan con tanta frecuencia (por ejemplo, después de que el usuario agrega otro atributo). Pensando que también necesitaremos algunas correcciones más generales, pero eso es para otro problema.

Todavía hay algo de rareza con las imágenes alineadas a derecha / izquierda. Me pregunto si en estos casos deberíamos cambiar explícitamente el tamaño a un porcentaje del ancho del editor y actualizar el atributo de tamaños para que coincida.

Sí, pensando que el comportamiento anterior era mejor allí. Probablemente deberíamos volver a configurar las imágenes alineadas a la derecha / izquierda al 50% de ancho. También puede cambiar sizes si mantenemos ese atributo en la etiqueta img.

Me sorprendió la opción de agregar un valor srcset específico a cada tamaño devuelto por la API REST y por wp_prepare_attachment_for_js

Probé varios enfoques allí, pero este parece funcionar mejor. En el momento en que se agrega srcset la meta de la imagen ya está almacenada en caché, por lo que agrega una sobrecarga insignificante al cargar los datos para la biblioteca multimedia y la API. De esa manera también hacemos coincidir el srcset "adecuado" que se utilizará en el front-end.

Deberíamos abrir un ticket en el núcleo para esto ...

Sí, una vez que se fusione Gutenberg, esto debería ir a las funciones adecuadas.

He visto algunos avisos en el filtro REST que a veces $ response-> data ['media_type'] no existe

Hmm, probablemente deberíamos abrir un ticket de tráfico central para eso. Siempre debe estar presente.

A continuación, analizaré la posibilidad de agregar el código de front-end que usa los nuevos atributos. Entonces tendremos un buen comienzo para ajustar todo esto :)

Tuve una charla con @azaozz en el día del colaborador de WCEU y quiero compartir mis pensamientos con todos en un esfuerzo por hacer avanzar esto.

__Context: __ Front-end (tema / territorio del complemento)
__Supuestos: __ La propuesta presentada por @azaozz re: establecer un atributo data-wp-percent-width con el ancho mostrado en relación con el espacio disponible.

Propuesta

El desafío que me interesa, como he estipulado antes (# 6131), es cómo los desarrolladores de temas y complementos pueden controlar el atributo sizes en el front-end del sitio en función de diversos factores, incluidos pero no limitado a diferentes diseños (barras laterales o no, otros factores) sin tener que reescribir manualmente todo el atributo sizes para cada condición como en este ejemplo .

Considere los siguientes escenarios, de la a a la i:

Históricamente, hemos sabido dos cosas sobre cualquier imagen mostrada: el ancho físico del archivo de imagen y el $content_width definido por el tema. Luego usamos estos dos parámetros para calcular el atributo sizes .

Gutenberg presenta no solo los anchos alignwide y alignfull , sino también la capacidad de hacer varios elementos wide o full incluyendo pero no limitado a columnas, etc. como resultado, hay una gran cantidad de posibles anchos de visualización dentro de cualquier tema, además de los desafíos habituales que plantea el diseño web receptivo.

Estos ejemplos muestran que hay _dos constantes_ que pueden ser definidas fácilmente por el desarrollador del tema (y por los desarrolladores de complementos de extensión):

• $content_width : el ancho máximo del contenido cuando no se muestra como alignwide o alignfull .
• $max_display_area - el espacio máximo disponible disponible para ser llenado si el contenido se establece en alignfull .

También hay una tercera suposición que podemos hacer:

• Un elemento configurado en alignwide ocupará el $content_width completo más la mitad del espacio disponible entre $content_width y $max_display_area , y se puede calcular como

$content_width + ( $max_display_area - $content_width ) / 2

En otras palabras, si WordPress conoce los valores $content_width y $max_display_area , puede calcular con precisión el espacio dentro del cual se muestra el contenido y, a partir de ahí, determinar sobre la marcha cuál es el atributo sizes de una imagen mostrada se basa en cómo se muestra, incluido el nuevo data-wp-percent-width presentado por @azaozz.

Aplicación práctica

El desarrollador del tema define dos valores:

• $content_width declarando el ancho máximo de _content_ (como en el ancho del contenido si no se aplica alignwide o alignfull ) para cualquier condición de visualización.
• $max_display_area declarando el ancho máximo disponible para cualquier condición de visualización.

Ambos valores serán variables dependiendo de las condiciones, por lo que ninguno puede ser global como lo es $content_width hoy (a menos que no entienda cómo funciona actualmente $content_width ).

Para las imágenes que se muestran sin alignwide o alignfull , la variable $content_width (y el atributo de datos de ancho personalizado si está disponible) es suficiente para determinar el atributo sizes : el tamaño mostrado nunca será más ancho que $content_width o algún porcentaje de $content-width definido por el atributo de datos. Esto será significativamente más sencillo de configurar para los desarrolladores de temas que la metodología actual por cierto.

Para imágenes mostradas en un contexto alignwide o alignfull , necesitamos usar el $max_display_area . _Podría_ tener sentido definir esta variable como una matriz de algún tipo que empareja los anchos de las ventanas gráficas y las áreas de visualización disponibles. Esta matriz puede, en combinación con el atributo de datos, convertirse en atributos sizes generados sobre la marcha.

Entonces, para los ejemplos anteriores, un tema declararía algo como:

// In this theme there is a fixed maximum content width of 720px.
$content_width = 720px;

if ( is_active_sidebar( 'sidebar-1' ) {
  $max_display_area = [
    'min-width: 48em' => 'calc( 100vw - 30em), // sidebar is 30em wide.
    'fallback' => '100vw',
  ];
} else {
  $max_display_area = [
    'fallback' => '100vw',
  ];
}

Suponiendo que para d, eyf, el punto de interrupción donde aparece la barra lateral está en 48em y para g, h e i, el atributo data-wp-percent-width es 50%, los atributos sizes resultantes para ejemplos en la parte superior de este comentario sería el siguiente:

/**
 * a: Image width is equal to $content_width area.
 */
sizes="(min-width: $content_width) $content_width, fallback"
sizes="(min-width: 720px) 720px, 100vw"

/**
 * b: Image width is 50% of the available space between $content_width and $max_display_area.
 */
sizes="(min-width: $content_width) calc(($max_display_area - $content_width) / 2), fallback"
sizes="(min-width: 720px) calc((100vw - 720px) / 2), 100vw"

/**
 * c: Image width is equal to fallback.
 */
sizes="fallback"
sizes="100vw"

/**
 * d: Image widths is equal to $content_width area.
 */
sizes="(min-width: $content_width) $content_width, fallback"
sizes="(min-width: 720px) 720px, 100vw"

/**
 *e: Image width is $content_width plus 50% of the available space between $content_width and $max_display_area.
 */
sizes="(min-width: $content_width) calc(($max_display_area - $content_width) / 2), fallback"
sizes="(min-width: 720px) calc((100vw - 30em) - 720px) / 2, 100vw"

/**
 * f: Image width is equal to $max_display_area.
 */
sizes="$max_display_area, fallback"
sizes="(min-width: 48em) calc(100vw - 30em), 100vw"

/**
 * g: Image width is 50% of $content_width. 
 */
sizes="(min-width: $content_width) calc($max_display_area * (data-wp-percent-width / 100)), calc(fallback * (data-image-width / 100))"
sizes="(min-width: 720px) calc(720px * .5), calc(100vw * .5)"

/**
 * h: Image width is 50% of $content_width plus 50% of the available space between $content_width and $max_display_area.
 */ 
sizes="(min-width: $content_width) calc((($max_display_area - $content_width) / 2) * (data-wp-percent-width / 100)), calc( fallback * (data-image-width / 100))"
sizes="(min-width: 720px) calc(((100vw - 720px) / 2) * .5), calc(100vw * .5)"

/**
 * i: Image width is equal to 50% of fallback.
 */
sizes="calc(fallback * (data-wp-percent-width / 100))"
sizes="calc(100vw * .5)"

Gracias @ mor10 , muy bien dicho :)

Sí, para procesar y mostrar imágenes correctamente en la interfaz, necesitamos un par de bits de datos: algo de contexto del editor sobre cómo se usó exactamente la imagen y algunos datos del tema sobre cómo se mostrará la imagen.

Tengo un par de pequeñas sugerencias / aclaraciones.

$content_width - el ancho máximo del contenido cuando no se muestra como alignwide o alignfull.
$max_display_area - el espacio máximo disponible disponible para ser llenado si el contenido está configurado en alignfull.

Estoy (todavía) pensando que deberíamos dejar que el tema (pueda) especificar los tres anchos: contenido / columna principal, ancho y completo. De esa manera no forzaremos nada sobre los temas. Algunos pueden querer imágenes alignwide un poco más anchas o más estrechas. Usar la mitad de la diferencia entre content_width y full para wide puede ser una alternativa, en caso de que el tema esté desactualizado, ¿quizás?

Entonces estos deberían ser algo como:

• $content_width
• $alignwide_width
• alignfull_width

(Técnicamente, también pueden estar en una matriz asociativa, por lo que no "ensuciamos" demasiado el espacio global. Tener esa matriz también indicará que el tema es compatible con esto).

Otra distinción importante es que esperamos que estos nuevos anchos sean "contextuales". Es decir, deben ser configurados por la plantilla actual antes de que comience a generar el HTML (y quizás restablecerlos al final). Esto es fundamental para generar atributos sizes más precisos para todas las imágenes.

Gutenberg presenta no solo los anchos alignwide y alignfull , sino también la capacidad de hacer varios elementos wide o full .

No creas que debemos preocuparnos por esas imágenes. Si un bloque se establece en full , no tendría sentido tener una imagen alignfull en él. Será exactamente igual que la imagen "normal". Lo mismo para los bloques wide .

Tener los tres anchos especificados tiene sentido, y la matriz asociativa lo haría más limpio. La única pregunta es cómo modificar eso con condiciones ... ¿Supongo que el desarrollador del tema simplemente modificaría la matriz?

No creas que debemos preocuparnos por esas imágenes. Si un bloque se establece en full , no tendría sentido tener una imagen alignfull en él. Será exactamente igual que la imagen "normal". Lo mismo para los bloques wide .

Si miras los ejemplos en mi comentario, verás que tenemos que dar cuenta de estos. Si alguien tiene una pantalla muy grande y un bloque está configurado en alignfull con una imagen del 50% adentro, esa imagen podría ser sustancialmente más grande que el ancho del contenido. sizes atributos alignwide o alignfull tendrá anchos diferentes a los de otro modo.

Hola @ mor10 , en tu ejemplo, ¿no deberían ser los tamaños para 'b':

tamaños = "(min-width: $ content_width) calc ($ content_width + ($ max_display_area - $ content_width) / 2), respaldo"

?

@alialaa Las matemáticas bien podrían ser difíciles. Se proporciona solo como un ejemplo prototípico.

@azaozz ¿Dónde estamos con esto? Acabo de probar Gutenberg 3.3 con el tema de inicio oficial de Gutenberg y, por lo que puedo decir, los bloques actuales están usando el tamaño de imagen completo para todo. Esto provoca un impacto significativo en el rendimiento cuando se activa el complemento.

@ mor10 Estoy tratando de implementar algo que sea muy similar al código proporcionado por usted (el filtro wp_calculate_image_sizes ), excepto que estoy tratando de lograr esto para un tema más grande que tiene muchas más variaciones de diseño. El mayor problema hasta ahora es implementar un generador robusto de atributo sizes para cada lugar en el que pueda aparecer una imagen en el tema. Los mayores problemas son:

• diseño fluido frente a ancho fijo
• Sistema de cuadrícula (en porcentajes del contenedor)
• Brecha de cuadrícula
• Presencia / ausencia de barra lateral
• Puntos de interrupción de consultas de medios múltiples

Lo que logré implementar ya es algo de lógica PHP que acepta un conjunto de parámetros y genera una variedad de tamaños, con descriptores de ancho y consultas de medios. Mi objetivo es cubrir los diseños de bootstrap más comunes, son muy utilizados

Para el contexto, aquí están los puntos de interrupción (con consultas de medios ligeramente modificadas) que se utilizan para generar estos números.

Los parámetros válidos para la cosa son:

1. bootstrap_class : puede ser muy largo, acepta lo que acepta bootstrap, esto en realidad se analiza y se usa para generar múltiples consultas de medios
2. gutters : verdadero | falso. Ponga las canaletas 30px en el cálculo o no. Esta cantidad es configurable
3. fluid : verdadero | falso. Los diseños no fluidos son los más difíciles, tienen max-width en píxeles

Aquí hay algunos casos de prueba que realmente pasan, en formato JSON (cada entrada es un caso de prueba, el primer objeto es la entrada a mi lógica y el segundo es la salida):

[
    [

        {"bootstrap_class": "col-md-12", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(100vw - 30px)"}]
    ],

    [
        {"bootstrap_class": "col-sm-12", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(100vw - 30px)"}]
    ],

    [
        {"bootstrap_class": "col-xs-6", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(50vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-8", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(66.6667vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-5", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(41.6667vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-9", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(75vw - 30px)"}]
    ],
    [
        {
            "bootstrap_class": "col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5",
            "gutters": true,
            "fluid": true
        },
        [
            {"media_query": "1300px", "image_size": "calc(41.6667vw - 30px)"},
            {"media_query": "1000px", "image_size": "calc(91.6667vw - 30px)"},
            {"media_query": "690px", "image_size": "calc(58.3333vw - 30px)"},
            {"media_query": "480px", "image_size": "calc(25vw - 30px)"},
            {"media_query": false, "image_size": "calc(83.3333vw - 30px)"}
        ]
    ]
]

Después de obtener el resultado, se puede ensamblar fácilmente en un atributo sizes adecuado listo para insertarse en HTML.

Por ejemplo, esto es lo que debería ser la salida para una imagen col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5 muy complicada:

[
    {
        "bootstrap_class": "col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5",
        "gutters": true,
        "fluid": true
    },

    [
        {"media_query": "1300px", "image_size": "calc(41.6667vw - 30px)"},
        {"media_query": "1000px", "image_size": "calc(91.6667vw - 30px)"},
        {"media_query": "690px", "image_size": "calc(58.3333vw - 30px)"},
        {"media_query": "480px", "image_size": "calc(25vw - 30px)"},
        {"media_query": false, "image_size": "calc(83.3333vw - 30px)"}
    ]
],

Que en el HTML ensamblado final se vería así:

<div class="container-fluid">
  <div class="row">
    <div class="col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5">

      <img
        srcset="..."
        sizes="
          (min-width: 1300px) calc(41.6667vw - 30px),
          (min-width: 1000px) calc(91.6667vw - 30px),
          (min-width: 690px) calc(58.3333vw - 30px),
          (min-width: 480px) calc(25vw - 30px),
          calc(83.3333vw - 30px),
        "
      >

    </div>
  </div>
</div>

Ahora los casos de prueba para los diseños no fluidos son mucho más complicados y más difíciles de seguir.

Además, a veces el bootstrap_class no es suficiente y necesitamos poder expresar el ancho de la imagen en porcentajes sin procesar.

Si está interesado, puedo saltar a una charla más detallada en otro lugar sobre esto, estoy realmente interesado en avanzar correctamente, todavía hay muchos problemas que enfrento

8593 ha agregado los atributos srcset y sizes a imágenes individuales de la galería, pero el atributo sizes aún actúa como si cada imagen ocupara todo el ancho del contenido de la vista, que rara vez es el caso.

Relacionado: # 1450

¿Dónde estamos con esto?

Mirándolo en el cajero automático, estuvo un rato afk. Hope tendrá una rama actualizada y "funcional" en unos días.

Se actualizó la rama del bloque de imágenes: https://github.com/WordPress/gutenberg/tree/update/image-block. Bastantes cambios desde la última actualización, todas las funciones nuevas / necesarias están ahí, ¡pruébelo!

@joemcgill @getsource @ mor10 pensando en hacer un relaciones públicas mañana, se agradecen las reseñas de la sucursal :)

Se actualizó la rama nuevamente. Casi listo, solo necesita más pruebas :)

Agregando esto al hito de WP 5.0 porque es bastante importante que no introduzcamos regresiones de rendimiento con imágenes insertadas en el contenido de la publicación y no quiero olvidar revisar las actualizaciones aquí.

Debemos recordar que estos problemas de rendimiento no son solo con imágenes que se integran vía etiqueta HTML (bloque de imagen y galería) sino también con el bloque de imagen de portada, donde las imágenes se insertan vía css como imagen de fondo.

La solución a través de srcset no funcionará para estos bloques.

Twenty Nineteen ofrece ahora un campo de pruebas concreto para este problema. Consulte https://github.com/WordPress/twentynineteen/issues/50#issuecomment -434120505 para obtener más detalles.

@azaozz Al ejecutar la rama referenciada usando Twenty Nineteen, mi imagen insertada obtiene el siguiente marcado:

<img 
  src="http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-1024x768.jpg" 
  alt="Big Sur" 
  width="640" 
  height="480" 
  srcset="http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-1024x768.jpg 1024w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-300x225.jpg 300w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-768x576.jpg 768w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049.jpg 1600w" 
  sizes="(max-width: 640px) 100vw, 640px">

Parece que el ancho máximo está configurado para coincidir con el conjunto global content_width en el tema .

¿Qué nuevo marcado (si corresponde) debo agregar al tema para probar la nueva funcionalidad?

@ mor10 correcto, está usando $content_width PHP global. Esa es una alternativa del $block_width global recién introducido que debe contener tres valores: predeterminado, ancho y completo, consulte: https://github.com/WordPress/gutenberg/blob/update/image-block/packages /block-library/src/image/index.php#L26 (tenga en cuenta que estos anchos funcionan más como el ancho máximo, al igual que el (antiguo) $content_width ).

Para probar, tal vez siga el ejemplo del phpdoc en el bloque de imágenes:

/**
 * Get the expected block width from the global $block_width array.
 *
 * The global $block_width array is expectd to be set by the theme for each block container.
 * It should contain three values: default, wide and full, in pixels.
 * - The `default` value should be the expected block width (similarly to $content_width).
 * - The `wide` value is optional and is used when the block alignment is set to `wide`.
 * - Similarly the `full` value is optional and used then the alignment is set to `full`.
 * If `wide` and `full` are not set, the `default` value is used instead.
 *
 * Example:
 *     $GLOBALS['block_width'] = array(
 *         'default' => 640,
 *         'wide'    => 800,
 *         'full'    => 1024,
 *     );
 *
 * In addition the $block_width array should be set contextually for each block container.
 * For example: in the main content column the `default` width will be something like 640(px),
 * but for a sidebar it would be something like 250.

Si está buscando establecer un atributo sizes más preciso, la mejor manera sería usar el filtro https://developer.wordpress.org/reference/hooks/wp_calculate_image_sizes/ . Se pensó en agregar algo "más fácil" para los temas, pero establecer el sizes adecuado es muy contextual y depende en gran medida del estilo (columnas, puntos de interrupción, márgenes, relleno, etc.). No hay una "manera fácil", es mejor dejar el control total sobre el tema (es decir, utilizar el filtro).

¿Por qué este valor está en píxeles? Muchos (probablemente la mayoría) de los temas no usarán valores de píxeles para los anchos. Twenty Nineteen es solo un ejemplo. Debería ser posible definir los anchos utilizando cualquier valor de ancho. Por ejemplo, las imágenes de ancho completo serán en la mayoría de los casos 100vw .

Además, ¿por qué se establece como una opción global, frente a una opción add_theme_support o mediante un filtro?

Sería muy útil ver esta rama abierta como PR, incluso si está marcada como WIP o con la etiqueta "En curso". Hace que sea más fácil revisar el código, discutirlo, etc. ☺️

¿Por qué este valor está en píxeles

Debido a que el (archivo) tamaño de la imagen en píxeles y es porque tenemos que establecer el <img> de etiqueta width y height atributos (mejores prácticas). Un valor de 100vw se usa por defecto en el atributo sizes , pero el tema también debe pasar el ancho máximo aceptable incluso para un bloque de imagen "alinear completo".

Probablemente haya temas que decidan que los visitantes del sitio deben descargar imágenes de 3 a 4 MB siempre que el sitio se vea bien en una pantalla de 2560 píxeles. Otros serán más pragmáticos y lo limitarán a un valor algo más "sensato".

Por cierto, para que esto funcione bien, necesitamos otro tamaño más grande generado por defecto para todas las imágenes cargadas.

¿Por qué se establece como una opción global, frente a una opción add_theme_support o mediante un filtro?

La idea es que este global sea "contextual", es decir, que tenga diferentes valores para diferentes "plantillas". Hay varias formas de hacer esto, pero una acción PHP global o disparando una acción WP parece más fácil de usar.

@azaozz Consulte https://github.com/WordPress/twentynineteen/pull/411. Hablamos sobre una forma de detectar si la imagen actual se mostraba como normal, alignwide o alignfull dentro de wp_calculate_image_sizes un tiempo. Creo que una idea fue agregar un atributo de datos dentro del elemento <img> . Sin esta información contextual, no veo cómo puedo proporcionar los atributos sizes correctos para las tres opciones de diseño. Ideas bienvenidas.

Sin esta información contextual ...

Correcto. Esta información está en la matriz $block_attributes . Se está pasando al (nuevo) filtro render_block_core_image_tag_attributes (puede necesitar un nombre mejor ...). Una vez que se haya fusionado con Gutenberg y el núcleo, creo que podremos pasar los atributos del bloque a los filtros wp_calculate_image_srcset y wp_calculate_image_sizes .

¿Dónde estás en eso? ¿Puedo probarlo actualmente?

Todavía no, ya que modifica los archivos principales. Puede agregarlo como un "truco" :)

Debe pasar $block_attributes al llamar a wp_calculate_image_srcset() y wp_calculate_image_sizes() , consulte https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block- library / src / image / index.php # L210 y https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block-library/src/image/index.php#L213. Luego pase lo mismo a los filtros en estas funciones en /wp-includes/media.php.

¡Gracias por probar!

¿Hay entradas principales en las que pueda apilar para encaminar esto? GB y Twenty Nineteen no pueden lanzar a menos que esto se resuelva en mi opinión.

@azaozz Tuve la oportunidad de hacer algunas pruebas de la rama ayer (perdón por el retraso). Quiero hacer mucho más, pero quería dejar los siguientes comentarios:

Primero, reiteraré de nuevo que estoy totalmente en contra de la idea de guardar los atributos srcset y sizes en el marcado de la imagen en la base de datos. El marcado en la base de datos debe ser inmutable y lo más preparado posible para el futuro. Desde una perspectiva de contenido puro, la etiqueta básica img con un solo src debe permanecer, y srcset y sizes es un detalle de implementación que se maneja mejor en la parte delantera. srcset atributos

Gutenberg ya formatea el marcado de imágenes de una manera que admita nuestra solución de imagen receptiva actual a través del filtro frontal, por lo que creo que el enfoque debería ser mejorar los filtros disponibles para que los temas modifiquen el atributo sizes función de los atributos del bloque que contiene la imagen (por ejemplo, alineación, columnas de la galería, etc.).

Notas adicionales:

Noté que en el editor, Chrome ahora está descargando dos versiones de cada imagen (esto no sucede en la rama maestra). El segundo es debido al cambio del atributo src del componente de imagen en fetchImageSize() que se llama durante componentDidMount . Esto niega cualquier beneficio que provenga de agregar srcset y sizes al componente.

En las imágenes de ancho completo, el ancho máximo se limita a 1024px, lo que rompe la vista previa. Esto no sucede en el maestro.

Continuaré probando y agregando notas, pero también me hago eco de

@joemcgill gracias por probar! :)

Volveré a reiterar que estoy en contra de la idea de guardar los atributos srcset y los tamaños en el marcado de la imagen en la base de datos ... los atributos srcset pueden y deben cambiar siempre que se generen tamaños de imagen adicionales para archivos adjuntos (después de cambiar de tema o agregar una nueva imagen tamaños a un tema existente, etc.).

Esto es algo que vimos hace unos años al implementar srcset y sizes . En teoría, eso suena algo posible, sin embargo, en la práctica, esto ocurre tan raramente que debería dejarse que los complementos lo manejen. También rompe la generación de srcset y sizes cuando el contenido se exporta desde un sitio de WP y se importa en otro a medida que cambian las ID de los archivos adjuntos (pero las URL no cambian).

Sin embargo, en este caso, los atributos srcset y sizes son únicamente por el bien del editor. Siempre se regeneran en el front-end, consulte https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block-library/src/image/index.php#L244.

Todavía creo que deberíamos abrir un ticket principal para WP 5.1+ para considerar la reutilización del atributo srcset ya que corrige el contenido importado. El atributo sizes predeterminado es independiente del tema, pero piensa que siempre debe regenerarse y filtrarse en el front-end.

Gutenberg ya formatea el marcado de imágenes de una manera que es compatible con nuestra solución de imagen receptiva actual a través del filtro frontal.

No del todo :) Actualmente, Gutenberg "fuerza" las imágenes de tamaño completo tanto en el editor como en el front-end. Es cierto que se agrega srcset atributo <img> etiquetas sizes predeterminado allí. Está "borked" :)

Creo que el enfoque debería ser mejorar los filtros disponibles para que los temas modifiquen el atributo de tamaños ...

Totalmente de acuerdo. Esto agrega algunos filtros nuevos que ayudan allí, pero lo más importante es que debemos pasar el block_attributes al filtro wp_calculate_image_sizes (también a wp_calculate_image_srcset para que coincida).

Además, después de la última actualización, se pasan bastantes datos relacionados con el editor en estos atributos de bloque. Eso permite el escalado adecuado de imágenes en el front-end, restableciendo width y height (y asegurando que siempre estén presentes, práctica recomendada) y, en general, brinda muchas más opciones al tema. al renderizar el bloque de imagen.

Noté que en el editor, Chrome ahora está descargando dos versiones de cada imagen.

Esto solo ocurre con las imágenes recién cargadas. Como la imagen se agrega como "vista previa" mientras se carga, necesitamos cambiar src para que apunte al tamaño "grande" después de que haya una publicación adjunta. Además, dentro del editor, el beneficio de tener srcset es cargar y mostrar imágenes "retina". No hay beneficios de velocidad ya que el contenido del editor (HTML) se carga mucho después de que la página ha terminado de cargarse.

En las imágenes de ancho completo, el ancho máximo se limita a 1024px, lo que rompe la vista previa. Esto no sucede en el maestro.

Correcto. La alternativa aquí es descargar siempre imágenes de 2 a 4 MB o, a veces, más grandes. Eso es inaceptable, aunque solo sea en el editor. Para solucionar esta limitación, necesitamos generar otro tamaño de imagen por defecto, mayor que "grande". Esto se discutió muchas veces en Slack, y hay un ticket central que es bastante "antiguo". Definitivamente deberíamos pensar en hacerlo pronto.

Seguiré probando y agregando notas

¡Sí por favor! :)
Al pensar en hacer relaciones públicas esta noche, parece que se tienen en cuenta la mayoría de los casos extremos en el manejo de imágenes.

Sin embargo, en este caso, los atributos srcset y size son puramente para el editor.

Si ese es el caso, definitivamente no tiene sentido guardar esos atributos en el marcado guardado en la base de datos.

No del todo :) Actualmente, Gutenberg "fuerza" las imágenes de tamaño completo tanto en el editor como en el front-end. Es cierto que se agrega un atributo srcset a etiquetas, pero mire el atributo de tamaños predeterminados allí. Está "borked" :)

Ah, cierto, una distinción útil aquí es que el atributo de ancho de la imagen se está guardando incorrectamente, porque ya no estamos restringiendo el tamaño de la imagen a content_width .

Esto solo ocurre con las imágenes recién cargadas.

No creo que esto sea cierto. Puedo guardar una publicación, actualizar el editor y seguir viendo la doble descarga.

Correcto. La alternativa aquí es descargar siempre imágenes de 2 a 4 MB o, a veces, más grandes. Eso es inaceptable, aunque solo sea en el editor.

Lo siento, no creo que haya sido claro aquí. Lo que veo es que el ancho de la imagen está limitado en CSS por el estilo en línea en el envoltorio div en el editor. Aquí hay algunas capturas de pantalla para ayudar:

Imagen de tamaño completo en el editor que no ocupa todo el ancho: https://cloudup.com/cHob4kcjLrN

Marcado de lo anterior en el inspector - https://cloudup.com/cIVWetqpSoF

El alcance de este ticket es muy grande, pero hay algunos bits que son cruciales para WP 5.0. ¿Podemos desglosar los problemas específicos que serían regresiones? Como yo lo veo, esto incluye:

• [] Evite que las imágenes a tamaño completo se carguen en la parte frontal.
• [] Guarde elementos width a img más apropiados en el contenido de la publicación (práctica recomendada, pero también relevante para calcular un atributo sizes predeterminado para imágenes receptivas).

Mejoras de alta prioridad:

• [] Proporcione una forma de filtrar sizes en la interfaz en función de las alineaciones de la imagen (# 6131).
• [x] Evita que se carguen imágenes de tamaño completo en el editor.

Mejoras (es bueno tenerlas):

• [] Mejorar el rendimiento de carga de imágenes en el editor (por ejemplo, a través de imágenes receptivas)
• [] Mejore el manejo de anchos de imagen redimensionados manualmente entre el editor y la interfaz.
• [] Agregue un tamaño de imagen generado adicional para 2x grande (necesitamos evaluar el impacto en la generación de imágenes aquí. Esto está relacionado con https://core.trac.wordpress.org/ticket/37840 que está bloqueado por https: // core.trac.wordpress.org/ticket/40439)

¿Algo que me estoy perdiendo?

Proporcionó un ejemplo en el repositorio de Twenty Nineteen de por qué esto es un bloqueador para el tema y para Gutenberg en general. El impacto de rendimiento en el que ha incurrido Gutenberg actualmente es significativo: https://github.com/WordPress/twentynineteen/issues/50#issuecomment -436829300

Según mis pruebas, las imágenes receptivas aún no se resuelven en 5.0 RC1. wp_calculate_image_sizes no tiene un atributo de propiedades de bloque y render_block_core_image_tag_attributes de # 11973 no se ha fusionado.

No quiero poner un punto demasiado fino, pero esto significa que todas las imágenes no redimensionadas manualmente dentro del editor y alineadas alignnone , alignwide y alignfull en RC1 están rotas porque su sizes atributos

Para probar, active Twenty Nineteen, cargue una imagen grande (1200px o más ancha) en una publicación, alinéela none , alignwide o alignfull , y verifique el resultado sizes atributo. Encontrará que independientemente del ancho mostrado o del ancho intrínseco de la imagen, el valor es:

sizes="(max-width: 1024px) 100vw, 1024px"

Esto significa que para cualquier situación en la que la imagen se muestre con un ancho superior a 1024 px (por lo que prácticamente todos los casos en los que se usa una pantalla de computadora portátil / de escritorio), el navegador cargará una imagen de origen de 1024 px de ancho y la estirará causando desenfoque.

¿Cuál es el plan para fusionar esto? ¿Que puedo hacer para ayudar?

Relacionado:

• Ticket principal 45406: agregue tamaños de imagen predeterminados adicionales para srcset para acomodar ventanas gráficas más amplias
• Ticket principal 45407: agregue atributos de bloque a wp_calculate_image_sizes para permitir el manejo adecuado del atributo sizes

Se ha solicitado una prueba para mostrar el comportamiento actual y corregido, así que los he creado ambos:

Las dos publicaciones vinculadas a continuación muestran la salida actual del núcleo y una versión corregida respectivamente. Tenga en cuenta las instrucciones detalladas sobre cómo probar esto. Las imágenes receptivas son una característica central del navegador y los navegadores trabajan muy duro para hacer que la funcionalidad sea invisible. Forzar la visibilidad requiere ser bastante duro en sus pruebas.

Preste especial atención a lo siguiente: las imágenes receptivas se ven afectadas por la densidad de visualización. Esto se puede hacer usando la vista previa móvil en las herramientas de desarrollo de su navegador.

• Demostración 1: Tamaños generados automáticamente proporcionados por el núcleo https://gutenberg.mor10.com/image-test-current/
• Demostración 2: Mismo contenido con atributos de tamaños corregidos https://gutenberg.mor10.com/responsive-images-demo-corrected-code/

Gracias a todos por pensar y preocuparse tanto en esto. Veo dos preocupaciones enredadas que deberían separarse para avanzar.

• Evite roturas evidentes en 5.0 (como cargar imágenes enormes).
• Reconsidere cómo WordPress maneja el espacio multimedia en un mundo de experiencias de visualización flexibles.

Para el primero, debe haber una identificación clara de cualquier tema pendiente y un acuerdo sobre lo que significa "roto". Especialmente en torno a características recién introducidas que no tienen ninguna expectativa de antes (imágenes amplias, bloque de portada, etc.). Tengo entendido que el principal obstáculo de cargar una fuente demasiado grande se resuelve eligiendo "grande" de forma predeterminada.

En cuanto al segundo, creo firmemente que debemos dedicar un ciclo completo a los medios de comunicación, ya que llevamos problemas de una época en que las cosas eran más simples. Ahora los medios existen en un mundo donde los recursos rudimentarios que tenemos en el núcleo no son suficientes: una gran cantidad de dispositivos que acceden a la web con diferentes expectativas, densidades de píxeles, tamaños de pantalla, etc. Esto no se puede resolver por completo solo con WordPress y necesitaría la participación de otros grupos, como servicios de alojamiento y administración de ancho de banda, navegadores, grupos web estándar, etc. Tampoco es razonable esperar arreglarlo todo al mismo tiempo que estamos haciendo 5.0.

Cuando observamos cómo WordPress administra los activos de forma predeterminada, es evidente que las variaciones que crea no son suficientes para impulsar la amplia gama de dispositivos, condiciones de visualización y expectativas de rendimiento. En la escala superior, estamos tratando con 1024px o tamaño completo en una instalación regular. Esto no es suficiente. Hay una gran brecha entre "fuente" y "grande" que hace que casi cualquier intento de imágenes receptivas o soporte de alta resolución sea una batalla perdida. Necesitamos tener una mejor segmentación de los activos de medios sin sobrecargar los servidores para que esto se pueda escalar y cumplir con las expectativas de calidad.

Esto solo se complica aún más por el hecho de que estas opciones son configurables por el usuario, los temas y los complementos, por lo que las suposiciones sobre lo que "grande" se adaptaría no pueden ir demasiado lejos.

Ser capaz de ofrecer la imagen adecuada en el contexto adecuado es fundamental.

Idealmente, el usuario no tiene que intervenir en absoluto para que sus creaciones se vean bien y tengan un buen rendimiento .

Sin embargo, nuestra propuesta actual no parece lo suficientemente flexible a nivel técnico o de experiencia del usuario para cumplir con esto, al tiempo que agrega una considerable sobrecarga y complejidad:

• El escalado a otros bloques que no sean wp:image sigue sin resolverse.
• Implementación de servidor poco ortodoxa (probablemente necesite algo como # 10108) que agrega complejidad.
• Sobrecarga en la reproducción de marcado de imagen _ad hoc_ (servidor vs cliente), chocando con posibles extensiones y fidelidad del lado del cliente.
• Falta de claridad en la UX esperada en torno a tamaños porcentuales.
• Demasiada responsabilidad por el lado del tema.
• Más importante aún, la falta de claridad en la superposición con las condiciones y requisitos de la

Al presentar este código y las expectativas (para temas, etc.) crearemos una red complicada de requisitos y perderemos la oportunidad de adoptar un enfoque más holístico del problema. Creo que esto se haría mejor con el tiempo y en conjunto con la fase 2, ya que las expectativas de dónde vive un bloque y las interacciones del usuario aumentarán considerablemente.

Los temas ya no podrían simplemente decir qué anchos les interesan para el contenido, ya que los bloques se colocarán en cualquier lugar de una página. Los bloques también se pueden mover entre áreas de bloques, por lo que los anchos siempre deben ser contextuales y controlados por la raíz InnerBlocks inmediata. Esto incluye elementos como columnas dentro del área de contenido principal, pero también áreas fuera del contenido en sí. Cualquier API que desarrollemos aquí debe considerar estas expectativas, ya que de lo contrario crearemos una red de código heredado que será difícil de desenredar de manera efectiva.

Lo que veo que se convertirá en una API más robusta y preparada para el futuro es adjuntar responsabilidades de ancho de medios a cada contenedor de bloque, de los cuales post_content es solo uno. Podría verse así:

innerBlocks( 'post-content', sizes: {
    default: 600,
    wide: 1000,
    full: 100vw,
}

Esto especifica un ancho máximo predeterminado y la _disponibilidad_ de una alineación amplia para los bloques debajo de esa raíz. Tan pronto como crea otra raíz (como columnas), el contexto cambia.

Lo que nos permitiría también hacer:

innerBlocks( 'sidebar', sizes: {
    default: 300,
    wide: false,
    full: false
} )

y así.

Esto debe combinarse con el manejo intrínseco de imágenes receptivas y, lo que es más importante, con una mejor segmentación para la creación de activos o algún tipo de manejo dinámico, si es que es viable.

Gracias @mtias ,

Estoy totalmente de acuerdo tanto con la necesidad de evitar roturas en 5.0 como con la necesidad de hacer un enfoque de más alto nivel en los medios en WordPress para abordar estos problemas.

Con respecto al primero, no estoy seguro de haber abordado por completo los problemas que describí como necesarios en https://github.com/WordPress/gutenberg/issues/6177#issuecomment -435091640, específicamente:

Guarde elementos width a img más apropiados en el contenido de la publicación (práctica recomendada, pero también relevante para calcular un atributo sizes predeterminado para imágenes receptivas).

Si podemos confirmar que se ha abordado, me sentiría cómodo con todo lo demás que se maneja en las versiones 5.0.xy posteriores.

Respecto a lo último, repensar el manejo de los medios ha sido una de mis esperanzas durante algún tiempo, y es una de las razones por las que tuvimos discusiones iniciales sobre algunos de estos problemas de alto nivel durante las reuniones cumbre de la comunidad durante la WCEU 2017 cuando Gutenberg recién comenzaba. Espero reanudar esas conversaciones una vez que finalice el ciclo de lanzamiento de WP 5.0.

Totalmente de acuerdo con @joemcgill arriba ^

Me encantaría trabajar juntos en el tipo de esfuerzo de alto nivel del que estás hablando, y es algo de lo que hemos estado hablando y en lo que queremos trabajar durante bastante tiempo.

Cuente conmigo. Creo que nosotros (WordPress) estamos en condiciones no solo de resolver esto por nosotros mismos, sino de crear nuevos modelos para el manejo de medios que ayuden a la web en su conjunto. Podríamos obtener la participación de navegadores, hosts, CDN y organismos de estándares y usar WP como canal de distribución para nuevas mejores prácticas.

Lo que hemos encontrado aquí es el límite absoluto de la especificación de imágenes receptivas RICG. Ahora tenemos un caso de prueba de lo que funciona y lo que no funciona. Esto nos coloca en una posición única para hacer avanzar el trabajo.

@joemcgill ¿Puedes aclarar esto?

Guarde un ancho más apropiado para los elementos img en el contenido de la publicación (práctica recomendada, pero también relevante para calcular un atributo de tamaños predeterminado para imágenes receptivas).

¿Qué hace que un ancho sea "más apropiado"? Solo trato de comprender los parámetros de ese elemento en particular, ya que no estoy seguro de hacerlo ahora :)

Para la pregunta intrínseca de tamaño / jank, esto ahora es relevante:

https://www.chromestatus.com/feature/4704436815396864
https://codepen.io/eeeps/pen/qLKwEZ

Hilo decepcionante para leer; ya que no puedo ver ningún progreso que se haya hecho. La solución en este momento es simplemente cargar las imágenes en el tamaño exacto necesario y duplicar el tamaño o ignorar la retina. ¿Hay algún progreso que pueda llegar a WordPress? Por el momento, no quiero darles a los clientes la posibilidad de tener una página de 30 MB porque no pueden cambiar el tamaño de manera eficiente y no puedo forzar que las imágenes se correlacionen con el diseño y el rendimiento.

@yratof sí, estoy de acuerdo en que el progreso aquí ha sido más lento de lo previsto. Sin embargo, después de muchas discusiones aquí (en el repositorio de Gutenberg) y en Slack, hemos decidido que no tiene sentido agregar correcciones marginales que mejoran "algo" una cosa u otra. El alcance de esto se redujo muchas veces.

La mejor manera de avanzar es analizar detenidamente cómo WP maneja los medios y, en particular, las imágenes, y solucionar y mejorar todos los problemas subyacentes. Por favor, vea el comentario de Matías arriba . Si usted (o cualquier otra persona) quiere involucrarse en ese trabajo, espero que podamos lanzarlo "formalmente" tan pronto como WP 5.1 esté listo / lanzado. Hasta entonces, piense en lo que le gustaría arreglar / mejorar y cómo deberían "funcionar" las imágenes en WP, preferiblemente con algunos ejemplos de código :)

Solo para decir cuánto me encantaría esto .... Actualmente mi blog tiene 350mb en la página de inicio ..... Es una locura

¿Es este el hilo apropiado para preguntar si el Bloque de Galería de Gutenberg puede tener un selector de tamaño de imagen agregado para que las imágenes se puedan reducir a tamaño mediano en lugar de reducirlo a tamaño completo?

Hoy me encontré haciendo esto:

// onDomReady
document.querySelectorAll('.wp-block-gallery.columns-2 figure img')
  .forEach(x => {
    x.setAttribute('sizes', '(max-width: 781px) 50vw, 344px');
  });

... cuál se podría parametrizar con $content_width y .columns-N . Y lanza un complemento. Espero que no llegue a eso :) ... y recordaré desactivar esto una vez que llegue al núcleo.

EDITAR: el código JavaScript funcionó una vez, accidentalmente, supongo. Tendría que inyectar el atributo sizes a nivel de PHP, en algún lugar, idealmente entre el marcado de Gutenberg y el filtro the_content . Ugh.

EDIT2: Así que implementé la solución PHP con DOMDocument & Xpath . Parece funcionar y lo usaré en producción. Obviamente, muy propenso a errores, no lo recomendaría.

Solo para decir cuánto me encantaría esto .... Actualmente mi blog tiene 350mb en la página de inicio ..... Es una locura

Como medida temporal, escalaría manualmente sus imágenes a un tamaño mucho más pequeño, las comprimiría y luego limitaría su blog a 4 publicaciones o algo así. Porque vas a matar los datos de alguien cuando vean tu blog lol

FYI intrinsicsize ahora es una cosa: https://github.com/WICG/intrinsicsize-attribute

/ update / image-block es un "trabajo en progreso" :) Por favor, pruebe.

• Inserte siempre el tamaño de la imagen large , o full si no existe grande.

¿Qué tal: inserta siempre todas las opciones de tamaños de imagen de get_intermediate_image_sizes (); ?
¿Cuál es el valor añadido de impedir el acceso a determinados tamaños de imágenes?

agregue un filtro para poder habilitar algunos tamaños de imagen, o habilite escribir su tamaño de imagen personalizado para usar.
por ahora, mis opciones son "miniatura, medio, tamaño completo", que es una elección RIDÍCULA para una función de producción enviada al 30% de los sitios web de Internet (wordpress).

todos los usuarios están cargando tamaños de imagen de 5 MB en lugar de 500ko.

Ni siquiera estoy seguro de si es posible filtrar el bloque para agregar lazysizes.

Hola.
No soy un experto en Wordpress pero pensé:
"Al menos una función de galería simple está a mano".

Bien...
¿Existe un punto fijo en el tiempo cuando el tamaño desplegable (para mostrar imágenes 'pequeñas' = 'miniaturas' en la página y enlazar a la imagen más grande ('' grande ')?
Quiero decir, estoy hablando de 5.2.2 y es junio de 2019.
¿Cuáles son las alternativas además de los complementos pagados?

Estoy realmente harto de inhabilitar a Gutenberg. El cuarto sitio que pruebo, el primero que se mantuvo CON Gutenberg (hasta ahora, pero no por mucho tiempo y ya no está y las columnas serán ACF). Esto es, no sé, soy relativamente nuevo en WP (al menos el tipo más profundo) y esto no hace feliz a nadie.

Ok, para mí https://github.com/klihelp/Kli-Gutenberg-Gallery funciona. Gracias por eso !!

No debería ser necesario agregar un complemento para manejar imágenes después de gutenberg @ararename :(

Bueno, entonces, ¿por qué está este hilo aquí?
Y se trata de un escenario para la galería, no de imágenes.

No debería ser necesario agregar un complemento para manejar imágenes después de gutenberg @ararename :(

Sí, pero el bloque de imágenes, el bloque de galería y el bloque de texto multimedia son malos en cuanto a cómo manejan el tamaño de la imagen. No entiendo cómo llegaron a la producción. ¿Cómo puede fallar al tener en cuenta los tamaños de imagen en 2017-2019 al reconstruir completamente desde cero las características más utilizadas del CMS más utilizado en el mundo? Cuando el editor clásico estaba casi listo para manejar cualquier tamaño de imagen sin problemas.

Esto es espantoso. Estoy desgarrado por tener que elegir entre hacer mi propia imagen sensible / galería / bloque de texto multimedia sin poder beneficiarme de ningún bloque nativo de wordpress en futuras actualizaciones o seguir con las que fallan con la esperanza de que Gutenberg mejore mientras los clientes descargan imágenes 4k en su móvil o imágenes de 500px en su monitor 4k

Eso es lo que pensé cuando lo descubrí: ¿por qué algo en este estado entra en una versión 'productiva' distribuida por miles?
Como resultado: Gutenberg queda deshabilitado por miles y miles como última oportunidad para hacer las cosas a tiempo (bueno, no a tiempo).
Si no hubiera encontrado el complemento 'Kli-Gutenberg-Gallery-master' útil y funcionando, habría tenido que invertir días solo para algo que el núcleo debería ofrecer pero no lo hace.
Este es el estado alfa, no la producción.

¡Hola a todos! 👋

¿Se está avanzando en esto? ¿La conversación se ha alejado de este ticket?

Me gustaría seguir adelante e involucrarme si puedo para ayudar a que esto avance. 😄

Hola, Keith, es posible que pueda contactarte sobre esto la semana que viene. Lo crea o no, no puedo acceder al backend de la instalación de wordpress con el que tuve ese problema y no tengo tiempo para instalar una versión local completa de mis copias de seguridad.

Por lo que recuerdo haber usado los complementos 'simple-gallery' MÁS 'fancybox-for-wordpress' juntos Y configurando el ancho de imagen de las imágenes en cuestión (los pulgares, para los cuales creé un tamaño de imagen personalizado en functions.php) a 100 El% de ancho y el alto en automático (esto sobrescribe los atributos de ancho / alto html en línea, si corresponde) satisfizo mis necesidades. Avísame si esto ya te ayudó. Sin embargo, estará fuera hasta al menos el martes.

¿cualquier progreso?

¿Se está trabajando en esto? ¿O rastreado en otro lugar?

@mtias @azaozz - ¿Es hora de comenzar a agregar selectores de tamaño de imagen a cada bloque que usa imágenes? Los tamaños de imagen no se han abordado totalmente con 5.0 o 5.1 y el bloque de imagen ya tiene un selector.

¿Quizás el Cover Block pueda obtener un selector a continuación (# 19223)?

Construimos un multisitio para la facultad de la Universidad de Tulane. Las imágenes de tamaño completo de los bloques de portada son nuestra mayor fuente de recursos.

¿Hay alguna actualización al respecto?
Quiero mostrar imágenes de la galería como miniatura. Bloque de galería predeterminado usando imágenes de tamaño completo y escalarlo usando CSS.

@ararename> Ok, para mí https://github.com/klihelp/Kli-Gutenberg-Gallery funciona. Gracias por eso !!

¿Puedes explicar cómo se usa? ¿Cómo funcionó para ti? ¿Cambió todas las galerías de publicaciones antiguas con otro código corto de complemento de galería? o el complemento lo hace automáticamente?

De hecho, instalé el complemento y no lo administré

@CompartirTexturas
Era una nueva instalación, no recuerdo si era importante mantener un orden al instalar los plugins, pero esto es lo que tengo instalado:

• FancyBox para WordPress, versión 3.2.2, de Colorlib
• Klip - Galería Gutenberg, versión 1.0.0, de Klipolis
• Galería más simple, versión 4.4

Y después de cargar imágenes en la galería, simplemente funcionó. En realidad, me había olvidado de los códigos cortos que usa Klip - Gutenberg Gallery y _no_ estoy usando _cualquier_.

Casi lo había olvidado después de que se cerró el tema, pero tenía este texto listo en ese momento:
No estoy en el tema como tal, pero dije que estaría publicando mi 'solución' para una galería de imágenes alimentada por un bloque de galería de Gutenberg (es decir, para el frontend, el backend tiene tamaño completo, pero eso no me preocupaba. Estoy seguro de que los editores tienen suficiente ancho de banda y el trabajo no se pagó de una manera que pudiera hacerme investigar más de lo necesario; de todos modos, supongo que llegará un momento en que Wordpress 5 funcione como se esperaba cuando salió 5.0).

Primero, si lo recuerdo bien, el problema de las 'imágenes como miniaturas en el elemento de la galería' desapareció después de una actualización de 5.1. * A 5.2. *.

Para una galería de trabajo tenía que tener instalada

• Galería Klip-Gutenberg
• Galería más simple
• FancyBox para WordPress

No iré a probar qué salió mal con cuál faltaba, de todos modos tenía ganas de adivinar, pero con cualquiera de estos faltantes algo se rompió.

Y en algún lugar del camino tuve que hacer
.fancyboxforwp img {ancho: 100%! importante; altura: auto! importante;}

Y tuve que poner las líneas (la parte donde se inicializa $ (". Fancybox"). Fancybox) 133 a 157 (aprox) en los comentarios para no tener algún error Js en el navegador.

_Sí, esto suena loco._
Pero revisé y todavía funciona (fe, no backend, como ya se dijo).
Espero que tengas éxito de alguna manera, salud
Franco

Un pensamiento más:
He establecido, en mi functions.php:
add_image_size ('miniatura', 152, 152, verdadero);
Así que había establecido explícitamente un tamaño para las miniaturas, tal vez esto también afecte el resultado general.
Y he estado usando el complemento Regenerate thumbnails varias veces, tal vez esto también afecte el resultado general. Simplemente adivinando y comprobando cosas conectadas ...

@ararename Gracias por una respuesta rápida. Mi sitio web ya tiene más de 500 publicaciones. Entonces no funcionará para mí :(
Esperaré a la próxima actualización de Wordpress Gutenberg.

@azaozz ¿Hay alguna actualización al respecto? Todo lo que quiero saber es cómo usar el enlace de miniaturas de imágenes en mi galería en lugar de imágenes completas.

¿Cuál es el estado de esto, en particular con respecto a los bloques de cobertura receptivos en Gutenberg? Esos se están convirtiendo en un dolor de cabeza de rendimiento para mí.

Imágenes de portada receptivas

Para proponer una ruta para las imágenes de portada receptivas, he estado tratando de comprender cómo funciona el conjunto de imágenes CSS https://developer.mozilla.org/en-US/docs/Web/CSS/image-set y haciendo algunas pruebas .

Las dos primeras secciones presentan image-set y src-set / size como mecanismos para imágenes receptivas. La última sección concluye y analiza el camino a seguir para las imágenes de portada receptivas.

Conjunto de imágenes

La propiedad de conjunto de imágenes parece muy diferente del atributo srcset. Image-set no admite la configuración de varios tamaños de imagen; admite la configuración de múltiples resoluciones de imagen (dpi / densidad). Parece que los diferentes tamaños de imagen generados automáticamente por WordPress tienen todos un 72DPI.
La propiedad de conjunto de imágenes hace que el navegador descargue la mejor imagen en función de algunas condiciones. Algunos ejemplos de condiciones son:

• Los píxeles de la pantalla por pulgada.
• Elija descargar una imagen de menor ppp cuando la conexión sea muy lenta.
• Descarga una imagen mejor al enviar algo a una impresora.

El tamaño de la ventana gráfica no parece afectar la imagen elegida por el conjunto de imágenes.

Src-set y tamaños

Srcset nos permite proporcionar una lista de diferentes tamaños de imagen (las resoluciones también son compatibles, aunque rara vez se usan), y el atributo de tamaños proporciona una consulta de medios como sintaxis para elegir el tamaño de la imagen que se muestra. Cuando el navegador conoce el ancho de la imagen, descarga el tamaño más cercano del srcset.

WordPress usa el siguiente atributo de tamaños "(ancho máximo: $ ancho px) 100vw, $ ancho px" donde $ ancho es el ancho del archivo de imagen, lo que significa que si la ventana gráfica es menor que $ ancho usa el tamaño de la ventana gráfica como el tamaño de la imagen si el la ventana gráfica es mayor que $ width use $ width como ancho de la imagen.

Los pares de atributos de tamaño y srcset de WordPress aseguran que en una pantalla cuyo ancho sea x cantidad de píxeles, no descarguemos imágenes cuyo ancho sea mayor que x.

El camino a seguir

El bloque de portada agrega imágenes como fondo CSS, por lo que al principio, la propiedad de conjunto de imágenes parece una buena opción para permitir que el navegador elija un archivo de imagen de un conjunto de archivos disponibles según el dispositivo.
Pero cuando decimos "Imagen de portada receptiva", creo que queremos decir que si la ventana del dispositivo es pequeña, deberíamos descargar una imagen pequeña, si la ventana del dispositivo es grande, deberíamos descargar una imagen con un tamaño mayor.

Image-set no parece permitir este comportamiento; permite descargar una imagen con un ppp más alto si la densidad de píxeles del dispositivo es alta (por ejemplo, pantalla retina) y una imagen con ppp bajos si la densidad de píxeles de la pantalla es pequeña.

Un teléfono móvil y una pantalla de computadora pueden tener la misma densidad de píxeles, por lo que parece que al usar el conjunto de imágenes, ambos dispositivos descargarán la misma imagen (siempre que la velocidad de la red y otras variables sean las mismas). No deseamos este comportamiento, creo que queremos descargar una imagen "más pequeña" en el teléfono móvil.

Otro desafío para el uso de conjuntos de imágenes es que parece que todos los archivos de imagen que generamos en WordPress tienen la misma cantidad de DPI.

Después de esta exploración, parece que el conjunto de imágenes no es adecuado para las imágenes de portada receptivas. El camino a seguir parece ser hacer que la imagen de portada use un elemento de imagen con los atributos normales de src-set y tamaños establecidos por WordPress y luego con CSS hacer que la imagen parezca un fondo (como lo hacemos con los videos). También hay algunos desafíos en ese camino, principalmente con el paralaje. No estoy seguro de si es posible con un elemento de imagen normal, pero parece que deberíamos intentarlo.

Si me perdí algo o si tiene información adicional que pueda ser útil, deje un comentario.

Grandes pensamientos, @jorgefilipecosta. Acabo de crear # 19909, cuyo objetivo es explorar cómo cualquier bloque puede recibir ediciones receptivas. ¿Puedes echar un vistazo para ver si tu idea de imágenes de portada receptivas podría aprovechar esa interfaz?

Si FLIF o JPEG-XR ya pudieran ser lo suficientemente compatibles ... 🐱
Es posible combinar el conjunto de imágenes con consultas de medios normales utilizando algunos bucles,
esto daría lugar a grandes cantidades de CSS. Claro, gzip probablemente lo aplastaría, pero también es una complejidad como todas las consultas de medios anuladas apiladas en las Herramientas de desarrollo.
Por ahora uso un <img con srcset y sizes y lo coloco absolutamente detrás del contenido.
Usando este enfoque, no tengo que manejar la parte hidpi / retina y solo proporciono algunas reglas para los tamaños. - Pero esto tendría que ajustarse por separado a la hoja de estilo.

Actualmente, la imagen de portada se coloca como imagen de fondo CSS en su tamaño original completo, sin cambio de tamaño, sin compresión ni optimizaciones del lado del servidor. Esto es muy malo para los tiempos de carga de UX, cuando se debe cargar una variante separada y reducida y usarla para el bloque de cobertura.

¿Ya hay una actualización para esto?
Acabo de agregar una galería a mi sitio y ahora el tamaño de mi página es la friolera de 25 MB porque la galería no carga miniaturas sino las imágenes completas.

Hola @azaozz y otros.
¿Podemos obtener una actualización de estado para este problema?

Parece que están sucediendo muchas cosas en este tema. Es importante dividirlo en problemas más pequeños que sean más fáciles de manejar.

Gracias.

¿Hay alguna forma de solucionar el problema de Galleri? Me refiero a vincular al archivo multimedia. Actualmente, algunas de mis imágenes tienen enlaces válidos a ancho completo, pero la mayoría de ellos enlazan a formato grande (1024x).

Hola @ CNK001

Vea si puede localizar un problema relacionado. Hice una búsqueda de problemas de etiquetas de medios: https://github.com/WordPress/gutenberg/labels/%5BFeature%5D%20Media
Si no puede encontrar uno, abra un nuevo problema.

Acabo de recibir una solicitud de soporte para un usuario que necesita un manejo de imágenes más avanzado.

Después de una de las últimas actualizaciones automáticas de Wordpress, mi solución se fue por el desagüe como ...
Backend y frontend completamente jodidos. Tengo que empezar de nuevo.

¿Alguien encontró una solución al problema de que las galerías no muestran miniaturas sino imágenes a tamaño completo?
Estaría muy agradecido porque esto me está poniendo de los nervios desde hace más de un año, y estoy un poco loco ... tener que investigar profundamente este tema nuevamente.
Cualquier ayuda muy apreciada, gracias y: que tengas un buen día :-)

Hola @ararename

La galería está siendo modificada para usar bloques internos. Para obtener más información, consulte esta solicitud de extracción.
https://github.com/WordPress/gutenberg/pull/25940

@paaljoachim ¡ Gracias por la rápida respuesta! Voy a comprobar :-)

@ararename , PhotoPress . Tiene una transformación de galería central.

Gracias @padams por otra opción. Pensé que lo abordaría hoy, pero me llevará algunos días volver a este tema. Informaré cómo fue.