Lineamientos de UI del iframe

Crowder es white-label: cada ticketera define su propia paleta y tipografía, y vos heredás ese tema visual dentro del iframe. Este documento no te prescribe colores ni fuentes — define solo el contrato del slot que se te garantiza y la geometría/forma recomendada para los componentes del iframe.

Tu iframe debe heredar el tema visual de la ticketera (paleta y tipografía) y aplicar las formas descritas acá. Para el protocolo de mensajes ver Implementación del iframe.

A. Contrato del slot

Lo que el host de Crowder en la página de la ticketera te garantiza dentro del iframe. Podés asumir estas condiciones como dadas.

Layout y dimensiones

El iframe se renderiza dentro de un contenedor .embedded-app-slot en la página de checkout/upsell. El layout padre tiene max-width: 1200px con margen lateral de 24px.

Breakpoint	Ancho del slot	Layout
Mobile (< 768px)	100% del viewport (con padding lateral 16px)	Una columna: iframe arriba, Resumen de compra como barra sticky al pie
Tablet (768–1024px)	Fluido, entre 480 y 700px	Dos columnas: iframe (flex 1) + Resumen (~340px)
Desktop (≥ 1024px)	Fluido, entre 640 y 760px	Dos columnas: iframe (flex 1) + Resumen (380px fijo). Gap 24px

Diseñá fluido

No asumas un ancho exacto. Diseñá fluido dentro de los rangos de la tabla.

Altura del iframe

El iframe es autosize: vos emitís un mensaje type: "display" con sizes.iframeHeight (px) que informa la altura de tu contenido. El host ajusta el <iframe> a ese valor, haciendo clamp con el min-height del slot. Resultado: el iframe crece según su contenido, sin scrollbar interno.

Breakpoint	min-height (piso del host)
Mobile	480px
Desktop / Tablet	560px

Si el iframeHeight reportado es menor al piso, el host mantiene el min-height. Si es mayor, el iframe crece. Emití display al montar y cada vez que tu contenido cambia de altura (típicamente con un ResizeObserver sobre document.documentElement). Para conocer el viewport en sentido inverso (host → iframe) no necesitás postMessage: leé window.innerWidth/innerHeight directamente.

Forma del iframe

El host aplica:

.embedded-app-slot__iframe {
  width: 100%;
  border: 0;
  border-radius: 12px;        /* desktop / tablet */
  background: transparent;
}

En mobile el border-radius baja a 0px (el iframe ocupa todo el ancho del viewport). Podés usar transparent en tu body para heredar el fondo del host, o pintar tu propio fondo con el token de superficie de la ticketera.

Background fijo (sin dark mode automático)

El fondo del iframe debe ser un color fijo, por defecto blanco. No lo cambies en automático con prefers-color-scheme: dark ni con ningún otro media query del sistema. Si la ticketera expone un token de superficie, usalo — pero como valor fijo, no como expresión que conmute con el modo del SO.

