Contrato del renderizador de UI de bloques

La fase 1 define el contrato público de renderizado previsto entre los layouts, los slots y los tipos de bloque del CMS y las primitivas de WebBlocks UI ya distribuidas y cargadas por el layout público. Esta fase es únicamente documental. Todavía no reescribe los renderizadores.

Primitivas verificadas de WebBlocks UI

Verificadas con los recursos realmente distribuidos que utiliza el CMS:

  • CSS: https://cdn.jsdelivr.net/gh/fklavyenet/webblocks-ui@v2.7.12/packages/webblocks/dist/webblocks-ui.css
  • CSS de iconos: https://cdn.jsdelivr.net/gh/fklavyenet/webblocks-ui@v2.7.12/packages/webblocks/dist/webblocks-icons.css
  • JS: https://cdn.jsdelivr.net/gh/fklavyenet/webblocks-ui@v2.7.12/packages/webblocks/dist/webblocks-ui.js

Primitivas y patrones confirmados:

  • wb-content-shell
  • wb-content-header
  • wb-content-body
  • wb-content-footer
  • wb-promo
  • wb-callout
  • wb-link-list
  • wb-stat
  • wb-gallery
  • wb-alert
  • wb-rich-text
  • wb-rich-text-readable
  • wb-rich-text-compact
  • wb-rich-text-loose
  • wb-btn
  • wb-grid
  • wb-grid-2
  • wb-grid-3
  • wb-grid-4
  • wb-stack
  • wb-gap-1
  • wb-gap-2
  • wb-gap-3
  • wb-gap-4
  • wb-gap-6
  • wb-gap-8

Primitivas ausentes y carencias de UI por ahora:

  • wb-prose — NO ENCONTRADO en los recursos distribuidos de WebBlocks UI. Considérelo una carencia de UI y no dependa de él para el layout de la fase 2 ni para la alineación de los renderizadores.
  • wb-promo-muted — NO ENCONTRADO en los recursos distribuidos de WebBlocks UI.
  • wb-promo-accent — NO ENCONTRADO en los recursos distribuidos de WebBlocks UI.
  • wb-cluster-3 — NO ENCONTRADO en los recursos distribuidos de WebBlocks UI.

Hooks de JS distribuidos y verificados relevantes para el renderizado público actual:

  • data-wb-toggle="dropdown"
  • data-wb-toggle="modal"
  • data-wb-gallery-target
  • #wb-overlay-root

Modos de layout de la fase 2B

Las páginas públicas utilizan ahora modos explícitos de composición de layout:

  • stack es el modo predeterminado.
  • sidebar se utiliza cuando la página tiene un slot de barra lateral con contenido.
  • content se reserva para futuras páginas de documentación o editoriales con metadatos explícitos y no debe deducirse de la URL ni del título.
  • wb-content-shell no es un contenedor universal y solo debería aparecer cuando los metadatos de la página admitan explícitamente una presentación de tipo content-shell.

Matriz

