Gutenberg respeta el soporte del editor declarado por un CPT y no se cargará si no es compatible.

Si esto significa que Gutenberg no se carga en absoluto y se usa el editor Clásico en su lugar, eso nos coloca en el camino hacia un administrador de WP fracturado que se divide entre los entornos Gutenberg y Clásico. Esto sería malo para WordPress de muchas maneras.

• Los nuevos usuarios tendrían que aprender las formas principales y sutiles en las que se diferencian los dos tipos de interfaces. Una acción tan simple como publicar una publicación o cambiar a la vista de texto funciona de manera diferente en los editores Gutenberg y Classic.

• Los desarrolladores existentes se verían obligados a mantener la funcionalidad de sus temas y complementos en ambos entornos. No estamos hablando de un período de transición; estamos hablando indefinidamente. Los complementos que están destinados a extender cualquier tipo de publicación serían los más afectados. Si esos desarrolladores terminan convirtiendo sus metacajas en bloques, todavía tendrán que mantener las antiguas cajas meta en caso de que alguien use su complemento en un tipo de publicación que no sea de Gutenberg.

• Los nuevos desarrolladores de complementos que ingresen al desarrollo de WordPress tendrían que aprender a crear complementos de dos maneras diferentes. Suponiendo que adopten los bloques de Gutenberg, es posible que su funcionalidad de complemento ni siquiera esté disponible en los tipos de publicaciones que utilizan el editor clásico.

Por mucho que creo que debemos hacer que las metacajas funcionen, simplemente apagar Gutenberg no es la mejor solución a largo plazo.

Si esto significa que Gutenberg no se carga en absoluto y se usa el editor Clásico en su lugar, eso nos coloca en el camino hacia un administrador de WP fracturado que se divide entre los entornos Gutenberg y Clásico.

En los casos en los que un CPT no quiere habilitar el editor en absoluto, ese parece ser el mejor camino a seguir. Es simplemente una vista de administrador diferente, optimizada para una experiencia diferente. (La vista de "órdenes" de Woo, por ejemplo.) No ayudaría a nadie intentar representarlos dentro del contexto de Gutenberg.

Es similar al advenimiento del Personalizador: era un nuevo paradigma de interfaz que hacía algunas de las mismas cosas en un contexto diferente. Siempre necesitaremos una interfaz de "administración" y una interfaz de "edición". Así es, en parte, cómo avanzamos, aclarando los diferentes propósitos de las interfaces.

Pero debido al aumento del alcance de Gutenberg, no se trata simplemente de habilitar o deshabilitar el tipo de editor. Dado que Gutenberg ahora determina toda la interfaz de edición, hay una lista completa de efectos secundarios asociados con el tipo de editor que mencioné anteriormente.

Siempre necesitaremos una interfaz de "administración" y una interfaz de "edición".

Esos son exactamente los roles que cumplen el editor y los metaboxes en la actualidad. No son experiencias aisladas. Trabajan juntos.

entonces tal vez debería abordarse la fluctuación del alcance, y Gutenberg debería limitarse al área poblada por wp_editor() . Sin duda resolvería muchos problemas de compatibilidad.

Fluencia del alcance

Abordar el aumento del alcance es mi preferencia y algo que muchos de nosotros hemos estado pidiendo durante los últimos meses. Hacerlo nos permitiría mejorar el editor sin dividir la experiencia del administrador.

Habilitación de Gutenberg por tipo de publicación

Con respecto a la capacidad de desactivar Gutenberg por tipo de publicación, quiero enfatizar que evitar el problema no es lo mismo que llegar a una solución. Alternar Gutenberg por tipo de publicación puede evitar la incompatibilidad de metabox para algunos complementos, pero daña el panorama de WordPress a largo plazo.

Si no puede ver por qué, imagine ser un nuevo desarrollador de complementos que ingresará a la industria dentro de dos años, después de la fusión de Gutenberg.

