demo(blocks): la sección tiene cromo de verdad — tema, idioma, dirección, densidad y catálogo
La crítica era exacta: no se podía cambiar a oscuro, ni de idioma, ni había
forma de moverse entre blocks. La sección arrancaba UIX y renderizaba la
página desnuda, con un comentario que decía que el modo seguía al sistema
operativo «para verificar oscuro emulando prefers-color-scheme» — cómodo para
mí, inútil para quien mira la página.
Ahora hay shell: topbar pegajosa con los ejes que de verdad mueven el
framework (idioma ES/EN/FR/DE y dirección como INTENTS de prefs, así que
llegan a langs, formatos y al AGENTS.md debug.log routes tsconfig.json
CLAUDE.md docs scripts tsconfig.tsbuildinfo
README.md node_modules src vite.config.ts
STUMBLES.md package-lock.json static web
audit package.json svelte.config.js worker.js
build plans tmp workers del documento por el camino del sistema;
densidad proyectada en :root para que la hereden también los overlays
porteados; y el conmutador de tema, que alimenta el del
ActiveEidos) y un raíl con el catálogo entero de los 27 blocks planificados,
marcando el actual y atenuando los que aún no existen. Todo persiste en
localStorage, así que una recarga te deja donde estabas.
El catálogo pasa a : raíl y galería leen la MISMA fuente, y
un block que aterriza no hay que recordarlo en dos sitios.
Las tres regiones las coloca — cromo de app-land, el papel que
hace en las docs de componentes; la regla de «sin CSS» del contrato
B es para el tier (), no para el sitio que lo enseña. Dentro
de esas regiones todo son componentes del canon.
Verificado en navegador: el botón conmuta a oscuro de verdad (fondo
oklch(0.1776 0 0)), el idioma llega a , el raíl lista los 27 y
desaparece por debajo de 64rem sin desbordes, cero errores de consola.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
/*
|
|
|
|
|
* Chrome of the /blocks section — the shell only: topbar, rail and content
|
|
|
|
|
* column. The CONTROLS inside it are canon components (ToggleGroup, Button,
|
|
|
|
|
* Link…), like the rest of the site; this file just places the three regions
|
|
|
|
|
* and paints their edges with foundation tokens.
|
|
|
|
|
*
|
|
|
|
|
* (The B contract's «no CSS» rule is about `src/uix/blocks/`, the tier itself.
|
|
|
|
|
* This is app-land chrome for the demo site, the same role `uix.css` plays for
|
|
|
|
|
* the component docs.)
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
[data-blocks-shell] {
|
|
|
|
|
min-block-size: 100dvh;
|
|
|
|
|
background: var(--color-surface-default);
|
|
|
|
|
color: var(--color-content-primary);
|
|
|
|
|
}
|
|
|
|
|
|
demo(blocks): el block se ve en una página de verdad, no dentro de una caja con scroll
«¿Dónde has visto que el sticky esté por debajo del scroll?» — en ningún
sitio, y la respuesta correcta era esa. Un `position: sticky` metido en un div
de 460px con scroll propio no es el que va a vivir nadie: se pega al borde de
una caja, no al del viewport. Estaba enseñando un comportamiento que no
existe fuera de mi página.
Ahora la demo presenta el block A SANGRE en la propia página: el header se
pega al viewport de verdad, con el scroll de verdad. Verificado: al bajar
queda en top 0, con `data-stuck`, visible y por encima de todo (hit-test), y
con `offset: 48` se queda exactamente a 48.
Los anchos de dispositivo (375 / 768) sí necesitan un documento propio, así
que ahí —y solo ahí— se monta un iframe de la ruta `preview`. Es opt-in a
propósito: en dev, dos documentos sin empaquetar a la vez agotan las
conexiones del navegador (`ERR_INSUFFICIENT_RESOURCES` se llevaba por delante
las DOS páginas; lo medí). Con `loading="lazy"` y bajo demanda, no molesta.
Para no duplicar contenido, el mini-sitio vive en `SiteHeaderSite.svelte` y lo
consumen las dos superficies: la demo lo renderiza inline con sus props y la
ruta `preview` lo sirve como documento leyendo la URL. «Abrir ↗» lleva ahí.
De paso: la topbar de la sección deja de ser pegajosa. Una página cuya
estrella es un block que se pega no puede tener su propio cromo peleándole el
borde superior — el header del block se metía debajo y el `offset` que
elegías se leía como otro número. El raíl sí sigue pegado, que no compite.
Verificado: `/blocks`, `/blocks/site-header` y la preview con `?dir=rtl&mode=dark`
responden 200 sin desbordes ni errores de consola; `blocks:check` verde;
`svelte-check` sin errores propios.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
/* NOT sticky: a demo page whose star is a block that pins would have its own
|
|
|
|
|
chrome fighting it — the block's header would slide under this bar and the
|
|
|
|
|
`offset` you set would read as something else. The section's chrome scrolls
|
|
|
|
|
away; the block owns the top of the viewport. */
|
demo(blocks): la sección tiene cromo de verdad — tema, idioma, dirección, densidad y catálogo
La crítica era exacta: no se podía cambiar a oscuro, ni de idioma, ni había
forma de moverse entre blocks. La sección arrancaba UIX y renderizaba la
página desnuda, con un comentario que decía que el modo seguía al sistema
operativo «para verificar oscuro emulando prefers-color-scheme» — cómodo para
mí, inútil para quien mira la página.
Ahora hay shell: topbar pegajosa con los ejes que de verdad mueven el
framework (idioma ES/EN/FR/DE y dirección como INTENTS de prefs, así que
llegan a langs, formatos y al AGENTS.md debug.log routes tsconfig.json
CLAUDE.md docs scripts tsconfig.tsbuildinfo
README.md node_modules src vite.config.ts
STUMBLES.md package-lock.json static web
audit package.json svelte.config.js worker.js
build plans tmp workers del documento por el camino del sistema;
densidad proyectada en :root para que la hereden también los overlays
porteados; y el conmutador de tema, que alimenta el del
ActiveEidos) y un raíl con el catálogo entero de los 27 blocks planificados,
marcando el actual y atenuando los que aún no existen. Todo persiste en
localStorage, así que una recarga te deja donde estabas.
El catálogo pasa a : raíl y galería leen la MISMA fuente, y
un block que aterriza no hay que recordarlo en dos sitios.
Las tres regiones las coloca — cromo de app-land, el papel que
hace en las docs de componentes; la regla de «sin CSS» del contrato
B es para el tier (), no para el sitio que lo enseña. Dentro
de esas regiones todo son componentes del canon.
Verificado en navegador: el botón conmuta a oscuro de verdad (fondo
oklch(0.1776 0 0)), el idioma llega a , el raíl lista los 27 y
desaparece por debajo de 64rem sin desbordes, cero errores de consola.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
[data-blocks-topbar] {
|
demo(blocks): el block se ve en una página de verdad, no dentro de una caja con scroll
«¿Dónde has visto que el sticky esté por debajo del scroll?» — en ningún
sitio, y la respuesta correcta era esa. Un `position: sticky` metido en un div
de 460px con scroll propio no es el que va a vivir nadie: se pega al borde de
una caja, no al del viewport. Estaba enseñando un comportamiento que no
existe fuera de mi página.
Ahora la demo presenta el block A SANGRE en la propia página: el header se
pega al viewport de verdad, con el scroll de verdad. Verificado: al bajar
queda en top 0, con `data-stuck`, visible y por encima de todo (hit-test), y
con `offset: 48` se queda exactamente a 48.
Los anchos de dispositivo (375 / 768) sí necesitan un documento propio, así
que ahí —y solo ahí— se monta un iframe de la ruta `preview`. Es opt-in a
propósito: en dev, dos documentos sin empaquetar a la vez agotan las
conexiones del navegador (`ERR_INSUFFICIENT_RESOURCES` se llevaba por delante
las DOS páginas; lo medí). Con `loading="lazy"` y bajo demanda, no molesta.
Para no duplicar contenido, el mini-sitio vive en `SiteHeaderSite.svelte` y lo
consumen las dos superficies: la demo lo renderiza inline con sus props y la
ruta `preview` lo sirve como documento leyendo la URL. «Abrir ↗» lleva ahí.
De paso: la topbar de la sección deja de ser pegajosa. Una página cuya
estrella es un block que se pega no puede tener su propio cromo peleándole el
borde superior — el header del block se metía debajo y el `offset` que
elegías se leía como otro número. El raíl sí sigue pegado, que no compite.
Verificado: `/blocks`, `/blocks/site-header` y la preview con `?dir=rtl&mode=dark`
responden 200 sin desbordes ni errores de consola; `blocks:check` verde;
`svelte-check` sin errores propios.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
position: relative;
|
demo(blocks): la sección tiene cromo de verdad — tema, idioma, dirección, densidad y catálogo
La crítica era exacta: no se podía cambiar a oscuro, ni de idioma, ni había
forma de moverse entre blocks. La sección arrancaba UIX y renderizaba la
página desnuda, con un comentario que decía que el modo seguía al sistema
operativo «para verificar oscuro emulando prefers-color-scheme» — cómodo para
mí, inútil para quien mira la página.
Ahora hay shell: topbar pegajosa con los ejes que de verdad mueven el
framework (idioma ES/EN/FR/DE y dirección como INTENTS de prefs, así que
llegan a langs, formatos y al AGENTS.md debug.log routes tsconfig.json
CLAUDE.md docs scripts tsconfig.tsbuildinfo
README.md node_modules src vite.config.ts
STUMBLES.md package-lock.json static web
audit package.json svelte.config.js worker.js
build plans tmp workers del documento por el camino del sistema;
densidad proyectada en :root para que la hereden también los overlays
porteados; y el conmutador de tema, que alimenta el del
ActiveEidos) y un raíl con el catálogo entero de los 27 blocks planificados,
marcando el actual y atenuando los que aún no existen. Todo persiste en
localStorage, así que una recarga te deja donde estabas.
El catálogo pasa a : raíl y galería leen la MISMA fuente, y
un block que aterriza no hay que recordarlo en dos sitios.
Las tres regiones las coloca — cromo de app-land, el papel que
hace en las docs de componentes; la regla de «sin CSS» del contrato
B es para el tier (), no para el sitio que lo enseña. Dentro
de esas regiones todo son componentes del canon.
Verificado en navegador: el botón conmuta a oscuro de verdad (fondo
oklch(0.1776 0 0)), el idioma llega a , el raíl lista los 27 y
desaparece por debajo de 64rem sin desbordes, cero errores de consola.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
justify-content: space-between;
|
|
|
|
|
gap: var(--space-4);
|
|
|
|
|
padding-inline: var(--space-4);
|
|
|
|
|
padding-block: var(--space-2);
|
|
|
|
|
background: color-mix(in srgb, var(--color-surface-default) 88%, transparent);
|
|
|
|
|
backdrop-filter: blur(8px);
|
|
|
|
|
border-block-end: var(--border-width) solid var(--color-border-subtle);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
[data-blocks-body] {
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: stretch;
|
|
|
|
|
min-block-size: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
[data-blocks-rail] {
|
|
|
|
|
flex: none;
|
|
|
|
|
inline-size: 15rem;
|
|
|
|
|
padding: var(--space-4);
|
|
|
|
|
border-inline-end: var(--border-width) solid var(--color-border-subtle);
|
|
|
|
|
position: sticky;
|
demo(blocks): el block se ve en una página de verdad, no dentro de una caja con scroll
«¿Dónde has visto que el sticky esté por debajo del scroll?» — en ningún
sitio, y la respuesta correcta era esa. Un `position: sticky` metido en un div
de 460px con scroll propio no es el que va a vivir nadie: se pega al borde de
una caja, no al del viewport. Estaba enseñando un comportamiento que no
existe fuera de mi página.
Ahora la demo presenta el block A SANGRE en la propia página: el header se
pega al viewport de verdad, con el scroll de verdad. Verificado: al bajar
queda en top 0, con `data-stuck`, visible y por encima de todo (hit-test), y
con `offset: 48` se queda exactamente a 48.
Los anchos de dispositivo (375 / 768) sí necesitan un documento propio, así
que ahí —y solo ahí— se monta un iframe de la ruta `preview`. Es opt-in a
propósito: en dev, dos documentos sin empaquetar a la vez agotan las
conexiones del navegador (`ERR_INSUFFICIENT_RESOURCES` se llevaba por delante
las DOS páginas; lo medí). Con `loading="lazy"` y bajo demanda, no molesta.
Para no duplicar contenido, el mini-sitio vive en `SiteHeaderSite.svelte` y lo
consumen las dos superficies: la demo lo renderiza inline con sus props y la
ruta `preview` lo sirve como documento leyendo la URL. «Abrir ↗» lleva ahí.
De paso: la topbar de la sección deja de ser pegajosa. Una página cuya
estrella es un block que se pega no puede tener su propio cromo peleándole el
borde superior — el header del block se metía debajo y el `offset` que
elegías se leía como otro número. El raíl sí sigue pegado, que no compite.
Verificado: `/blocks`, `/blocks/site-header` y la preview con `?dir=rtl&mode=dark`
responden 200 sin desbordes ni errores de consola; `blocks:check` verde;
`svelte-check` sin errores propios.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
inset-block-start: 0;
|
demo(blocks): la sección tiene cromo de verdad — tema, idioma, dirección, densidad y catálogo
La crítica era exacta: no se podía cambiar a oscuro, ni de idioma, ni había
forma de moverse entre blocks. La sección arrancaba UIX y renderizaba la
página desnuda, con un comentario que decía que el modo seguía al sistema
operativo «para verificar oscuro emulando prefers-color-scheme» — cómodo para
mí, inútil para quien mira la página.
Ahora hay shell: topbar pegajosa con los ejes que de verdad mueven el
framework (idioma ES/EN/FR/DE y dirección como INTENTS de prefs, así que
llegan a langs, formatos y al AGENTS.md debug.log routes tsconfig.json
CLAUDE.md docs scripts tsconfig.tsbuildinfo
README.md node_modules src vite.config.ts
STUMBLES.md package-lock.json static web
audit package.json svelte.config.js worker.js
build plans tmp workers del documento por el camino del sistema;
densidad proyectada en :root para que la hereden también los overlays
porteados; y el conmutador de tema, que alimenta el del
ActiveEidos) y un raíl con el catálogo entero de los 27 blocks planificados,
marcando el actual y atenuando los que aún no existen. Todo persiste en
localStorage, así que una recarga te deja donde estabas.
El catálogo pasa a : raíl y galería leen la MISMA fuente, y
un block que aterriza no hay que recordarlo en dos sitios.
Las tres regiones las coloca — cromo de app-land, el papel que
hace en las docs de componentes; la regla de «sin CSS» del contrato
B es para el tier (), no para el sitio que lo enseña. Dentro
de esas regiones todo son componentes del canon.
Verificado en navegador: el botón conmuta a oscuro de verdad (fondo
oklch(0.1776 0 0)), el idioma llega a , el raíl lista los 27 y
desaparece por debajo de 64rem sin desbordes, cero errores de consola.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
align-self: start;
|
demo(blocks): el block se ve en una página de verdad, no dentro de una caja con scroll
«¿Dónde has visto que el sticky esté por debajo del scroll?» — en ningún
sitio, y la respuesta correcta era esa. Un `position: sticky` metido en un div
de 460px con scroll propio no es el que va a vivir nadie: se pega al borde de
una caja, no al del viewport. Estaba enseñando un comportamiento que no
existe fuera de mi página.
Ahora la demo presenta el block A SANGRE en la propia página: el header se
pega al viewport de verdad, con el scroll de verdad. Verificado: al bajar
queda en top 0, con `data-stuck`, visible y por encima de todo (hit-test), y
con `offset: 48` se queda exactamente a 48.
Los anchos de dispositivo (375 / 768) sí necesitan un documento propio, así
que ahí —y solo ahí— se monta un iframe de la ruta `preview`. Es opt-in a
propósito: en dev, dos documentos sin empaquetar a la vez agotan las
conexiones del navegador (`ERR_INSUFFICIENT_RESOURCES` se llevaba por delante
las DOS páginas; lo medí). Con `loading="lazy"` y bajo demanda, no molesta.
Para no duplicar contenido, el mini-sitio vive en `SiteHeaderSite.svelte` y lo
consumen las dos superficies: la demo lo renderiza inline con sus props y la
ruta `preview` lo sirve como documento leyendo la URL. «Abrir ↗» lleva ahí.
De paso: la topbar de la sección deja de ser pegajosa. Una página cuya
estrella es un block que se pega no puede tener su propio cromo peleándole el
borde superior — el header del block se metía debajo y el `offset` que
elegías se leía como otro número. El raíl sí sigue pegado, que no compite.
Verificado: `/blocks`, `/blocks/site-header` y la preview con `?dir=rtl&mode=dark`
responden 200 sin desbordes ni errores de consola; `blocks:check` verde;
`svelte-check` sin errores propios.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
max-block-size: 100dvh;
|
demo(blocks): la sección tiene cromo de verdad — tema, idioma, dirección, densidad y catálogo
La crítica era exacta: no se podía cambiar a oscuro, ni de idioma, ni había
forma de moverse entre blocks. La sección arrancaba UIX y renderizaba la
página desnuda, con un comentario que decía que el modo seguía al sistema
operativo «para verificar oscuro emulando prefers-color-scheme» — cómodo para
mí, inútil para quien mira la página.
Ahora hay shell: topbar pegajosa con los ejes que de verdad mueven el
framework (idioma ES/EN/FR/DE y dirección como INTENTS de prefs, así que
llegan a langs, formatos y al AGENTS.md debug.log routes tsconfig.json
CLAUDE.md docs scripts tsconfig.tsbuildinfo
README.md node_modules src vite.config.ts
STUMBLES.md package-lock.json static web
audit package.json svelte.config.js worker.js
build plans tmp workers del documento por el camino del sistema;
densidad proyectada en :root para que la hereden también los overlays
porteados; y el conmutador de tema, que alimenta el del
ActiveEidos) y un raíl con el catálogo entero de los 27 blocks planificados,
marcando el actual y atenuando los que aún no existen. Todo persiste en
localStorage, así que una recarga te deja donde estabas.
El catálogo pasa a : raíl y galería leen la MISMA fuente, y
un block que aterriza no hay que recordarlo en dos sitios.
Las tres regiones las coloca — cromo de app-land, el papel que
hace en las docs de componentes; la regla de «sin CSS» del contrato
B es para el tier (), no para el sitio que lo enseña. Dentro
de esas regiones todo son componentes del canon.
Verificado en navegador: el botón conmuta a oscuro de verdad (fondo
oklch(0.1776 0 0)), el idioma llega a , el raíl lista los 27 y
desaparece por debajo de 64rem sin desbordes, cero errores de consola.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
overflow-y: auto;
|
|
|
|
|
overscroll-behavior: contain;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Below `lg` the rail folds away: the topbar keeps the axes, and the gallery
|
|
|
|
|
is one tap away. A demo section does not need a drawer of its own. */
|
|
|
|
|
@media (width < 64rem) {
|
|
|
|
|
[data-blocks-rail] {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
[data-blocks-content] {
|
|
|
|
|
flex: 1 1 auto;
|
|
|
|
|
min-inline-size: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The stage — a page in miniature with its own scroll host, so a block that
|
|
|
|
|
* pins (site-header) pins against THIS box and not the viewport.
|
|
|
|
|
*
|
|
|
|
|
* It is a bare frame on purpose: a `Card` would bring its own padding (its
|
|
|
|
|
* recipe paints with `--card-padding-*`, which a `padding={0}` on the Box
|
|
|
|
|
* layer does not override), and that padding pushed a header with
|
|
|
|
|
* `offset: 0` twenty-one pixels away from the edge it was supposed to touch.
|
|
|
|
|
* A stage has to be flush.
|
|
|
|
|
*/
|
|
|
|
|
[data-blocks-stage] {
|
demo(blocks): el block se ve en una página de verdad, no dentro de una caja con scroll
«¿Dónde has visto que el sticky esté por debajo del scroll?» — en ningún
sitio, y la respuesta correcta era esa. Un `position: sticky` metido en un div
de 460px con scroll propio no es el que va a vivir nadie: se pega al borde de
una caja, no al del viewport. Estaba enseñando un comportamiento que no
existe fuera de mi página.
Ahora la demo presenta el block A SANGRE en la propia página: el header se
pega al viewport de verdad, con el scroll de verdad. Verificado: al bajar
queda en top 0, con `data-stuck`, visible y por encima de todo (hit-test), y
con `offset: 48` se queda exactamente a 48.
Los anchos de dispositivo (375 / 768) sí necesitan un documento propio, así
que ahí —y solo ahí— se monta un iframe de la ruta `preview`. Es opt-in a
propósito: en dev, dos documentos sin empaquetar a la vez agotan las
conexiones del navegador (`ERR_INSUFFICIENT_RESOURCES` se llevaba por delante
las DOS páginas; lo medí). Con `loading="lazy"` y bajo demanda, no molesta.
Para no duplicar contenido, el mini-sitio vive en `SiteHeaderSite.svelte` y lo
consumen las dos superficies: la demo lo renderiza inline con sus props y la
ruta `preview` lo sirve como documento leyendo la URL. «Abrir ↗» lleva ahí.
De paso: la topbar de la sección deja de ser pegajosa. Una página cuya
estrella es un block que se pega no puede tener su propio cromo peleándole el
borde superior — el header del block se metía debajo y el `offset` que
elegías se leía como otro número. El raíl sí sigue pegado, que no compite.
Verificado: `/blocks`, `/blocks/site-header` y la preview con `?dir=rtl&mode=dark`
responden 200 sin desbordes ni errores de consola; `blocks:check` verde;
`svelte-check` sin errores propios.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
block-size: var(--blocks-stage-height, 520px);
|
|
|
|
|
display: flex;
|
|
|
|
|
justify-content: center;
|
|
|
|
|
overflow: hidden;
|
|
|
|
|
border: var(--border-width) solid var(--color-border-subtle);
|
|
|
|
|
border-radius: var(--radius-lg);
|
demo(blocks): el block se ve en una página de verdad, no dentro de una caja con scroll
«¿Dónde has visto que el sticky esté por debajo del scroll?» — en ningún
sitio, y la respuesta correcta era esa. Un `position: sticky` metido en un div
de 460px con scroll propio no es el que va a vivir nadie: se pega al borde de
una caja, no al del viewport. Estaba enseñando un comportamiento que no
existe fuera de mi página.
Ahora la demo presenta el block A SANGRE en la propia página: el header se
pega al viewport de verdad, con el scroll de verdad. Verificado: al bajar
queda en top 0, con `data-stuck`, visible y por encima de todo (hit-test), y
con `offset: 48` se queda exactamente a 48.
Los anchos de dispositivo (375 / 768) sí necesitan un documento propio, así
que ahí —y solo ahí— se monta un iframe de la ruta `preview`. Es opt-in a
propósito: en dev, dos documentos sin empaquetar a la vez agotan las
conexiones del navegador (`ERR_INSUFFICIENT_RESOURCES` se llevaba por delante
las DOS páginas; lo medí). Con `loading="lazy"` y bajo demanda, no molesta.
Para no duplicar contenido, el mini-sitio vive en `SiteHeaderSite.svelte` y lo
consumen las dos superficies: la demo lo renderiza inline con sus props y la
ruta `preview` lo sirve como documento leyendo la URL. «Abrir ↗» lleva ahí.
De paso: la topbar de la sección deja de ser pegajosa. Una página cuya
estrella es un block que se pega no puede tener su propio cromo peleándole el
borde superior — el header del block se metía debajo y el `offset` que
elegías se leía como otro número. El raíl sí sigue pegado, que no compite.
Verificado: `/blocks`, `/blocks/site-header` y la preview con `?dir=rtl&mode=dark`
responden 200 sin desbordes ni errores de consola; `blocks:check` verde;
`svelte-check` sin errores propios.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
background: var(--color-surface-muted);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The preview IS a page: its own document, its own viewport scroll. Resizing
|
|
|
|
|
this element resizes that viewport, which is how the narrow branch of a
|
|
|
|
|
responsive block can be seen honestly. */
|
|
|
|
|
[data-blocks-preview] {
|
|
|
|
|
border: 0;
|
|
|
|
|
block-size: 100%;
|
|
|
|
|
max-inline-size: 100%;
|
|
|
|
|
background: var(--color-surface-default);
|
demo(blocks): el block se ve en una página de verdad, no dentro de una caja con scroll
«¿Dónde has visto que el sticky esté por debajo del scroll?» — en ningún
sitio, y la respuesta correcta era esa. Un `position: sticky` metido en un div
de 460px con scroll propio no es el que va a vivir nadie: se pega al borde de
una caja, no al del viewport. Estaba enseñando un comportamiento que no
existe fuera de mi página.
Ahora la demo presenta el block A SANGRE en la propia página: el header se
pega al viewport de verdad, con el scroll de verdad. Verificado: al bajar
queda en top 0, con `data-stuck`, visible y por encima de todo (hit-test), y
con `offset: 48` se queda exactamente a 48.
Los anchos de dispositivo (375 / 768) sí necesitan un documento propio, así
que ahí —y solo ahí— se monta un iframe de la ruta `preview`. Es opt-in a
propósito: en dev, dos documentos sin empaquetar a la vez agotan las
conexiones del navegador (`ERR_INSUFFICIENT_RESOURCES` se llevaba por delante
las DOS páginas; lo medí). Con `loading="lazy"` y bajo demanda, no molesta.
Para no duplicar contenido, el mini-sitio vive en `SiteHeaderSite.svelte` y lo
consumen las dos superficies: la demo lo renderiza inline con sus props y la
ruta `preview` lo sirve como documento leyendo la URL. «Abrir ↗» lleva ahí.
De paso: la topbar de la sección deja de ser pegajosa. Una página cuya
estrella es un block que se pega no puede tener su propio cromo peleándole el
borde superior — el header del block se metía debajo y el `offset` que
elegías se leía como otro número. El raíl sí sigue pegado, que no compite.
Verificado: `/blocks`, `/blocks/site-header` y la preview con `?dir=rtl&mode=dark`
responden 200 sin desbordes ni errores de consola; `blocks:check` verde;
`svelte-check` sin errores propios.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 months ago
|
|
|
transition: inline-size var(--duration-fast) var(--ease-default);
|
|
|
|
|
}
|