Bloque del CMS Primitiva/patrón de WebBlocks UI Estado Prioridad Siguiente acción
layout público wb-public-body, wb-public-main, wb-container aceptable P0 shell/layout mantener el shell estable y acercar el chrome específico de cada slot a las primitivas documentadas
slot de cabecera wb-section, wb-container, primitivas de navegación/lista débil P0 shell/layout alinear el chrome personalizado de la cabecera con las reglas documentadas del shell
slot principal wb-public-main, wb-container, wb-content-shell aceptable P0 shell/layout añadir el uso de wb-content-shell donde el contenido se lea como un artículo o documentación
slot de barra lateral wb-grid, wb-stack, opcionalmente un aside con wb-content-shell débil P0 shell/layout dejar de tratar las barras laterales genéricas como falsas barras laterales de aplicación
slot de pie wb-section, wb-container, wb-grid, primitivas de lista de enlaces/navegación aceptable P0 shell/layout mantener el pie sobre las primitivas de layout distribuidas y evitar clases personalizadas adicionales
heading heredado eliminado retirado P0 eliminado no reintroducirlo; header es el bloque canónico de encabezado/título
text texto de cuerpo con el ritmo de wb-stack aceptable P2 calidad del contenido mantener una salida sencilla y evitar envoltorios tipográficos a medida
rich-text wb-rich-text wb-rich-text-readable aceptable P2 calidad del contenido mantener el texto de cuerpo seguro acotado a la primitiva de texto enriquecido distribuida
html HTML en bruto de confianza dentro del envoltorio de bloque público aceptable P3 posterior/personalizado mantenerlo restringido al uso editorial/administrativo de confianza y elevar cualquier contenido de superposición distribuido a la raíz de superposiciones compartida de la página
section wb-section, opcionalmente wb-promo aceptable P1 marketing público/docs mantener estable la sección predeterminada y reservar la semántica promo para variantes explícitas
columns wb-grid, wb-grid-2, wb-grid-3, wb-grid-4, wb-link-list aceptable P1 marketing público/docs mantener explícitas las variantes dirigidas por el elemento padre y evitar reintroducir tarjetas envolventes forzadas
column_item celda simple, wb-card, wb-stat o elemento de lista de enlaces aceptable P1 marketing público/docs mantener el renderizado del elemento dirigido por la asignación columns.variant del padre
callout wb-alert, opcionalmente wb-callout aceptable P2 calidad del contenido ampliar la asignación de variantes si existe un callout de barra lateral/ayuda distribuido
quote blockquote semántico, opcionalmente una tarjeta enmarcada aceptable P2 calidad del contenido hacer que el marco sea condicional en lugar de siempre con aspecto de tarjeta
faq tarjeta simple de pregunta/respuesta aceptable P3 personalizado/alternativa mantener el tratamiento estable de tarjeta única y dejar la divulgación agrupada en los bloques de acordeón
tabs patrón de pestañas interactivo débil P2 calidad del contenido aplazarlo hasta que exista un patrón de pestañas realmente distribuido
button variantes de wb-btn débil P1 marketing público/docs asignar todas las variantes admitidas del CMS y añadir la dirección del grupo de botones
image figure, img, figcaption semánticos débil P2 calidad del contenido respetar el comportamiento del enlace y añadir marco de medios solo cuando sea necesario
gallery wb-gallery más el modal de la raíz de superposiciones aceptable P1 marketing público/docs seguir utilizando los hooks de galería distribuidos y la raíz de superposiciones central, manteniendo el texto introductorio fuera del propio bloque Gallery
download wb-btn o CTA de tarjeta con botón aceptable P2 calidad del contenido añadir más adelante variantes explícitas de tarjeta/descarga
navigation-auto primitivas de navegación/lista, opcionalmente wb-link-list aceptable P1 marketing público/docs mantener sencillos los menús sencillos y reservar las barras laterales de documentación para shells de documentación reales
menu alias heredado de navigation-auto aceptable P3 posterior/personalizado mantenerlo solo para datos migrados
contact_form primitivas de formulario, wb-btn, wb-alert aceptable P1 marketing público/docs mantener los campos estructurados del editor y evitar formularios en HTML en bruto
hero shell de marketing wb-promo aceptable P1 marketing público/docs mantener el hero como elemento de primer nivel, traducido y orientado a la acción mediante bloques de botón hijos
card-grid patrón de cuadrícula de tarjetas débil P1 marketing público/docs mantener estable la cuadrícula de tarjetas estructurada actual y revisar más adelante un modelado de primer nivel
showcase-list patrón de escaparate/galería débil P3 posterior/personalizado formalizarlo como bloque de escaparate de primer nivel o mantenerlo personalizado
contact-info lista de enlaces / tarjeta de datos de contacto débil P2 calidad del contenido promoverlo a primer nivel solo si los editores lo necesitan más allá de las páginas precargadas
code patrón de bloque de código ausente P2 calidad del contenido añadir soporte de primer nivel en renderizador/administrador o mantener deliberadamente la alternativa
list primitiva de lista aceptable P1 marketing público/docs mantener el editor específico basado en líneas y preservar la compatibilidad con los ajustes de estilo alternativo heredados
table patrón wb-table aceptable P1 marketing público/docs mantener el editor específico basado en líneas y preservar las filas de ajustes de estilo alternativo heredadas
accordion patrón de divulgación semántico aceptable P1 marketing público/docs mantener el renderizador semántico de primer nivel con bloques hijos como elementos
feature-grid patrón delegado columns.variant = cards aceptable P1 marketing público/docs mantenerlo publicado como alias de compatibilidad, pero preferir columns para el contenido estructurado nuevo
stats / metric-card patrón delegado columns.variant = stats débil P1 marketing público/docs mantener los alias honestos y añadir contratos específicos de estadísticas reales solo si pasan a ser propiedad del producto
logo-cloud cuadrícula de logotipos / franja de marcas débil P1 marketing público/docs añadir gestión estructurada de medios si sigue siendo un elemento del producto
testimonial patrón de testimonio delegado en la cita débil P2 calidad del contenido mantener honesto el comportamiento del alias salvo que un contrato de testimonio independiente pase a ser propiedad del producto
timeline patrón de línea de tiempo débil P2 calidad del contenido promoverlo solo si el contenido de línea de tiempo es un caso de uso recurrente real
pricing patrón de tarjeta/cuadrícula de precios débil P1 marketing público/docs convertirlo en elemento de primer nivel solo con planes y características estructurados
toc navegación de tabla de contenidos aceptable P1 marketing público/docs mantener la recopilación del índice de la misma página únicamente sobre bloques header con ancla explícita
breadcrumb navegación de migas de pan ausente P2 calidad del contenido aplazarlo hasta que el shell de página pública realmente lo necesite y se confirme un patrón distribuido
cookie-notice patrón compartido de banner/modal de privacidad ausente P3 posterior/personalizado mantener la interfaz de consentimiento en el layout público en lugar de en los renderizadores de bloques

Layout de página y slots

Layout público

  • El layout público es dueño del shell de toda la página y debería mantener el contrato base <body class="wb-public-body">.
  • Page Layout es el nombre orientado al editor del modo de shell público exterior.
  • El campo de compatibilidad almacenado sigue siendo public_shell en esta fase, pero los Page Layouts se gestionan ahora como registros a nivel de instalación en el administrador.
  • Page Layout puede añadir clases de body validadas, como layout-default o layout-docs, a esa clase de body base.
  • Las regiones principales de la página deberían construirse primero con las primitivas de layout distribuidas de WebBlocks UI: wb-public-main, wb-container, wb-section, wb-stack, wb-grid.
  • wb-content-shell, wb-content-header, wb-content-body y wb-content-footer pertenecen al área de contenido principal cuando la página se lee como un artículo, una guía, documentación o contenido editorial. No son el chrome de cabecera o de pie de todo el sitio.
  • #wb-overlay-root es el único punto de montaje compartido para las superposiciones públicas, como el visor de galería, el modal de búsqueda pública y el modal de preferencias de cookies.
  • Los layouts públicos son dueños de ese envoltorio; los bloques, los partials y el HTML de confianza pueden aportar hijos de superposición, pero no deben renderizar contenedores raíz de superposición que compitan con él.
  • El HTML importado de confianza que utiliza hooks de activación distribuidos de WebBlocks UI debe preservar el contrato entre el disparador y su destino. Si un disparador dentro del contenido principal importado apunta a un modal, un panel lateral, un popover o un visor de galería situado fuera de <main>, el extractor debe elevar ese destino referenciado al #wb-overlay-root compartido en lugar de descartarlo.
  • Cuando el CMS prerrenderiza una capa de diálogo compartida bajo #wb-overlay-root, esa capa debe permanecer visible para que WebBlocks UI v2.7.12 pueda portar hacia ella los destinos de modal y de galería de confianza sin dejarlos dentro de un ancestro oculto.

Card

  • card es dueño de article.wb-card como raíz del renderizador, con data-wb-public-block-type="card".
  • card_header es dueño de div.wb-card-header, con data-wb-public-block-type="card-header".
  • card_body es dueño de div.wb-card-body, con data-wb-public-block-type="card-body".
  • card_footer es dueño de div.wb-card-footer, con data-wb-public-block-type="card-footer".
  • Las regiones de Card deberían renderizar sus propias raíces directamente y no deben recibir envoltorios públicos genéricos adicionales.
  • El contrato normal de Card es contenido hijo componible a través de esas tres regiones, no un renderizador integrado de promo o de medios.
  • Las filas de Card guardadas antiguamente todavía pueden utilizar un renderizador alternativo mínimo, pero solo cuando la Card no tiene regiones de Card hijas.
  • wb-sidebar se reserva para un verdadero shell de navegación de documentación o de aplicación. Las barras laterales genéricas de marketing o editoriales deberían seguir siendo contenido aside ordinario, compuesto con wb-grid, wb-stack, tarjetas, callouts y listas de enlaces.