• Como desarrollador, ¿escribe la interfaz de usuario de su complemento como un bloque o como un metabox? Si desea admitir todos los tipos de publicaciones, deberá escribirlas como ambas.
• Cuando un usuario está buscando complementos, ¿sabe que la funcionalidad que promete en su página de complementos solo funciona en los tipos de publicaciones habilitadas para Gutenberg? ¿Se sentirán decepcionados cuando descubran que no pueden usarlo junto con el editor clásico?
• Cuando ese mismo usuario se pone en contacto con usted para solicitar asistencia, ¿sabe si está preguntando cómo funciona su complemento en el editor clásico o en el editor de Gutenberg? ¿Ese cliente siquiera sabe la diferencia?
• Cuando desee agregar funcionalidad meses después del lanzamiento, ¿está dispuesto a multiplicar su tiempo de desarrollo para construir esa funcionalidad tanto en el metabox de PHP como en el bloque JS?

Esas son solo algunas de las preguntas que confunden el panorama cuando avanzamos con dos editores y ningún camino hacia la singularidad en la interfaz de usuario.

show_in_rest

El hecho de que las publicaciones no puedan usar Gutenberg cuando show_in_rest no está configurado es solo otro ejemplo de una funcionalidad no relacionada que afecta la experiencia de edición. No hay ninguna razón por la que mi preferencia por la visibilidad de publicaciones públicas en la API REST deba afectar la interfaz que uso al editar. Entiendo las razones técnicas, pero la lógica no está ahí, y sospecho que muchos desarrolladores ni siquiera son conscientes de que esto es una limitación en este momento.

Todavía me desconcierta cómo Gutenberg se salió del alcance de los parámetros de wp_editor (). Si el "editor" de Gutenberg se restringiera a wp_editor (), entonces la "habilitación como opción" por tipo de publicación se convierte en una realidad y es mucho más manejable y ampliable en el futuro. Todavía no he visto una explicación racional de por qué el deslizamiento del alcance de Gutenberg no se puede reducir y simplemente estar contenido dentro de wp_editor ().

No tiene sentido que Gutenberg esté habilitado para tipos de publicaciones personalizadas que no usan el editor y que no se muestran directamente en la interfaz.

He visto varios sitios web donde los CPT se utilizan no solo para tipos de publicaciones genuinas, sino como un método para crear interfaces de administración para varias configuraciones y elementos.

Por ejemplo, un sitio de autor en el que he trabajado tiene CPT para "Libros" y "Enlaces de tienda". Tener a Gutenberg como editor de las páginas de listados de Libros tiene absolutamente sentido. Pero los "enlaces de la tienda" no tienen publicaciones ni páginas propias, sino que se utilizan para proporcionar la lógica de los enlaces a las librerías en línea en cada página del "libro". La plantilla de la página Libros muestra enlaces de la tienda a páginas de productos que coinciden con la región (por ejemplo, Reino Unido, EE. UU.) Y el formato (por ejemplo, libro electrónico, impresión), insertando el ISBN almacenado en un metacampo de publicación en la estructura de URL de cada tienda en línea; consulte las capturas de pantalla.

Es posible que los CPT no sean la mejor manera de administrar este tipo de datos y configuraciones, pero hay muchos sitios web que han unido varias funciones utilizando CPT sin editor y metacampos personalizados; podría proporcionar otros ejemplos de este tipo de uso. Sería confuso y contraproducente obligar al editor de Gutenberg a utilizar CPT que no utilizan el editor en absoluto.

No tiene sentido que Gutenberg esté habilitado para tipos de publicaciones personalizadas que no usan el editor y que no se muestran directamente en la interfaz.

No, no tiene sentido, pero siempre que Gutenberg sea un reemplazo de pantalla completa, la decisión de incluir o excluir a Gutenberg tiene ramificaciones más grandes que van más allá de si desea un editor en su tipo de publicación o no.

Por ejemplo, imagina que eres un desarrollador de complementos y quieres que tu metacaja "Configuración de enlaces de la tienda" esté disponible en un tipo de publicación que use Gutenberg y un segundo tipo de publicación que no lo haga. Cuando distribuye un complemento a miles de usuarios que esperan que funcione con cualquier tipo de publicación, no puede darse el lujo de elegir. Ahí es cuando entran en juego las preguntas mencionadas en https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341867663.

