/* Theme Name: DLC Coffee Theme URI: https://dlccoffee.com Description: Child theme de Twenty Twenty-Five para DLC Coffee / El Socorro. Aquí vive el sistema de diseño DLC (tokens en theme.json, patrones y plantillas propias); todo lo demás se hereda del padre. Author: Caramba Moreno Author URI: https://www.carambamoreno.com Template: twentytwentyfive Version: 0.2.6 Requires at least: 6.7 Tested up to: 7.1 Requires PHP: 8.1 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Text Domain: dlc */ /* ============================================================================ ★★ CÓDIGO A LA MEDIDA nº 1 de 12 — regla propia del theme. Leer antes de tocar. ---------------------------------------------------------------------------- QUÉ: sube de 150px a 180px el ancho mínimo de columna de la rejilla de productos, para que la lista quede en UNA columna en toda la familia de iPhone (375 · 390 · 414) en vez de dos. POR QUÉ HACE FALTA CÓDIGO: el mínimo lo hard-codea WooCommerce en su propio CSS —`minmax(max(150px, calc(N% - Xem)), 1fr)`— y NO es configurable por atributo del bloque ni por theme.json: `grid-template-columns` no es una propiedad que theme.json soporte. `displayLayout.shrinkColumns` decide SI encoge, no DESDE QUÉ ancho. QUÉ DEFECTO ARREGLA (medido, no estimado): a 390px la rejilla mantenía 2 columnas ⇒ tarjeta de 156px ⇒ el botón «Add to cart» se partía en TRES líneas y pisaba el precio. A 375 el sitio YA hacía 1 columna y se veía bien: esto extiende ese comportamiento 40px hacia arriba, no inventa uno. POR QUÉ 180: para que 2 columnas NO quepan a 414 (el disponible es 354 y 2×180 + 17.7 de gap = 377.7 > 354). Desktop no se toca: a 1512 el `calc(25% - .9375em)` vale 315 > 180, así que el max() sigue eligiéndolo y la rejilla se queda en 4 columnas. ESTADO: decisión de BUILD por AUSENCIA de diseño móvil — el sistema de DLC está definido para desktop. Si algún día el diseño cubre móvil, este número sale de ahí y esta regla se borra. ============================================================================ */ .wc-block-product-template__responsive.columns-2, .wc-block-product-template__responsive.columns-3, .wc-block-product-template__responsive.columns-4, .wc-block-product-template__responsive.columns-5, .wc-block-product-template__responsive.columns-6 { grid-template-columns: repeat(auto-fill, minmax(max(180px, var(--dlc-col-fluida, 0px)), 1fr)); } .wc-block-product-template__responsive.columns-2 { --dlc-col-fluida: 50%; } .wc-block-product-template__responsive.columns-3 { --dlc-col-fluida: 33.33333%; } .wc-block-product-template__responsive.columns-4 { --dlc-col-fluida: 25%; } .wc-block-product-template__responsive.columns-5 { --dlc-col-fluida: 20%; } .wc-block-product-template__responsive.columns-6 { --dlc-col-fluida: 16.66667%; } /* ============================================================================ ★★ CÓDIGO A LA MEDIDA nº 4 — tarjetas CONTIGUAS (gap 0) con el borde FUNDIDO. ---------------------------------------------------------------------------- QUÉ: quita la separación entre tarjetas de la rejilla de productos, para que queden pegadas como en el nodo (x = 0/346/692/1038) en vez de con 20px. ★ EL NÚMERO QUE CONFIRMA QUE ESTO ES LO QUE EL NODO PEDÍA: 346 × 4 = **1384**, que es exactamente el ancho útil del sitio. Con gap 0 y columnas al 25% limpio, la rejilla cae sola en la medida del nodo. Por eso las variables de arriba pierden la resta del gap: `calc(25% - .9375em)` descontaba una separación que ya no existe, y dejaba huecos. POR QUÉ HACE FALTA CÓDIGO (verificado, ya documentado en `DLC-ENTREGA-REJILLA-LOOP.md`): WooCommerce hard-codea `grid-gap:1.25em` en `.wc-block-product-template__responsive`, y **no es un atributo del bloque**: poner `style.spacing.blockGap:0px` en `product-collection` no tuvo ningún efecto, porque el gap vive en un elemento HIJO. Y `product-template` declara `layout.allowEditing:false`, así que tampoco se toca desde ahí. ★ POR QUÉ NO SE USÓ MARGEN NEGATIVO: en CSS Grid el margen negativo NO colapsa bordes — solo ensancha el item fuera de su celda. Es grid, no flex (medido: `display:grid`, `gridTemplateColumns` de 4 columnas). ★ CÓMO SE FUNDE EL BORDE, y por qué NO con el truco del fondo del contenedor: cada tarjeta lleva borde solo en DERECHA y ABAJO (atributos nativos del bloque, no CSS), y el contenedor cierra ARRIBA e IZQUIERDA. Así entre dos tarjetas hay UNA línea de 1px, no dos pegadas. El otro mecanismo evaluado —fondo del contenedor del color del borde con `gap:1px`— se descartó con un dato: hay **7 productos en 4 columnas**, o sea una fila incompleta, y ese truco pinta la celda vacía como una **tarjeta fantasma**. ESTADO: si Woo expone el gap como atributo del bloque, esto se borra. ============================================================================ */ .wc-block-product-template__responsive { gap: 0; } /* El contenedor cierra los dos lados que la tarjeta no dibuja. */ .wc-block-product-template__responsive { border-top: 1px solid #eae9e8; border-left: 1px solid #eae9e8; } /* ============================================================================ ★★ CÓDIGO A LA MEDIDA nº 2 — la barra de filtros del shop, en FILA. ---------------------------------------------------------------------------- QUÉ: pone las facetas del bloque `woocommerce/product-filters` una al lado de otra en vez de apiladas. POR QUÉ NO SE PUEDE CON GUTENBERG NI CON WOO (medido, no supuesto): 1. El `layout` del bloque `product-filters` gobierna su envoltura, pero las facetas viven dentro de un `
` que arma su propio `render()`. Ese div NO es un bloque, así que ningún atributo de layout lo alcanza. 2. Woo le fija `flex-direction:column` en su propio stylesheet (`product-filters-style.css`), pensado para una barra lateral, y **no publica ninguna variante horizontal**: barrido de ese archivo por `flex-direction:row|horizontal|inline` → 0 reglas. 3. La regla de Woo va con `:where(.wc-block-product-filters)`, que aporta especificidad CERO a propósito — el propio Woo la deja preparada para que el theme la sobrescriba. Por eso acá basta con subir un nivel de especificidad y NO hace falta `!important`. QUÉ RESUELVE: el diseño pide una BARRA (Variety · Farm · Cup profile en una línea, sobre la rejilla). Apiladas, las tres facetas ocupaban 423px de alto antes del primer producto. ESTADO: si algún día Woo publica un layout horizontal nativo para este bloque, esta regla se borra y se usa el suyo. ============================================================================ */ .wc-block-product-filters .wc-block-product-filters__content { flex-direction: row; flex-wrap: wrap; align-items: flex-start; column-gap: 32px; row-gap: 16px; } /* Cada faceta se encoge a su contenido en vez de estirarse al ancho completo. */ .wc-block-product-filters .wc-block-product-filters__content > * { flex: 0 1 auto; max-width: 100%; } /* ============================================================================ ★★ CÓDIGO A LA MEDIDA nº 3 — el recuadro del selector de cantidad. ---------------------------------------------------------------------------- QUÉ: le pone al stepper de cantidad de la ficha el fondo `paper` y el borde `ink` a opacidad plena que pide el diseño. Woo lo sirve sin fondo y con el borde a 30% de opacidad. POR QUÉ NO SE PUEDE CON ATRIBUTOS (probado ejecutando, no leído de los supports): el bloque `woocommerce/add-to-cart-with-options-quantity-selector` declara `"supports": {"interactivity": true}` y nada más — ni color, ni borde, ni spacing. Se le pasó `className:"dlc-qty"` y `style.color.background:"#F4F1EA"` y se renderizó: **ninguno de los dos llega al DOM**. El bloque arma su propia salida y los descarta, igual que `product-button` bajo `AddToCartWithOptions`. POR QUÉ ASÍ Y NO CON UN HEX: los dos valores salen de los tokens del `theme.json`. Si el token cambia, esto cambia con él en vez de quedar congelado. QUÉ NO HACE: no toca el alto. El nodo dibuja 110×48 y el sitio da 109×44, pero el alto **emerge** del contenido — fijarlo sería inventar un número. Queda reportado como diferencia, no compensado acá. ESTADO: si Woo le agrega supports de color y borde a este bloque, esta regla se borra y se usan los atributos. ============================================================================ */ /* ⚠️ El fondo y el borde NO van en el mismo nodo que el bloque: el wrapper `__quantity-selector` no tiene borde propio. El borde 1px y el radius 4 viven en el HIJO `.wc-block-components-quantity-selector` — los dos miden 109×44, así que a ojo son el mismo elemento y no lo son. Se localiza por su estructura. */ .wc-block-add-to-cart-with-options__quantity-selector .wc-block-components-quantity-selector { background-color: var(--wp--preset--color--paper); border-color: var(--wp--preset--color--ink); } /* ============================================================================ ★★ CÓDIGO A LA MEDIDA nº 5 — el `line-height` del botón de añadir al carrito. ---------------------------------------------------------------------------- QUÉ: devuelve al botón de producto el interlineado 1.2 que declara el sistema (B6). Sin esto sirve **24px** (= 1.5, heredado del cuerpo). CAUSA, medida en el runtime — no deducida del código: WooCommerce emite `.wp-block-button.wc-block-components-product-button .wc-block-components-product-button__button { line-height: inherit }` con especificidad **(0,3,0)**, mientras que TODO lo que sale de `theme.json` se emite con `:where()`, que vale **(0,1,0)**. Se listaron las tres reglas con `line-height` que le aplican al botón: las dos del theme dicen 1.2 y la de Woo dice `inherit` — y gana la de Woo. ⇒ **No es que el token esté mal puesto: es que no puede ganar.** Es el mismo patrón que la regla nº 2, con otro bloque. QUÉ CORRIGE, en número: con `inherit` el alto del botón sale **48**; con 1.2 emerge **43.2**, que es lo que dibuja el nodo. El alto **no se declara**: sale de padding 12 + 19.2 + padding 12. ESTADO: si Woo deja de forzar `inherit`, esta regla se borra. ============================================================================ */ .wp-block-button.wc-block-components-product-button .wc-block-components-product-button__button { line-height: 1.2; } /* ============================================================================ ★★ CÓDIGO A LA MEDIDA nº 6 — el ASPECTO de la tabla de especificaciones. ---------------------------------------------------------------------------- QUÉ: convierte la tabla de atributos de la ficha en la lista etiqueta→valor SIN BORDES que dibuja el nodo (`Frame 143`, `311:38038`): filas de 17px (13 × 1.3), separación 12, y el VALOR arrancando siempre en x=112. Woo la sirve como tabla con recuadro: borde de 1px en cada celda, 8px de relleno, etiqueta en 16px/700 y filas de 73px de alto. POR QUÉ HACE FALTA CÓDIGO (verificado, no supuesto): 1. El BORDE Y EL RELLENO no son de Woo ni del bloque: son del CSS del bloque de tabla del NÚCLEO — `.wp-block-table td,.wp-block-table th {border:1px solid;padding:.5em}`. El `
` que emite `ProductSpecifications::render()` lleva la clase `wp-block-table`, así que hereda esa regla entera. No hay atributo que la apague. 2. `woocommerce/product-specifications` declara en su `block.json` `supports: {spacing:{margin,padding}, typography:{fontSize,lineHeight}}` — **sin color, sin borde, y sin nada por celda**. Ni el ancho de la columna de etiquetas ni el color de la etiqueta son alcanzables por atributo, porque viven en el ``, que no es un bloque. 3. El valor va envuelto en `

` por `wpautop()` dentro del render de Woo (`ProductSpecifications.php:103`), y ese párrafo aporta sus márgenes: es la mitad de los 73px de fila. DECISIÓN QUE LO ORDENA (Mauricio, 27-ago): «la tabla se queda con las filas que tenga — no importa que tenga solo 2 datos. Importa el ASPECTO.» Por eso NO se cambia el bloque ni se arman las filas a mano: las filas las sigue derivando Woo del dato (aparecen y desaparecen solas cuando el cliente cargue Proceso y Altura); lo que se corrige es cómo se ven. EL OFFSET DE 112: el nodo pone el valor SIEMPRE en x=112, sea cual sea el largo de la etiqueta, así que la columna se fija con `width` + `min-width` + `max-width` — no basta `width`, que en layout automático es una sugerencia y cedería ante una etiqueta larga («Altitude», «Process»). ⚠️ **`table-layout:fixed` NO sirve acá, probado:** con layout fijo los anchos los dicta la PRIMERA fila de la tabla, y ésa es la del `` que emite Woo — que sigue mandando aunque `screen-reader-text` la saque de pantalla con `position:absolute`. Medido en la página real, cambiando una regla a la vez: fijo + ancho en `tbody` → **244.8** (mitad de la tabla, o sea el ancho lo puso el thead); fijo + `thead{display:none}` → 112; **automático + ancho en `tbody` → 112**. Se descartó ocultar el `thead`: es el encabezado que lee el lector de pantalla y quitarlo deja la tabla sin cabecera accesible. ESTADO: si el núcleo deja de vestir `.wp-block-table` por celda, o si Woo le agrega supports de borde/color a este bloque, esto se borra. ============================================================================ */ /* Las celdas pierden el recuadro y el relleno del bloque de tabla del núcleo. ⚠️ ETIQUETA y VALOR NO comparten token — leído del nodo con `get_design_context` el 28-ago (`311:38038`): la etiqueta es `Utilitario/Botón` (Hanken **SemiBold 600 · 13 / 1.2**) y el valor es `Utilitario/Etiqueta` (Hanken **Medium 500 · 13 / 1.3**). El registro escrito decía que los dos usaban `Utilitario/Etiqueta`; el nodo dice otra cosa. */ .wp-block-woocommerce-product-specifications tbody th, .wp-block-woocommerce-product-specifications tbody td { border: 0; padding: 0; vertical-align: top; font-family: var(--wp--preset--font-family--dlc-body); font-size: 13px; } .wp-block-woocommerce-product-specifications tbody th { font-weight: 600; line-height: 1.2; } .wp-block-woocommerce-product-specifications tbody td { font-weight: 500; line-height: 1.3; } /* La etiqueta: columna fija de 112px y el neutro del sistema, igual que el eyebrow de la ficha. Los tres anchos son a propósito (ver el comentario). */ .wp-block-woocommerce-product-specifications tbody th.wp-block-product-specifications-item__label { width: 112px; min-width: 112px; max-width: 112px; color: #9e998f; } /* El valor: ink y sin subrayado — en el nodo es texto plano, no un enlace. Sigue siendo el enlace al archivo del término; solo deja de anunciarse. */ .wp-block-woocommerce-product-specifications tbody td.wp-block-product-specifications-item__value, .wp-block-woocommerce-product-specifications tbody td.wp-block-product-specifications-item__value a { color: var(--wp--preset--color--ink); text-decoration: none; } /* El `

` que mete `wpautop()` no aporta aire: la fila mide su interlínea. */ .wp-block-woocommerce-product-specifications tbody td.wp-block-product-specifications-item__value p { margin: 0; } /* La separación de 12 entre filas va como relleno inferior de todas menos la última: así el bloque cierra en `5×17 + 4×12 = 133` como el nodo, y con 2 filas cierra en 46, sin aire sobrante arriba ni abajo. */ .wp-block-woocommerce-product-specifications tbody tr:not(:last-child) > * { padding-bottom: 12px; } /* ============================================================================ ★★ CÓDIGO A LA MEDIDA nº 7 — la LÍNEA de los jumbos del Home: geometría, estados, tono claro sobre fondo oscuro, y las dos guardas del título. ---------------------------------------------------------------------------- QUÉ: pinta y anima la línea que acompaña a los títulos «Find Locally» y «Buy Now» (banda `wp_block` 112). En reposo mide 32px; al pasar el mouse o al enfocar con el teclado crece hasta el borde derecho de su fila. DE DÓNDE SALE CADA VALOR (spec `DLC-ENTREGA-LINEA-QUE-CRECE.md`, medida sobre el master `630:8318` y el átomo `Flecha` `589:7643`, no estimada): · grosor 2px = el cuerpo del `path` del átomo (`y ∈ [7,9]` de 16). No es una distancia, así que no le aplica la escala de espaciado. · color Ink = `tono="Oscura"` que instancia el master. Es TOKEN. · Gold en `:active` = token. Ningún hex inventado. · reposo 32px = tope de la escala base y 2× el módulo 16 de la banda. ⚠️ ES EL ÚNICO VALOR SIN MEDICIÓN DE ORIGEN — la línea que crece no existía en el sistema. Alternativas dentro de escala: 24 o 48. Pendiente de que Mauricio lo vea renderizado (H-01 de la spec). POR QUÉ ES LA LÍNEA Y NO LA FLECHA: la flecha se quitó por decisión de Mauricio, y con ella se fue la única afordancia de estos dos títulos, que son botones `Fantasma/Jumbo` sin fondo ni borde. La línea la devuelve. Verificado en el Figma: en las dos instancias de la banda la flecha ya NO se dibuja (SVG exportado vacío en una, `hidden="true"` en la otra), así que esto no contradice el nodo: lo repara. QUÉ ES NATIVO Y QUÉ NO — la separación importa: · NATIVO: la PISTA que ocupa el resto de la fila. Es un `core/group` con `style.layout.selfStretch:"fill"`, que WordPress traduce a `flex-grow:1` en una clase `wp-container-content-*`. Probado ejecutando `do_blocks()`: sale `.wp-container-content-9cfa9a5a {flex-grow:1}`. Es el mismo mecanismo del precedente del bento de fincas (`526:4696`, `flex-[1_0_0]`). · A LA MEDIDA (esto): el estado. Gutenberg no tiene hover, foco ni transición para un grupo. ★ POR QUÉ NO VA EN UNA BLOCK STYLE VARIATION, que era el plan (probado, no supuesto — `WP_Theme_JSON::process_blocks_custom_css` en el WP 7.1 de este sitio): 1. Un selector que NO empieza por `&` sale roto. `h3:hover + &` produce `:root :where(){h3:hover +}` — una regla inválida más una declaración huérfana. 2. **Las `@media` NO sobreviven, y fallan en silencio y HACIA EL LADO PELIGROSO.** De 4 reglas de entrada salieron 2: la de `hover:none` desapareció entera, y la de `prefers-reduced-motion` **perdió su `@media` y quedó incondicional** — habría dejado a TODO el mundo sin transición. Un fallo que ningún control de "¿está la clase?" caza. ⇒ La regla general: el `css` de una variación sirve para declaraciones planas ancladas en `&`; en cuanto hay media query o selector de hermano, va al stylesheet del theme. POR QUÉ SE ANIMA `background-size` Y NO `width`: la pista conserva su tamaño siempre; lo que crece es la línea PINTADA dentro de ella. Animar el ancho del contenedor flex movería el título en cada hover. MÓVIL: sin hover no hay nada que revelar, así que la línea va al 100% fija. Es la intención original del diseño (la flecha siempre iba de extremo a extremo). ESTADO: si Gutenberg publica estados de interacción para bloques, esto se borra y se usan los suyos. ============================================================================ */ .dlc-titulo-linea .dlc-linea { align-self: center; height: 2px; background-image: linear-gradient(var(--wp--preset--color--ink), var(--wp--preset--color--ink)); background-repeat: no-repeat; background-position: left center; background-size: 32px 2px; transition: background-size 200ms ease-in; } /* Hover y foco de teclado corren la línea hasta el borde de la fila. El `:focus-within` cubre el teclado sin depender de `:has()`. */ .dlc-titulo-linea:hover .dlc-linea, .dlc-titulo-linea:focus-within .dlc-linea { background-size: 100% 2px; transition-timing-function: ease-out; } /* La pulsación se lee instantánea y pasa a Gold mientras dura. */ .dlc-titulo-linea:active .dlc-linea { background-size: 100% 2px; background-image: linear-gradient(var(--wp--preset--color--gold), var(--wp--preset--color--gold)); transition-duration: 0ms; } /* El anillo de foco va en el enlace del título, y solo por teclado: el clic de ratón no lo deja. Sin esto el sitio se queda sin navegación accesible. */ .dlc-titulo-linea a:focus-visible { outline: 2px solid var(--wp--preset--color--ink); outline-offset: 4px; } /* ── Tono CLARO de la línea, para la mitad de fondo oscuro ──────────────────── El átomo `Flecha` del sistema define dos tonos: `Oscura` (Ink, sobre papel) y `Clara` (blanco, sobre foto o fondo oscuro). Al pasar la mitad derecha a fondo `ink` por la desviación 2, la línea Ink queda del mismo color que su fondo y DESAPARECE. Esto no rediseña la línea —su tratamiento sigue pospuesto a ALMA—: aplica el tono que el sistema ya tiene definido para ese caso, y que el propio nodo `311:43553` usa (stroke blanco en la mitad oscura). Se usa `paper`, no blanco puro, porque es el color de texto que el sistema ya pone sobre `ink` (precedente vivo: `wp_block` 114, Premios). */ .dlc-titulo-linea .dlc-linea--clara { background-image: linear-gradient(var(--wp--preset--color--paper), var(--wp--preset--color--paper)); } .dlc-titulo-linea:active .dlc-linea--clara { background-image: linear-gradient(var(--wp--preset--color--gold), var(--wp--preset--color--gold)); } /* ── Las dos mitades reparten el 50% CON su borde adentro ───────────────────── Sin esto el `flex-basis: 50%` se mide sobre el content-box, así que el borde de 2px de la mitad izquierda se SUMA a su ancho y el reparto deja de ser parejo. **Medido antes de escribir esta regla**, con el borde ya puesto: a 1512 → izquierda 694 · derecha 690 (asimetría 4px = 2px × 2 lados) a 1280 → izquierda 592 · derecha 588 (la misma) La suma seguía cerrando en el ancho de la banda y NO había desborde —por eso no se ve como error— pero las dos mitades no medían lo mismo. Gutenberg no tiene atributo para `box-sizing`, así que va acá. */ .wp-block-column.dlc-jumbo { box-sizing: border-box; } /* ── El título no se parte, y la fila recorta ───────────────────────────────── Las dos las declara el nodo `311:43553` (`whitespace-nowrap` en el título, `overflow-clip` en la mitad) y Gutenberg no tiene atributo para ninguna. Hacen falta AHORA y no antes porque el padding de cada mitad sube de 16 a 32: el ancho disponible para el título baja 32px, y sin `nowrap` «Find Locally» pasa a poder partirse en los anchos chicos. El `clip` es su guarda: impide que un título largo empuje la línea fuera de la caja. */ .dlc-titulo-linea :is(h1,h2,h3,h4,h5,h6) { white-space: nowrap; } .dlc-titulo-linea { overflow: clip; } /* Táctil: no hay hover que revele nada ⇒ la línea va completa y quieta. */ @media (hover: none) { .dlc-titulo-linea .dlc-linea { background-size: 100% 2px; transition: none; } } /* El cambio de estado se conserva; lo que desaparece es el movimiento. */ @media (prefers-reduced-motion: reduce) { .dlc-titulo-linea .dlc-linea { transition: none; } } /* ============================================================================ ★★ CÓDIGO A LA MEDIDA nº 8 — el CHIP de filtro, vestido como el Botón del sistema. ---------------------------------------------------------------------------- QUÉ: lleva el chip del bloque `woocommerce/product-filter-chips` al átomo de diseño «Botón · Jerarquía Secundario · Tamaño Pequeño · Modo Filtro» (nodo Figma 677:9013): padding 8/12, radio 0, borde Ink 1px, y la barra con los chips PEGADOS (bordes fundidos), activo en Ink sobre Paper. POR QUÉ NO SE PUEDE CON GUTENBERG NI CON WOO (medido, no supuesto): Se puso el bloque con TODOS sus atributos soportados —`chipText`, `chipBorder`, `selectedChipText`, `selectedChipBackground`, `selectedChipBorder`, y tipografía en el bloque padre— y el chip llegó sólo hasta: font-size 11px ✔ · color Ink ✔ y se quedó en: padding 4.4/8.25 · radio 2px · alto 25.3 · gap 4 · borde al 40% de opacidad. La causa es la especificidad: Woo estiliza `.wc-block-product-filter-chips__item` con una CLASE (0,1,0), no con `:where()`, así que ni `theme.json` ni los atributos del bloque lo alcanzan. Y una Block Style Variation tampoco: su `css` se emite dentro de `:root :where(…)` con especificidad 0. (El `gap` sí sale de un `:where()`, pero se corrige acá junto al resto para que la barra quede definida en un solo lugar.) CÓMO: se sube UN nivel de especificidad usando el contenedor `__items` como ancestro. Sin `!important` y sin depender del orden de carga. PEGADOS: `gap:0` + `margin-left:-1px` en todos menos el primero. El contenedor renderiza `display:flex` (medido), donde el margen negativo SÍ colapsa bordes; en grid no funcionaría. DÓNDE SE VE: `/shop/`, el Home y `/varieties/` — los tres instancian el mismo patrón sincronizado, el `wp_block` 466. ESTADO: si Woo publica controles de padding/radio/gap para este bloque, o pasa sus reglas a `:where()`, esta regla se borra y se usan los suyos. Prueba de que ya sobra: quitar este bloque y comprobar que el chip sigue midiendo padding 8/12, radio 0 y hueco 0 entre chips. ============================================================================ */ .wc-block-product-filter-chips__items { gap: 0; } .wc-block-product-filter-chips__items .wc-block-product-filter-chips__item { padding: 8px 12px; border-radius: 0; border-color: var(--wp--preset--color--ink); background: transparent; color: var(--wp--preset--color--ink); /* El nodo pide caja de 29; en CSS el borde va FUERA del padding box, así que 29 del nodo = 31.2 servidos. Sin fijar el interlineado salen 32.5. */ line-height: 1.2; } /* Bordes fundidos: cada chip se solapa 1px con el anterior. */ .wc-block-product-filter-chips__items .wc-block-product-filter-chips__item + .wc-block-product-filter-chips__item { margin-left: -1px; } /* El chip vigente usa la jerarquía Principal del sistema: Ink sobre Paper. */ .wc-block-product-filter-chips__items .wc-block-product-filter-chips__item[aria-checked="true"] { background: var(--wp--preset--color--ink); border-color: var(--wp--preset--color--ink); color: var(--wp--preset--color--paper); position: relative; z-index: 1; } /* ============================================================================ RETIRADO — nº 9 «esconder un bloque por debajo de 640px» (2026-09-29, Roberto) Aquí vivía `.dlc--hide-for-small` (display:none bajo 39.9375em), que escondía BUY NOW y FIND LOCALLY en teléfono para que la barra del topbar no se partiera en dos filas. LO REEMPLAZA EL CONTROL NATIVO DE GUTENBERG. WordPress 7.0 trae visibilidad de bloque por dispositivo (`wp-includes/block-supports/block-visibility.php`; casilla «Ocultar en móvil / tablet / escritorio» en la barra del bloque), y los cortes de ESTE sitio se declaran en `theme.json` bajo `settings` -> `viewport` (mobile 39.9375em, tablet 63.9375em) — los mismos que tenía esta regla, así que el comportamiento no cambió ni un píxel. DÓNDE ESTÁ AHORA: en los 4 template parts de header (555, 556, 557 y 611), el bloque `wp:buttons` lleva, dentro de `metadata` -> `blockVisibility` -> `viewport`, la clave `mobile` en false. Se edita desde el editor de sitio, sin tocar CSS. Verificado en el front: el div de los botones sale con la clase `wp-block-hidden-mobile`. ⚠ LO QUE SIGUE SIENDO VERDAD Y NO LO ARREGLA NADIE TODAVÍA — es información de DISEÑO, no de este CSS, y por eso se conserva: · 640px–1110px: la barra SIGUE en dos filas. Cubrirlo obliga a esconder el botón de compra hasta 1200px (toda laptop de 13"), y eso es decisión de negocio. PENDIENTE de Mauricio/Oscar. · 320px: la barra queda en dos filas AUNQUE no haya ningún botón — logo(140)+36+hamburguesa(24) + 32 + íconos(65) = 297 > 260 de ancho disponible. Faltan 37px. Necesita decisión de diseño aparte. · No existe un tipo de topbar móvil en el pilar de diseño (`DLC-ENTREGA-TIPOS-HEADER.md` §1.10). ============================================================================ */ /* ============================================================================ ★★ CÓDIGO A LA MEDIDA nº 10 — los bordes del bento de marcas cuando colapsa. ---------------------------------------------------------------------------- QUÉ: bajo 781px, donde el bento de «Marcas · fincas hermanas» pasa de rejilla a UNA columna, normaliza los bordes de las 4 tarjetas a una TIRA CONTINUA: cada tarjeta con filo superior, izquierdo y derecho, sin filo inferior, y el cierre de abajo lo pone el contenedor. EL DEFECTO, MEDIDO (staging, 2026-08-28): las 4 tarjetas traen los bordes RECORTADOS A MANO para la rejilla de escritorio — cada una omite el filo que le presta su vecina: San Lorenzo top 1 · right 0 · bottom 1 · left 1 El Socorro los cuatro a 1 San Guayabá top 1 · right 1 · bottom 0 · left 0 Río Arriba top 1 · right 1 · bottom 1 · left 0 En escritorio eso es correcto: a 1512 hay CERO uniones verticales. Al apilarse cambian las vecinas y el recorte queda al revés: · San Lorenzo/El Socorro → 1+1 = 2px, línea DOBLE · El Socorro/San Guayabá → 1+1 = 2px, línea DOBLE · y tres de las cuatro tarjetas quedan ABIERTAS de un lado (San Lorenzo sin derecha; San Guayabá sin izquierda ni abajo; Río Arriba sin izquierda). Sólo El Socorro se lee como tarjeta. Idéntico a 390 y a 320. El punto de quiebre es EXACTO: medido a un píxel de cada lado, 782 → rejilla con 0 dobles; 781 → una columna con 2. POR QUÉ HACE FALTA CÓDIGO (verificado, no supuesto): 1. `style.border` de un bloque NO tiene variante por breakpoint: es un solo valor para todos los anchos. Los bordes del bento salen como ESTILO INLINE en el elemento, así que además la regla necesita `!important` para ganarles (por eso están, y sólo por eso). 2. Una Block Style Variation TAMPOCO sirve: su `css` DESCARTA las `@media` al pasar por `WP_Theme_JSON::process_blocks_custom_css` (lección 33 del corpus, probada el 2026-08-28: de 4 reglas de entrada salieron 2, y una perdió el `@media` y pasó a aplicarse a todos). 3. `theme.json` no admite media queries. ⇒ dos rutas nativas cerradas con evidencia. Esto NO es pereza: si lo leés dentro de seis meses y el núcleo ya trae bordes por breakpoint, borralo — pero comprobá primero esas tres, no la fecha. BREAKPOINT: 781px, el de `.wp-block-columns` del núcleo. NO es un número elegido: es el ancho al que el propio core apila las columnas, así que la regla entra exactamente cuando aparece el defecto. EL GANCHO: `.dlc--bento-marcas`, clase estructural en el `core/columns` del `wp_block` 111 (eso sí es Gutenberg puro, un atributo). ⚠️ NO se puede colgar de `.has-caqui-border-color` a secas: en el Home son 16 elementos y 12 son las tarjetas de tostador del hilo del mapa. ⚠️ NI de `.cm--tarjeta-clickeable`: acoplaría el borde a que la tarjeta sea clicable, que son dos cosas distintas. EL CIERRE DE ABAJO va en el CONTENEDOR, no en «la última tarjeta»: así la regla no depende de cuál tarjeta queda última ni de cuántas hay, y sobrevive a que el bento se reordene. DÓNDE SE VE: `wp_block` 111 «Marcas · fincas hermanas», que renderizan la página 60 (Home) y la 14 (Design System). ESTADO: vigente. Se retira si diseño define un tratamiento móvil propio para el bento — hoy no existe uno. ============================================================================ */ @media screen and (max-width: 781px) { .dlc--bento-marcas .has-caqui-border-color { border-style: solid !important; border-color: var(--wp--preset--color--caqui) !important; border-top-width: 1px !important; border-right-width: 1px !important; border-bottom-width: 0 !important; border-left-width: 1px !important; } .dlc--bento-marcas { border-bottom: 1px solid var(--wp--preset--color--caqui); } } /* ============================================================================ ★★ CÓDIGO A LA MEDIDA nº 11 — el header PEGADO (sticky). ---------------------------------------------------------------------------- QUÉ: fija el header arriba al hacer scroll, y evita que tape el destino de las dos anclas del sitio. POR QUÉ NO ES EL ATRIBUTO NATIVO (probado, y probado en el orden correcto): `position: sticky` SÍ es soporte nativo del bloque y SÍ está habilitado acá — verificado ejecutando, no leyendo: · `WP_Theme_JSON_Resolver::get_merged_data()->get_settings()['position']` → `{"sticky":true}` (lo enciende `appearanceTools`) · `core/group` declara `supports.position.sticky` · `do_blocks()` con el atributo emite `is-position-sticky` Se puso el atributo en el grupo `header` de `parts/header.html`, se desplegó, y el CSS del núcleo se aplicó de verdad (`position:sticky; top:0px; z-index:10`). **Y AUN ASÍ NO SE PEGABA.** Medido: tras 2000px de scroll el header quedaba en `top: -2000` — se iba con la página. LA CAUSA, medida en la cadena de ancestros: el grupo del header vive DENTRO del envoltorio que genera WordPress para la template part — `

`— y ese envoltorio mide EXACTAMENTE lo mismo que él: 77px contra 77px, **recorrido = 0**. Un elemento `sticky` sólo se pega dentro de la caja de SU PADRE, así que no tenía un solo píxel donde pegarse. La cadena está limpia: sin `overflow:hidden`, sin `transform`, sin `contain` en ningún nivel. ⇒ El sticky tiene que ir en el ENVOLTORIO, cuyo padre es `.wp-site-blocks` (8290px) y ahí sí hay recorrido. Y EL ENVOLTORIO NO ACEPTA EL ATRIBUTO: `core/template-part` **no declara** `supports.position` (verificado en el registro de bloques), así que no hay forma nativa de marcarlo. Por eso esto es código a la medida y no pereza. El atributo nativo se RETIRÓ de `parts/header.html` para no dejar dos mecanismos declarando lo mismo, uno de ellos inerte. LAS ANCLAS: el sticky introduce un defecto que antes no existía — el destino de un salto queda DEBAJO del header. El sitio tiene exactamente dos anclas, y una es de accesibilidad: · `#wp--skip-link--target` — el «saltar al contenido», en TODA página · `#mapa-home` — en el Home Sin `scroll-margin-top`, saltar deja el destino tapado. Los valores salen de la escala de 16 y cubren el alto MEDIDO del header: 77px en escritorio → 96; y hasta 151px cuando el topbar se parte en dos filas bajo 781 → 160. ⚠️ HALLAZGO ABIERTO, NO RESUELTO ACÁ: el header no mide lo mismo en todos los anchos porque el topbar se parte en dos filas. Medido: 1512 → 77px (8% de pantalla) · 390 → 77px (9%) · **780 → 151px (17%)** · **320 → 144px (25%)**. Pegado, ese alto se queda en pantalla todo el rato. A 320 es un cuarto de la pantalla. Si molesta, la salida NO es tocar esta regla: es el topbar móvil, que sigue sin definirse en diseño (ver el bloque nº 9). Queda reportado, no decidido. ★★ EL Z-INDEX — por qué 20 y no 10 (corregido 2026-08-28, mismo día): La primera versión de esta regla usó `z-index: 10`, copiando el valor que el núcleo le da a los bloques sticky. **Fue un error, y produjo tres síntomas visibles**: el contenido de `historia`, el del `checkout` y el mapa se montaban ENCIMA de la barra. La causa está documentada y es del núcleo: **WordPress le da `z-index:10` a TODOS los bloques marcados «Sticky» y no es configurable desde el editor** ⇒ dos sticky cualesquiera EMPATAN, y desempata el **orden del documento**: gana el que va después, que siempre es el contenido. Medido en las tres páginas, contra quién compite de verdad: · `/historia/` → **5** bloques sticky más, todos en `z-index:10` · `/find-locally/` → 1 bloque sticky más en 10 (y el mapa con capas 5–6) · `/checkout/` → sin rivales sticky; su problema era el fondo Y el techo que NO hay que pasar, porque deben quedar POR ENCIMA: · `wc-block-components-drawer__screen-overlay` — **9999** (el cajón del mini-carrito) · `wc-block-components-notices__snackbar` — **100000** (los avisos) ⇒ **20**: por encima del 10 fijo del núcleo con margen para un sticky futuro, y muy por debajo de las capas de WooCommerce, que si se tapan rompen el carrito. **Un `9999` al aire habría roto el mini-carrito.** ⚠️ EL FONDO NO ES PARTE DE ESTA REGLA, y conviene saber por qué: el envoltorio sticky es transparente, pero el grupo del header que lleva adentro es **opaco (`paper`) y lo cubre entero** — medido: 1512×77 contra 1512×77. ⇒ en las páginas normales **no hacía falta fondo**; el síntoma de «se lee a través» era el empate de `z-index`. **La excepción real es el CHECKOUT**, que usa OTRA template part (`checkout-header`, `wp_template_part` 383, vive en la BD) y **esa sí estaba sin fondo** (`rgba(0,0,0,0)`). Se le puso `backgroundColor: paper` **por Gutenberg, como atributo** — no con CSS, y por eso no está acá. DÓNDE SE VE: todas las páginas. ESTADO: vigente. Se retira si `core/template-part` llega a declarar `supports.position` — comprobalo con el registro de bloques antes de borrar, no por la fecha. ============================================================================ */ header.wp-block-template-part { position: sticky; top: 0; /* 20, no 10 — ver «EL Z-INDEX» arriba. */ z-index: 20; } #wp--skip-link--target, #mapa-home { scroll-margin-top: 96px; } @media screen and (max-width: 781px) { #wp--skip-link--target, #mapa-home { scroll-margin-top: 160px; } } /* ============================================================================ RETIRADO — nº 12 «mostrar un bloque SOLO por debajo de 640px» (2026-09-29, Roberto) Aquí vivía `.dlc--solo-movil` (display:none desde 40em), que metía el link al mapa dentro del menú móvil. Era el complemento exacto del nº 9. LO REEMPLAZA EL CONTROL NATIVO DE GUTENBERG, igual que el nº 9. En los headers 555, 556 y 557 el `wp:navigation-link` lleva, dentro de `metadata` -> `blockVisibility` -> `viewport`, las claves `tablet` y `desktop` en false. Verificado en el front: el `
  • ` sale con las clases `wp-block-hidden-desktop` y `wp-block-hidden-tablet`. Nota: este caso NO tenía equivalente en el plugin `caramba-moreno-css-queries` —habría hecho falta combinar hide-for-medium + hide-for-large—, y con el control nativo se expresa marcando dos casillas. ============================================================================ */ /* ============================================================================ ★★ CÓDIGO A LA MEDIDA nº 13 — la barra de carga del router, por ENCIMA del header. QUÉ: le da `z-index` a `.wp-interactivity-router-loading-bar`, la barra de progreso que WordPress pinta arriba del todo cuando la Interactivity API navega — en este sitio, cada vez que se toca un filtro de la tienda. POR QUÉ EXISTE: el núcleo la declara `position: fixed; top: 0` y **sin z-index propio** (`z-index: auto`). El header de este tema es `position: sticky; top: 0; z-index: 20` (bloque nº 11) y mide 151px de alto. Los dos ocupan el mismo borde superior, así que la barra —de 4px— queda DEBAJO del header y no se ve nunca. Medido en runtime el 2026-09-14 en `/shop/`: barra `z-index: auto`, header `z-index: 20`. Reportado por Mauricio como «el loading state de los filtros no se ve a menos que uno fuerce el scroll hacia arriba». Es 30 y no 21 para dejar el hueco de la escala 10/20/30 que ya usa el tema, no por precisión. DÓNDE SE VE: `/shop/` y cualquier página con filtros de producto. ESTADO: vigente. Se retira si el núcleo llega a darle z-index propio a esa barra — comprobalo mirando el CSS servido de `wp-includes`, no por la fecha. ⚠️ LO QUE ESTO **NO** ARREGLA: la barra tarda **849 ms** en aparecer (medido el mismo día, mismo runtime), así que llega cuando el filtrado casi terminó. El indicador que de verdad sirve va SOBRE la parrilla de productos, que es lo que cambia y donde está el ojo. Eso es trabajo aparte y no se hizo acá. ============================================================================ */ .wp-interactivity-router-loading-bar { z-index: 30; }