Envoltorios de slot

  • Los wrappers de slot son comportamiento determinista de runtime, no ajustes editoriales libres a nivel de página.
  • El handle de layout de página se resuelve primero a un registro gestionado de Page Layout cuando está disponible, y los Page Layout Slots gestionados de ese registro se usan entonces para resolver el elemento, las clases, los ids y los fragmentos estructurales de confianza del wrapper de slot.
  • La comparación en Edit Page y Add Missing Layout Slots cambian la estructura de la página únicamente creando los Page Slots que faltan; no cambian la propiedad del wrapper público.
  • Los campos HTML de confianza de Page Layout Slot existen solo para la estructura de layout adyacente al wrapper. No son una superficie para scripts, y los bloques siguen siendo dueños de las raíces de contenido renderizadas dentro del wrapper de slot.
  • Cuando un slot de cabecera público por defecto contiene únicamente un bloque Navbar, el CMS promueve el wrapper de slot a la raíz nav.wb-navbar para que el comportamiento sticky de WebBlocks UI no quede limitado por una caja de cabecera padre demasiado baja.
  • wb-navbar--static sigue siendo la clase de exclusión para los bloques Navbar públicos no sticky.
  • default asigna header, main, sidebar y footer a wrappers semánticos y recurre a div para los slots desconocidos.
  • docs asigna header al wrapper de la navbar de docs, sidebar al wrapper de la barra lateral de docs y main al wrapper principal de docs, manteniendo wb-dashboard-shell como propiedad de la página.
  • Los layouts integrados default y docs conservan definiciones gestionadas de reserva para que el renderizado siga siendo estable antes de que existan filas de slot relacionales, o sin ellas.
  • Los bloques se renderizan dentro del wrapper de slot resuelto y no son dueños del marcado del shell de página.
  • El comportamiento sticky de la navbar pertenece a .wb-navbar. El CMS no debería añadir una segunda clase sticky específica de la navbar al wrapper de slot ni a la salida del bloque navbar.
  • Cuando un slot de página usa source_type = shared_slot, el Shared Slot aporta únicamente el árbol de bloques interno. No debe renderizar su propio shell de página ni su propio wrapper de slot.
  • La compatibilidad del Shared Slot se comprueba antes de renderizar: el ámbito de sitio debe coincidir, el public_shell opcional debe coincidir exactamente con el handle del layout de la página consumidora y el slot_name opcional debe coincidir con el slot de la página consumidora.
  • Los wrappers públicos genéricos de bloque deben mantenerse no semánticos y no deben usarse para bloques de layout o que sean dueños de su raíz.
  • El shell de página es dueño del shell exterior, los wrappers de slot son dueños del wrapper de región y los bloques que poseen su raíz son dueños de su propio elemento raíz público real.
  • Los bloques que poseen su raíz deben colocar data-wb-public-block-type en su propia raíz de renderizador en lugar de recibir un wrapper exterior wb-public-block adicional.

Slot header

  • Asignación prevista: región header construida a partir de wb-section y wb-container, con las primitivas de navegación y lista distribuidas en su interior.
  • Use wb-stack o wb-grid para el ritmo interno, según si la cabecera se lee como un banner apilado o como una barra de navegación horizontal.
  • La navegación principal o legal puede renderizarse mediante navigation-auto o menu, pero el slot no debería obligar a los renderizadores de bloque a emitir HTML específico de cabecera.
  • La implementación actual es débil porque el slot de cabecera es dueño de varias clases de chrome wb-public-* personalizadas. La fase 2A mantiene intacto el shell existente de wb-section y wb-container y aplaza a una pasada posterior cualquier reducción segura del chrome de cabecera personalizado.

Slot main

  • Asignación prevista: <main class="wb-public-main"> es la región de contenido principal.
  • Shell por defecto: wb-public-main > .wb-container > .wb-stack para las pilas de bloques habituales.
  • Shell editorial/docs: wb-public-main > .wb-container > .wb-content-shell con secciones opcionales wb-content-header, wb-content-body y wb-content-footer.
  • El layout de bloques anidados debería usar wb-stack, wb-stack-, wb-gap-, wb-grid y wb-grid-* antes que cualquier clase de wrapper personalizada.
  • La implementación actual es aceptable porque ya da al slot main un wrapper público estable y un ritmo de bloques. La fase 2B añade modos de layout explícitos para que wb-content-shell quede reservado en lugar de imponerse a todas las páginas.

Slot sidebar

  • Asignación prevista: aside adyacente al contenido principal mediante wb-grid u otra primitiva de layout distribuida.
  • El contenido por defecto debería ser un wb-stack de bloques de apoyo, opcionalmente agrupados en un wb-card o un wb-callout si encaja con el contenido del bloque.
  • wb-sidebar solo debería usarse cuando la página renderiza explícitamente un shell de navegación de docs o de aplicación, no para contenido de marketing de apoyo genérico.
  • La implementación actual es débil porque todavía usa un shell wb-public-sidebar personalizado. La fase 2A elimina el wrapper exterior wb-card forzado para que los bloques interiores controlen si se renderizan como tarjetas o como callouts.

Slot footer

  • Asignación prevista: región footer construida a partir de wb-section, wb-container y wb-grid o wb-stack.
  • Las listas de navegación deberían usar primitivas simples de navegación/lista o wb-link-list cuando el patrón de interfaz distribuido encaje.
  • Los bloques de contenido de apoyo pueden renderizarse con normalidad dentro del pie; no deberían necesitar renderizadores de bloque específicos del pie.
  • La implementación actual es aceptable porque se mantiene cerca de las primitivas de layout distribuidas, con solo un poco de chrome de pie específico del CMS alrededor del control de configuración de cookies.

Bloques de contenido principales

`header`

  • Slug del bloque en el CMS: header
  • Campos de administración: text, level, anchor
  • Campos traducibles: texto de title
  • Campos compartidos: variant/level, ajuste de alineación, anchor
  • Salida prevista en WebBlocks UI: <h1>-<h6> semántico según level; id opcional a partir del anchor compartido; ningún wrapper inventado más allá del elemento de encabezado.
  • Implementación actual: aceptable
  • Contrato de TOC: los anchors compartidos explícitos son la única fuente admitida para el TOC, y el TOC público recoge los bloques header con anchor del mismo árbol de página renderizado, incluidos los descendientes de layout anidados.
  • Notas para mejoras posteriores de renderizador/administración: mantener explícito el comportamiento de los anchors, conservar la salida sin wrapper y mantener la semántica de encabezados en manos de Header en lugar de un bloque heredado paralelo.