Vale la pena repetir que las metacajas aisladas dentro de su propio tipo de publicación son las menos afectadas por Gutenberg, por lo que debemos considerar cómo afecta la funcionalidad del complemento que sirve en todos los tipos de publicaciones.

Sí, puedo ver que los complementos que tienen que admitir interfaces tanto de Gutenberg como de otros fabricantes sería un problema importante en curso

Supongo que la pregunta entonces es cómo Gutenberg debería manejar los CPT que no son compatibles con el editor: ¿cómo funciona Gutenberg en contextos donde no tiene sentido construir una página a partir de bloques, donde solo se maneja meta?

... cómo Gutenberg debería manejar los CPT que no son compatibles con el editor: ¿cómo funciona Gutenberg en contextos donde no tiene sentido construir una página a partir de bloques, donde solo se maneja con meta?

Si Gutenberg fuera a reducir y solo reemplazar el editor como en el concepto de Yoast que mencioné en https://github.com/WordPress/gutenberg/issues/3304#issuecomment -341474018, entonces habilitar o deshabilitar Gutenberg se vuelve bastante sencillo.

• Si editor está habilitado, entonces el editor de bloques está presente y las metacajas pueden aparecer encima o debajo de él, dependiendo de los ganchos que se utilicen.
• Si editor está deshabilitado, entonces el editor de bloques está ausente y los cuadros de meta se deslizan hacia arriba para convertirse en la interfaz principal para el tipo de publicación.

Básicamente, así es como funciona hoy en día, y al mantener ese comportamiento, permitiría que los complementos pasen gradualmente las metacajas a bloques en los casos en que eso tenga sentido. También evitaría muchas de las preguntas confusas enumeradas anteriormente que están asociadas con una experiencia de administración dividida.

Encuentro que el término "aumento de alcance" es un término extraño de usar, dada la publicación de inicio y la bendición que ha recibido el proyecto . Se siente despectivo para el trabajo que ya se ha hecho, en público, desde el 11 de enero, cuando comenzamos a discutir e investigar cómo mejorar la experiencia de edición en su conjunto . Nada se nos acercó sigilosamente, este fue siempre el plan, y es por eso que no hay un plazo establecido para el enfoque.

Sea como fuere, me gustaría hablar un poco sobre la perspectiva del El status quo es la salida fácil, pero no siempre la correcta.

Agregar bloques al editor existente sin repensar el flujo habría agregado complejidad donde ya había complejidad .

Dado el mandato de repensar la autoría de publicaciones para involucrar bloques para reemplazar códigos cortos, HTML personalizado, widgets y más, estaría desperdiciando mi responsabilidad como diseñador al no mirar todo el flujo de escritura, edición y publicación de manera integral.

No estoy convencido de que WordPress sea relevante en cinco años , a menos que el proyecto en su conjunto tome medidas audaces para afrontar el futuro. Durante años, se ha anunciado un núcleo de JavaScript en las notas clave de State of the Word. Teniendo esto en cuenta, y la oportunidad que tenemos de simplificar radicalmente la creación de contenido de publicaciones enriquecidas, observar la experiencia de edición completa en lugar de una ventana pequeña no solo es una oportunidad, sino que podría decirse que sería negligente diseñar de otra manera, a pesar de los desafíos que conlleva. con eso.

Es imposible diseñar un buen editor sin mirar toda la pantalla . Esto es un inconveniente, dificulta el proyecto y, dado el legado de WordPress, lo hace aún más difícil. No ha sido fácil y aún nos queda mucho camino por recorrer, en particular en torno a cómo se puede extender Gutenberg de forma nativa. Pero dar medio paso, construir Gutenberg para reemplazar solo el área de texto del contenido, sería un flaco favor para WordPress y un mal diseño para arrancar.

Es posible cargar un componente de Gutenberg , solo el lienzo del editor, en la pantalla de edición actual. Será una experiencia muy comprometida y una interfaz de usuario Frankenstein, pero puede ser una vía a explorar para garantizar una buena ruta de migración de 4.9 a 5.0. Pero debe quedar claro que esta no es la experiencia de stock ni la óptima.

