/* Theme Name: Cuna en Calma Theme URI: https://www.cunaencalma.com/ Description: Tema de bloques para Cuna en Calma, la web de Isabel Cartagena, psicologa especializada en sueno infantil. Todo el contenido se edita desde el editor de bloques: la identidad visual vive en theme.json y las paginas se montan con patrones de bloques nativos. Author: Cuna en Calma Version: 0.1.0 Requires at least: 6.7 Requires PHP: 7.4 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Text Domain: cuna-en-calma Tags: block-patterns, full-site-editing, one-column */ /* * Deliberately almost empty. Colours, typography, spacing and element styles * are defined in theme.json so that the block editor exposes them to the site * owner as controls instead of hiding them in a stylesheet she cannot reach. * * Only add a rule here when theme.json genuinely cannot express it. * * The self-hosted heading face lives in assets/fonts/ebgaramond-latin.woff2 and * is declared through settings.typography.fontFamilies[].fontFace, which makes * WordPress emit the @font-face rule and lets the editor preview it too. * * WHY THIS IS NOT A CHILD THEME. It started as a child of Twenty Twenty-Five * and that was wrong. WordPress does not merge preset arrays between parent and * child, it replaces them: declaring our own palette, font sizes and spacing * scale wiped out the parent's slugs (base, contrast, accent-1..6, small, * large, x-large...). Everything still inherited from the parent kept pointing * at CSS variables that no longer existed, including the 404 page, search, * archives and the thirty-odd Twenty Twenty-Five patterns the site owner sees * in the inserter. Since this theme ships its own template for every view the * site actually uses, inheriting bought nothing and cost that. Standing alone * also means a Twenty Twenty-Five update can never move anything here. * * TWO HEADER FIELDS ARE MISSING ON PURPOSE. There is no "Tested up to" because * the theme has never been run against any WordPress at all, and there is no * "accessibility-ready" tag because that is an audited wordpress.org label with * a published checklist, not something a theme grants itself. Add either one * only after doing the work it claims. */ /* * The only two rules in this file, and both are here because theme.json cannot * express them. Everything else lives in theme.json so the site owner sees it * as a control in the editor instead of hidden in a stylesheet. * * 1. The mobile menu open/close buttons ship at exactly 24x24, the floor of * WCAG 2.2 criterion 2.5.8. They are the only navigation control that exists * on a phone, which is where most of this site is read. Negative margin * matches the padding so nothing moves: the target grows, the layout does * not. theme.json has no entry for core/navigation's inner elements. * 2. summary is not an addressable theme.json element, so the accordion would * otherwise keep the browser's default focus ring while every other control * has the themed one. */ .wp-block-navigation__responsive-container-open, .wp-block-navigation__responsive-container-close { padding: 0.625rem; margin: -0.625rem; } .wp-block-details > summary:focus-visible { outline: 2px solid var(--wp--preset--color--tinta); outline-offset: 2px; } /* * The focus ring, only when it helps. * * theme.json can style :focus but not :focus-visible, so the themed ring also * appeared on a plain mouse click, where it reads as a glitch rather than as * guidance. This takes it away in exactly the case the browser says does not * warrant it, and leaves everything else alone: the colour and width stay in * theme.json, where the site owner can still see and change them. * * :focus-visible is what decides, not us. Keyboard focus, and any focus the * browser judges worth showing, keeps its ring. */ a:focus:not(:focus-visible), .wp-element-button:focus:not(:focus-visible), .wp-block-button__link:focus:not(:focus-visible) { outline: none; } /* * The menu toggles are not wp-element-button, so the button styles in * theme.json do not reach them and they keep the browser's default focus ring. */ .wp-block-navigation__responsive-container-open:focus-visible, .wp-block-navigation__responsive-container-close:focus-visible { outline: 2px solid var(--wp--preset--color--tinta); outline-offset: 2px; } /* --- The heading face does not resize the page when it arrives ------------- EB Garamond is self-hosted with font-display: swap, so the first paint uses the fallback and the real face swaps in a moment later. Measured on the server: Georgia sets the same string 16.8 % WIDER than EB Garamond, so the h1 appeared large and visibly shrank once the font landed. These two faces are the same local fonts with size-adjust applied, which brings the fallback to within 0.05 % of the real one. Two of them because the correction differs per font (85.6 % for Georgia, 93.6 % for Times New Roman) and a single face with two local() sources could only carry one number. They sit ahead of the unadjusted names in the stack in theme.json, so a machine with neither still falls through to plain Georgia and then to serif. Line height is unaffected: the theme sets it numerically (1.1, 1.2, 1.7), so it is computed from the declared font-size, which size-adjust does not touch. This cannot live in theme.json: its fontFace entries describe the webfont, and a metric-adjusted local fallback is not a font the editor should offer. */ @font-face { font-family: "Garamond respaldo A"; src: local("Georgia"); size-adjust: 85.6%; font-display: swap; } @font-face { font-family: "Garamond respaldo B"; src: local("Times New Roman"); size-adjust: 93.6%; font-display: swap; } /* ========================================================================== Brand motif and motion layer -------------------------------------------------------------------------- Everything below is here because theme.json genuinely cannot express it: it has no syntax for @keyframes, @supports, @media (prefers-reduced-motion) or pseudo-elements. Colours, sizes and spacing stay in theme.json, where the site owner sees them as controls in the editor. Register: this is a child sleep psychologist, read by exhausted parents at three in the morning. Motion is short, decelerating and never bouncy. Nothing moves that the reader did not ask to move. RECALIBRATED 2026-08-23. The first pass took "light touch" too far and landed under the threshold of perception: 6px on the accordion, 1px on button hover, and a scroll range that finished before the element reached the reading band. The owner opened every page and saw no motion at all, which is the same outcome as having written none of it. Distances roughly doubled and the easing curve was changed. If you are tempted to soften these again, measure first: under about 8px of travel nothing reads as movement. ========================================================================== */ :root { /* Was cubic-bezier(0.22, 1, 0.36, 1), an easeOutQuint that spent 76 % of the distance in the first quarter of the time. Measured frame by frame, the accordion had 1.4px of its 6px left after 60ms: the motion was over before anyone could see it had started. This curve spreads the travel instead of front-loading it, which is what makes a short move readable. */ --cec-ease: cubic-bezier(0.4, 0, 0.2, 1); /* The surface a section sits on, so a decoration can punch a hole in a rule and match whichever band it happens to be on. */ --cec-surface: var(--wp--preset--color--crema); } .has-manta-background-color { --cec-surface: var(--wp--preset--color--manta); } /* --- The separator becomes the moon between two rules --------------------- The same device already used on the construction page, so the holding page and the real site speak one language. */ .wp-block-separator:not(.is-style-dots) { position: relative; overflow: visible; border: 0; height: 1px; background: linear-gradient(to right, transparent, var(--wp--preset--color--salvia), transparent); opacity: 0.75; } .wp-block-separator:not(.is-style-dots)::after { content: "\1F319" / ""; position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%); padding-inline: 0.75rem; background: var(--cec-surface); font-size: 1rem; line-height: 1; } /* --- How lines end -------------------------------------------------------- THE BODY IS JUSTIFIED, AND THAT IS A DECISION OF THE SITE OWNER'S, taken on 07/09/2026 with the measurements in front of her. They are worth keeping here, because justification is not free: word spaces go from a uniform 6.2 px to a median of 24 and a peak of 30 at 1280 px, and to a peak of 41.6 on a 390 px phone. WCAG 1.4.8 advises against justified text for that reason. HYPHENATION WAS TRIED AND REMOVED. `hyphens: auto` cuts the damage a lot - measured in production, the peak word space went from 29.7 px to 15.5 - but it does it by breaking words at the end of a line ("le-vantéis", "sim-plemente") and the owner did not want those. So the spaces carry the whole slack on their own now. If the holes ever become a problem, this is the line that fixes them: `hyphens: auto` on the same rule, with the page declaring its language, which WordPress already does on . `text-wrap: pretty` stays underneath: it costs nothing and picks better break points, which justification benefits from too. WHERE IT IS NOT APPLIED, AND WHY: - Anything centred. A centred paragraph carries `has-text-align-center`, and `main p` would out-specify it and silently un-centre the whole site. - Narrow columns. Measured on /asesoria-de-sueno/: text at reading width runs about 56 characters per line, but inside the plan cards it runs 32, in columns down to 260 px. Below roughly 45 characters there are too few spaces in a line to absorb the slack, so justifying turns them into holes. That covers the plan cards and the numbered steps on the front page, which the owner asked to keep left-aligned by name. Headings are left out on purpose: the destacada quote already uses `balance`, which is the right one for short display text. */ main p, main li { text-wrap: pretty; } /* Headings are balanced site-wide (theme.json), which splits a long one into two halves of the same length. Centred, that reads as intended. Aligned to the left it leaves the first line half empty, as the owner pointed out on the privacy page: there a heading fills its first line and only the words that do not fit go down, even a single one. Plain `wrap`, not `pretty`: `pretty` moves a second word down to keep the last line from holding just one, which is the opposite of what she asked for. */ main :is(h2, h3).wp-block-heading:not(.has-text-align-center) { text-wrap: wrap; } main p:not([class*="has-text-align"]), main li:not([class*="has-text-align"]) { text-align: justify; } /* Narrow columns keep the ragged edge: see the measurement above. A .wp-block-column is narrow by definition, so it is covered wholesale rather than one pattern at a time - the three columns of "Esto no es dejar llorar" were being justified at 32 characters a line, with word spaces reaching 30.3 px, until this was widened on 07/09/2026. */ main .wp-block-group.has-border-color p:not([class*="has-text-align"]), main .wp-block-group.has-border-color li:not([class*="has-text-align"]), main .wp-block-column p:not([class*="has-text-align"]), main .wp-block-column li:not([class*="has-text-align"]), main .cec-paso p:not([class*="has-text-align"]), main .cec-paso li:not([class*="has-text-align"]) { text-align: left; } /* A column heading sat 28 px above its text, less than one line of it, so the two read as one lump. One line of air separates them without breaking the pair apart. */ main .wp-block-column > :is(h2, h3, h4) + * { margin-top: var(--wp--preset--spacing--40); } /* --- The air between sections --------------------------------------------- Two things were stacking up and the result was a 188 px hole, measured on 07/09/2026 between the moon separator that closes the intro of /asesoria-de-sueno/ and the star that opens the next section. WHERE THE 188 CAME FROM: 80 px of padding at the bottom of one section, plus 80 px at the top of the next, plus 28 px of blockGap that the post-content adds BETWEEN them. Same trap as the header one documented in CLAUDE.md: WordPress puts its gap ON TOP of padding the block already has, and nobody asked for it. The templates already set blockGap 0 on the main group; the post-content inside has its own layout and needs saying again. WHY THE SECOND RULE IS A NEGATIVE MARGIN AND NOT LESS PADDING: the padding is written INLINE by every pattern (style="padding-top:var(--wp--preset--spacing--60)"), so a stylesheet cannot lower it without !important. The margin is ours, so it is where the correction goes. It uses the same spacing preset, which means it scales down with it on a phone instead of eating a fixed 40 px there. AND WHY ONLY BETWEEN SECTIONS THAT SHARE A BACKGROUND: where the band changes colour, those 160 px read as the band breathing and look right. Where both sections carry the SAME background there is nothing to separate, so the same gap reads as a mistake - and the section is already closed by a separator and opened by a star. Measured after the change: 120 px. "The same background" has to be spelled out one colour at a time: CSS cannot ask whether two siblings happen to be painted alike. The first pass only covered two sections with no background at all, and missed the pair that actually shows on the front page - two manta bands in a row, still 160 px apart on 07/09/2026. If a new band colour is ever used on a section, add its pair here or the hole comes back. */ .wp-block-post-content > * + * { margin-top: 0; } .wp-block-post-content > .wp-block-group:not(.has-background) + .wp-block-group:not(.has-background), .wp-block-post-content > .has-manta-background-color + .has-manta-background-color, .wp-block-post-content > .has-crema-background-color + .has-crema-background-color, .wp-block-post-content > .has-salvia-background-color + .has-salvia-background-color, .wp-block-post-content > .has-salvia-oscuro-background-color + .has-salvia-oscuro-background-color { margin-top: calc(var(--wp--preset--spacing--60) * -0.5); } /* --- Three ways of not being a plain paragraph ---------------------------- The site owner's complaint on 07/09/2026 was that some texts "se supone que es diferente, pero parece muy similar al previo y posterior". They were not all the same thing, so they do not get the same mark: .cec-apostilla an aside - a remark off to the side of the main thread. A rule down its left edge, which is what an aside has looked like since long before the web. Left-aligned even where the body is justified: an aside is not body text. .cec-promesa a promise, said in the brand's own voice. No rule and no box: it is set in Garamond, which is what the theme already uses for anything that is meant to be looked at rather than read. .cec-remite a pointer to another page, in small type. Deliberately the quietest of the three: it is navigation, not content. What was already there stays as it was: the bordered box says "this is a statement", and the destacada quote says "this is what moves me". Three marks, three jobs, none of them stepping on the others. */ main p.cec-apostilla, main li.cec-apostilla { border-left: 3px solid var(--wp--preset--color--salvia); padding-left: var(--wp--preset--spacing--30); padding-block: 0.25rem; text-align: left; /* The column width includes the rule and the padding. Without this the aside was wider than the column and, centred, its rule stood 15px out to the left of every other text edge. */ box-sizing: border-box; } main .cec-promesa { color: var(--wp--preset--color--salvia-oscuro); line-height: 1.35; } /* Sin color propio: hereda el de su bloque, que es el mismo de la linea que va bajo el boton. En taupe se leia "gris muy clarito" y no parecia un enlace. */ main .cec-remite { color: inherit; } /* --- The tagline, framed -------------------------------------------------- Two short gold rules, one on each side. Isabel asked for "algun detalle decorativo a cada lado del eslogan para destacarlo" on 07/09/2026; it is the small uppercase line that opens the front page ("Dormir en calma, criar con confianza") and the advisory page ("Cuna en Calma"). Rules and not another star: the star already means "a section begins here", and reusing it would say the wrong thing. On a narrow screen the rules shrink rather than squeezing the words, which is what flex would otherwise do. */ main .cec-eslogan { display: flex; align-items: center; justify-content: center; gap: var(--wp--preset--spacing--30); /* En una linea. Medido el 08/09/2026 a 1280 px: el texto en mayusculas con su letter-spacing pide 433 px y el bloque da 571, asi que cabia justo, con los filetes ya encogidos de 56 a 41 px para dejarle sitio. Cabia por CERO pixeles de margen, y cualquier ventana un poco mas estrecha lo partia en dos. Con nowrap el texto manda: los filetes ceden primero, y pueden llegar a desaparecer, que es mejor que romper el eslogan. */ white-space: nowrap; } /* Por debajo de esto ya no hay sitio ni quitando los filetes, asi que se le permite partirse antes que salirse de la pantalla. */ @media (max-width: 34rem) { main .cec-eslogan { white-space: normal; text-wrap: balance; } } /* Filete liso a cada lado. Se probaron seis variantes el 08/09/2026 (luna del separador, filete con punto, rombo, degradado, tres puntos) y se volvio a esta: es la que menos ruido hace al lado de la estrella que abre cada seccion y de la luna que las cierra. */ main .cec-eslogan::before, main .cec-eslogan::after { content: ""; flex: 0 1 2.75rem; height: 1px; background: var(--wp--preset--color--dorado); } /* --- A star over the section heading -------------------------------------- */ main .wp-block-group > h2.wp-block-heading.has-text-align-center::before { content: "\2726" / ""; display: block; margin-bottom: 0.5rem; color: var(--wp--preset--color--dorado); font-size: 0.7em; line-height: 1; animation: cec-twinkle 3.5s infinite ease-in-out; } @keyframes cec-twinkle { 0%, 100% { opacity: 0.35; transform: scale(0.9); } 50% { opacity: 0.85; transform: scale(1.1); } } /* --- Two voices in the section headings ----------------------------------- Ten h2s in the same salvia at the same size read as a table of contents, not as a page. They are not the same kind of thing either. The ones on a manta band are the two moments of recognition and the closes: sentences addressed to the reader. The ones on cream are structural labels. So the band headings become the voice, in ink and at the text weight rather than the label weight, and give up the star, which stays as the mark of a section label. The band is already the gesture there; a star on top of it, right under the moon of the separator, was three gold marks stacked in twenty vertical pixels. Direct child on purpose. "Cuentame vuestro caso" in asesoria-llamada-final sits on manta too, but it is a call to action inside its own bordered card, so it is a third thing and keeps the label treatment. */ main .has-manta-background-color > h2.wp-block-heading { color: var(--wp--preset--color--tinta); font-weight: 400; } main .has-manta-background-color > h2.wp-block-heading.has-text-align-center::before { content: none; } /* --- The secondary button fills in on hover -------------------------------- The three plan buttons are outlined rather than solid, so that choosing a plan and writing to Isabel do not compete as the same kind of act. WordPress ships is-style-outline, but it only removes the fill; it has no hover of its own, and the solid button's hover in theme.json cannot reach it because theme.json has no way to address a block style. Filling in on hover is the one gesture that keeps the two kinds of button related: the secondary becomes the primary under the pointer, rather than inventing a third colour. Both states are salvia oscuro against cream, which measures 5.46:1 for the text and the same for the border, over the 3:1 that 1.4.11 asks of a control's boundary. */ /* Both states are set here, and that is what keeps them out of an !important fight. The colour used to come from the block's textColor attribute, which WordPress emits as a .has-salvia-oscuro-color utility class carrying its own !important; the hover then could not override it without matching that, and the text stayed salvia oscuro on a salvia oscuro fill: 1:1, unreadable. With the attribute gone the class is gone too, and ordinary specificity decides. Which means: DO NOT set a text colour on these buttons from the editor. It would bring the utility class back and take the hover text with it. */ .wp-block-button.is-style-outline > .wp-block-button__link { color: var(--wp--preset--color--salvia-oscuro); } /* The fill is the button's own colour at a tenth, not the colour itself. Filling solid was too loud for a secondary button: measured in luminance, the jump from cream to salvia oscuro is 0.828, which reads as the button changing into a different button. At 10 % it is 0.122 - about seven times gentler, and still clearly more than the 0.095 you get from manta, which turned out to be too close to cream to notice. TEN PER CENT IS NEAR A CEILING, not a round number picked by eye. The text stays salvia oscuro, so the darker the fill the worse it reads against it: 10 % measures 4.80:1, 12 % gives 4.67, and 15 % drops to 4.49 and fails AA. Do not deepen this without re-measuring the text on top of it. manta first as the fallback: color-mix is widely supported but if it is not, a slightly warmer surface is a better outcome than no feedback at all. :focus-visible, not :focus. A clicked link keeps focus, and the WhatsApp and Instagram buttons open a new tab, so on coming back the button was still filled and read as selected. For the same reason the hover fill is limited to real pointers: on a phone :hover sticks after the tap. The reset comes first and has no :hover exception. It holds the outline transparent on a mouse or touch focus, where theme.json's own button :focus would otherwise paint it solid - and a tapped button on a phone is focused AND stuck in :hover, so excluding :hover here brought the dark fill back in exactly the case this is for. The hover rule after it wins back only where there is a real pointer. */ .wp-block-button.is-style-outline > .wp-block-button__link:focus:not(:focus-visible) { background-color: transparent; color: var(--wp--preset--color--salvia-oscuro); } @media (hover: hover) { .wp-block-button.is-style-outline > .wp-block-button__link:hover, .wp-block-button.is-style-outline > .wp-block-button__link:focus:not(:focus-visible):hover { background-color: var(--wp--preset--color--manta); background-color: color-mix( in srgb, var(--wp--preset--color--salvia-oscuro) 10%, var(--wp--preset--color--crema) ); } } .wp-block-button.is-style-outline > .wp-block-button__link:focus-visible { background-color: var(--wp--preset--color--manta); background-color: color-mix( in srgb, var(--wp--preset--color--salvia-oscuro) 10%, var(--wp--preset--color--crema) ); } /* --- WhatsApp and Instagram, as secondary buttons ---------------------------- Below the main "Escríbeme" button in the four contact blocks. Outlined and a step smaller, so the form stays the obvious first choice and these read as the alternative for whoever would rather send a message. The icon is a mask painted in currentColor, so it follows the text through the outline button's hover and needs nothing in the block markup: the site owner can retitle or remove the buttons from the editor like any other. */ .wp-block-button.cec-canal > .wp-block-button__link { display: inline-flex; align-items: center; gap: 0.5em; font-size: var(--wp--preset--font-size--pequeno); padding: 0.6rem 1.25rem; } .wp-block-button.cec-canal > .wp-block-button__link::before { content: ""; flex: none; width: 1.15em; height: 1.15em; background-color: currentColor; -webkit-mask: var(--cec-icono) center / contain no-repeat; mask: var(--cec-icono) center / contain no-repeat; } .cec-canal-whatsapp { --cec-icono: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'%3E%3Cpath d='M17.472 14.382c-.297-.149-1.758-.867-2.03-.967-.273-.099-.471-.148-.67.15-.197.297-.767.966-.94 1.164-.173.199-.347.223-.644.075-.297-.15-1.255-.463-2.39-1.475-.883-.788-1.48-1.761-1.653-2.059-.173-.297-.018-.458.13-.606.134-.133.298-.347.446-.52.149-.174.198-.298.298-.497.099-.198.05-.371-.025-.52-.075-.149-.669-1.612-.916-2.207-.242-.579-.487-.5-.669-.51-.173-.008-.371-.01-.57-.01-.198 0-.52.074-.792.372-.272.297-1.04 1.016-1.04 2.479 0 1.462 1.065 2.875 1.213 3.074.149.198 2.096 3.2 5.077 4.487.709.306 1.262.489 1.694.625.712.227 1.36.195 1.871.118.571-.085 1.758-.719 2.006-1.413.248-.694.248-1.289.173-1.413-.074-.124-.272-.198-.57-.347m-5.421 7.403h-.004a9.87 9.87 0 01-5.031-1.378l-.361-.214-3.741.982.998-3.648-.235-.374a9.86 9.86 0 01-1.51-5.26c.001-5.45 4.436-9.884 9.888-9.884 2.64 0 5.122 1.03 6.988 2.898a9.825 9.825 0 012.893 6.994c-.003 5.45-4.437 9.884-9.885 9.884m8.413-18.297A11.815 11.815 0 0012.05 0C5.495 0 .16 5.335.157 11.892c0 2.096.547 4.142 1.588 5.945L.057 24l6.305-1.654a11.882 11.882 0 005.683 1.448h.005c6.554 0 11.89-5.335 11.893-11.893a11.821 11.821 0 00-3.48-8.413Z'/%3E%3C/svg%3E"); } .cec-canal-instagram { --cec-icono: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'%3E%3Cpath d='M7.0301.084c-1.2768.0602-2.1487.264-2.911.5634-.7888.3075-1.4575.72-2.1228 1.3877-.6652.6677-1.075 1.3368-1.3802 2.127-.2954.7638-.4956 1.6365-.552 2.914-.0564 1.2775-.0689 1.6882-.0626 4.947.0062 3.2586.0206 3.6671.0825 4.9473.061 1.2765.264 2.1482.5635 2.9107.308.7889.72 1.4573 1.388 2.1228.6679.6655 1.3365 1.0743 2.1285 1.38.7632.295 1.6361.4961 2.9134.552 1.2773.056 1.6884.069 4.9462.0627 3.2578-.0062 3.668-.0207 4.9478-.0814 1.28-.0607 2.147-.2652 2.9098-.5633.7889-.3086 1.4578-.72 2.1228-1.3881.665-.6682 1.0745-1.3378 1.3795-2.1284.2957-.7632.4966-1.636.552-2.9124.056-1.2809.0692-1.6898.063-4.948-.0063-3.2583-.021-3.6668-.0817-4.9465-.0607-1.2797-.264-2.1487-.5633-2.9117-.3084-.7889-.72-1.4568-1.3876-2.1228C21.2982 1.33 20.628.9208 19.8378.6165 19.074.321 18.2017.1197 16.9244.0645 15.6471.0093 15.236-.005 11.977.0014 8.718.0076 8.31.0215 7.0301.0839m.1402 21.6932c-1.17-.0509-1.8053-.2453-2.2287-.408-.5606-.216-.96-.4771-1.3819-.895-.422-.4178-.6811-.8186-.9-1.378-.1644-.4234-.3624-1.058-.4171-2.228-.0595-1.2645-.072-1.6442-.079-4.848-.007-3.2037.0053-3.583.0607-4.848.05-1.169.2456-1.805.408-2.2282.216-.5613.4762-.96.895-1.3816.4188-.4217.8184-.6814 1.3783-.9003.423-.1651 1.0575-.3614 2.227-.4171 1.2655-.06 1.6447-.072 4.848-.079 3.2033-.007 3.5835.005 4.8495.0608 1.169.0508 1.8053.2445 2.228.408.5608.216.96.4754 1.3816.895.4217.4194.6816.8176.9005 1.3787.1653.4217.3617 1.056.4169 2.2263.0602 1.2655.0739 1.645.0796 4.848.0058 3.203-.0055 3.5834-.061 4.848-.051 1.17-.245 1.8055-.408 2.2294-.216.5604-.4763.96-.8954 1.3814-.419.4215-.8181.6811-1.3783.9-.4224.1649-1.0577.3617-2.2262.4174-1.2656.0595-1.6448.072-4.8493.079-3.2045.007-3.5825-.006-4.848-.0608M16.953 5.5864A1.44 1.44 0 1 0 18.39 4.144a1.44 1.44 0 0 0-1.437 1.4424M5.8385 12.012c.0067 3.4032 2.7706 6.1557 6.173 6.1493 3.4026-.0065 6.157-2.7701 6.1506-6.1733-.0065-3.4032-2.771-6.1565-6.174-6.1498-3.403.0067-6.156 2.771-6.1496 6.1738M8 12.0077a4 4 0 1 1 4.008 3.9921A3.9996 3.9996 0 0 1 8 12.0077'/%3E%3C/svg%3E"); } /* --- The footer links are big enough to hit with a tired thumb ------------- They are stacked one per line inside a paragraph, so each was only as tall as its own text: 20px, with 10px between them. That squeaks past WCAG 2.5.8 on the spacing exception, and still gets mistapped by someone holding a phone in one hand at three in the morning. Vertical padding on an inline element grows the hit area without touching the line box, so the target goes to 28px and the footer does not grow at all. 4px, not more, and this was measured: at 6px the targets overlap by 2px and a tap near the edge would fire the wrong link, which is worse than the problem. If the footer line-height ever changes, measure again before raising this. */ footer a { padding-block: 4px; /* Clear of the descenders: at the default offset the underline ran through the "_" of @cuna_en_calma, which then read as "@cuna en calma". */ text-underline-offset: 0.25em; } /* --- A long address does not push the page sideways ------------------------ info@cunaencalma.com sets at 359px and has no break opportunity in it, so at 200 % text size on a 390px phone it ran the document out to 417px and the page scrolled sideways. WCAG 1.4.4 asks for 200 % without that. anywhere rather than break-word because it also shrinks the min-content width, which is what stops the containing paragraph from being pushed wide in the first place. Scoped to mailto so ordinary prose keeps normal hyphenation-free wrapping. theme.json has no selector for an attribute, so it lives here. */ a[href^="mailto:"] { overflow-wrap: anywhere; } /* --- The header does not sprawl wider than the page it belongs to ---------- The bar used plain alignwide, so on a large screen it stretched to 1184px while the text under it sat at 736: the logo started 224px outside the column it heads, and the first screen read as a wide bar floating over a narrow page. Closing that gap from the other side does not work and was measured: taking the hero out to 880px puts its paragraph at 98 characters per line, well past the 45-75 that is comfortable. The text has to stay where it is, so the bar comes in instead. 62rem is the compromise. Below about 880px the logo and the menu lose the air between them and the bar reads as cramped, which is worse than the gap it fixes; 62rem keeps that breathing room while halving the misalignment. If a sixth menu item is ever added, check this still holds. */ header .wp-block-group.alignwide { max-width: 62rem; } /* --- Photographs get the same softened corner as the boxes ----------------- The site rounds every box it draws at 12px; a portrait sitting square in the middle of them read as the one hard-edged thing on the page. Why not theme.json: the site logo in parts/header.html is a core/image, not a core/site-logo, so a radius on core/image would round the logo too. Scoping it to main is the only way to say "content images" here. IT IS 12px, THE SAME AS EVERY OTHER BOX. It was 16 for a while, on the theory that the same radius reads smaller on a large photo than on a small card. That theory does not survive the real page: on 08/09/2026, with Isabel's photo in place, the 415 px picture at 16px sat right above the green band at 12px, which is 1120 px wide. The bigger box had the tighter corner, and the eye catches that immediately. Whatever the argument, two shapes stacked one on top of the other have to agree. Note the placeholder carries its own rounded frame inside the SVG: that dashed rectangle is drawn art, not CSS, so a radius here cannot soften it. Both were changed together. */ main figure.wp-block-image img { border-radius: 12px; } /* --- The pull quote ------------------------------------------------------- Registered as a block style in functions.php, so it is a choice in the block sidebar and not something only this stylesheet knows about. The quote in theme.json is a gold rule on the left, which is right for a quote inside running text. This one has the opposite job: it stops the page. It drops the left rule for a short gold one above, centres, and holds its own measure so the line length stays readable at the larger size. balance rather than the pretty inherited from theme.json: this is a short centred block where even line lengths matter more than a single orphan. */ main .wp-block-quote.is-style-destacada { max-width: 42rem; margin-inline: auto; margin-block: var(--wp--preset--spacing--50); border: 0; padding-left: 0; line-height: 1.4; text-align: center; } /* inherit, so the centring above beats the justified body text rule, which would otherwise reach these paragraphs and open wide gaps between words. */ main .wp-block-quote.is-style-destacada p { text-wrap: balance; text-align: inherit; } /* When the quote is the only thing inside its container, that container is already providing the air. Adding ours on top leaves the box half empty. */ main .wp-block-quote.is-style-destacada:only-child { margin-block: 0; } main .wp-block-quote.is-style-destacada::before { content: ""; display: block; width: 3rem; height: 2px; margin: 0 auto var(--wp--preset--spacing--30); background: var(--wp--preset--color--dorado); } /* --- The accordion question is the whole card ----------------------------- The padding used to sit on
, so only the text of the question answered a tap: between 37 % and 61 % of each card's height. theme.json now puts it on the summary, and this draws the marker: the browser's black triangle, with the second line of a long question starting under it, gives way to a "+" in the heading face that turns into a "×" when open. Positioned, not flex: Safari has a history of ignoring display: flex on , and a marker laid out as an absolute box does not depend on it. display: block drops the list-item marker everywhere except old WebKit, which needs its own pseudo-element hidden. */ .wp-block-details > summary { display: block; position: relative; padding-right: calc(var(--wp--preset--spacing--30) + 1.75rem); list-style: none; } .wp-block-details > summary::-webkit-details-marker { display: none; } .wp-block-details > summary::after { content: "+"; /* Empty alternative text: without it a screen reader read "más" at the end of every question. The line above is the fallback where this syntax is not understood. */ content: "+" / ""; position: absolute; top: var(--wp--preset--spacing--30); right: var(--wp--preset--spacing--30); font-family: var(--wp--preset--font-family--garamond); font-size: 1.75rem; font-weight: 400; line-height: 1; color: var(--wp--preset--color--salvia-oscuro); transition: transform 200ms var(--cec-ease); } .wp-block-details[open] > summary::after { transform: rotate(45deg); } /* The air under the answer. It cannot live in theme.json: the block carries is-layout-flow, and core's `:root :where(.is-layout-flow) > :last-child` sets the bottom margin to 0 with the same weight, printed later, so the answer touched the bottom of the card. A class plus :last-child outweighs both. display: flow-root on
keeps the margin inside the card. */ .wp-block-details > :last-child { margin-bottom: var(--wp--preset--spacing--30); } /* --- The accordion unfolds instead of jumping ----------------------------- Two layers, and the fallback comes first. Everywhere, the content fades and slides in. Where ::details-content and interpolate-size exist, the panel height itself animates instead and the fade steps aside. */ .wp-block-details > summary { transition: color 200ms var(--cec-ease); } .wp-block-details[open] > summary ~ * { animation: cec-unfold 320ms var(--cec-ease) both; } @keyframes cec-unfold { from { opacity: 0; transform: translateY(-0.875rem); } to { opacity: 1; transform: none; } } /* The panel itself grows, where the browser can do it. THIS WAS TRIED ONCE AND REMOVED, so read this before touching it. The note said interpolate-size left the panel at 12px with a 194px answer inside, and that the text was clipped. Re-measured on 2026-08-23: with the transition taken out, block-size:auto on the pseudo-element resolves to the full height correctly (221.8px for a 194px answer plus padding). What never started was the transition, and it never started because Chrome does not run CSS transitions in a background tab, which is the only place this had ever been measured from. The 12px was almost certainly that artefact and not a real clip. Why it is worth having: what the keyframes above animate is the content INSIDE the panel, not the panel. The box snaps to its full height and the text fades in within it, which is why it reads as abrupt however long you make it, and why there was no closing animation at all: `[open] > summary ~ *` can only ever run on the way open. A transition runs both ways. The fade-and-slide stays as the fallback: it is switched off only inside this @supports, so a browser without ::details-content keeps exactly what it had. IF THE TEXT IS EVER CLIPPED AGAIN, this block is the first thing to delete; removing it restores the previous behaviour with nothing else to undo. */ @supports selector(::details-content) and (interpolate-size: allow-keywords) { :root { interpolate-size: allow-keywords; } /* One movement, not two: the panel grows, so the content stays put. */ .wp-block-details[open] > summary ~ * { animation: none; } /* theme.json gives summary a smaller bottom padding only while [open]. That attribute is removed the instant you click to close, so the gap changed in one frame and the answer jumped upwards just before the panel started collapsing. Transitioning it over the same 380ms makes the gap close with the panel instead of ahead of it. */ .wp-block-details > summary { transition: color 200ms var(--cec-ease), padding-bottom 380ms var(--cec-ease); } .wp-block-details::details-content { block-size: 0; overflow: hidden; opacity: 0; transition: block-size 380ms var(--cec-ease), opacity 260ms var(--cec-ease), content-visibility 380ms allow-discrete; } .wp-block-details[open]::details-content { block-size: auto; opacity: 1; } } /* --- Micro-interactions ---------------------------------------------------- */ .wp-element-button, .wp-block-button__link { transition: background-color 200ms var(--cec-ease), transform 200ms var(--cec-ease), box-shadow 200ms var(--cec-ease); } .wp-element-button:hover, .wp-block-button__link:hover { transform: translateY(-2px); box-shadow: 0 6px 18px rgba(44, 42, 38, 0.20); } .wp-element-button:active, .wp-block-button__link:active { transform: translateY(0); box-shadow: none; transition-duration: 120ms; } /* The underline firms up on hover instead of blinking on. */ main a:not(.wp-element-button):not(.wp-block-button__link) { text-decoration-color: color-mix(in srgb, currentColor 45%, transparent); transition: text-decoration-color 200ms var(--cec-ease), color 200ms var(--cec-ease); } main a:not(.wp-element-button):not(.wp-block-button__link):hover { text-decoration-color: currentColor; color: var(--wp--preset--color--tinta); } /* Plan cards answer the pointer with a shadow, so they read as pickable. Only boxes that hold a button: the extra-session box and the statements have nothing to click, and a box that reacts to the mouse promises a click that does nothing. Only where a real pointer hovers: on a phone the hover state sticks after a tap and the shadow stayed on. No lift either: the arrival animation below fills its end state, transform: none, which overrides any transform set here, so the lift never showed anyway. */ main .wp-block-group.has-border-color { transition: box-shadow 240ms var(--cec-ease); } @media (hover: hover) { main .wp-block-group.has-border-color:has(.wp-block-button):hover { box-shadow: 0 10px 28px rgba(44, 42, 38, 0.12); } } /* --- The opening ---------------------------------------------------------- The one orchestrated moment of the site: the hero arrives in reading order instead of all at once. COVER EVERY CHILD OR THE ORDER BREAKS. There used to be five nth-child rules and the hero has six elements, so the sixth kept the default delay of 0 and arrived FIRST: on the front page the button appeared before the strapline it is meant to follow. It went unnoticed for days because nothing looks broken, it just reads oddly. The nth-child(n+7) rule below is the backstop: anything past the sixth does not animate at all rather than jumping the queue. TIMING. It was 600ms with delays up to 380, so the hero was not complete for 980ms. That is a long time to hold still in front of someone who came to read and is holding a baby. 450ms with 50ms steps finishes at 750 and still reads as one thing arriving in order rather than five separate fades. */ @media (prefers-reduced-motion: no-preference) { .wp-block-post-content > .wp-block-group:first-child > * { animation: cec-enter 450ms var(--cec-ease) both; } .wp-block-post-content > .wp-block-group:first-child > *:nth-child(1) { animation-delay: 50ms; } .wp-block-post-content > .wp-block-group:first-child > *:nth-child(2) { animation-delay: 100ms; } .wp-block-post-content > .wp-block-group:first-child > *:nth-child(3) { animation-delay: 150ms; } .wp-block-post-content > .wp-block-group:first-child > *:nth-child(4) { animation-delay: 200ms; } .wp-block-post-content > .wp-block-group:first-child > *:nth-child(5) { animation-delay: 250ms; } .wp-block-post-content > .wp-block-group:first-child > *:nth-child(6) { animation-delay: 300ms; } /* Sobre mi wraps its whole page in one root group, so from here down these are whole sections far below the fold. Animating them buys nothing. */ .wp-block-post-content > .wp-block-group:first-child > *:nth-child(n+7) { animation: none; } } @keyframes cec-enter { from { opacity: 0; transform: translateY(1.25rem); } to { opacity: 1; transform: none; } } /* --- Arriving on scroll ---------------------------------------------------- Scroll-driven, so there is no JavaScript that can fail and leave the page looking empty. The hidden state lives ONLY inside @supports: a browser without the feature never hides anything at all. PICKING THE RANGE IS NOT A MATTER OF TASTE, so measure before changing it. The cover range is the viewport height plus the element height, and for a 28px heading the viewport dominates completely: cover 18% finished the fade with the element still at 73 % of screen height, and cover 30% only moved that to 69 %. Both died in the bottom third, where nobody is looking, which is why this read as "no animation at all" twice. cover 50% lands it between 35 % and 50 % of screen height across element sizes and viewports, i.e. at or just above the middle: late enough to be seen, early enough that nothing is half-faded in the band where people read. Deliberately three places only: the plan cards, the numbered steps and the section headings. If every paragraph appeared, the site would feel slow. */ @supports (animation-timeline: view()) { @media (prefers-reduced-motion: no-preference) { main .wp-block-group.has-border-color, main .wp-block-columns > .wp-block-column, main .wp-block-group > .wp-block-heading { animation: cec-arrive 400ms var(--cec-ease) both; animation-timeline: view(); animation-range: entry 0% cover 50%; } /* The hero is already on screen at load and has its own entrance. */ .wp-block-post-content > .wp-block-group:first-child .wp-block-heading { animation-timeline: auto; animation-range: normal; animation-name: cec-enter; } /* Boxes taller than the screen never reach "cover 50%" while anyone is reading them: at 1280 the plan cards are 1113px tall and were read at 56-83 % opacity. A fixed distance instead: the box is fully in once its top is 240px into the screen, whatever its height. */ main .wp-block-group.has-border-color { animation-range: entry 0% entry 240px; } /* A heading inside a box arrives with its box. Animated on its own as well, it faded in a second time inside a box that was already fading. */ main .has-border-color .wp-block-heading { animation: none; } } } @keyframes cec-arrive { from { opacity: 0; transform: translateY(2.5rem); } to { opacity: 1; transform: none; } } /* --- Nobody gets motion sick because of this site -------------------------- */ @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; } .wp-element-button:hover, .wp-block-button__link:hover, main .wp-block-group.has-border-color:has(.wp-block-button):hover { transform: none; box-shadow: none; } /* The universal reset above is *, *::before, *::after, and none of those match ::details-content. Without naming it the panel would keep growing over 380ms for someone who asked for no motion at all. */ .wp-block-details::details-content, .wp-block-details > summary { transition-duration: 0.01ms !important; } } /* --- El formulario de contacto, dentro del sistema ------------------------ Fluent Forms trae su propia hoja y no pregunta: tipografía de sistema en las etiquetas a 22 px, campos a 13,3 px (el tamaño por defecto del navegador, porque el plugin no lo fija), bordes gris #DADBDD y radios de 7 px. Nada de eso es del tema, y en la página de la que depende el negocio se nota. Esto NO rediseña el formulario: lo devuelve a lo que ya existe. Cada valor de aquí sale de theme.json, no hay ni un color ni un radio ni una curva nuevos. LA ÚNICA EXCEPCIÓN es el color de error, más abajo, y está razonada ahí. POR QUÉ ES TAN ESPECÍFICO EL SELECTOR. La hoja del plugin gana por especificidad en varios sitios, así que se ancla en .fluentform. No se usa !important: si algún día hace falta, es señal de que el plugin cambió algo y conviene mirarlo, no taparlo. Ver el landmine de las clases has-*-color. -------------------------------------------------------------------------- */ .fluentform .ff-el-group, .fluentform .ff-el-input--label label, .fluentform .ff-el-form-control, .fluentform .ff-btn-submit { font-family: var(--wp--preset--font-family--sistema); } /* Las etiquetas eran más grandes que el propio texto de la página. */ .fluentform .ff-el-input--label label { font-size: var(--wp--preset--font-size--base); font-weight: 500; line-height: 1.4; color: var(--wp--preset--color--tinta); margin-bottom: 0.4rem; } /* El asterisco de obligatorio venía en rojo del plugin. Salvia oscuro sobre crema da 5,5:1, y el estado real lo comunica el atributo required, no el color. */ /* OJO al anidamiento: las clases ff-el-is-required y asterisk-right van en el CONTENEDOR .ff-el-input--label, no en el grupo. Con el selector puesto un nivel mas arriba no aplica y el asterisco se queda en el rosa del plugin (rgb(245,108,108)), que sobre crema no llega al contraste minimo. */ .fluentform .ff-el-input--label.ff-el-is-required.asterisk-right label:after, .fluentform .ff-el-input--label.ff-el-is-required.asterisk-left label:before { color: var(--wp--preset--color--salvia-oscuro); } .fluentform .ff-el-form-control { font-size: var(--wp--preset--font-size--base); line-height: 1.5; color: var(--wp--preset--color--tinta); background-color: #fff; /* Taupe puro sobre blanco da 2,66:1 y WCAG 1.4.11 pide 3:1 para el borde de un control. Se oscurece con tinta, que sigue siendo la paleta. */ border: 1px solid color-mix(in srgb, var(--wp--preset--color--taupe) 62%, var(--wp--preset--color--tinta)); border-radius: 12px; padding: 0.7rem 0.9rem; /* 48 px de alto: por encima del mínimo cómodo para un pulgar, y esta página se lee sobre todo de madrugada y con una mano. */ min-height: 48px; box-shadow: none; transition: border-color 160ms ease, box-shadow 160ms ease; } .fluentform textarea.ff-el-form-control { min-height: 8rem; } /* Taupe alone is 2.66:1 on the white field. Mixed with ink it reaches 4.8:1 and still reads lighter than what the family types. */ .fluentform .ff-el-form-control::placeholder { color: color-mix(in srgb, var(--wp--preset--color--taupe) 62%, var(--wp--preset--color--tinta)); opacity: 1; } /* El mismo anillo de foco que el resto del sitio, y solo cuando el navegador dice que ayuda. */ .fluentform .ff-el-form-control:focus-visible { outline: 2px solid var(--wp--preset--color--tinta); outline-offset: 2px; border-color: var(--wp--preset--color--salvia-oscuro); } .fluentform .ff-el-form-control:focus:not(:focus-visible) { outline: none; border-color: var(--wp--preset--color--salvia-oscuro); } /* Texto de ayuda: el tamaño pequeño del tema, no el gris del plugin. */ .fluentform .ff-el-help-message { font-size: var(--wp--preset--font-size--pequeno); line-height: 1.6; color: var(--wp--preset--color--tinta); opacity: 0.85; margin-top: 0.35rem; } /* El icono de ayuda venía en azul, que no existe en esta paleta. */ .fluentform .ff-el-tooltip { color: var(--wp--preset--color--salvia-oscuro); } /* Casillas y opciones: el navegador las pinta con su azul si no se le dice otra cosa, y se agrandan para poder acertar con el dedo. */ .fluentform input[type="radio"], .fluentform input[type="checkbox"] { accent-color: var(--wp--preset--color--salvia-oscuro); /* 24 px clavados: es el minimo de WCAG 2.5.8 para un objetivo tactil, y 1,15rem se quedaba en 18,4. */ width: 24px; height: 24px; min-height: 0; flex: 0 0 auto; /* Sin esto la casilla queda pegada a su texto: «[]He leido y acepto...». El margen va en el propio control y no en el texto porque la casilla de privacidad vive dentro de un display:table-cell del plugin, donde un margen puesto en el hermano no llega. */ margin-inline-end: 0.6rem; /* Misma cuenta que la casilla de privacidad: media linea menos medio cuadrado. Con vertical-align: middle quedaban 2 px bajos. */ vertical-align: top; margin-block-start: calc((1.6em - 24px) / 2); } /* * La casilla de privacidad, alineada con la PRIMERA LINEA de su texto. * * El plugin la monta en una tabla de dos celdas y le pone 8px de padding * arriba, con lo que la casilla cae 5 px por debajo del centro del texto. Se ve. * * No se centra con vertical-align: middle a proposito: en movil el texto ocupa * dos lineas, y entonces «middle» centraria la casilla contra el bloque entero * y quedaria flotando en mitad del parrafo. Lo correcto es alinearla con la * primera linea. * * El desplazamiento se CALCULA, no se pone a ojo: media linea menos medio * cuadrado. Asi sigue cuadrando cuando la tipografia fluida cambia de tamano * entre 390 y 1920 px, que es justo donde un numero fijo se rompe. */ .fluentform .ff_tc_checkbox { width: 1px; padding: 0 1rem 0 0; vertical-align: top; font-size: var(--wp--preset--font-size--base); line-height: 1.6; } .fluentform .ff_tc_checkbox input[type="checkbox"] { margin-block-start: calc((1.6em - 24px) / 2); margin-inline-end: 0; vertical-align: top; } .fluentform .ff_tc_checkbox + td, .fluentform .ff-el-tc .ff_tc_content { vertical-align: top; line-height: 1.6; } .fluentform .ff-el-form-check-label, .fluentform .ff_gdpr_field + label, .fluentform .ff-el-tc label { font-size: var(--wp--preset--font-size--base); line-height: 1.6; color: var(--wp--preset--color--tinta); } /* Cada opción, con sitio para el dedo. */ .fluentform .ff-el-form-check { padding-block: 0.35rem; } /* El botón, igual que cualquier otro botón del sitio: los valores son los mismos que elements.button de theme.json. Se repiten aquí porque el plugin dibuja el suyo fuera del alcance de .wp-element-button. */ .fluentform .ff-btn-submit { background-color: var(--wp--preset--color--salvia-oscuro); color: var(--wp--preset--color--crema); border: 0; border-radius: 999px; padding: 0.85rem 1.75rem; min-width: 10rem; font-size: var(--wp--preset--font-size--base); font-weight: 600; line-height: 1.2; cursor: pointer; transition: background-color 160ms ease; } .fluentform .ff-btn-submit:hover, .fluentform .ff-btn-submit:focus { background-color: #4C563F; color: var(--wp--preset--color--crema); } .fluentform .ff-btn-submit:focus-visible { outline: 2px solid var(--wp--preset--color--tinta); outline-offset: 2px; } .fluentform .ff-btn-submit:focus:not(:focus-visible) { outline: none; } /* * EL ÚNICO COLOR NUEVO DE TODO EL TEMA, y se añade a sabiendas. * * Un formulario tiene un estado que esta web no tenía: el error de validación. * La paleta no da nada que sirva. `dorado` sobre crema da 1,8:1, ilegible; * `taupe` da 2,2:1. Y decirlo solo con texto en tinta deja el error * indistinguible del resto de la página justo cuando alguien está atascado. * * #A03328 sobre crema da 6,1:1, por encima de AA, y es un rojo apagado que * convive con la paleta en vez de gritar. El color NO es el único indicador: * el mensaje va en texto y el campo queda marcado con aria-invalid. */ .fluentform .ff-el-is-error .ff-el-form-control, .fluentform .ff-el-form-control[aria-invalid="true"] { border-color: #A03328; } .fluentform .error, .fluentform .text-danger, .fluentform .ff-el-is-error .error { color: #A03328; font-size: var(--wp--preset--font-size--pequeno); line-height: 1.6; margin-top: 0.35rem; } /* El aviso de éxito, por si algún día se deja el mensaje en vez de redirigir. */ .fluentform .ff-message-success { color: var(--wp--preset--color--tinta); background-color: var(--wp--preset--color--manta); border: 0; border-radius: 12px; padding: var(--wp--preset--spacing--30); } @media (prefers-reduced-motion: reduce) { .fluentform .ff-el-form-control, .fluentform .ff-btn-submit { transition: none; } } /* * El texto de ayuda NO puede vivir en un globo de ayuda. * * Fluent Forms lo esconde por defecto tras un icono que hay que sobrevolar. En * este formulario, la ayuda del campo abierto dice literalmente "no hace falta * que me cuentes detalles medicos aqui": es la frase que evita que una madre * escriba la historia clinica de su hijo en un campo que va por correo. Ocultar * eso tras un hover es esconderlo de quien va con teclado, con lector de * pantalla, y de cualquiera con el dedo en una pantalla tactil, donde el hover * no existe. * * El ajuste helpMessagePlacement del formulario se pone a "after_label" para que * salga como texto. Esto es el respaldo por si alguien lo cambia sin querer. */ .fluentform .ff-el-tooltip { display: none; } .fluentform .ff-el-help-message { display: block; } /* --- La letra pequena no puede correr tanto como el texto normal ---------- Comparte la columna de 640 px con el texto de lectura, pero es mas pequena, asi que le caben mas caracteres: 82 por linea, medidos en las cinco paginas. El rango bueno son 45-75. Por encima, el ojo pierde la linea al volver a la izquierda, y esto es letra que se lee cansado y de madrugada. Se acota en `ch` y no en pixeles: asi sigue valiendo cuando la tipografia fluida cambia de tamano entre 390 y 1920 px. Donde ya es estrecha (tarjetas, columnas del pie) no hace nada, porque un max-width solo actua si hay mas sitio del que hace falta. OJO CON LA UNIDAD: `ch` NO es «un caracter». Mide el ancho del glifo «0», que en esta tipografia es bastante mas ancho que la letra media de un texto en espanol. Medido aqui: 70ch dan 82 caracteres reales por linea, no 70. Poner el numero que quieres de caracteres se lee bien y esta mal. El valor de abajo sale de medir, no de la equivalencia intuitiva. ------------------------------------------------------------------------- */ main .has-pequeno-font-size { /* 60ch ~ 70 caracteres reales. Ver el aviso de arriba. */ max-width: 60ch; } main .has-pequeno-font-size.has-text-align-center { margin-inline: auto; } /* Except a left-aligned note right under a row of buttons, which is the email line under WhatsApp and Instagram on /contacto/. The constrained layout centres any block narrower than the column, with !important, so the 60ch measure pushed the note in from the left edge the buttons start on. Two lines of text do not need the measure; lining up with the buttons does. */ main .wp-block-buttons + .has-pequeno-font-size:not(.has-text-align-center) { max-width: var(--wp--style--global--content-size); } /* Any other left-aligned small note keeps its 60ch measure but starts on the column edge, like the text around it. The constrained layout centred it with !important, so "Formas de pago…" or "Última actualización…" stood 48px in from everything else. The margin puts its left edge where the column's is: half of what the container has beyond the column width. */ main .is-layout-constrained > p.has-pequeno-font-size:not([class*="has-text-align"]):not(.cec-apostilla) { margin-left: max(0px, (100% - var(--wp--style--global--content-size)) / 2) !important; margin-right: auto !important; } /* --- The extra-session box on /asesoria-de-sueno/ -------------------------- It spans the full wide row under the three plan cards. From 782 px it is centred, as the site owner chose, and the description gets a wider measure than the 60ch above so it sits on two lines from about 900 px up, which keeps the box low; `balance` makes the two lines the same length. On a phone it stays left-aligned like every other block, since a single centred box among left-aligned ones looked out of place there. It hangs on the heading anchor, so the title can be reworded freely. A block given its own alignment in the editor carries a has-text-align-* class and is left out, the same exclusion the bordered-box rule near the top of this file uses, so that choice still wins over the centring. ------------------------------------------------------------------------- */ @media (min-width: 782px) { main .wp-block-group:has(> #sesion-adicional) > :not([class*="has-text-align"]) { text-align: center; margin-inline: auto; } main .wp-block-group:has(> #sesion-adicional) > .has-pequeno-font-size { max-width: 90ch; text-wrap: balance; } } /* --- Where you are, in the menu --------------------------------------------- functions.php marks the link of the page being read with aria-current. An underline in salvia oscuro (5.5:1 on cream) shows it; the gold of the tagline rules is 1.67:1, too faint for something that says where you are. The same rule reaches the links of the open mobile menu. */ .wp-block-navigation a[aria-current="page"] { text-decoration: underline; text-decoration-color: var(--wp--preset--color--salvia-oscuro); text-decoration-thickness: 2px; text-underline-offset: 0.45em; } /* --- The footer, two by two on a narrow screen ----------------------------- With the "La web" column the footer has four, and from 782px, where columns stop stacking, to about 800px each is 166px wide: info@cunaencalma.com needs about 170px and broke in the middle of the word. Up to 55rem the four go in two rows of two; above that they fit in one with room to spare. */ @media (min-width: 782px) and (max-width: 55rem) { footer .wp-block-columns { flex-wrap: wrap !important; } footer .wp-block-columns > .wp-block-column { flex-basis: 40% !important; } } /* --- Stacked columns on a phone -------------------------------------------- Columns stack below 782px with a 20px gap between them, less than the 28px between a heading and its own text, so each heading read as the end of the block above it ("Esto no es dejar llorar"), and the same in the footer, now four columns long on a phone. A gap of a section step keeps every heading with the text it introduces. */ @media (max-width: 781px) { main .wp-block-columns, footer .wp-block-columns { row-gap: var(--wp--preset--spacing--50); } } /* --- The header on a tablet held upright ------------------------------------ Between about 600px and 876px the menu does not fit beside the logo and wraps to a second row, which space-between left hanging on the left under a centred page. Centred, both rows line up with the hero below them, and the header loses 19px at 768. */ @media (min-width: 600px) and (max-width: 55rem) { header .wp-block-group.alignwide { justify-content: center; row-gap: var(--wp--preset--spacing--20); } } /* --- El menú móvil --------------------------------------------------------- Ocupa la pantalla, centrado, y entra y sale con un fundido. WordPress lo trae casi sin vestir: sin padding, con scroll horizontal porque coloca el botón de cerrar 10 px por fuera, y con una entrada que es un fade de 0,1 s y ninguna salida. SE PROBÓ UN CAJÓN LATERAL Y SE DESCARTÓ. Entraba desde la derecha con la página velada detrás. Se veía raro (parecía salir del centro y luego recolocarse), dejaba el botón de cerrar a distinta altura que la hamburguesa, y cada pieza traía su propia pelea con la cascada del núcleo. Un menú a pantalla completa con un fundido hace el mismo trabajo sin nada de eso. No lo reintentes sin un motivo mejor que «queda más moderno». TODO VA DENTRO DE LA MEDIA QUERY de 599 px, el mismo punto de corte que usa el núcleo para `overlayMenu: mobile`. Fuera de ella este mismo contenedor ES el menú de escritorio, y una opacidad 0 sin acotar lo dejaría invisible. -------------------------------------------------------------------------- */ @media (max-width: 599px) { /* * ESTADO CERRADO, y además el que gobierna la SALIDA. * * Aquí se repite el aspecto de panel (fondo, columna, tamaño) porque al * cerrar WordPress quita la clase `is-menu-open` y con ella se va todo eso, * mientras la transición mantiene el elemento visible un instante más. Sin * esto se veían los enlaces en fila y sin fondo pegados arriba mientras se * desvanecían. Nada de esto se ve con el menú del todo cerrado, porque * entonces es `display: none`. */ .wp-block-navigation__responsive-container { box-sizing: border-box; inset: 0; z-index: 100000; flex-direction: column; overflow: auto; color: var(--wp--preset--color--salvia-oscuro); /* Arriba, el mismo espacio que la cabecera (spacing 30), para que el botón de cerrar caiga a la altura de la hamburguesa que lo abrió. */ padding: var(--wp--preset--spacing--30) var(--wp--preset--spacing--30) var(--wp--preset--spacing--50); opacity: 0; transition: opacity 180ms var(--cec-ease), display 180ms allow-discrete; } /* * El fondo, también durante la salida, y aquí sí hace falta `!important`. * El núcleo escribe * :not(.is-menu-open.is-menu-open) { background-color: inherit !important } * duplicando la clase para subirse la especificidad. A un `!important` solo * se le gana con otro. */ .wp-block-navigation__responsive-container:not(.is-menu-open.is-menu-open) { background-color: var(--wp--preset--color--crema) !important; color: var(--wp--preset--color--salvia-oscuro) !important; } /* * EL SELECTOR ES ASÍ DE LARGO PORQUE EL DEL NÚCLEO LO ES. WordPress escribe * `.wp-block-navigation:not(.has-background) .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay)`, * cinco clases: especificidad 0,5,0. Con menos, el fondo salía blanco. */ .wp-block-navigation:not(.has-background) .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) { background-color: var(--wp--preset--color--crema); } /* * LA ENTRADA ES UNA ANIMACIÓN Y NO UNA TRANSICIÓN, a propósito. * * Lo natural sería una transición con `@starting-style`, y está soportado, * pero no se ve: el menú pasa de no estar dibujado (display: none) a * estarlo, y ahí la transición depende de que el navegador acepte el estado * de partida en el mismo fotograma en que se añade la clase. Una animación * no depende de eso: si el elemento se dibuja con la clase, se ejecuta. * * Y sustituye a la del núcleo (`overlay-menu__fade-in-animation`), que si no * corre por debajo: un fundido de 0,1 s con un salto vertical que se nota. */ .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) { opacity: 1; animation: cec-menu-entra 240ms var(--cec-ease) both; padding: var(--wp--preset--spacing--30) var(--wp--preset--spacing--30) var(--wp--preset--spacing--50); } @keyframes cec-menu-entra { from { opacity: 0; } to { opacity: 1; } } /* El diálogo trae un margen superior propio que descuadra la X. */ .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) .wp-block-navigation__responsive-dialog { margin-top: 0; } /* * El botón de cerrar, dentro del contenedor. * * El núcleo lo saca 10 px por la derecha y con eso basta para que aparezca * una barra de scroll horizontal en un menú. Se apoya en el padding del * contenedor, que ya le da sitio. */ .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) .wp-block-navigation__responsive-container-close { right: 0; top: 0; color: var(--wp--preset--color--salvia-oscuro); } /* * Los enlaces, centrados. * * En la cabecera van a la derecha porque comparten fila con el logo. Aquí * ocupan una pantalla entera para ellos solos, y pegados al margen parecen * un descuido. Además el resto del sitio centra los titulares de página. * * Hay que nombrar `items-justified-right`: esa clase se la pone el bloque * por la alineación de la cabecera y fija `align-items` directamente, * saltándose la variable `--navigation-layout-align`. */ .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) .wp-block-navigation__container, .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) .wp-block-navigation__container.items-justified-right { align-items: center; width: 100%; } .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) .wp-block-navigation__responsive-container-content { width: 100%; } /* Cada enlace, con sitio de sobra para el dedo. */ .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) .wp-block-navigation-item__content { display: block; padding-block: 0.5rem; } @media (prefers-reduced-motion: reduce) { .wp-block-navigation__responsive-container, .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) { animation: none; transition: display 1ms allow-discrete; } } } /* --- The floating WhatsApp and Instagram buttons ------------------------- Fixed in the corner, in the brand's dark sage rather than WhatsApp green: the glyph is what people recognise, and a saturated green would be the one colour on the site that is not in the palette. Cream on dark sage is 5.46:1. The cream ring keeps the disc visible where it passes over the dark sage box in "Sobre mí", which is its own colour. Instagram sits above WhatsApp, same size and colours, so the pair reads as one set of ways to write to her rather than two competing badges. Both live in one fixed column, printed in the order they are seen, so the stack needs no offsets and keyboard focus goes top to bottom. The glyph is the same --cec-icono mask the in-page channel buttons use, set by the channel class. Hidden while the mobile menu is open (core flags it with `has-modal-open` on ), since the stack would cover one of its links, and on a narrow screen while a form field has focus: there the full-width fields pass under the stack, and with the keyboard up a tap on the right end of a field would open a chat instead. The stack height is a variable because the room left under the footer depends on it. */ :root { --cec-flotante-tam: 3.5rem; --cec-flotante-hueco: 0.75rem; --cec-flotante-pila: calc(2 * var(--cec-flotante-tam) + var(--cec-flotante-hueco)); } .cec-flotantes { position: fixed; right: 1.25rem; bottom: 1.25rem; z-index: 50; display: flex; flex-direction: column; gap: var(--cec-flotante-hueco); } .cec-flotante { display: flex; align-items: center; justify-content: center; width: var(--cec-flotante-tam); height: var(--cec-flotante-tam); border-radius: 50%; border: 2px solid var(--wp--preset--color--crema); background-color: var(--wp--preset--color--salvia-oscuro); color: var(--wp--preset--color--crema); box-shadow: 0 4px 14px rgba(44, 42, 38, 0.22); transition: transform 200ms var(--cec-ease), box-shadow 200ms var(--cec-ease); } .cec-flotante::before { content: ""; width: 1.75rem; height: 1.75rem; background-color: currentColor; -webkit-mask: var(--cec-icono) center / contain no-repeat; mask: var(--cec-icono) center / contain no-repeat; } /* The Instagram glyph is a full square and reads larger than WhatsApp's round one at the same size. */ .cec-flotante.cec-canal-instagram::before { width: 1.625rem; height: 1.625rem; } /* Only where hover is real: on a phone :hover sticks after the tap, and the button would still be raised when the family comes back from WhatsApp. */ @media (hover: hover) { .cec-flotante:hover { transform: translateY(-2px); box-shadow: 0 8px 22px rgba(44, 42, 38, 0.28); } } .cec-flotante:active { transform: translateY(0); box-shadow: 0 2px 8px rgba(44, 42, 38, 0.22); transition-duration: 120ms; } /* The last footer line would otherwise end under the stack, with no way to scroll it clear. The footer's own padding is inline, so the room goes on the margin of its last line; that padding already covers the inset. Only on narrow screens: wider, the centred line is nowhere near the corner. */ @media (max-width: 781px) { footer.wp-block-template-part > .wp-block-group > :last-child { margin-block-end: var(--cec-flotante-pila); } html:has(main :is(input, textarea, select):focus) .cec-flotantes { display: none; } } .cec-flotante:focus-visible { outline: 2px solid var(--wp--preset--color--tinta); outline-offset: 3px; } html.has-modal-open .cec-flotantes { display: none; } @media (prefers-reduced-motion: reduce) { .cec-flotante { transition: none; } .cec-flotante:hover, .cec-flotante:active { transform: none; } } @media print { .cec-flotantes { display: none; } }