`text`

  • Slug del bloque en el CMS: text
  • Campos de administración: content
  • Campos traducibles: content
  • Campos compartidos: ninguno
  • Salida prevista en WebBlocks UI: párrafo o texto corrido ordinario; use un ritmo wb-stack distribuido solo cuando haga falta para varios nodos de texto.
  • Implementación actual: aceptable
  • Nota de mapeo de importación/sincronización: use text/plain_text solo para texto corrido sencillo sin marcado de formato en línea seguro.
  • Notas para mejoras posteriores de renderizador/administración: mantener este bloque simple y evitar convertirlo en un pseudobloque de texto enriquecido.

`rich-text`

  • Slug del bloque en el CMS: rich-text
  • Campos de administración: content
  • Campos traducibles: content
  • Campos compartidos: ninguno
  • Salida prevista en WebBlocks UI: texto corrido saneado envuelto en wb-rich-text wb-rich-text-readable usando la primitiva de texto enriquecido distribuida por WebBlocks UI.
  • Implementación actual: aceptable
  • Modelo de almacenamiento: Rich Text guarda un fragmento HTML seguro restringido, no marcadores Markdown. Las etiquetas permitidas son p, strong, em, code, a[href], ul, ol, li y br cuando hace falta. Las clases, los estilos, los atributos de evento, los encabezados, los medios, las tablas, los botones y el HTML no admitido se eliminan durante el saneamiento.
  • Comportamiento en administración: el editor de administración es una superficie contenteditable sin dependencias, sincronizada con un campo de formulario oculto. Está limitado de forma intencionada al formato de texto corrido y no sustituye a Header, Button, Media, Table, Layout, HTML ni a otros tipos de bloque dedicados.
  • Nota de mapeo de importación/sincronización: cuando el texto corrido importado contenga formato en línea seguro, varios párrafos o listas simples, debería convertirse en rich-text en lugar de text.
  • Notas para mejoras posteriores de renderizador/administración: mantener Rich Text limitado a texto corrido editorial seguro. wb-rich-text sigue siendo la primitiva pública de tipografía. Los encabezados, los medios, los botones, las tablas, el layout y la composición de HTML en crudo siguen siendo bloques o funciones aparte.

`html`

  • Slug del bloque en el CMS: html
  • Campos de administración: content
  • Campos traducibles: content
  • Campos compartidos: ninguno
  • Salida prevista en WebBlocks UI: HTML de confianza en crudo dentro del wrapper público de bloque habitual.
  • Implementación actual: aceptable
  • Notas para mejoras posteriores de renderizador/administración: reservar este bloque para un uso editorial/administrativo de confianza, documentar claramente el riesgo de XSS y no hacer que los editores corrientes dependan de HTML de WebBlocks pegado para el contenido normal. Cuando el HTML de confianza incluya marcado de overlay distribuido por WebBlocks UI, el shell de página pública debería elevar ese contenido de overlay interno al #wb-overlay-root compartido y propiedad de la página, en lugar de renderizar raíces de overlay duplicadas en línea.

`section`

  • Slug del bloque en el CMS: section
  • Campos de administración: title, variant, content
  • Campos traducibles: title, content
  • Campos compartidos: variant
  • Salida prevista en WebBlocks UI: el wrapper por defecto usa wb-section; las variantes promo explícitas pueden mapearse a wb-promo cuando el patrón distribuido encaje; las acciones de CTA deberían venir de bloques hijos, no de HTML en crudo.
  • Implementación actual: aceptable
  • Regla de wrapper: el bloque Section es dueño de la raíz real <section class="wb-section ..."> y lleva data-wb-public-block-type="section" en ese elemento. Los wrappers públicos genéricos de bloque no deben envolverlo.
  • Notas para mejoras posteriores de renderizador/administración: mantener estables las secciones por defecto, tratar promo como una variante de marketing explícita y mantener estructurados los botones y grupos de botones hijos.
  • Comportamiento de CTA en promo: los bloques button hijos se renderizan en wb-promo-actions; los hijos que no son botones siguen renderizándose fuera de la fila de CTA.

Regla de wrapper de layout

  • header, section, container, grid, cluster, card y content_header son bloques de layout o de shell de contenido que poseen su raíz y no deberían recibir un wrapper público genérico del bucle público de bloques.
  • Section es dueño de la raíz semántica <section class="wb-section"> cuando hace falta.
  • Container, Grid y Cluster son dueños de sus propias raíces de layout no semánticas, salvo que un renderizador concreto elija otra cosa de forma intencionada.
  • Card es dueño de su raíz <article class="wb-card">.
  • Card Header, Card Body y Card Footer son dueños de sus raíces de región correspondientes en WebBlocks UI y juntos definen la estructura pública normal de Card.
  • Header es dueño de su raíz de encabezado semántica, como <h1> o <h2>.
  • Content Header es dueño de su raíz semántica <header class="wb-content-header"> y siempre renderiza su título como <h1 class="wb-content-title">.
  • La estandarización de la fase 3 de Layout + Card mantiene alineados estos bloques que poseen su raíz en los partials del renderizador, Block::ownsPublicRoot(), el registro de contratos, el modal de contrato de solo lectura en administración y el comando de auditoría de contratos.

`hero`

  • Slug del bloque en el CMS: hero
  • Campos de administración: subtitle, title, content, variant
  • Campos traducibles: subtitle como antetítulo, title como titular, content como texto de apoyo
  • Campos compartidos: variant, estructura de bloques hijos
  • Salida prevista en WebBlocks UI: wb-promo > .wb-promo-copy con wb-eyebrow, wb-promo-title, wb-promo-text y wb-promo-actions opcionales
  • Implementación actual: aceptable
  • Notas para mejoras posteriores de renderizador/administración: las acciones de CTA del hero deberían venir de bloques button hijos, no debería usarse HTML en crudo para el contenido normal del hero y los ajustes heredados de hero importados solo deberían actuar como reserva cuando los campos traducidos canónicos estén vacíos.
  • Comportamiento de CTA del hero: los bloques button hijos se renderizan en wb-promo-actions; los hijos que no son botones se ignoran en la fila de CTA.
  • Regla de wrapper: hero es ahora dueño de su raíz de renderizador y coloca data-wb-public-block-type="hero" en esa raíz, por lo que el bucle de slot no debe añadir un wrapper público exterior genérico.