Supongo que la pregunta entonces es cómo Gutenberg debería manejar los CPT que no son compatibles con el editor: ¿cómo funciona Gutenberg en contextos donde no tiene sentido construir una página a partir de bloques, donde solo se maneja meta?

@CalebWoodbridge, así es como funciona. Ver: https://github.com/WordPress/gutenberg/blob/master/lib/register.php#L290

Yo diría que el uso del término "variación del alcance" no es correcto. Es un término que ciertamente no se aplica a un proyecto que pretende hacer lo que es Gutenberg.

Perdóname por tomar un lado en esto, pero creo que vale la pena decirlo. Al igual que se respeta a los desarrolladores cuando dicen algo técnico, piense en los diseñadores de la misma manera. Los diseñadores que trabajan en este proyecto tienen mucha experiencia y habilidad, respeto profundamente el trabajo y es un placer ser el líder de diseño de un proyecto con diseñadores tan increíbles.

Me siento honrado de tener la oportunidad de trabajar con los diseñadores que están en Gutenberg. Es un placer diario y algo que no siempre obtenemos en WordPress. La mayoría de las veces, como diseñador en el núcleo, eres una persona solitaria, ha sido increíble trabajar juntos.

La experiencia es clave cuando miramos el enfoque de diseño. @jasmussen en la visión original junto con @matias sentaron las bases de una experiencia completa. Como segundo líder de diseño, ha sido algo que valoro y quiero preservar.

Uno de los grandes problemas con WordPress en el pasado desde una perspectiva de diseño ha sido una espiral de pequeñas iteraciones sobre pequeñas iteraciones. Si bien funciona para los primeros, con el tiempo se suma a una experiencia que se mantiene junto con parches de mejoras. Hay mucho WordPress que sufre de esto. El editor es uno, los medios son otro y hay muchos más que se pueden señalar.

Gutenberg nos ha dado espacio para eliminar los parches, mirar lo que tenemos y volver a construir. Como resultado, nos ha dado el comienzo de un lenguaje visual sólido para pasar a la personalización y más allá. Tener un lenguaje visual que haga avanzar a WordPress en los próximos 10 años. Sí, tenemos que pensar tan lejos.

Quiero tomar un punto para advertir también contra Frankendesigns. Todos los diseñadores del mundo, en algún momento, alguien les sugirió que "simplemente pusieran x aquí o y allá". Esto no permite que el diseñador diseñe. Como proyecto, estamos en una espiral descendente si no dejamos que los diseñadores diseñen. Este es el tipo de proceso que, para ser franco, mata el fuego en los diseñadores. Mantengamos el fuego encendido.

Esta es una nota personal, que va más allá de Gutenberg. Me apasiona que creamos un espacio donde los diseñadores puedan prosperar y crecer; no siempre lo hemos sido como proyecto. Demostremos con Gutenberg que hacemos eso. La pasión es genial, pero respeta la visión del diseño al igual que en WordPress la visión técnica. Escuchemos a los diseñadores tanto como a los que hablan sobre el último framework JS.

Hasta el punto de ser atrevido planteado por @jasmussen , el buen diseño es audaz. Siempre lo ha sido. También requiere espacio para explorar y pensar, Gutenberg ha sido increíble por eso. Tenemos (todavía tenemos) un espacio donde podemos explorar ideas que antes sentíamos que eran demasiado como un proyecto para abordar. Ha habido libertad para iterar, experimentar y probar. Esto ha producido un diseño increíble, no lo olvidemos.

Quiero ser claro, no estoy diciendo que Gutenberg esté "hecho" o perfecto como diseño. Necesitamos iterar y necesitamos probar. Lo que no necesitamos es retroceder, alejarnos del fuerte lenguaje de diseño establecido. No necesitamos Frankendesign. Lo que necesitamos es probar, obtener comentarios y permitir que los diseñadores repitan.

Uno de los grandes problemas con WordPress en el pasado desde una perspectiva de diseño ha sido una espiral de pequeñas iteraciones sobre pequeñas iteraciones. Si bien funciona para los primeros, con el tiempo se suma a una experiencia que se mantiene junto con parches de mejoras.