/* ✅ Correcto: color fijo */
body { background: #ffffff; }

/* ❌ Incorrecto: conmuta con el dark mode del SO */
@media (prefers-color-scheme: dark) {
  body { background: #111; }
}

Por qué: el host de la ticketera define su propio tema visual y el iframe tiene que verse coherente con ese tema, no con la preferencia del SO del comprador. Un iframe que se pone oscuro mientras el resto del checkout sigue claro rompe la continuidad visual.

Padding y ancho del contenido

Tu contenido debe respetar 16px de padding contra los bordes del iframe (horizontal y vertical) en todos los breakpoints. El host no inyecta padding interno: si lo omitís, el contenido queda pegado a los costados y a la parte superior/inferior (especialmente notorio en mobile, donde el iframe va sin border-radius y a ancho completo del viewport). Aplicalo al contenedor raíz del body — no a cada componente — para mantener una columna visual consistente.

body {
  padding: 16px;
}

El contenido del iframe ocupa el 100% del ancho disponible (slot menos los 16px de cada lado). El slot ya viene dimensionado por el host (entre 480 y 760px según breakpoint, ver tabla arriba), así que no agregues una max-width extra ni margin: auto para centrar la columna interna — eso deja franjas vacías a los costados y el formulario se ve angosto contra un slot ancho. El form, los inputs y el CTA deben extenderse de borde a borde del padding.

Lo que Crowder NO inyecta dentro del iframe

• Sin header ni navbar de Crowder (el breadcrumb del evento vive en el host, arriba del slot).
• Sin loading propio durante submit. Apenas Crowder dispara submit, el host pone el botón Continuar en estado de loading y bloquea visualmente la transición. El iframe no debe renderizar su propio spinner global ni overlay con loader — alcanza con deshabilitar inputs/botones para evitar edición concurrente (ver Implementación del iframe).
• Sin disclaimer legal dentro del iframe — el texto que aclara al comprador que el producto adicional lo ofrece y administra un tercero (“Estos productos son ofrecidos y administrados por…”) lo renderiza Crowder fuera del iframe. No lo repitas adentro.
• Sin paleta ni fuentes propias de Crowder. Tu iframe hereda del tema de la ticketera.
• Sin CSS reset compartido.

Lo que el iframe NO debe renderizar (lo pone el host)

Estos elementos viven fuera del iframe. Replicarlos adentro es un error: el usuario ve el mismo contenido dos veces y el flujo se rompe.

• Título y subtítulo de la sección. El host imprime el nombre del bloque (ej. “Add-ons”) y su descripción corta (“Productos opcionales para tu experiencia”) arriba del iframe. No rendericés tu propio H1/H2 con el mismo concepto adentro.
• Footer con sumatorio, total acumulado y botón “Continuar”. El total, el estado del carrito (“Ready to continue”) y el CTA que avanza al siguiente paso los renderiza el host (barra sticky en mobile, columna lateral en desktop). El iframe no debe incluir un footer con totales ni un botón propio para avanzar de paso — para avanzar usá el handshake submit / submitted documentado en Implementación del iframe.

B. Lineamientos de forma

Esta sección es recomendación, no requisito de protocolo. Define la geometría sin tocar color ni tipografía.

Principios

1. Color y tipografía los provee la ticketera. Consumí los tokens visuales que la ticketera expone. Si no expone un token específico, usá currentColor, inherit o variables CSS con fallbacks neutrales.
2. La forma es responsabilidad tuya y debe seguir esta guía para mantener consistencia con el resto del flujo de checkout.
3. No reproduzcas branding de Crowder dentro del iframe. El iframe es tuyo y viste el tema de la ticketera.

Geometría de componentes

Componente	border-radius	Notas
Cards de contexto y agrupadoras	8px	Borde izquierdo destacado de 3px solid (color primario del tema)
Sub-cards (ej. ítem de ticket)	8px	Borde 1px en color de borde del tema, padding 12px 16px
Cards de producto (grilla de shop)	4px	overflow: hidden para que la imagen respete el radio
Chips de filtro de categoría	8px	Padding 12px 20px, diferenciación por fondo
Rows de selección (lista)	4px	Separadas por border-bottom: 1px solid
Badges de tipo / tarifa	4px	Padding 2px 8px, tipografía pequeña
Botón primario (CTA)	6px	Altura 48px
Stepper numérico (— 0 +)	3px	Altura 50px
Modal / dialog	6px	—
Inputs / fields	0 (sin redondeo)	Underline-only: border-bottom: 1px solid, sin borde lateral ni superior, fondo transparente, height: 40px. Ver tab Inputs y formularios

Tipografía de descripciones e identificadores

Regla simple: sans para prosa, mono solo para identificadores opacos.

Tipo de contenido	Clase / spec	Cuándo
Descripción / texto explicativo	text-sm text-muted-foreground (sans)	Prosa que el comprador lee — descripciones de items, ayudas, leyendas
Metadata legible del item	text-xs text-muted-foreground (sans)	Palabras de dominio: sector, tarifa, fila, asiento, categoría
Identificadores opacos	text-xs font-mono	Cadenas que el ojo necesita alinear o comparar carácter a carácter: UUID, short codes, número de orden, hash

Por qué: el monoespaciado aporta legibilidad técnica solo cuando hay caracteres a alinear o comparar. Para palabras de dominio (sector A, fila 12, Platea VIP) el mono se ve “técnico” sin razón y rompe la coherencia con el resto del item. Reservalo para los IDs reales.

Patrones por componente

Cards de contexto

Las cards que muestran información de contexto usan un borde izquierdo de 3px que indica el tipo de bloque:

• Contexto provisto por Crowder (evento, tickets recibidos): color primario del tema.
• Tu propia respuesta (ítems seleccionados): color de éxito del tema.

Resto de la card: border-radius: 8px, padding 20px, fondo en color de superficie del tema.

Tabs

Tabs de texto plano con indicador de línea inferior. Sin fondo, sin border-radius.

• Altura de fila: ~44px
• Tab activo: border-bottom: 2px solid (color primario del tema)
• Tab inactivo: sin borde
• Separador inferior del bloque: border-bottom: 1px solid (color de borde del tema)
• Padding por tab: 8px 0px, margin-right: 24px

Botón primario

• border-radius: 6px, altura 48px
• Tipografía: font-size: 0.875rem (14px relativo al body), font-weight: 600, line-height: 1, letter-spacing: 0 — heredando la font-family del tema. No subir a 1rem: con altura 48px el texto a 16px se ve sobredimensionado contra el resto del cuerpo.
• Padding horizontal: 16px mínimo. El botón es width: auto por defecto — no estires al 100% del ancho salvo en mobile angosto (menos de 480px).
• Estado habilitado: fondo primario, texto sobre primario
• Estado deshabilitado: opacity: 0.5, sin cambio de forma
• Foco: outline: 2px solid (color primario del tema), outline-offset: 2px
• En el iframe el CTA suele alinearse a la derecha y ocupar ~50% del ancho

Stepper

Para selección de cantidades (— · 0 · +).

• Altura 50px, border-radius: 3px
• Botones laterales del mismo alto, separación con borde 1px

Cards de producto

Grilla de 2 columnas. Cada card:

• border-radius: 4px, overflow: hidden
• Imagen en la mitad superior (proporción 16:9 o cuadrada)
• Label de categoría en metadata (uppercase pequeño)
• Nombre del producto
• Precio + stepper alineados al pie de la card

Inputs y formularios

Crowder es la plataforma padre. Cualquier formulario embebido (iframe, partner forms, integraciones) adapta su forma visual a este sistema. Los colores quedan excluidos — son parte de la customización white-label de cada ticketera.

Tipografía del sistema de formularios

El iframe nunca fija font-size en px para campos, labels, helpers o botones — todos los tamaños se expresan en rem/em heredando del body que define la ticketera. Así un partner con body en 14px y otro en 16px mantienen las mismas proporciones internas.

Elemento	font-size	line-height	Otras
Valor del input / select / textarea	0.875rem (heredado del body)	1.4	font-weight: normal
Floating label (idle)	0.875rem	1.4	mismo tamaño que el valor
Floating label (activo)	~0.74rem (vía scale(0.85))	—	ver patrón abajo
Helper text / error debajo del campo	0.75rem	1.3	—
CTA del formulario	0.875rem	1	font-weight: 600 (ver tab Botón primario)

El input y el CTA quedan al mismo tamaño (0.875rem): el peso 600 y la altura 48px diferencian al botón sin agrandar el texto. Nunca subir el valor del input a 1rem — a 16px se ve sobredimensionado contra el resto del cuerpo del checkout.

En mobile el host garantiza body ≥ 16px para evitar el auto-zoom de iOS — el iframe no necesita aplicar un mínimo propio en los inputs.

Input de texto

• border-bottom: 1px solid (único borde — sin borde superior, izquierdo ni derecho)
• border-radius: 0
• background-color: transparent
• height: 40px, margin: 0
• font-size: 0.875rem, line-height: 1.4, font-weight: normal — relativo al body del host, sin override en px

Select / dropdown

• Mismas reglas que el input de texto (underline, sin borde lateral, sin redondeo)
• El chevron de expansión es el único elemento diferenciador permitido

Wrapper de campo

• position: relative (requerido por el floating label)
• margin-bottom: 40px
• Sin borde, sin fondo, sin redondeo

Floating label

Patrón floating label: la etiqueta vive dentro del campo y se eleva al recibir foco o cuando el campo tiene contenido. No se usan labels fijas por encima del campo.

• Estado por defecto: position: absolute; top: 20px; font-size: 1rem; opacity: 0.5 (mismo tamaño que el valor del input)
• Estado activo (focus o con valor): transform: translate(0, -30px) scale(0.75); opacity: 0.5 (queda en ~0.75rem efectivos)
• Transición: transform 0.25s, opacity 0.25s ease-in-out

Estados del campo

• Focus o con valor: border-color del underline cambia al color de marca del tema — ese cambio es el indicador de foco, no el outline default del browser
• Inválido / error: border-color en color de error del tema
• Reseteá el outline default (outline: 0; box-shadow: 0) — el cambio de border-color cubre el requisito de foco visible de la sección D, siempre que el contraste con el fondo cumpla WCAG AA

Radio buttons y checkboxes

• Radio o checkbox simple, alineado con el texto
• Sin contenedor con borde alrededor de cada opción (no se usa el patrón “card-option”)
• El patrón Rows de selección (ver tab correspondiente) es distinto: lista de opciones con ícono + texto + precio + chevron. No es un control de formulario, es una lista navegable, y mantiene sus separadores y borde de selección.

Botón primario (CTA) del formulario

Aplica todo lo del tab Botón primario (filled, border-radius: 6px, altura 48px). El refuerzo específico para formularios: el CTA outlined sin fill no está permitido como acción primaria. border-radius: 6px en el CTA es el único radio admitido dentro del sistema de formularios — todo el resto (input, select, wrapper) va sin redondeo.

Rows de selección

Lista vertical de opciones (ej. método de entrega, planes de seguro).

• border-radius: 4px, padding 30px 20px
• Ícono / radio a la izquierda (~50×50px), texto al centro, precio + chevron › a la derecha
• Separadas por border-bottom: 1px solid (color de borde del tema)
• Opción seleccionada: border-left: 3px solid (color primario del tema)

C. Formato de moneda

El context te llega con currency como código ISO 4217 (ARS, PEN, USD, BRL, etc.) y los price como number con hasta 2 decimales. No muestres el código crudo ni 15000.5 sin formatear: el iframe tiene que renderizar el monto con el símbolo, los separadores y los decimales que el usuario de esa plaza espera ver.

La forma simple y correcta de hacerlo es delegar en el browser:

format-money.js

const formatMoney = (amount, currency, locale) =>
  new Intl.NumberFormat(locale, {
    style: 'currency',
    currency, // 'PEN', 'ARS', 'USD'...
  }).format(amount);

// formatMoney(15000.5, 'PEN', 'es-PE') → "S/ 15,000.50"
// formatMoney(15000.5, 'ARS', 'es-AR') → "$ 15.000,50"
// formatMoney(15000,   'CLP', 'es-CL') → "$ 15.000"

Usá el locale del context para que separadores y posición del símbolo respeten la convención local. Si tenés que mostrar un monto antes de recibir el context, mostrá un skeleton — no inventes un símbolo.

Tabla de referencia

Símbolo y decimales esperados por moneda. La columna Decimales es el minimumFractionDigits / maximumFractionDigits que debe ver el usuario (no la precisión del number que llega por el wire).

currency	País	Símbolo	Decimales	Ejemplo (15000.5)
ARS	Argentina	$	2	$ 15.000,50
BOB	Bolivia	Bs	2	Bs 15.000,50
BRL	Brasil	R$	2	R$ 15.000,50
CLP	Chile	$	0	$ 15.001
COP	Colombia	$	0	$ 15.001
USD	Ecuador	US$ / $	2	US$ 15,000.50
EUR	Guayana Francesa	€	2	15.000,50 €
GYD	Guyana	G$	0	G$ 15.001
PYG	Paraguay	₲	0	₲ 15.001
PEN	Perú	S/	2	S/ 15,000.50
SRD	Surinam	$	2	$ 15.000,50
UYU	Uruguay	$U	2	$U 15.000,50
VES	Venezuela	Bs.	2	Bs. 15.000,50

Monedas sin decimales

CLP, COP, PYG y GYD no usan centavos en la práctica comercial. Si te llega un price con decimales en una de estas monedas, redondeá al entero más cercano para mostrarlo (Intl.NumberFormat ya lo hace por defecto con style: 'currency').

Coherencia con el resumen del host

El resumen de compra (a la izquierda del iframe) usa el mismo formateo. Si tu iframe muestra S/ 15,000.50 y el resumen muestra PEN 15000.5, asumí que es un bug — abrí un issue con la moneda y el locale.

D. Accesibilidad

• Foco visible en todos los interactivos: :focus-visible con outline de 2px y outline-offset: 2px.
• Targets táctiles ≥ 44×44px en mobile.
• prefers-reduced-motion: reduce debe deshabilitar animaciones no esenciales.
• Idioma del contenido alineado al locale del payload.
• Contraste: sos responsable de respetar WCAG AA al aplicar la paleta de la ticketera (texto 4.5:1, componentes 3:1).

Qué NO hacer

Anti-patrones

• Definir paleta de color o tipografía propias dentro del iframe (heredá del tema de la ticketera).
• Cambiar el background del iframe en automático con prefers-color-scheme: dark — el fondo es fijo, por defecto blanco.
• Reproducir branding o logos de Crowder dentro del iframe.
• Renderizar un header/navbar propio dentro del iframe.
• Mostrar un spinner u overlay con loader propio durante submit — el loading del Continuar lo renderiza el host. Bloqueá la edición (inputs/botones disabled), pero no agregues indicador de carga visible.
• Omitir el padding de 16px del contenido (horizontal y vertical) — sin él, el contenido queda pegado a los bordes del iframe (sobre todo en mobile).
• Repetir el nombre del evento o el breadcrumb (ya viven en el host).
• Renderizar un título o subtítulo de sección propio (ej. “Add-ons / Productos opcionales…”) — el host ya los imprime arriba del iframe.
• Renderizar un footer con sumatorio, total acumulado o botón “Continuar” dentro del iframe — esa barra es del host. Para avanzar de paso usá el handshake submit / submitted.
• Incluir el disclaimer legal “ofrecidos y administrados por…” dentro del iframe (lo pone Crowder afuera).
• Abrir modales que excedan el área del iframe — usar paneles o acordeones internos.
• Asumir un ancho fijo (ej. 707px). Diseñá fluido dentro de los rangos del contrato.
• Aplicar una max-width interna ni margin: auto para centrar el contenido dentro del iframe — el slot ya viene dimensionado por el host, una restricción extra deja franjas vacías a los costados (el form se ve angosto contra un slot ancho). El contenido ocupa el 100% del ancho menos los 16px de padding.
• Omitir el type: "display" inicial: si el iframe no reporta su altura, el host queda en el min-height del slot.
• Re-emitir display en cada frame: usá ResizeObserver (no setInterval) y emití solo cuando la altura realmente cambia.
• Poner borde en los cuatro lados de un input o border-radius en inputs/selects — el sistema es underline-only.
• Usar labels fijas encima del campo en lugar del patrón floating label.
• Envolver opciones de radio/checkbox dentro de cards con borde (no se usa el patrón “card-option”).
• Renderizar el CTA principal del formulario como outlined sin fill.
• Inputs con height mayor a 40px.
• Fijar font-size en px para inputs, labels, helpers o botones — el sistema corre en rem/em heredando del body de la ticketera.
• Renderizar el CTA del formulario con font-size: 1rem o mayor — el botón usa 0.875rem para no sobredimensionarse contra los 48px de altura.
• Estirar el CTA al 100% del ancho fuera de mobile angosto — el botón es width: auto (~50% del ancho del iframe en desktop).