`columns`

  • Slug del bloque en el CMS: columns
  • Campos de administración: title, subtitle, content, variant, column_items repetible
  • Campos traducibles: title, subtitle, content, texto de los column_item hijos
  • Campos compartidos: variant, orden de los hijos, enlaces de los hijos, estructura
  • Salida prevista en WebBlocks UI: contenedor de layout para hijos repetibles mediante wb-grid, wb-grid-2, wb-grid-3, wb-grid-4, o un wb-grid genérico cuando el número es dinámico.
  • Implementación actual: aceptable
  • Mapeo de variantes:
  • cards -> contenedor de rejilla con cada hijo renderizado como wb-card > .wb-card-body
  • plain -> contenedor de rejilla con contenido hijo apilado y sin marco
  • stats -> contenedor de rejilla con los elementos hijos renderizados como wb-stat
  • links -> wb-link-list con los elementos hijos renderizados como filas de lista de enlaces
  • Notas para mejoras posteriores de renderizador/administración: mantener en el bloque padre la responsabilidad de la elección de presentación, para que el contenido existente de column_item pueda seguir siendo simple y reutilizable.

`column_item`

  • Slug del bloque en el CMS: column_item
  • Campos de administración: title, url, content
  • Campos traducibles: title, content
  • Campos compartidos: url
  • Salida prevista en WebBlocks UI: una celda de rejilla que puede renderizarse como contenido simple, wb-card, wb-stat, wb-link-list-item u otro tratamiento de celda distribuido, según la variante del padre o del elemento.
  • Implementación actual: aceptable
  • Notas para mejoras posteriores de renderizador/administración: column_item sigue siendo una unidad de contenido simple y ahora delega la presentación pública en su bloque columns padre. El mapeo actual de stats es deliberadamente conservador porque todavía no existe un campo de valor numérico dedicado.

`cta`

  • Slug del bloque CMS: cta
  • Campos de administración: subtitle, title, content, CTA principal gestionado, CTA secundario gestionado, variant
  • Campos traducibles: subtitle como antetítulo, title como titular, content como texto de apoyo, además de las etiquetas de los button hijos
  • Campos compartidos: variant, las URL de los CTA hijos, el orden de los hijos
  • Salida prevista de WebBlocks UI: sección de estilo promocional wb-card wb-promo con wb-promo-copy y wb-promo-actions
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: mantenga las etiquetas de los CTA en manos del idioma, en los botones hijos, mantenga compartidas las URL de los CTA y evite reintroducir cargas de CTA basadas en settings.
  • Regla de envoltorio: cta ahora posee su propia raíz de renderizado y coloca data-wb-public-block-type="cta" en esa raíz, de modo que el bucle de slots no debe añadir un envoltorio público exterior genérico.

`feature-grid`

  • Slug del bloque CMS: feature-grid
  • Campos de administración: title, subtitle, content, feature_items repetibles
  • Campos traducibles: title, subtitle, content, el texto de los feature-item hijos
  • Campos compartidos: el orden de los hijos, los enlaces de los hijos, la estructura
  • Salida prevista de WebBlocks UI: la misma estructura pública de rejilla de tarjetas que utiliza columns.variant = cards
  • Implementación actual: aceptable como alias de compatibilidad
  • Notas para futuras mejoras del renderizador o de la administración: mantenga Feature Grid respaldado por el código fuente y documentado, pero deje explícito que actualmente delega en el renderizador compartido de tarjetas de Columns en lugar de poseer un marcado propio de feature-grid.

`feature-item`

  • Slug del bloque CMS: feature-item
  • Campos de administración: title, url, content
  • Campos traducibles: title, content
  • Campos compartidos: url
  • Salida prevista de WebBlocks UI: la misma carcasa de elemento de tarjeta que utiliza column_item en la presentación de tarjetas de Columns
  • Implementación actual: aceptable como alias de compatibilidad
  • Notas para futuras mejoras del renderizador o de la administración: mantenga Feature Item documentado como un contrato de hijo auxiliar respaldado por el código fuente mientras siga delegando en la presentación de tarjetas compartida de Column Item.

`callout`

  • Slug del bloque CMS: callout
  • Campos de administración: title, variant, content
  • Campos traducibles: title, content
  • Campos compartidos: variant
  • Salida prevista de WebBlocks UI: el comportamiento de aviso/alerta se corresponde con wb-alert-*; las variantes de barra lateral o de ayuda pueden corresponderse con wb-callout si ese primitivo existe en WebBlocks UI.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: mantenga explícita la correspondencia de tono e introduzca carcasas alternativas de callout solo cuando la UI publicada las tenga.

`quote`

  • Slug del bloque CMS: quote
  • Campos de administración: content, title, subtitle
  • Campos traducibles: content, title, subtitle
  • Campos compartidos: ninguno
  • Salida prevista de WebBlocks UI: un blockquote semántico; utilice el marco de tarjeta o callout publicado solo cuando la cita se presente intencionadamente como un testimonio o una tarjeta enmarcada.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: permita una variante de cita semántica sin marco y utilice testimonial solo si llega a convertirse en un patrón independiente de primer nivel.

`faq`

  • Slug del bloque CMS: faq
  • Campos de administración: title, content
  • Campos traducibles: title, content
  • Campos compartidos: ninguno
  • Salida prevista de WebBlocks UI: contenido simple de pregunta y respuesta dentro de una carcasa estable de wb-card y wb-stack.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: FAQ sigue siendo simple y retrocompatible. Cuando se utiliza como hijo de un bloque de la familia accordion, su title y su content actúan como el resumen y el cuerpo del desplegable.

`accordion`

  • Slug del bloque CMS: accordion
  • Campos de administración: title, content
  • Campos traducibles: title, content
  • Campos compartidos: la estructura y el orden de los bloques hijos
  • Salida prevista de WebBlocks UI: desplegables agrupados semánticos mediante <details> y <summary>, sin JS de acordeón propio ni clases inventadas.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: los bloques hijos aportan los elementos desplegables. Los bloques sin un title y un content utilizables se omiten en lugar de renderizarse como envoltorios vacíos.