Tratar de conciliar declaraciones como esta con declaraciones públicas como esta http://matiasventura.com/post/gutenberg-or-the-ship-of-theseus/ hace que sea muy difícil para los usuarios sentir que están recibiendo una comunicación honesta sobre el trabajo. Siendo hecho. Millones de personas utilizan WordPress de millones de formas, y se ha dejado muy claro que, con respecto a aspectos técnicos como el soporte de metabox o el formato de almacenamiento posterior, se requiere un enfoque incremental, con la menor cantidad de roturas posible. Esta decisión ha complicado varias partes de la implementación y ha obligado a tomar decisiones que son subóptimas pero que están mejor respaldadas de muchas maneras.

No es razonable limitar el desarrollo a un estándar y el diseño a otro. A veces, el 'diseño atrevido' debe reducirse para lograr una producción razonable. Esto es bien conocido en la fabricación de automóviles y es por eso que es fácil comparar Gutenberg con un concept car.

Claro, desea un diseño integral que use javascript para la totalidad del administrador, pero esa no puede ser la versión v5 sin romper la experiencia de millones de usuarios. En cambio, si reduce la escala para centrarse en el editor, en lugar de en la página de edición, puede proporcionar una experiencia mucho mejor (que puede lograr muchos de sus objetivos secundarios con un uso juicioso de CSS), sin interrupciones.

Luego, al proporcionar una API Fields bien documentada, puede convertir complementos y temas a la mentalidad de bloques de Gutenberg durante el próximo año, haciendo que sea más fácil y más lógico producir la misma interfaz. Muy rápidamente, los metaboxes se convierten en la antigua forma de hacer las cosas, y todos los complementos de alto valor se convertirán en bloques ... una vez más, esto tiene que suceder de manera orgánica. Forzar las manos de la gente desaprobando características o creando una interfaz dividida donde los autores de complementos tienen que codificar tanto para gutenberg como para metaboxes es insostenible.