`faq-list`

  • Slug del bloque CMS: faq-list
  • Campos de administración: las mismas expectativas editoriales que accordion
  • Campos traducibles: heredados del bloque padre y de los elementos hijos
  • Campos compartidos: la estructura y el orden de los bloques hijos
  • Salida prevista de WebBlocks UI: la misma que accordion; este slug es ahora un alias transitorio y no un patrón independiente a largo plazo.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: mantenga el contenido antiguo en funcionamiento, pero oriente el uso futuro de desplegables agrupados hacia accordion.

`tabs`

  • Slug del bloque CMS: tabs
  • Campos de administración: title, subtitle, content
  • Campos traducibles: title, subtitle, content
  • Campos compartidos: ninguno
  • Salida prevista de WebBlocks UI: un conjunto de pestañas realmente interactivo si tabs sigue siendo un bloque de primer nivel.
  • Implementación actual: débil
  • Notas para futuras mejoras del renderizador o de la administración: tabs queda explícitamente aplazado hasta que WebBlocks UI publique un patrón de pestañas real. El tratamiento actual de tarjeta simple se mantiene solo como alternativa de compatibilidad y no se promueve.

`button`

  • Slug del bloque CMS: button
  • Campos de administración: title, url, subtitle, variant
  • Campos traducibles: title
  • Campos compartidos: url, subtitle/destino, variant, relación opcional con un archivo adjunto
  • Salida prevista de WebBlocks UI: correspondencia explícita de variantes wb-btn para primary, secondary, outline, ghost y danger; los valores desconocidos deben recurrir a wb-btn wb-btn-primary.
  • Implementación actual: aceptable
  • Correspondencia de variantes:
  • primary -> wb-btn wb-btn-primary
  • secondary -> wb-btn wb-btn-secondary
  • outline -> wb-btn wb-btn-outline
  • ghost -> wb-btn wb-btn-ghost
  • danger -> wb-btn wb-btn-danger
  • desconocido o vacío -> wb-btn wb-btn-primary
  • Notas para futuras mejoras del renderizador o de la administración: mantenga aislada la compatibilidad con adjuntos y descargas, renderice <button type="button"> únicamente cuando no haya URL y formalice un bloque de grupo de botones de primer nivel solo cuando los editores lo necesiten más allá de las filas de botones hijos.

Filas de CTA

  • Los bloques de sección de tipo hero y promocional deben modelar los CTA con bloques button hijos.
  • Las filas de CTA promocionales se renderizan en wb-promo-actions.
  • Fuera de los contextos promocionales, las filas de acción ordinarias pueden utilizar utilidades de cluster publicadas como wb-cluster wb-cluster-2.
  • Un bloque button-group de primer nivel queda aplazado por ahora; el modelo actual de botones hijos ya admite filas de CTA estructuradas sin añadir nueva arquitectura de bloques.

`image`

  • Slug del bloque CMS: image
  • Campos de administración: media_id, subtitle, url, title
  • Campos traducibles: title como pie de foto, subtitle como texto alternativo
  • Campos compartidos: media_id, url
  • Salida prevista de WebBlocks UI: figure, img y, opcionalmente, figcaption semánticos; utilice las clases publicadas de medios o de tarjeta solo cuando la imagen se enmarque intencionadamente.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: la Fase 3 mantiene ahora el pie de foto y el texto alternativo en la vía de traducción de la imagen, conserva la URL de enlace compartida opcional y mantiene una salida semántica sin envoltorios cuando existen medios.

`gallery`

  • Slug del bloque CMS: gallery
  • Campos de administración: filas compactas de la lista Gallery Items, ajustes de presentación de Gallery compartidos y modales de metadatos por elemento
  • Campos traducibles: alt_text, caption, overlay_title y overlay_text de cada elemento de la galería, mediante block_gallery_item_translations
  • Campos compartidos: la selección y el orden de los medios de la galería, las columnas, el espaciado, la variante, la relación de aspecto, el modo de pies de foto, el modo de superposición y el interruptor de lightbox
  • Salida prevista de WebBlocks UI: el patrón de galería de WebBlocks con el visor montado bajo #wb-overlay-root; los hooks de galería publicados de WebBlocks UI deben gobernar la interacción en primer lugar.
  • Implementación actual: aceptable
  • Contrato de renderizado público: Gallery ya no emite un encabezado ni un párrafo de introducción públicos. Los valores heredados de título y descripción de Gallery pueden seguir almacenados en registros antiguos, pero el renderizador público los ignora. Los medios de Gallery con relación de aspecto fija conservan la imagen completa con un ajuste de tipo contain centrado, de modo que las imágenes tipo captura de pantalla no se recortan dentro de los mosaicos fijos.
  • Contrato editorial: cuando se necesiten encabezados de sección o texto explicativo, utilice Content Header más Plain Text o Rich Text antes del bloque Gallery.
  • Notas para futuras mejoras del renderizador o de la administración: el renderizador actual escribe los medios ordenados canónicos de la galería a través de block_media, resuelve el texto de cada elemento en manos del idioma mediante block_gallery_item_translations, conserva los elementos heredados de reserva para el contenido guardado antiguo y mantiene data-wb-gallery-target emparejado con un único modal de visor compartido bajo #wb-overlay-root.

`download`

  • Slug del bloque CMS: download
  • Campos de administración: title, subtitle, media_id, variant
  • Campos traducibles: title, subtitle
  • Campos compartidos: media_id, variant
  • Salida prevista de WebBlocks UI: un CTA de archivo como wb-btn, o una wb-card compacta más un wb-btn cuando la variante necesita más contexto.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: la Fase 3 mantiene ahora la etiqueta visible y el texto de ayuda en las traducciones de texto, conserva la propiedad compartida de los medios y de la variante del botón, y suprime la salida de un CTA roto cuando no existe una fuente de medios.

`contact_form`

  • Slug del bloque CMS: contact_form
  • Campos de administración: heading, intro_text, submit_label, success_message, recipient_email, send_email_notification, store_submissions
  • Campos traducibles: heading, intro_text, submit_label, success_message
  • Campos compartidos: recipient_email, send_email_notification, store_submissions
  • Comportamiento previsto: el envío público almacena primero el mensaje y después intenta una notificación por correo síncrona al destinatario resuelto; las vistas de administración deben mostrar un estado compacto de la notificación y un detalle seguro del fallo cuando la entrega no se realiza.
  • Endpoint público de envío: formulario nativo del navegador POST /contact-messages con CSRF, campo de comprobación antispam oculto generado por el CMS, validación obligatoria de name, email y message, subject opcional y un comportamiento de éxito genérico para los envíos con el campo de comprobación relleno.
  • Notas: la sobrescritura del destinatario en el bloque tiene prioridad, después el contact_recipient_email del sitio público actual, después CONTACT_RECIPIENT_EMAIL y, por último, MAIL_FROM_ADDRESS como reserva local segura cuando no hay configurado ningún destinatario de contacto explícito.

`video`

  • Slug del bloque CMS: video
  • Campos de administración: title, content, url, media_id
  • Campos traducibles: title, content
  • Campos compartidos: url, media_id
  • Salida prevista de WebBlocks UI: <video controls> semántico para las fuentes directas, o un <iframe> de proveedor seguro únicamente para URL conocidas de YouTube/Vimeo, dentro de una carcasa wb-card simple.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: la Fase 3 da ahora a Video un formulario de administración y una vía de guardado propios, mantiene traducido el texto visible, conserva el renderizado que da prioridad a los medios alojados y recurre a un simple enlace externo para las URL desconocidas seguras en lugar de incrustarlas de forma insegura.

`audio`

  • Slug del bloque CMS: audio
  • Campos de administración: title, content, url, media_id
  • Campos traducibles: title, content
  • Campos compartidos: url, media_id
  • Salida prevista de WebBlocks UI: <audio controls> semántico dentro de una carcasa wb-card simple.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: la Fase 3 da ahora a Audio un formulario de administración y una vía de guardado propios, mantiene traducido el texto visible y suprime los controles vacíos cuando no existe una fuente utilizable.

`file`

  • Slug del bloque CMS: file
  • Campos de administración: title, content, url, media_id
  • Campos traducibles: title, content
  • Campos compartidos: url, media_id
  • Salida prevista de WebBlocks UI: una tarjeta de archivo compacta con una acción de descarga o apertura wb-btn wb-btn-secondary.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: la Fase 3 da ahora a File un formulario de administración y una vía de guardado propios, mantiene traducido el texto visible y deja explícito el contrato compartido de fuente por medios o por URL sin renderizar anclas vacías no válidas.

`map`

  • Slug del bloque CMS: map
  • Campos de administración: title, content, url
  • Campos traducibles: ninguno
  • Campos compartidos: title, content, url
  • Salida prevista de WebBlocks UI: un resumen de ubicación simple con un botón externo Open map, no un widget de mapa propio.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: mantenga la implementación centrada en el enlace mientras no exista un patrón real publicado de mapa o de incrustación.

`slider`

  • Slug del bloque CMS: slider
  • Campos de administración: recursos de galería ordenados y texto opcional
  • Campos traducibles: ninguno
  • Campos compartidos: los recursos y la estructura
  • Salida prevista de WebBlocks UI: no hay renderizador promovido en la Fase 4; utilice gallery u otros bloques de medios estructurados siempre que sea posible.
  • Implementación actual: débil
  • Notas para futuras mejoras del renderizador o de la administración: slider sigue aplazado porque no existe un patrón de carrusel de WebBlocks UI confirmado y publicado sobre el que merezca la pena estandarizar.

`code`

  • Slug del bloque CMS: code
  • Campos de administración: title, content
  • Campos traducibles: title, content
  • Campos compartidos: settings.language opcional
  • Salida prevista de WebBlocks UI: código fuente escapado dentro de un <pre><code> semántico, sin HTML inyectado y sin dependencia de resaltado de sintaxis.
  • Implementación actual: aceptable
  • Nota de mapeo de importación/sincronización: los fragmentos sin formato o de varias líneas, como los ejemplos <pre><code> y los bloques de inclusión de paquetes, deben convertirse en code y no en rich-text.
  • Notas para futuras mejoras del renderizador o de la administración: mantenga el renderizado de código seguro y sin dependencias. Los metadatos opcionales de lenguaje pueden exponerse desde los ajustes, pero un editor de código completo o una pila de resaltado de sintaxis quedan deliberadamente fuera del alcance de la Fase 3.

`toc`

  • Slug del bloque CMS: toc
  • Campos de administración: title
  • Campos traducibles: title
  • Campos compartidos: ninguno
  • Salida prevista de WebBlocks UI: un wb-link-list construido a partir de los bloques header con anclaje existentes en la misma página.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: la implementación de la Fase 3 se mantiene deliberadamente mínima. Solo se renderiza cuando los bloques Header ya exponen identificadores de anclaje explícitos y no intenta analizar encabezados complejos ni generar anclajes automáticamente.

`navigation-auto`

  • Slug del bloque CMS: navigation-auto
  • Campos de administración: navigation_menu_key
  • Campos traducibles: ninguno
  • Campos compartidos: settings.menu_key
  • Salida prevista de WebBlocks UI: una lista de navegación del sitio que use primitivas simples de nav/lista o wb-link-list cuando proceda; no simule una barra lateral de documentación salvo que el shell de la página sea realmente un shell de documentación.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: mantenga el bloque centrado en renderizar árboles de navegación y deje que el slot o el shell de la página decida si la salida es navegación de cabecera, de pie de página o de documentación.

`menu`

  • Slug del bloque CMS: menu
  • Campos de administración: navigation_menu_key
  • Campos traducibles: ninguno
  • Campos compartidos: settings.menu_key
  • Salida prevista de WebBlocks UI: la misma que navigation-auto; este bloque sigue siendo un alias heredado para los datos migrados.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: mantenga la compatibilidad con el contenido antiguo, pero prefiera navigation-auto en la experiencia de administración y en los futuros seeds.

Nota heredada / transitoria de la Fase 3

  • tabs, slider, menu y faq-list siguen siendo slugs heredados en fase de borrador dentro del catálogo del CMS, y no contratos básicos publicados.
  • showcase-list y contact-info siguen existiendo únicamente como bloques de compatibilidad de renderizado público y no se promueven al catálogo básico publicado en esta fase.
  • Esta fase documenta esas vías con honestidad, conserva el renderizado de compatibilidad allí donde ya existe y añade una sanitización segura de los enlaces públicos definidos en los ajustes, sin introducir un nuevo sistema JavaScript de pestañas o de slider.