Es bueno que mencione la revisión de los medios como un área que necesita ser revisada ... esa es un área que sufrió debido a una revisión descontrolada e inflexible. Fue la primera sección de WordPress que adoptó por completo un marco JS, y fue en gran medida un gran paso hacia atrás para los desarrolladores. La falta de personalización en la Biblioteca de medios no es una señal de que sea perfecta, sino que carece de un diseño reflexivo que tenga en cuenta los casos de uso actuales y futuros. He intentado modificar la interfaz de medios muchas veces, solo para descubrir que alguien, en algún momento, decidió que los componentes principales deberían estar codificados en las plantillas de la red troncal. ¡Ayer, literalmente, me encontré con uno de estos casos! (como puede ver en el séptimo párrafo aquí: https://gschoppe.com/wordpress/disable-attachment-pages/)

Escalar Gutenberg de nuevo al editor, en lugar de la página de edición, le daría un camino a seguir que no rompe todo. Una vez que Gutenberg esté bien establecido como la base de las interfaces de publicación personalizadas, la visión de solo JavaScript puede moverse para hacerse cargo del resto de la página de edición. Este tipo de iteración es absolutamente crucial en grandes paquetes de software, a menos que (como Matt ha afirmado inaceptable) ofrezca versiones LTS y haga que cada versión principal sea un cambio radical completo.

Hay dos pozos en los que corre el riesgo de caer, y ha identificado uno. Sí, sin avanzar hacia una interfaz unificada que utilice tecnologías modernas, es probable que WordPress muera en la próxima media década. Pero también, si WordPress no proporciona el soporte adecuado para su enorme comunidad de desarrolladores y usuarios profesionales durante esta transición, morirá mucho antes.

Tome un ritmo, reduzca la escala y ofrezca algo que abra la caja de herramientas a los usuarios, sin interrumpir el flujo de trabajo existente. Luego, puede escalar hacia adelante, versión por versión. Tienes un hermoso auto conceptual, pero lo que necesitamos es un auto de producción que funcione para todos los casos extremos de la conducción en el mundo real. Pero al proporcionar el concepto, puede tomar esa idea y aplicarla a un alcance más limitado, y dentro de un año, esos principios serán omnipresentes.

@gschoppe , gracias por tomarse el tiempo para responder.

Primero, algo de claridad. No estoy de acuerdo con que mi comentario contradiga la publicación de Matias. Estoy totalmente de acuerdo con la publicación que hizo, también es mi visión y, como líderes de este proyecto, estamos unidos en la forma en que vemos la dirección. Tu opinión personal es tuya, así que continuemos desde ese punto.

No es razonable limitar el desarrollo a un estándar y el diseño a otro.

Estoy de acuerdo y mi comentario no pretende que el diseño se escuche más o tenga diferentes estándares, se trata de escuchar todas las voces, aplicando el mismo estándar a todas.

Es bueno que mencione la revisión de los medios como un área que necesita ser revisada ... esa es un área que sufrió debido a una revisión descontrolada e inflexible.

Me encantaría ver un medio enfocado desde cero con diseñadores y desarrolladores, ese no ha sido el caso.

Pero también, si WordPress no proporciona el soporte adecuado para su enorme comunidad de desarrolladores y usuarios profesionales durante esta transición, morirá mucho antes.

Es interesante que digas esto ya que nadie está quitando ninguna funcionalidad. Ninguna sugerencia de diseño de Gutenberg ha hecho eso. De una forma u otra, se pueden realizar todas las funciones existentes, incluso si se utiliza el complemento del editor clásico.

No puedo pensar en nada más Frankendesign que confiar en iframes para armar una interfaz de usuario. Si bien entiendo que las metacajas están dando un gran vuelco al proceso de diseño, parte del diseño se trata de limitaciones. Avanzar como si esas limitaciones no existieran o posponer el plan de transición hasta el final agregará más preocupación a una comunidad ya preocupada y escéptica.

Si el plan a largo plazo para Gutenberg fuera territorio de complementos, entonces diría que experimente sin límites. Pero si no está destinado a ser un complemento en el que la gente deba optar en lugar de optar por excluirse, entonces tiene que lidiar de manera realista con el núcleo y todo el bagaje que trae consigo.

mi comentario no tiene como objetivo que el diseño se escuche más

Todos los diseñadores del mundo, en algún momento, alguien les sugirió que "simplemente pusieran x aquí o y allá". Esto no permite que el diseñador diseñe. Como proyecto, estamos en una espiral descendente si no dejamos que los diseñadores diseñen. Este es el tipo de proceso que, para ser franco, mata el fuego en los diseñadores. Mantengamos el fuego encendido.

En todos los negocios del mundo, los diseños se ajustan a las limitaciones de la implementación. Si la compatibilidad con versiones anteriores de los metaboxes es una limitación, el diseño debe aceptar eso y trabajar dentro de las limitaciones.

Para ser franco, ¿el soporte completo para metaboxes, sin pérdida de accesibilidad, es una restricción de diseño o no? Me gustaría una respuesta clara, al igual que miles de personas más.

Ninguna sugerencia de diseño de Gutenberg ha hecho eso. De una forma u otra, se pueden realizar todas las funciones existentes, incluso si se utiliza el complemento del editor clásico.

Actualmente, Gutenberg coloca todos los metacampos en un iframe. Eso rompe la funcionalidad a un nivel muy profundo. Estamos en la era de la accesibilidad, y tomar el método principal esperado de crear experiencias de usuario personalizadas y guardarlo en un iframe elimina fundamentalmente toda la accesibilidad de esas herramientas. También triplica la cantidad de solicitudes requeridas para cargar el editor y brinda a los usuarios una interfaz de usuario terrible, encarcelando experiencias modales de pantalla completa en un área pequeña.

Actualmente, este hilo analiza si Gutenberg debe optar por participar u optar por no recibir tipos de publicaciones personalizadas. Si se opta, las decisiones de IU previamente consistentes tomadas por desarrolladores que desean admitir todos los tipos de publicaciones se dividirán entre la experiencia de Gutenberg y la experiencia clásica, lo que requerirá el doble de trabajo de desarrollo para brindar una experiencia de usuario razonable para ambos, y no garantizará la coherencia. de la experiencia del usuario.

Actualmente, la función wp_editor() (que es la forma actual de mejores prácticas para implementar una copia con todas las funciones de la experiencia de edición en páginas sin editar) no proporciona una interfaz de Gutenberg, lo que significa que no puedo crear experiencias de edición personalizadas en páginas que no son de publicación ... ¿cuál es mi camino a seguir allí, además de brindarles a los usuarios una experiencia de usuario dividida?

Si bien el complemento para eliminar Gutenberg puede resolver algunos problemas, no puede enviarlo como una solución para los desarrolladores de complementos. No tienen la libertad de decir "si desea una interfaz de usuario coherente y accesible en todos los tipos de publicaciones, debe deshabilitar el nuevo editor".

La eliminación de funciones NO es compatible con versiones anteriores del flujo de trabajo estándar. La eliminación de funciones es el último recurso para el 1% de los usuarios que no se pueden acomodar como experiencias de primera clase. En este caso, ninguno de los ejemplos que he dado son problemas del 1%.

Para agregar un poco de aceite a las llamas: la semana pasada, encontré un problema masivo con el uso de iFrames, es decir. pueden funcionar bien en los sistemas de escritorio, pero en el 90% de los casos probados, fallan masivamente en Mobile / Responsive. Después de buscar en numerosos hilos de mensajes en foros, artículos en la red y preguntas sobre Stack Overflow, decidí abandonar por completo el enfoque de iframe, porque la capacidad de respuesta se vuelve muy complicada con em .. ugh. Algunas tareas de conversión fueron bastante fáciles de realizar, como "usar una redirección al subdominio real donde reside el proyecto" en lugar de depender de un iframe para colocar una bonita decoración, también conocida como solo muestra el supuesto dominio principal, pero otras eran mucho más horribles.

No obstante, en comparación con la enorme cantidad de trabajo que tendría que hacer para obtener RWD correctamente, y sobre todo, confiable Y mantenible, para trabajar con iframes, el cambio fue mucho menos esfuerzo y, por lo tanto, la mejor salida.

En resumen, aunque los iframes parecen a primera vista una salida fácil, son una MUY MALA elección de diseño, no solo por (muchos) problemas de accesibilidad.

Solo mis 0,02 centavos
cu, w0lf.

Gracias @mtias por mostrar este problema.
A continuación, publico mis pensamientos sobre cómo Gutenberg puede abrir puertas para los desarrolladores de complementos de WordPress.

Clase CSS personalizable para cualquier bloque existente

Necesario: clase CSS para cada envoltorio de bloque y acceso completo para personalizarlo. Sería genial si Gutenberg requiere la clase CSS en el elemento superior incluso de desarrolladores externos.

Propósito: De esta manera podemos agregar clases personalizadas a los bloques para un estilo avanzado. También podemos usar clases para agregar animaciones u otras propiedades de bloque avanzadas.

Ejemplo de uso: Creamos un sitio web para un gran cliente con un lenguaje de diseño estrictamente definido. El editor lateral debería poder crear bloques con un número predefinido de estilos creados por nuestro diseñador, especialmente para este cliente.

Atributos de datos personalizables para cualquier bloque existente

Necesario: Posibilidad de agregar atributos de datos personalizados para cualquier envoltorio de bloque.

Propósito: alternativa más limpia y flexible a las clases CSS personalizadas descritas anteriormente. Con los atributos de datos, podemos diseñar cualquier elemento de la página. Además del estilo, los atributos de datos personalizados se pueden usar para almacenar metadatos adicionales para JS.

Uso de ejemplo:

• bloques sensibles : marque un bloque para que se muestre solo en dispositivos móviles / computadoras de escritorio
• bloques condicionales : marque un bloque para que se muestre / oculte con JS <div data-condition="if-adblock"... , <div data-condition="if-from-facebook"...
• animación de bloque : marcar un bloque para animarlo <div data-animation="on-load animation-style-3"...
• diseño de bloque : <div data-skin="dark"...