`contact_form`

  • Slug del bloque CMS: contact_form
  • Campos de administración: heading, intro_text, submit_label, success_message, recipient_email, send_email_notification, store_submissions
  • Campos traducibles: title/heading, content/intro, submit_label, success_message
  • Campos compartidos: recipient_email, send_email_notification, store_submissions
  • Salida prevista de WebBlocks UI: los campos del formulario usan las primitivas de formulario de WebBlocks UI; la acción de envío usa wb-btn; la confirmación transitoria de éxito se muestra una sola vez como un toast de WebBlocks UI bajo el #wb-overlay-root público compartido, mientras que los errores de validación y los fallos que el usuario puede corregir permanecen en línea junto al formulario con wb-alert.
  • Implementación actual: aceptable
  • Notas para futuras mejoras del renderizador o de la administración: conserve los campos estructurados del formulario, mantenga los ajustes operativos fuera del texto editorial, guarde los destinatarios predeterminados del sitio en el registro del sitio en lugar de en un JSON arbitrario del bloque y evite que los editores tengan que pegar marcado de formulario en bruto o usar mailto: como sustituto del envío.

Bloques débiles o solo públicos

Bloque CMS Estado actual Dirección deseada Notas
card-grid solo renderizado público debería seguir siendo transitorio El renderizador ahora coincide con la misma estructura wb-grid y wb-card que columns.variant = cards, pero sigue dependiendo de settings.items. Prefiera Columns para el contenido estructurado nuevo.
showcase-list solo renderizado público debería seguir siendo fallback/personalizado Actualmente se trata de contenido sembrado específico de showcase y no debería pasar a ser básico salvo que el patrón se repita en varios sitios. Los disparadores de imagen públicos deben seguir cumpliendo el contrato de galería publicado emitiendo data-wb-gallery-target y registrando un único modal de visor compartido bajo #wb-overlay-root.
contact-info solo renderizado público debería convertirse en un bloque de primera clase Si los editores siguen usando tarjetas de metadatos de contacto, es mejor un pequeño bloque estructurado que contenido personalizado basado en ajustes. El renderizado de compatibilidad actual ignora ahora las URL inseguras de los ajustes en lugar de emitir anclas no válidas o peligrosas.
code renderizador público de primera clase aceptable El renderizado seguro con ya está implantado; las prestaciones de edición más ricas siguen siendo trabajo futuro opcional.
list renderizador público de primera clase aceptable Ya existe un renderizado de listas dedicado basado en líneas; mantenga la compatibilidad con el contenido heredado basado en ajustes.
table renderizador público de primera clase aceptable Ya existe un renderizado de tablas dedicado basado en líneas; mantenga la compatibilidad con las filas heredadas de los ajustes.
accordion renderizador público de primera clase aceptable El despliegue agrupado usa ahora semántico y bloques hijos en lugar del marcado de reserva basado en ajustes.
feature-grid alias de compatibilidad publicado debería seguir siendo transitorio El renderizador público delega en columns.variant = cards; prefiera Columns para el contenido nuevo, pero mantenga Feature Grid documentado porque está respaldado por código fuente y publicado.
stats solo alias debería fusionarse con Columns El renderizador público delega en la vía existente columns.variant = stats y debería seguir documentado como un comportamiento de alias en lugar de como un contrato publicado independiente.
metric-card alias de primera clase debería fusionarse con las primitivas de estadísticas El renderizador público usa ahora la misma orientación wb-stat que la variante stats de Columns.
logo-cloud solo fallback debería convertirse en un bloque de primera clase Promuévalo solo si existe una necesidad recurrente de filas estructuradas de logotipos o medios.
testimonial solo alias debería fusionarse con Quote El renderizador público delega en la variante testimonial de quote y debería seguir documentado como un comportamiento de alias en lugar de como un contrato publicado independiente.
timeline solo fallback debería convertirse en un bloque de primera clase Promuévalo solo con hitos estructurados y un patrón de interfaz publicado y claro.
pricing solo fallback debería convertirse en un bloque de primera clase Para que merezca la pena promover un bloque de precios, necesita campos estructurados de plan, características y CTA.
toc renderizador público de primera clase aceptable El renderizado mínimo del índice usa ahora los anclajes de Header existentes y wb-link-list; el comportamiento de sección activa sigue aplazado.
breadcrumb solo fallback debería convertirse en un bloque de primera clase Añádalo únicamente cuando el shell público realmente requiera una navegación de migas de pan.
cookie-notice solo fallback debería seguir siendo fallback/personalizado La interfaz pública de consentimiento ya vive en el shell del layout, por lo que este bloque no debería competir con el patrón de privacidad compartido.

Reglas del renderizador

  • Los renderizadores Blade deben dar preferencia a las clases wb-* publicadas.
  • No se admiten nuevas clases CSS públicas puntuales salvo que se documenten como una carencia de WebBlocks UI.
  • Nada de scripts en línea en los renderizadores de bloques.
  • Los bloques interactivos deben usar primero los data hooks publicados de WebBlocks UI.
  • El JS específico del CMS pertenece a public/cms/js solo cuando sea necesario.
  • El contenido de overlays, diálogos y modales debe usar #wb-overlay-root.
  • Los campos de administración no deben obligar a los editores a pegar HTML de WebBlocks UI en bruto para los bloques normales.
  • Siempre que sea posible, los bloques deben exponer campos estructurados y variantes, no HTML en bruto.
  • README.md debe actualizarse tras cualquier cambio relevante en el comportamiento del renderizador o de la administración.

Plan de fases

Fase 1

  • Solo documentación.
  • Establecer el contrato del renderizador.
  • Todavía sin reescritura del renderizador.

Fase 2

  • Alinear el layout público y los envoltorios de slot.
  • Asegurar que el contenido principal pueda renderizarse con wb-content-shell cuando proceda.
  • Añadir pruebas para la salida de clases del shell y de los slots.

Fase 3

  • Convertir card-grid, button-group y cualquier futuro patrón independiente de estadísticas o testimonios en bloques de primera clase solo cuando pasen a ser contratos reales propiedad del producto y no meros alias.
  • Añadir formularios de administración y soporte en el registro de traducciones donde haga falta.

Fase 3 completada: los bloques públicos básicos ya están alineados con las primitivas de WebBlocks UI.

Fase 4

  • Migrar el contenido de documentación sembrado o de demostración a bloques de primera clase.
  • Eliminar la dependencia de HTML en bruto o de settings.items allí donde exista un bloque estructurado.