/* restore extras — generated by restore_04_polish.py */

/* Consent overlays: the restore ships no analytics or third-party tracking at all, so there
   is nothing to consent to. Their scripts are gone too, meaning the banner can never be
   dismissed and would cover the top of every page. Removing the markup is unreliable when a
   JS bundle re-renders it, so it is hidden here as well. */
.cookies-banner, .cookies-banner-content, .cookie-banner, .cookie-consent, .cookie-notice,
.cc-window, .cc-banner, #cookie-law-info-bar, #cookieChoiceInfo, .gdpr-banner,
#tarteaucitronRoot, .consent-overlay, .cookiebar {
  display: none !important;
}
body.cookie-banner-open, body.has-cookie-banner, html.cookies-open {
  overflow: auto !important;
}

/* Dead account/login modals left by the CMS (no backend on a static host) */
.modal-login, #loginModal, .login-modal { display: none !important; }

/* Carousel slots the platform's JS bundles would have filled at runtime: without a working
   bundle they stay as <img> elements with no src and render as broken-image icons. Nothing is
   lost by hiding them — they never had content in the restore. */
img:not([src]), img[src=""], img[src="#"] { display: none !important; }

/* The client's backlink block must read as the page's own copy. Where a theme only colours
   links inside specific containers, the anchor would otherwise look like plain text — inherit
   the surrounding colour but keep an underline so it is still visibly a link. */
.content-wraparea a { color: inherit; text-decoration: underline; }

/* A few px of horizontal overflow on phones (an absolutely-positioned login list, a wide footer
   logo) makes the whole page pannable sideways, which reads as broken.
   NB: use `clip`, never `hidden`, and never on html together with height:100%. `overflow:hidden`
   turns the element into a scroll container: on themes that set html{height:100%} it stops body's
   overflow propagating to the viewport, the window stops scrolling entirely and every
   scroll-driven behaviour (sticky nav, back-to-top, in-page anchors, PageDown/End) dies.
   `clip` suppresses the sideways pan without creating a scroll container. */
body { overflow-x: clip; }
/* ---- end generated block; anything below is preserved across re-runs ---- */

/* ============================================================================
   Visual finishing pass, 2026-08-17.

   Every rule below was written because the defect was VISIBLE in a screenshot of
   the built page, and every colour used is one the site already ships (sampled
   from its own computed styles), so a repaired block reads as the designer's.

     --ccs-green      #9cd3a5   CTA band, footer, body panels, listing titles
     --ccs-green-dark #759e7c   active nav item
     --ccs-mint       #cae9d0   pale tint boxes
     --ccs-coral      #ff8282   primary button, accents
     --ccs-yellow     #fffaa1   emphasis on green panels
     --ccs-blue       #77b8db / --ccs-blue-mid #5f9abf / --ccs-blue-pale #bfe6ff
     --ccs-ink        #4a4a4a   body copy on white (used by the topic listings)

   --ccs-blue-ink is the ONLY value not lifted verbatim: it is the site's own
   blue darkened until white-page text reads on --ccs-blue-pale, which at the
   shipped pairing (#77b8db on #bfe6ff) was 1.65:1 and unreadable.
   ========================================================================== */
:root {
  --ccs-green: #9cd3a5;
  --ccs-green-dark: #759e7c;
  --ccs-mint: #cae9d0;
  --ccs-coral: #ff8282;
  --ccs-yellow: #fffaa1;
  --ccs-blue: #77b8db;
  --ccs-blue-mid: #5f9abf;
  --ccs-blue-pale: #bfe6ff;
  --ccs-blue-ink: #2f6285;
  --ccs-ink: #4a4a4a;
}

/* --- 1. The white-on-pale-pink text highlight ------------------------------
   "Deseja agendar uma consulta?" is white text sitting on a pale-pink highlight
   (#ffc0c0) over the green band: 1.35:1, the least legible thing on the site and
   repeated on every one of the 55 pages. The coral button standing next to it
   carries white text at 2.4:1 and reads fine, so the highlight adopts the
   button's colour and the two halves of the band finally match.

   The site uses this highlight in exactly two places — that band, and the word
   "missão" in the /sobre/ mission statement — so the rule is not scoped to the
   band: the second one had the same 1.35:1 problem and now matches. */
.backcolor_31 { background-color: var(--ccs-coral); }

/* --- 2. Form controls are not broken, they were switched off ---------------
   The restore disabled every field so nothing could be posted to a backend that
   no longer exists. The side effect was that both forms rendered as dead grey
   furniture: placeholders at #dbdbdb on white, the "Motivo" dropdown at 70%
   opacity, the newsletter button's label at rgba(16,16,16,.3) and the contacts
   "Enviar" button flat grey. restore-ui.js re-enables them and sends the typed
   content to the practice's own e-mail address; these rules are the fallback for
   a browser with no JS, where the fields stay disabled but stay READABLE.

   Wix's ENABLED input theme on this site resolves to a #4a4a4a fill with #1f333f
   text — near-black boxes — so switching the fields on is not enough; they have
   to be told to look like the white fields the page was designed around. */
.wixui-text-input__input, .wixui-text-box__input, .wixui-text-area__input {
  background-color: #fff !important;
  color: var(--ccs-ink) !important;
  -webkit-text-fill-color: var(--ccs-ink) !important;
  border: 1px solid #d8d8d8 !important;
  opacity: 1 !important;
}
select.wixui-dropdown__input, .wixui-dropdown__input {
  background-color: #fff !important;
  color: var(--ccs-ink) !important;
  opacity: 1 !important;
}
input:disabled, textarea:disabled, select:disabled {
  opacity: 1;
  color: var(--ccs-ink);
  -webkit-text-fill-color: var(--ccs-ink);
}
input::placeholder, textarea::placeholder { color: #8b8b8b; opacity: 1; }

/* The two submit buttons, once live, take the site's own button colours: coral
   for "Enviar" (same as the header CTA) and green for the newsletter, which is
   the colour its own panel already uses. !important because Wix's atomic button
   class .uDW_Qe carries the grey and must not be hand-edited — it is generated
   and the SSR markup reuses the name. */
.ccs-submit {
  background-color: var(--ccs-coral) !important;
  color: #fff !important;
  border: 0 !important;
  cursor: pointer;
  transition: background-color .18s ease;
}
.ccs-submit:hover { background-color: #ff6b6b !important; }
.ccs-submit--green { background-color: var(--ccs-green) !important; }
.ccs-submit--green:hover { background-color: var(--ccs-green-dark) !important; }

/* The note under each form used to be a bare grey paragraph hanging off the
   bottom of the panel. Give it the shape of a note the designer wrote. */
.ccs-form-note, .form-inactive-note {
  border-left: 4px solid var(--ccs-green);
  padding: 10px 0 10px 14px;
  color: var(--ccs-ink);
  line-height: 1.5;
}
.ccs-form-note a { color: var(--ccs-green-dark); text-decoration: underline; }
/* The line a submit writes back to the visitor. Coral, because it is the site's
   own "something just happened" colour, and it must not read as the standing
   note above it. */
.ccs-form-sent { border-left-color: var(--ccs-coral); font-weight: 600; }

/* --- 3. Homepage hero: a slideshow nobody could advance --------------------
   Three photographs are in the markup, laid side by side in a flex track that
   the deleted Wix bundle used to translate. Without it the page showed slide 1
   for ever under a caption that told the visitor to drag. restore-ui.js drives
   the track; this styles the frame and the controls it adds.

   The track is not a transform strip, it is a NATIVE horizontal scroll container
   (.CKet9C, clientWidth 937, scrollWidth 2811) — which is what the deleted caption
   meant by "drag". So the rebuilt control scrolls it rather than transforming it:
   no overflow overrides, the browser's own clipping, and a touch drag keeps
   working exactly as the widget intended.

   Two pieces of SSR furniture do have to go. Wix paints a SECOND, static copy of
   the current slide on top of the track (div.OSqXnG), so the track could scroll
   all it liked and the visitor would still be looking at slide 1. And the widget's
   counter — now honest at 1/5, since the two slides Wix never server-rendered are
   back in the markup — lands in the same bottom-right corner as the dots below,
   which say the same thing more clearly. With JavaScript off the track stays at
   scroll 0 and slide 1 shows exactly as before. */
[id^="SldShwGllry"] > .OSqXnG { display: none !important; }
[id^="SldShwGllry"] [data-testid="gallery-counter"] { display: none !important; }
/* scroll-behavior lives in restore-ui.js's go() now, per call - see the note there: as a
   property on the element it animated the browser's own scrollIntoView() too, which made
   the slide captions intermittently unhittable for anything that measures them. */
.CKet9C { scrollbar-width: none; }
.CKet9C::-webkit-scrollbar { display: none; }
.ccs-gal-btn {
  position: absolute;
  top: 50%;
  transform: translateY(-50%);
  width: 44px;
  height: 44px;
  border: 0;
  border-radius: 50%;
  background: rgba(255, 255, 255, .88);
  color: var(--ccs-green-dark);
  font-size: 22px;
  line-height: 44px;
  cursor: pointer;
  box-shadow: 0 2px 8px rgba(0, 0, 0, .18);
  transition: background-color .18s ease, color .18s ease;
  z-index: 3;
}
.ccs-gal-btn:hover { background: var(--ccs-coral); color: #fff; }
.ccs-gal-btn--prev { left: 14px; }
.ccs-gal-btn--next { right: 14px; }
.ccs-gal-dots {
  position: absolute;
  left: 0;
  right: 0;
  bottom: 14px;
  /* bottom RIGHT, where the widget's own slide counter used to sit: the caption
     strip is left-aligned, and centred dots collided with it on slides 2 and 3 */
  display: flex;
  justify-content: flex-end;
  padding-right: 22px;
  gap: 9px;
  z-index: 3;
}
.ccs-gal-dot {
  width: 10px;
  height: 10px;
  padding: 0;
  border: 0;
  border-radius: 50%;
  background: rgba(255, 255, 255, .9);
  /* a hairline ring so the dots read on a white photograph as well as a dark one */
  box-shadow: 0 0 0 1px rgba(0, 0, 0, .28);
  cursor: pointer;
  transition: background-color .18s ease;
}
.ccs-gal-dot[aria-current="true"] { background: var(--ccs-coral); }

/* --- 4. Blog and topic listings -------------------------------------------
   On /blog/ the card headline was #aaa8a8 and its own excerpt #717070: the
   title was LIGHTER than the text under it, so every headline read as disabled.
   The four topic listings (/infancia-1/ and siblings) already paint the same
   widget's titles in the site green with #4a4a4a excerpts — that pairing is the
   site's own answer, so /blog/ now uses it too. */
[data-hook="post-title"] { color: var(--ccs-green) !important; }
[data-hook="post-description"] { color: var(--ccs-ink) !important; }

/* Each card reserves a footer row for the view/like counters Wix used to render.
   With the counters gone the row was ~55px of white under a hairline rule that
   separated nothing from nothing. restore-ui.js puts the card's own "Ler mais"
   there — the read-more the listings never had. */
.post-list-item-wrapper { position: relative; }
.ccs-readmore {
  position: absolute;
  left: 36px;
  bottom: 14px;
  font-size: 15px;
  font-weight: 700;
  color: var(--ccs-coral);
  text-decoration: none;
  letter-spacing: .01em;
}
.ccs-readmore:hover { color: var(--ccs-green-dark); text-decoration: underline; }

/* --- 5. Service pages -----------------------------------------------------
   The Wix Bookings widget paints its own full-bleed white section, so all 12
   /service-page/ pages lost the 980px white card and the confetti margins that
   every other page on the site has, and read as a different site. The card is
   still underneath; the widget just has to stop covering it. */
section.smWa8GO { background-color: transparent; }

/* The booking control was removed with the dead Wix backend and nothing took its
   place, so a page that quotes a price ended on a bare address line. This is the
   replacement the site's own plan called for: its published e-mail and number. */
.ccs-service-cta {
  max-width: 720px;
  margin: 8px auto 56px;
  padding: 26px 30px;
  background: var(--ccs-green-panel);   /* round 9: was --ccs-green, white on it is 1.71:1 */
  text-align: center;
}
.ccs-service-cta p {
  margin: 0 0 16px;
  font-size: 18px;
  font-weight: 700;
  color: #fff;
}
.ccs-service-cta a {
  display: inline-block;
  margin: 4px 6px;
  padding: 12px 26px;
  background: var(--ccs-coral);
  color: #fff;
  font-size: 15px;
  font-weight: 700;
  text-decoration: none;
  transition: background-color .18s ease;
}
.ccs-service-cta a:hover { background: #ff6b6b; }
.ccs-service-cta a.ccs-cta-alt { background: #fff; color: var(--ccs-green-dark); }
.ccs-service-cta a.ccs-cta-alt:hover { background: var(--ccs-mint); }

/* --- 6. /consultas/ -------------------------------------------------------
   Two 35px white headings sat on pale mint (#cae9d0) at 1.31:1 and had to be
   squinted at. They now use the same green as the panel that runs directly
   beneath each of them, which is how white headings are set everywhere else. */
/* Round 9: these two carried 35px WHITE headings on the brand green, 1.71:1 against a
   3.0 floor. Same panel green as the footer. */
#comp-kpkwkbtk .wixui-box, #comp-m1f2jp4d .wixui-box { background-color: var(--ccs-green-panel); }

/* On the green panel the emphasised phrases ("primeira consulta", "packs de
   consultas", the two pack lines) carried the theme's dark green #759e7c, which
   on #9cd3a5 is 1.77:1 — the emphasis was fainter than the plain text around it.
   Bold white is what the blue band beside it uses for the same job. */
#comp-l1htcfsw .color_28, #comp-l1htcfsw .color_28 * { color: #fff; font-weight: 700; }

/* Two-column blocks where the photograph stops short of the coloured panel beside
   it and leaves a white step: 26px on /consultas/, 69px under the homepage
   newsletter. Both are the same Wix image component, so both fill their column. */
#comp-li2hx54e, #comp-li2hx54e img,
#comp-kpk56rth, #comp-kpk56rth img { height: 100%; object-fit: cover; }

/* The two pale-blue practitioner bands set their body copy AND the practitioner's
   name in #77b8db on #bfe6ff: 1.65:1, the paragraphs about psychology and speech
   therapy were barely there. The middle band (white on #5f9abf) was always fine
   and is untouched. */
#comp-m1f2ldt0 .wixui-rich-text__text, #comp-maqzxiv7 .wixui-rich-text__text { color: var(--ccs-blue-ink); }
#comp-m1f2ldt0 a.wixui-rich-text__text, #comp-maqzxiv7 a.wixui-rich-text__text { color: var(--ccs-blue-ink); }

/* --- 7. Post pages --------------------------------------------------------
   The two share controls at the foot of an article are <button>s whose handlers
   were stripped: clicking them did nothing. restore-ui.js wires them to a plain
   Facebook share URL and the clipboard; this is only their hover affordance. */
[data-hook="share-button"], .ccs-share-live { cursor: pointer; }
.ccs-share-live:hover { color: var(--ccs-coral); }
.ccs-share-done { color: var(--ccs-green-dark); font-size: 13px; margin-left: 8px; }

/* The article card ended with 83px of white and no way onward. */
.ccs-back-to-blog {
  display: inline-block;
  /* the share row is a flex row; sit at its far end rather than trailing the icons */
  margin-left: auto;
  align-self: center;
  font-size: 15px;
  font-weight: 700;
  color: var(--ccs-coral);
  text-decoration: none;
}
.ccs-back-to-blog:hover { color: var(--ccs-green-dark); text-decoration: underline; }

/* --- ccs-gap2: /equipe/ portrait ------------------------------------------------
   The authored page reuses the Wix rich-text island, which has no image slot. One rule, appended
   to the site's own stylesheet, rather than a <style> block on a single page. */
/* !important because the Wix rich-text island resets its descendants: the inline sheet carries
   `.ku3DBC div{margin:0}` (0,1,1) which outranks a bare class (0,1,0), so this wrapper's margin
   was being dropped and the caption ended flush against the bio paragraph below it. The inner
   caption rule was already patched this way; the wrapper was not, which is why the gap died. */
.ccs-equipe-portrait{margin:20px 0 26px !important}
.ccs-equipe-portrait img{display:block;width:100%;max-width:100%;height:auto;
  border:6px solid #ff8282;box-sizing:border-box}
.ccs-portrait-cap{margin:10px 0 0 !important;color:#fff;font-size:15px;line-height:1.4em;
  text-align:left}

/* --- ccs-fix2: /equipe/ the people the page names -------------------------------
   The page named four professionals and showed none of them, while /consultas/ already carries
   photographs of three of them. Same coral frame as the founder portrait so the page reads as one
   design; a flex row rather than a Wix grid cell because this rich-text island has no image slot. */
/* Same override as the portrait wrapper above (`.ku3DBC div{margin:0}`): without !important the
   grid's bottom margin vanished and "Para marcar consulta..." began on the line directly under
   card 1's caption, at a measured 0px gap. */
.ccs-team-grid{display:flex;flex-wrap:wrap;gap:20px;margin:22px 0 28px !important}
.ccs-team-card{flex:1 1 200px;min-width:180px}
.ccs-team-card img{display:block;width:100%;height:240px;object-fit:cover;object-position:50% 30%;
  border:6px solid #ff8282;box-sizing:border-box}
.ccs-team-card p{margin:10px 0 0 !important;color:#fff;font-size:16px;line-height:1.35em;
  text-align:left}
.ccs-team-card p b{display:block;font-size:17px;letter-spacing:.02em}

/* --- ccs-gap2: blog search ------------------------------------------------------
   The archived Wix search widget is inert markup. restore-ui.js turns it into a real filter; these
   are the states that filter needs. */
.ccs-search-open .ccs-search-field{display:block}
.ccs-search-field{display:none;margin:10px 0 0;width:100%;max-width:320px;padding:8px 12px;
  border:1px solid #9cd3a5;border-radius:4px;font:inherit;font-size:15px;color:#4a4a4a;
  background:#fff;box-sizing:border-box}
.ccs-search-field:focus{outline:2px solid #759e7c;outline-offset:1px}
.ccs-search-hit-none{display:none !important}
.ccs-search-count{margin:8px 0 0;font-size:14px;color:#4a4a4a}

/* --- ccs-gap2: contact page heading ---------------------------------------------
   #aaa8a8 on white is 2.37:1. The first visual pass fixed exactly this grey on the blog listing
   titles; the contact <h1> carries it too. Site ink, matching every other page heading. */
#comp-khytmuo6 .color_43,
#comp-khytmuo6 h1 span{color:#759e7c !important}

/* --- ccs-fix3: the backlink paragraph sat flush against its own panel -----------
   The block is a plain child of the newsletter form #comp-kpkwfsfa, whose real fields are
   ABSOLUTELY positioned inside it — so the form box carries no padding of its own and any
   normal-flow child lands on the panel edge. Measured at 1440: panel #comp-kpkwfscy
   l=250 r=807 t=1216 b=2025, the fields l=278 r=788, the first field top 1238.
   The insets below are those measurements, not taste: 28px left and 19px right put the
   paragraph on the same vertical rules as the Nome/Email inputs and the Subscrever button,
   and 22px bottom mirrors the panel's own top inset so the last line stops sitting on the
   green edge. Padding rather than margin, so the green panel grows with it and no white
   step opens beside the photo (#comp-kpk56rth is height:100% of the same row). */
.content-wraparea{padding:0 19px 22px 28px}

/* --- ccs-content: the eight topic pages -----------------------------------------
   Nine pages rendered the SAME Wix Pro Gallery of the same 27 cards: /blog/, the four
   /blog/categories/* and the four life-stage pages in the header menu. /infancia-1/ and
   /blog/categories/infancia/ were the same list twice, and the life-stage pages carried one
   sentence of their own. The blog keeps the photo grid; these eight now open with an authored
   introduction and list their articles as text, so a post cover is no longer the only thing on
   three to nine pages at once.
   Type and colour are the site's own: signika, ink #4a4a4a, headings and titles in the dark
   green #759e7c that the first visual pass settled on for listing titles, coral #ff8282 for the
   "Ler mais" affordance, hairlines in the #d6d6d6 the Wix cards themselves used. */
.ccs-topic-intro{max-width:940px;margin:0 auto;padding:4px 20px 0;box-sizing:border-box}
.ccs-topic-h{margin:0 0 14px;font-family:signika,sans-serif;font-size:30px;line-height:1.2;
  font-weight:700;color:#759e7c}
.ccs-topic-p{margin:0 0 14px;font-family:signika,sans-serif;font-size:16px;line-height:1.7;
  color:#4a4a4a;text-align:justify}
.ccs-topic-list{max-width:940px;margin:22px auto 0;padding:0 20px;list-style:none;
  box-sizing:border-box}
.ccs-topic-item{border-top:1px solid #d6d6d6}
.ccs-topic-item:last-child{border-bottom:1px solid #d6d6d6}
.ccs-topic-link{display:block;padding:18px 2px;text-decoration:none;color:inherit}
.ccs-topic-link:hover .ccs-topic-title{text-decoration:underline}
.ccs-topic-meta{display:block;font-family:signika,sans-serif;font-size:12px;color:#717070;
  margin-bottom:6px}
.ccs-topic-title{display:block;font-family:signika,sans-serif;font-size:22px;line-height:1.25;
  font-weight:700;color:#759e7c;margin-bottom:6px}
.ccs-topic-ex{display:block;font-family:signika,sans-serif;font-size:15px;line-height:1.6;
  color:#4a4a4a}
.ccs-topic-more{display:block;margin-top:8px;font-family:signika,sans-serif;font-size:14px;
  color:#ff8282}
.ccs-topic-all{max-width:940px;margin:20px auto 26px;padding:0 20px;
  font-family:signika,sans-serif;font-size:15px;box-sizing:border-box}
.ccs-topic-all a{color:#759e7c}
.ccs-topic-count{max-width:940px;margin:0 auto;padding:0 20px;font-family:signika,sans-serif;
  font-size:14px;color:#4a4a4a;box-sizing:border-box}

/* --- ccs-chrome: the page background is a background ------------------------------
   Wix painted the confetti texture as an <img> inside <wow-image class="... bgImage"> so its own
   runtime could art-direct it. There is no runtime here, so on all 56 pages it was simply a
   1920x1920 decorative image with the alt text "Sobre a Crescer com Sabor" - announced to screen
   readers as content, and counted by the image-reuse check as one photograph doing duty on every
   page. background-size:cover + background-position:50% 0% are the exact equivalents of the
   object-fit and object-position it carried, so nothing moves. */
wow-image.ccs-page-bg{display:block;width:100%;height:100%;
  background-image:url("/img/41d000_9bace29101c0110bf92b86118c5802c4-29790f37.webp");
  background-size:cover;background-position:50% 0%;background-repeat:no-repeat}

/* --- ccs-pages: the three pages that rendered correctly and said nothing ----------
   Body copy authored for /contato-com-mapa/ and for the two download-announcement posts. The
   post headings borrow the post's own paragraph classes for font and colour and only add weight
   and spacing, so an authored section is typographically indistinguishable from an authored one -
   which is the point: the reader must not be able to tell where the archive stopped. */
.ccs-page-copy{max-width:940px;margin:26px auto 8px;padding:0 20px;box-sizing:border-box}
/* On /contato-com-mapa/ the only safe normal-flow slot inside this Wix mesh section is at the end
   of the form column, so the copy inherited a 472px column and left the whole left half of the
   white card empty under the map. Measured in the live render at 1440: the page card is the site's
   980px column (l=230), the form column starts at l=713, so in PAGE coordinates the block began at
   x=483 and had to start at x=20. -463px is that difference, and it is a constant: this capture
   ships viewport width=980 and carries no layout @media rule, so the geometry does not move with
   the window - the same offset holds at 390. */
.ccs-page-copy.ccs-contact-page-inner{width:940px;margin-left:-463px;padding:0}
.ccs-copy-h{margin:18px 0 8px;font-family:signika,sans-serif;font-size:19px;line-height:1.3;
  font-weight:700;color:#759e7c}
.ccs-copy-p{margin:0 0 12px;font-family:signika,sans-serif;font-size:15px;line-height:1.7;
  color:#4a4a4a;text-align:justify}
.ccs-post-h{font-weight:700 !important;margin-top:26px !important;margin-bottom:6px !important}

/* --- ccs-fix4: the two paragraphs in the newsletter panel were set in different faces ---
   The independent review measured it: .ccs-form-note computed Arial 14px rgb(74,74,74) while the
   backlink paragraph one line below it computed signika 15px rgb(113,112,112), and signika is what
   the rest of the site uses. Two typographic systems inside the one panel the client is paying for.
   .ccs-form-note carried no font-family of its own, so this is the one-line fix the reviewer named;
   the size stays 14px because the note is a footnote to the form, not body copy. */
.ccs-form-note{font-family:signika,sans-serif}

/* --- ccs-home-intro: the front door now says what the practice is ------------------
   Same insets as .content-wraparea below it, measured from the form fields (l=278, r=788 in the
   1440 render), so the two paragraphs share the panel's vertical rules instead of stepping. */
.ccs-home-intro{padding:0 19px 0 28px}
.ccs-home-intro p{margin:0;color:#717070}

/* --- ccs-fix7: /service-page/ related reading -----------------------------
   The twelve service pages were the thinnest on the site and, now that the
   service-card CTAs are real links, they are where a paying visitor lands.
   The block adds no claim about the practice - only links to pages this site
   already publishes - so it reads as navigation, not as filler. */
.ccs-svc-read {
  max-width: 720px;
  margin: 30px auto 8px;
  padding: 22px 26px;
  background: #f4faf5;
  border-left: 4px solid var(--ccs-green);
}
.ccs-svc-read h2 {
  margin: 0 0 10px;
  font-family: signika, sans-serif;
  font-size: 19px;
  font-weight: 700;
  color: var(--ccs-green-dark);
}
.ccs-svc-read p {
  margin: 0 0 10px;
  font-family: signika, sans-serif;
  font-size: 15px;
  line-height: 1.7;
  color: var(--ccs-ink);
}
.ccs-svc-read ul { margin: 0 0 10px; padding-left: 22px; list-style: disc outside; }
.ccs-svc-read li {
  margin: 0 0 6px;
  font-family: signika, sans-serif;
  font-size: 15px;
  line-height: 1.6;
  color: var(--ccs-ink);
}
.ccs-svc-read a { color: var(--ccs-green-dark); text-decoration: underline; }
.ccs-svc-read a:hover { color: var(--ccs-coral); }

/* --- ccs-fix7: links inside authored body copy --------------------------
   The site sets a{text-decoration:none} globally and colours its links per
   component, so an <a> written into an authored .ccs-page-copy block fell
   through to the browser default and rendered bright blue against Signika
   grey. This gives those links the site's own green, underlined. */
.ccs-page-copy a {
  color: var(--ccs-green-dark);
  text-decoration: underline;
}
.ccs-page-copy a:hover { color: var(--ccs-coral); }

/* --- ccs-fix7: the PDF file cards ---------------------------------------
   Wix drove these downloads from JavaScript state and no PDF survives in the
   archive, so the card can only be a note. Remove the pointer affordance that
   the original <button> carried. */
.ccs-file-note { cursor: default; }

/* --- ccs-fix8: the link inside the "PDF indisponível" note ---------------
   Round 7 demoted the three Wix download cards to notes and pointed each note
   at the article that still carries the same content. Those <a> elements were
   written without the site's per-component link colour, so they fell through
   to the browser default and shipped as rgb(0,0,238) bright blue inside a
   coral/green page - the same failure .ccs-page-copy a was added to fix, one
   block later. Measured: 3 default-blue text runs across 56 pages, all three
   of them this note. Same declarations as .ccs-page-copy a so the two authored
   link contexts cannot drift apart again. */
.ccs-file-note-msg a {
  color: var(--ccs-green-dark);
  text-decoration: underline;
}
.ccs-file-note-msg a:hover { color: var(--ccs-coral); }

/* ==========================================================================
   ROUND 9 - the client opened the delivered zip and could not read it.
   Five findings, all reproduced and measured before anything below was written:
     1. the header reads as "a white block with buttons"
     2. "responsiveness was never delivered" - a phone got the 980px desktop
        page shrunk to 40%
     3. the footer is badly built for phones
     4. on a phone you cannot tell a link from the text around it
     5. an AbortError in the console of /papel-da-nutricao-durante-a-gravidez/
   Sections A-D below are findings 1, 3 and 4; section E is findings 2 and 3.
   Finding 5 was not a stylesheet problem at all: 34 of the 56 pages still
   carried Wix's <style id="page-transitions">@view-transition{navigation:auto}
   opt-in. A cross-document view transition needs BOTH documents to opt in, and
   the 22 pages that did not include the article the client opened, so the
   browser skipped the transition and rejected its promise. The opt-in is
   removed from all 34.
   ========================================================================== */

/* --- A. The palette had no readable step in use ---------------------------
   This is a Wix export and the colours come from the site own 65-slot palette,
   which is five hue ramps of five steps each (light -> dark):
     green   color_26..30   #cae9d0 #9cd3a5 #759e7c #7c9980 #273429
     yellow  color_21..25   #fffaa1 #fffbb5 #bfbc88 #807e5b #403f2d
     coral   color_31..35   #ffc0c0 #ff8282 #bf6161 #ca7878 #3f2020
     blue    color_16..20   #bfe6ff #77b8db #5f9abf #789fb4 #1f333f
   The restore did NOT lose a rule: _raw/crescercomsabor.pt/pages/index.html
   carries exactly the same #DrpDwnMn0{--txt:var(--color_27)} and the same
   .color_26 spans that the built page does. What the ORIGINAL did was use step
   1 or 2 of a ramp as TEXT, on white or on step 2 of another ramp, which is
   1.08 - 2.17:1 everywhere. So the fix is not to invent colours: it is to move
   each of those runs to the DARK step of the ramp it already belongs to, which
   keeps every pairing hue (a card whose rule is mint still writes in mint) and
   puts all of them over 4.5:1.

   --ccs-green-ink is the one value that is not a palette slot: the green ramp
   jumps from #759e7c (3.03:1 on white) straight to #273429 (13:1), and the
   navigation needed something in between that still reads as the brand green.
   It is #9cd3a5 held at its own hue (130deg) and saturation (38%) and taken
   down to 30% lightness - 6.48:1 on white. */
:root {
  --ccs-green-ink: #2f6a39;   /* nav, links, buttons on white   6.48:1 */
  --ccs-green-deep: #273429;  /* palette color_30              13.05:1 */
  --ccs-yellow-deep: #403f2d; /* palette color_25              10.68:1 */
  --ccs-coral-deep: #3f2020;  /* palette color_35              14.60:1 */
  --ccs-blue-deep: #1f333f;   /* palette color_20              13.10:1 */
}

/* A1. The header. Six labels in #9cd3a5 on a white bar: 1.71:1, which is what
   the client saw as an empty white block. The menu component takes its colours
   from custom properties, so one rule fixes the label, the hover fill and the
   current-page label on all 56 pages - no per-element override. Hover keeps the
   original inversion (white on the brand colour) but on the readable green. */
#DrpDwnMn0 {
  --txt: 47, 106, 57;      /* --ccs-green-ink, 6.48:1 on the white bar */
  --txts: 39, 52, 41;      /* current page: palette color_30, heavier still */
  --bgh: 47, 106, 57;      /* hover fill; --txth is already 255,255,255 */
  --bgs: 202, 233, 208;    /* current page fill: palette color_26 */
}
#DrpDwnMn0 .JghqhY { font-weight: 700; }

/* A2. The four life-stage cards on the homepage. Each card is a saturated panel
   with an 8px rule above it in a second colour, and the heading was set in that
   second colour LIGHTEST step: mint on coral 1.95:1, blue on yellow 2.17:1,
   coral on mint 2.00:1, yellow on blue 2.51:1. Each heading moves to the dark
   step of the same ramp, so the heading still answers the rule above it.
   (qa_legibility measured these against white and reported 1.31 and 1.08,
   because the panel colour is painted by an absolutely-positioned sibling that
   an ancestor walk never reaches - see section D.) */
#Cntnr0 .color_26, #Cntnr0 .color_26 * { color: var(--ccs-green-deep); }   /* on coral   6.19:1 */
#Cntnr1 .color_17, #Cntnr1 .color_17 * { color: var(--ccs-blue-deep); }    /* on yellow 11.24:1 */
#Cntnr2 .color_32, #Cntnr2 .color_32 * { color: var(--ccs-coral-deep); }   /* on mint    9.88:1 */
#Cntnr3 .color_21, #Cntnr3 .color_21 * { color: var(--ccs-yellow-deep); }  /* on blue    4.80:1 */
[id^="StBttn"] .l7_2fn { color: var(--ccs-green-ink); }

/* A3. The green panels: darken the PANEL, do not invert the type.
   White on the brand green #9cd3a5 is 1.71:1, and the site does that on the
   footer of all 56 pages, across the whole of /equipe/, and on three bands of
   /consultas/ where the emphasised words are additionally set in the pale
   yellow #fffaa1 - measured by the gate camera at 1.58:1, the only text on the
   site it still called invisible.

   The first attempt darkened the TYPE instead. It fails as a system: on a pale
   panel every colour that reaches 4.5:1 is nearly black, so the body copy
   (#273429) and its emphasis (#403f2d or #3f2020) come out 1.3:1 apart from
   each other and the emphasis stops being emphasis. Darkening the panel keeps
   the design as its author wrote it - light type on green, emphasis in yellow -
   and both halves become readable at once.

   --ccs-green-panel is the LIGHTEST green on the site own hue that carries
   both: white 5.09:1 and #fffaa1 4.55:1. Anything lighter drops the yellow
   under 4.5. The one green band it is deliberately NOT applied to is the
   "Deseja agendar uma consulta?" strip at the top of every page, which carries
   no type of its own - only a coral highlight and a coral button - and so has
   nothing to make readable and stays pastel. */
:root { --ccs-green-panel: #377c42; }
#comp-lfiqiq2j2 { --bg-overlay-color: var(--ccs-green-panel); }   /* footer, 56 pages */
#comp-l1htcfse  { --bg-overlay-color: var(--ccs-green-panel); }   /* /consultas/ band */
#comp-kpk6jlri  { --bg: 55, 124, 66; }                            /* /equipe/ panel */

/* A4. The newsletter panel (pale mint at 52% over white): its heading was
   #7c9980 (2.39:1), the consent label and the two contact links #759e7c
   (2.32:1), and the submit button white on #9cd3a5 (1.71:1). */
#comp-kpkwfsgi .color_29, #comp-kpkwfsgi .color_29 * { color: var(--ccs-green-ink); }
#comp-kpkwfsib .eW1tpy { color: var(--ccs-green-ink); }
.ccs-form-note, .form-inactive-note { color: #3f3f3f; }
.ccs-form-note a { color: var(--ccs-green-ink); }
.ccs-submit--green { background-color: var(--ccs-green-ink) !important; }
.ccs-submit--green:hover { background-color: var(--ccs-green-deep) !important; }

/* A5. Everywhere else the site writes in its own green on white or on a pale
   tint: listing titles, topic headings, service blocks, the contact heading.
   All of them were at 3.03:1. */
.ccs-topic-h, .ccs-topic-title, .ccs-topic-all a,
.ccs-svc-read h2, .ccs-svc-read a,
.ccs-page-copy a, .ccs-file-note-msg a,
.ccs-copy-h,
#comp-khytmuo6 .color_43, #comp-khytmuo6 h1 span { color: var(--ccs-green-ink) !important; }
[data-hook="post-title"] { color: var(--ccs-green-ink) !important; }

/* --- B. A link has to look like a link ------------------------------------
   Measured on the delivered build: 8 links whose colour, weight and decoration
   were identical to the prose around them. The site sets a{color:inherit} in
   the Wix rich-text island and never gives those anchors a colour, so in the
   footer a phone number and a street address were simply text.
   Underline rather than a colour change, because several of these sit on
   coloured panels where a second colour would fight the panel. Excluded: the
   navigation, anything Wix styles as a button, our own card and list
   affordances, and any link whose content is an image or an icon. */
p a:not(.piclkP):not([class*="wixui-button"]):not(.ccs-topic-link):not(.ccs-readmore):not(.ccs-back-to-blog):not(:has(img)):not(:has(svg)),
li a:not(.piclkP):not([class*="wixui-button"]):not(.ccs-topic-link):not(.ccs-readmore):not(.ccs-back-to-blog):not(:has(img)):not(:has(svg)),
td a:not(.piclkP):not([class*="wixui-button"]):not(:has(img)):not(:has(svg)) {
  text-decoration: underline;
  text-underline-offset: 2px;
}

/* --- C. Targets a finger can hit ------------------------------------------
   WCAG 2.5.8 puts the floor at 24x24. Vertical padding on an INLINE anchor
   grows its hit box without moving a single line of text, which is why these
   are padding-block and not min-height: the footer three-line address block
   photographs identically before and after. */
#comp-lfiqiq2j2 a, .ccs-home-intro a, .ccs-page-copy a,
.ccs-form-note a, .content-wraparea a, .ccs-file-note-msg a { padding-block: 5px; }
/* The homepage carousel dots were 10x10. The dot stays 10px; the button around
   it becomes 26px of transparent hit area. */
.ccs-gal-dot {
  width: 26px; height: 26px;
  background: transparent;
  box-shadow: none;
  display: grid;
  place-items: center;
}
.ccs-gal-dot::before {
  content: "";
  width: 10px; height: 10px;
  border-radius: 50%;
  background: rgba(255, 255, 255, .9);
  box-shadow: 0 0 0 1px rgba(0, 0, 0, .28);
  transition: background-color .18s ease;
}
.ccs-gal-dot[aria-current="true"] { background: transparent; }
.ccs-gal-dot[aria-current="true"]::before { background: var(--ccs-coral); }
.ccs-gal-dots { gap: 2px; padding-right: 14px; }
/* The four "Saiba mais" links were 200x21. */
[id^="StBttn"] { height: auto !important; }
[id^="StBttn"] .uDW_Qe { min-height: 26px; display: flex; align-items: center; justify-content: flex-end; }

/* --- D. Say out loud what the page already paints -------------------------
   Wix paints a section colour with an absolutely-positioned sibling
   (#bgLayers_X > .LWbAav), never on the element the text lives in. Every tool
   that resolves a background by walking ancestors - qa_legibility, a browser
   own contrast inspector, a screen-reader audit - therefore reads WHITE behind
   the footer text and behind all four homepage cards, and scores white text on
   the green footer as 1:1. The colours below are the ones those layers already
   paint, read out of the live render; declaring them on the element changes no
   pixel (the layer sits on top and is opaque) and makes the measured contrast
   the true one.

   The 28 rules below were generated by _scripts/_ccs_layer_css.js, which opened all
   56 pages and read the colour each layer actually paints. Layers whose colour is
   NOT fully opaque are deliberately left out and listed at the end: declaring a
   translucent colour underneath itself would composite it twice and darken the band. */
#Cntnr0 { background-color: rgb(255,130,130); }   /* box, 1 page(s) */
#Cntnr1 { background-color: rgb(255,250,161); }   /* box, 1 page(s) */
#Cntnr2 { background-color: rgb(202,233,208); }   /* box, 1 page(s) */
#Cntnr3 { background-color: rgb(119,184,219); }   /* box, 1 page(s) */
#Cntnr5 { background-color: rgb(119,184,219); }   /* box, 4 page(s) */
#comp-kpk6jlri { background-color: #377c42; }   /* box, 5 page(s) */
#comp-kpkwkbtk { background-color: #377c42; }   /* box, 1 page(s) */
#comp-l1htcfse { background-color: #377c42; }   /* bgLayers, 1 page(s) */
#comp-l1htw58q { background-color: rgb(191,230,255); }   /* bgLayers, 1 page(s) */
#comp-l1htw58w1 { background-color: rgb(0,0,0); }   /* bgLayers, 1 page(s) */
#comp-l1htw59u { background-color: rgb(0,0,0); }   /* bgLayers, 1 page(s) */
#comp-lfiqiq2j2 { background-color: #377c42; }   /* bgLayers, 56 page(s) */
#comp-lvzaagbz { background-color: rgb(156,211,165); }   /* bgLayers, 56 page(s) */
#comp-m1f2jp4d { background-color: #377c42; }   /* box, 1 page(s) */
#comp-m1f2ldt0 { background-color: rgb(191,230,255); }   /* bgLayers, 1 page(s) */
#comp-m1f3nbd9 { background-color: rgb(95,154,191); }   /* bgLayers, 1 page(s) */
#comp-maqzxiv7 { background-color: rgb(191,230,255); }   /* bgLayers, 1 page(s) */
#pageBackground_c4xp { background-color: rgb(255,255,255); }   /* bgLayers, 1 page(s) */
#pageBackground_cjg9 { background-color: rgb(255,255,255); }   /* bgLayers, 5 page(s) */
#pageBackground_cue5y { background-color: rgb(255,255,255); }   /* bgLayers, 5 page(s) */
#pageBackground_df8nz { background-color: rgb(255,255,255); }   /* bgLayers, 1 page(s) */
#pageBackground_mainPage { background-color: rgb(255,255,255); }   /* bgLayers, 1 page(s) */
#pageBackground_ms4yn { background-color: rgb(255,255,255); }   /* bgLayers, 1 page(s) */
#pageBackground_qajos { background-color: rgb(255,255,255); }   /* bgLayers, 27 page(s) */
#pageBackground_slizb { background-color: rgb(255,255,255); }   /* bgLayers, 1 page(s) */
#pageBackground_t0bw7 { background-color: rgb(255,255,255); }   /* bgLayers, 1 page(s) */
#pageBackground_urlfj { background-color: rgb(255,255,255); }   /* bgLayers, 1 page(s) */
#pageBackground_y2yjy { background-color: rgb(255,255,255); }   /* bgLayers, 12 page(s) */

/* NOT emitted - layer is translucent, declaring it under the layer would darken it: */
/* #comp-lg2ivul0 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivul01 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivul2 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivul21 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivul3 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivul31 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivul52 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivul6 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivul61 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivul62 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivul9 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivul91 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivula1 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivula2 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivula3 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivula5 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivulb { background-color: rgb(0,0,0); } */
/* #comp-lg2ivulb1 { background-color: rgb(0,0,0); } */
/* #comp-lg2ivulb2 { background-color: rgb(0,0,0); } */
/* #comp-li2himfj { background-color: rgb(0,0,0); } */

/* A6. The one band the first pass of this round left alone, and the last thing
   qa_legibility still reported: the "Deseja agendar uma consulta?" strip. Both
   halves of it were white on the site coral #ff8282 - 2.40:1 for a 27px
   headline that needs 3.0, and for a 16px button label that needs 4.5. The
   coral is the site own call-to-action colour and is worth keeping, so the type
   moves instead, to the deep step of the same coral ramp (palette color_35).
   Applied to .backcolor_31 as a whole because the site uses that highlight in
   exactly two places, this band and the word "missao" on /sobre/, and both had
   the same problem. */
.backcolor_31, .backcolor_31 * { color: var(--ccs-coral-deep) !important; }   /* 6.09:1 */
#comp-lvzaagc71 .StylableButton2545352419__label,
#comp-lvzaagc71 .StylableButton2545352419__link { color: var(--ccs-coral-deep) !important; }

/* --- E. A phone gets a phone layout ---------------------------------------
   THE COMPLAINT: "responsiveness was never delivered ... you need a magnifying
   glass". THE CAUSE: the delivered build shipped
   <meta name="viewport" content="width=980"> - the decision recorded for
   wenou.pt, the reference site of this group, because Wix hard-codes
   --site-width:980px and #site-root{min-width:var(--site-width)}, so a 390px
   phone given width=device-width simply CLIPPED the page. width=980 stopped the
   clipping by rendering the desktop page and scaling it to 40%, which is
   exactly the magnifying glass the client is holding.

   THE FIX: width=device-width on all 56 pages, and this block, which reflows
   the Wix mesh instead of shrinking it. Wix Thunderbolt lays a page out as a
   single-column CSS grid per container; every component is a grid child with
   `justify-self:start`, a fixed pixel `width`, a `margin-left` of the site
   margin and a `left` offset - so two components side by side are two children
   of the SAME grid row, separated only by `left`. Turning the grid into a flex
   column and dropping `left`, `margin-left` and the fixed widths puts those
   children one under another, full width, in document order. Nothing is
   hidden and nothing is scaled: the phone gets the same content in one column.

   Wix ships its own mobile stylesheet in these documents, ~76 rules gated on
   body.device-mobile-optimized. It is NOT usable: it addresses the separate
   mobile DOM (#TINY_MENU, a 320px #SITE_CONTAINER) that a desktop capture does
   not contain. Adding the class paints a 320px page with no menu. */
@media (max-width: 1023px) {

  /* E1. Release the 980px floor. Without this the page is clipped, not
     reflowed - which is why the first delivery avoided device-width. */
  body:not(.responsive) #site-root { min-width: 0; }
  #SITE_CONTAINER, #site-root, #masterPage, #SITE_PAGES, #PAGES_CONTAINER,
  #SITE_HEADER, #SITE_HEADER_WRAPPER, #SITE_FOOTER, #SITE_FOOTER_WRAPPER,
  #soapAfterPagesContainer, #soapBeforePagesContainer,
  section[id^="comp-"], div[id^="comp-"], .cKxVkc, .VrZrC0, .V5AUxf, .vlM3HR {
    min-width: 0 !important;
    max-width: 100% !important;
  }
  /* The site column is centred by margin-left:calc((100% - var(--site-width))/2)
     which goes NEGATIVE below 980px and drags the page off-screen to the left. */
  body:not(.device-mobile-optimized) .vlM3HR { margin-left: 0 !important; width: 100% !important; }

  /* E2. The mesh: one component per row, full width, document order. */
  [data-mesh-id$="inlineContent"],
  [data-mesh-id$="inlineContent-gridContainer"] {
    width: 100% !important;
    min-height: 0 !important;
    margin-top: 0 !important;
  }
  [data-mesh-id$="-gridContainer"] {
    display: flex !important;
    flex-direction: column !important;
    grid-template-columns: none !important;
    grid-template-rows: none !important;
    height: auto !important;
  }
  [data-mesh-id$="-gridContainer"] > * {
    grid-area: auto !important;
    position: relative !important;
    left: auto !important;
    right: auto !important;
    margin-left: 0 !important;
    margin-right: 0 !important;
    width: 100% !important;
    max-width: 100% !important;
    min-width: 0 !important;
    justify-self: stretch !important;
    align-self: auto !important;
    flex: 0 0 auto;
  }
  /* Fixed component heights are desktop measurements of desktop line-breaks; at
     390px every one of them is too short and the text spills out of its own
     panel. Galleries and icon bars are excluded - they have no flow content to
     measure and would collapse to nothing. */
  [data-mesh-id$="-gridContainer"] > *:not([id^="SldShwGllry"]):not([id^="LnkBr"]) {
    height: auto !important;
  }

  /* E3. Column strips (Wix's side-by-side sections, used by the footer and by
     every two-column band) stack. */
  .V5AUxf { flex-direction: column !important; }
  [class*="YzqVVZ"], .wixui-column-strip__column { width: 100% !important; }

  /* E4. Images. A Wix image component is a fixed-size box with an img at
     height:100%; once the box is width:100% the img has to take its height from
     its own intrinsic ratio instead. Scoped to .wixui-image so that the
     background layers (#bgLayers_*, the confetti page background) are untouched
     - those are meant to fill their box. */
  .wixui-image { height: auto !important; }
  .wixui-image > a, .wixui-image > wow-image, .wixui-image wow-image { height: auto !important; }
  .wixui-image img {
    position: static !important;
    width: 100% !important;
    height: auto !important;
    object-fit: contain !important;
  }

  /* E5. Breathing room. Full-bleed sections must NOT get side padding - their
     colour is painted by an absolutely-positioned inset:0 layer, which is
     positioned against the padding box and would leave white gutters. So the
     padding goes on the leaf content components only. */
  .wixui-rich-text, .wixui-form, .wixui-checkbox, [class*="FubTgk"] {
    padding-left: 18px !important;
    padding-right: 18px !important;
    box-sizing: border-box !important;
  }

  /* E6. The header. Logo and menu are two children of one grid row; stacked,
     the menu becomes a wrapping row of full-width-friendly links. 720px of
     fixed menu width becomes auto, and the labels wrap instead of clipping. */
  #comp-kiryq9e1 { width: 150px !important; margin: 0 auto !important; }
  #DrpDwnMn0 { height: auto !important; }
  #DrpDwnMn0 .LtxuwL {
    display: flex !important;
    flex-wrap: wrap !important;
    justify-content: center !important;
    width: 100% !important;
    height: auto !important;
    white-space: normal !important;
  }
  #DrpDwnMn0 .SUHLli, #DrpDwnMn0 .xu0rO4 {
    position: relative !important;
    display: block !important;
    left: auto !important;
    top: auto !important;
    width: auto !important;
    height: auto !important;
    visibility: visible !important;
  }
  #DrpDwnMn0 .piclkP { height: auto !important; width: auto !important; }
  #DrpDwnMn0 .JghqhY { padding: 11px 12px !important; }
  /* "Mais" is the desktop overflow control; with the menu wrapping there is
     nothing left over to put in it. */
  #DrpDwnMn0__more__, #DrpDwnMn0 .QQFha4 { display: none !important; }

  /* E7. The homepage hero. A native horizontal scroll track whose slides are
     937px wide; on a phone one slide has to be one screen. (The snapping itself
     is not in this media query - see below.) */
  [id^="SldShwGllry"] { height: auto !important; aspect-ratio: 937 / 574; }

  /* E8. The four life-stage cards. Document order inside their grid is
     card, rule, card, rule ... because Wix emits row 2 before row 1; the 8px
     rule belongs ABOVE the card it introduces. */
  #FvGrdLn1 { order: 1; } #Cntnr0 { order: 2; }
  #FvGrdLn0 { order: 3; } #Cntnr1 { order: 4; }
  #FvGrdLn2 { order: 5; } #Cntnr2 { order: 6; }
  #FvGrdLn3 { order: 7; } #Cntnr3 { order: 8; }
  [id^="Cntnr"] { margin-bottom: 22px !important; }
  [id^="Cntnr"] [data-mesh-id$="-gridContainer"] { padding-bottom: 14px; }

  /* E9. The footer, which the client called out separately. Stacked, the three
     blocks need their own spacing and the social row has to stop being an
     absolutely-positioned 182px strip. */
  #comp-lfiqiq2j2 [data-mesh-id$="-gridContainer"] { padding: 26px 0 30px; }
  #comp-lfiqiq2j2 [data-mesh-id$="-gridContainer"] > * { margin-bottom: 14px; }
  [id^="LnkBr"] { height: 46px !important; margin: 6px 0 18px !important; }
  [id^="LnkBr"] .mpGTIt {
    position: relative !important;
    display: flex !important;
    justify-content: flex-start !important;
    padding-left: 18px;
    white-space: normal !important;
  }
  #SITE_STRUCTURE_WRichText_1 p { text-align: left !important; }

  /* E10. Forms. Every field is an absolutely-measured 240px or 510px box inside
     a 557px panel. */
  .wixui-form [data-mesh-id$="-gridContainer"] > * { margin-bottom: 12px; }
  .wixui-text-input, .wixui-text-box, .wixui-dropdown, .wixui-text-area,
  .wixui-text-input__input, .wixui-text-box__input, .wixui-text-area__input,
  select.wixui-dropdown__input { width: 100% !important; box-sizing: border-box !important; }

  /* E11. Blocks this restore authored are written for a 940px column. */
  .ccs-topic-intro, .ccs-topic-list, .ccs-topic-all, .ccs-topic-count,
  .ccs-page-copy, .ccs-svc-read, .ccs-service-cta {
    max-width: 100% !important;
    width: auto !important;
    margin-left: 0 !important;
    margin-right: 0 !important;
    padding-left: 18px !important;
    padding-right: 18px !important;
    box-sizing: border-box !important;
  }
  .ccs-page-copy.ccs-contact-page-inner { width: auto !important; }
  .ccs-topic-p, .ccs-copy-p { text-align: left !important; }
  .ccs-team-card { flex: 1 1 100%; }
  .ccs-readmore { position: static; display: inline-block; margin: 10px 0 4px 36px; }

  /* E12. The blog and post widgets ship their own desktop grid. */
  .post-list-item-wrapper, [class*="post-list"] .container { width: 100% !important; }
}

/* A phone is not the only narrow window; at 390 the two-column bands inside the
   authored blocks are still too tight. */
@media (max-width: 600px) {
  .ccs-team-grid { display: block !important; }
  .ccs-team-card { margin-bottom: 18px; }
  .ccs-topic-title { font-size: 19px; }
  .ccs-topic-h { font-size: 24px; }
}

/* --- E, second pass. Written against the 390px render of the first pass, one
   rule per thing that was still wrong in the screenshot. ------------------- */
@media (max-width: 1023px) {

  /* E13. The menu had disappeared. Wix positions the whole navigation
     absolutely inside the component (.HYblus>nav{position:absolute;inset:0},
     .LtxuwL{position:absolute}) and clips the overflow (.eK3b7p), so once the
     component was allowed to size itself it measured 0 tall and clipped its own
     contents. Put the nav back in flow and let the six labels wrap. */
  #DrpDwnMn0 { overflow: visible !important; }
  #DrpDwnMn0 > nav { position: static !important; height: auto !important; }
  #DrpDwnMn0 .LtxuwL {
    position: static !important;
    height: auto !important;
    width: 100% !important;
    white-space: normal !important;
    display: flex !important;
    flex-wrap: wrap !important;
    justify-content: center !important;
    padding: 4px 0 !important;
    box-shadow: none !important;
  }
  #DrpDwnMn0 .ULfND1 { height: auto !important; }
  #DrpDwnMn0 .ktxcLB { border-left: 0 !important; }

  /* E14. Wix positions a component vertically inside its grid row with
     margin-top as well as with the row itself: the menu carried margin-top:115px
     and produced a 115px hole once the row became a flex column. Every one of
     those offsets is a desktop measurement. */
  [data-mesh-id$="-gridContainer"] > * { margin-top: 0 !important; }

  /* E15. The header and footer background bands are 980px wide and centred with
     a margin-left that goes negative under 980. */
  .hF1twx, .vlM3HR, .PFkO7r { margin-left: 0 !important; width: 100% !important; }

  /* E16. A Wix button is a fixed-height box with a label at height:100%; height
     auto collapsed the box and left the white label floating over the panel. */
  button.uDW_Qe, .ccs-submit {
    min-height: 46px !important;
    height: auto !important;
    display: flex !important;
    align-items: center;
    justify-content: center;
  }
  [class*="FubTgk"], [data-semantic-classname="button"] { height: auto !important; }
  .StylableButton2545352419__root { min-height: 46px; }

  /* E17. Justified type at 390px opens rivers between the words. The site uses
     it in a handful of inline styles. */
  [style*="text-align:justify"] { text-align: left !important; }
}

/* --- E, third pass. ------------------------------------------------------- */
@media (max-width: 1023px) {
  /* E18. "Mais" is Wix's desktop overflow control: it only ever holds the items
     that did not fit on one line, and with the menu wrapping there are none. It
     survived pass 2 because #DrpDwnMn0 .xu0rO4 (1,1,0) outranks the id alone
     (1,0,0) even with !important - specificity still decides between two
     important declarations. */
  #DrpDwnMn0 li[id$="__more__"] { display: none !important; }

  /* E19. The article body is justified by a Ricos class, not an inline style,
     so E17 did not reach it: .amZBh{text-align:justify!important}. Justified
     type in a 350px measure puts four-word rivers down every paragraph. */
  .amZBh, .amZBh > *, ._-7vPo, ._-7vPo > * { text-align: left !important; }
}

/* --- C2. The tap targets the first pass did not reach ---------------------
   Enumerated with the same rule qa_legibility uses (smaller dimension under
   24px, standalone links only), on every template: the blog category strip
   (5 links, 21px), its search toggle (19x16), the two share controls at the
   foot of an article (19x19), the "Ler mais" on all 27 blog cards (75x18) and
   the "Ver todos os artigos" line on the four topic pages (176x18).
   Padding-block again: it grows the hit box without moving the line. */
.blog-navigation-container-color, [class*="blog-navigation-container-item"] > a,
.ccs-readmore, .ccs-topic-all a, .ccs-back-to-blog { padding-block: 6px; }
[class*="search-input"] > div[role="button"], [class*="search-input"] [aria-label="Pesquisar"],
.ccs-search-toggle {
  min-width: 26px;
  min-height: 26px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
[data-hook="share-button"], .ccs-share-live { min-width: 26px; min-height: 26px; padding: 3px; }

/* --- A7. The pale palette used as TEXT, everywhere it was still doing it ---
   Section A fixed the header, the four cards, the footer and the newsletter
   panel because those are what the client pointed at. A sweep of all 56 pages
   (_scripts/_ccs_lowcontrast_probe.js, which groups every run of text under its
   colour and its resolved ground) showed the same habit in the article bodies
   and on six more templates: 436 runs of #ff8282 on white at 2.40:1, 189 of
   #5f9abf at 3.06:1, 37 of #759e7c at 3.03:1, 20 of #aaa8a8 at 2.37:1 and the
   life-stage page titles at 1.71:1. In the posts the colour is an INLINE style
   written by the site's own editor, which is why these are attribute selectors
   with !important - nothing else outranks a style attribute.

   Every replacement keeps the hue and the saturation of the colour it replaces
   and only takes the lightness down until the run reaches 4.6:1 on white, so an
   emphasis the author set in blue is still blue and one set in coral is still
   coral. Two exceptions: #ff8282 at full saturation darkens to a pure signal
   red, so it goes instead to the palette's own #bf6161 darkened to 4.6 - a
   muted brick that still reads as the site's coral; and the traffic-light words
   in the food-label article, where the whole point of the colour is that the
   reader can name it, keep their hue and only lose lightness ("amarelo" was
   the last text the gate camera still called invisible, at 1.53:1). */
:root {
  --ccs-coral-ink: #bb5656;    /* 4.60:1 on white, palette color_33 darkened */
  --ccs-grey-ink:  #717070;    /* 4.94:1, palette color_14 - the site's own grey */
}

/* inline emphasis inside the articles */
[style*="color:#ff8282"], [style*="color:#ff6161"],
[style*="color:rgb(255, 130, 130)"] { color: var(--ccs-coral-ink) !important; }
[style*="color:#5f9abf"], [style*="color:#77b8db"] { color: var(--ccs-blue-ink) !important; }
[style*="color:#70ad47"], [style*="color:#9cd3a5"],
[style*="color:#759e7c"] { color: var(--ccs-green-ink) !important; }
[style*="color:#7f7f7f"], [style*="color:#aaa8a8"] { color: var(--ccs-grey-ink) !important; }
[style*="color:#ff0000"] { color: #e00000 !important; }                 /* 4.6:1 */
[style*="color:#7fdb03"] { color: #4c8302 !important; }                 /* "verde"   4.6:1 */
[style*="color:#e9d203"] { color: #837602 !important; }                 /* "amarelo" 4.6:1 */

/* The palette classes, where they are text on a light ground. The three places
   the same classes sit on a COLOURED panel - the homepage cards and the
   testimonial photographs - are overridden by id earlier in this file and by
   the rule below, so they keep the light type the design intends. */
.color_27, .color_28 { color: var(--ccs-green-ink); }
.color_17 { color: var(--ccs-blue-ink); }
.color_13, .color_43 { color: var(--ccs-grey-ink); }
#Cntnr1 .color_17, #Cntnr1 .color_17 * { color: var(--ccs-blue-deep); }

/* The blog's own category strip, on 32 pages: #aaa8a8 on white, 2.37:1, with
   the current category indistinguishable from the rest. */
.blog-navigation-container-color { color: var(--ccs-grey-ink) !important; }
.blog-navigation-container-color[aria-current="page"] {
  color: var(--ccs-green-ink) !important;
  font-weight: 700;
}

/* A8. The panels whose white type the sweep still could not carry.
   Same reasoning as A3: darken the panel, keep the type light. Each new value
   is that panel's own colour taken down to 4.6:1 against white. */
#Cntnr5 { --bg: 44, 124, 167; }                             /* #2c7ca7, was color_17 #77b8db */
#comp-m1f3nbd9 { --bg-overlay-color: var(--ccs-blue-ink); } /* was color_41 #5f9abf */
/* "Feedbacks" was white on the pale blue #bfe6ff: 1.31:1. */
#comp-l1htw5a8 .color_36, #comp-l1htw5a8 .color_36 * { color: var(--ccs-blue-ink) !important; }
/* The twelve booking buttons carried white on the brand green. */
a.sgzSiFV { background-color: var(--ccs-green-panel) !important; }
/* The contact form's own submit, white on the site coral at 2.40:1. Same answer
   as the header call-to-action: the button keeps the coral, the label darkens. */
.ccs-submit { color: var(--ccs-coral-deep) !important; }

/* --- A7b / C3. Two misses found by re-running the sweep over all 56 pages ---
   1. The one text the gate camera still called invisible, "amarelo" at 1.53:1,
      is written `color:#E9D203` in UPPER case. An attribute selector matches its
      value case-sensitively unless told otherwise, so the rule above ran past
      it. The i flag is on all of them now, because the same editor wrote both
      cases and the next one is a coin toss. */
[style*="color:#ff8282" i], [style*="color:#ff6161" i],
[style*="color:rgb(255, 130, 130)" i] { color: var(--ccs-coral-ink) !important; }
/* #bfe6ff is deliberately NOT in this list. It is used in exactly one place - the emphasised
   words on the /consultas/ mid-blue band - and A8 darkens that band to --ccs-blue-ink, so
   remapping the text to the same value painted it on itself: the sweep caught five runs at
   1:1, invisible, created by this very fix. Left pale, it reads on the darkened band at 4.98:1. */
[style*="color:#5f9abf" i], [style*="color:#77b8db" i] { color: var(--ccs-blue-ink) !important; }
[style*="color:#70ad47" i], [style*="color:#9cd3a5" i],
[style*="color:#759e7c" i] { color: var(--ccs-green-ink) !important; }
[style*="color:#7f7f7f" i], [style*="color:#aaa8a8" i] { color: var(--ccs-grey-ink) !important; }
[style*="color:#ff0000" i] { color: #e00000 !important; }
[style*="color:#7fdb03" i] { color: #4c8302 !important; }   /* "verde"   4.6:1 */
[style*="color:#e9d203" i] { color: #837602 !important; }   /* "amarelo" 4.6:1 */

/* 2. Three more families of 18px-tall standalone link: the "related reading"
      lists on the twelve service pages, the links written into the Wix
      rich-text blocks on /contato-com-mapa/ and /consultas/, and the article
      bodies' own links (one of which is a bare YouTube URL used as its own
      label). */
.ccs-svc-read a, .wixui-rich-text a, .ccs-topic-intro a,
[class*="GKQb5"], .post-content a { padding-block: 5px; }

/* --- A9. The service catalogue ------------------------------------------
   /consultas/ is where a paying visitor chooses what to book, and the Wix
   Bookings widget set the nine service titles in #9cd3a5 on white (1.71:1
   against a 3.0 floor for 24px type) and every line of card metadata —
   including the price — in #759e7c at 3.03:1. It was the largest single block
   of unreadable text left on the site after sections A1-A8, 32 runs on one
   page. Same treatment as everywhere else: the site's own green, at the step
   that can be read. */
a.sk3GcZh h2, a.sk3GcZh [class*="s__38MnCt"] { color: var(--ccs-green-ink) !important; }
.sLavBz3, .sPX_PkC [class*="s__38MnCt"], .sPX_PkC p { color: var(--ccs-ink) !important; }

/* A9b. The last of /consultas/: the nine service tag-lines, set in the site
   coral on white at 2.40:1, and the two buttons on the authored service call
   to action, which this restore itself wrote as white-on-coral (2.40:1) and
   #759e7c-on-white (3.03:1) before there was a gate that could measure them. */
.soIXAHR [class*="s__38MnCt"] { color: var(--ccs-coral-ink) !important; }   /* 4.60:1 */
.ccs-service-cta a { color: var(--ccs-coral-deep); }                        /* 6.09:1 on coral */
.ccs-service-cta a.ccs-cta-alt { color: var(--ccs-green-ink); }             /* 6.48:1 on white */

/* --- A10. The last of the pale palette, found by a second full-site sweep ---
   Four sources the per-element rules could not reach, because none of them is a
   colour written on the element that carries the text:

   1. .font_2 is the theme's page-title style and it defaults to
      color:rgb(var(--color_27)) - #9cd3a5 - so every H1 that does not carry an
      explicit colour class is a 39px title at 1.71:1 against a 3.0 floor:
      "A equipa", "Sobre a Crescer com Sabor", "Página não encontrada",
      "Política de Privacidade", "Política de Cookies", "PRÉ-CONCEÇÃO E
      GRAVIDEZ". The :not() guard leaves alone any heading that DOES name its
      own palette colour, which is how the white headings on the coloured bands
      are written.
   2. --textLinksAndHashtagsColor is the blog theme's link colour, 95,154,191,
      and it paints every citation link in every reference list: 3.06:1.
   3. A handful of post headings are white on an inline coral highlight, the
      same pattern as .backcolor_31 on the homepage band.
   4. .color_18 / .color_41 are the same #5f9abf as a class. */
.font_2:not([class*="color_"]), .font_5:not([class*="color_"]) { color: var(--ccs-green-ink); }
[style*="--textLinksAndHashtagsColor"] { --textLinksAndHashtagsColor: 47, 98, 133; }
[style*="background-color:#ff8282" i], [style*="background-color:#ff8282" i] * {
  color: var(--ccs-coral-deep) !important;
}
.color_18, .color_41 { color: var(--ccs-blue-ink); }
.ccs-topic-more { color: var(--ccs-coral-ink); }
.ccs-readmore { color: var(--ccs-coral-ink); }
[style*="color:#bf6161" i] { color: #bb5656 !important; }

/* --- E20. /blog/ on a phone showed 40 photographs and not one headline -----
   The Wix Pro Gallery does its own layout in inline styles: a 940px absolutely
   positioned card per row, the picture floated left at 454px and the whole of
   the text - title, excerpt, date, reading time - in a 486px box floated right.
   At 390 the card is still 940 wide and the right-hand 550px of every card,
   which is all of its words, sits outside the viewport. Nothing else on the
   site was clipped, so the page looked like a deliberate photo grid rather
   than like a fault, which is how it survived the first mobile pass.
   Everything below is the same de-positioning that section E does to the mesh,
   applied to the gallery's own inline geometry. */
@media (max-width: 1023px) {
  [id^="pro-gallery-container-"], [id^="pro-gallery-margin-container-"] {
    height: auto !important;
    width: 100% !important;
    overflow: visible !important;
  }
  .item-link-wrapper, .gallery-item-container {
    position: static !important;
    width: 100% !important;
    height: auto !important;
    margin-bottom: 20px !important;
  }
  .gallery-item-container > div[style*="float:left"] { float: none !important; }
  .gallery-item-wrapper, .gallery-item-content {
    width: 100% !important;
    height: auto !important;
    margin: 0 !important;
  }
  .gallery-item-common-info-outer, .gallery-item-common-info {
    float: none !important;
    width: 100% !important;
    height: auto !important;
    overflow: visible !important;
  }
  .gallery-item-content picture, .gallery-item-content picture img {
    width: 100% !important;
    height: auto !important;
    position: static !important;
  }
  /* The card's own read-more, absolutely placed against a fixed-height card. */
  .post-list-item-wrapper { padding-bottom: 8px; }
}

/* E20b. The first attempt at the gallery collapsed every card to a 2px line:
   the Pro Gallery positions BOTH halves of a card absolutely
   (.gallery-item-content and .gallery-item-common-info), so once their
   ancestors were told to size themselves they had nothing to size to.
   Measured at 390 with a DOM dump rather than guessed. */
@media (max-width: 1023px) {
  .gallery-item-content, .gallery-item-common-info {
    position: relative !important;
    height: auto !important;
  }
  .gallery-item-container { overflow: visible !important; }
  .gallery-item-wrapper { height: auto !important; }
  /* Wix renders the same photograph twice per card, a preload copy and the real
     one; side by side in a flow layout that is two pictures. */
  .gallery-item-content picture:first-of-type { display: none !important; }
  .post-list-item-wrapper { padding-top: 18px !important; padding-bottom: 44px !important; }
}

/* A10b. The last two runs the final sweep still reported.
   .font_6 is the theme's sub-heading style and defaults to the same
   #9cd3a5 as .font_2; the guard is the same, and the footer headings, which
   ARE white, name their colour on an inner span and are untouched. */
.font_6:not([class*="color_"]) { color: var(--ccs-green-ink); }
/* The contact form's submit puts its label in a span of its own, so colouring
   the button was not enough. Scoped to the CORAL submit: the newsletter button
   is the green one, and the first version of this rule put dark maroon on
   #2f6a39 and took "Subscrever newsletter" from 6.48:1 down to 2.25:1 - a fix
   that broke a button two sections above it, caught by the next full sweep. */
.ccs-submit:not(.ccs-submit--green) .l7_2fn,
.ccs-submit:not(.ccs-submit--green) .wixui-button__label {
  color: var(--ccs-coral-deep) !important;
}
.ccs-submit--green .l7_2fn, .ccs-submit--green .wixui-button__label {
  color: #fff !important;                                  /* 6.48:1 on --ccs-green-ink */
}

/* --- E7b. The hero track snaps at every width ------------------------------
   It was a phone-only rule until qa_interactions failed on one run in three
   with the caption of a slide reported UNREACHABLE - "a real pointer lands on
   button.ccs-gal-btn--next instead". The captions span the full slide, so a
   slide that is only half scrolled in has its centre at the frame's right edge,
   which is exactly where the next arrow sits. Snapping means the track can only
   ever come to rest with one slide aligned, so every caption is either centred
   or off-view, never half-way under a control. It is also what the strip's own
   deleted caption asked for - the widget was built to be dragged. */
.CKet9C { scroll-snap-type: x mandatory; }
.CKet9C > * { scroll-snap-align: center; }

/* --- The five hero slides stopped pretending to be buttons ------------------
   Each slide is wrapped in <div class="JmYZSh" role="button" aria-haspopup
   data-testid="gallery-item-click-action-image-zoom"> - Wix's "click the photo
   to zoom it" action, whose lightbox went with the JavaScript. Clicking it does
   nothing, and it was ALSO the source of an intermittent qa_interactions
   failure: the wrapper spans the whole slide, so a slide that is half scrolled
   into the track has its centre under the next arrow, and the gate reported a
   control a real pointer cannot reach - on one run in three, naming a different
   blocker each time.
   The role, aria-haspopup and tabindex are removed from the markup and the
   pointer cursor here, which is the project's standing answer for an affordance
   whose behaviour is gone: keep the content, drop the promise. The photograph
   still carries its alt text and the slide its caption; the arrows, the dots,
   the keyboard and the touch drag are the controls that do work. */
[data-testid="gallery-item-click-action-image-zoom"] { cursor: default !important; }

/* --- E21. "Enviar" was 52% covered by the note under it at 390 -------------
   Reproduced 3/3 by an independent review and then measured with
   _scripts/_ccs_r10_enviar.js, which walks the ancestor chain from the <button>
   up to the form component and prints each box next to its computed height. The
   chain says it in one line: button 18/1451/354x46, and its parent
   div#comp-khytmuxd.FubTgk **height 0**.

   A Wix button is two elements. `.FubTgk{height:100%}` is the mesh child that
   owns the row, and `.FubTgk .uDW_Qe{position:absolute;inset:0}` is the button
   painted inside it. On the desktop grid the row has a reserved height and
   100% of it is 46px. Section E turns that grid into a flex column, so
   `height:100%` has nothing to be a percentage OF and falls back to the
   wrapper's own content - and its only child is out of flow. The wrapper
   measures 0. E16 then gives the button `min-height:46px` so that it is still
   VISIBLE, which is what makes this so easy to miss: the button looks right and
   is 46px of paint standing entirely outside the box that reserves space for
   it. The next element in normal flow, p.ccs-form-note, starts 22px above the
   button's bottom edge and covers 24 of its 46 pixels. Hit-testing down the
   centre line: only top+4 and 25% reached the button; the centre, 75% and the
   bottom all landed on the note.

   This is E20b's bug, one component over - "both halves of a card are
   positioned absolutely, so once their ancestors were told to size themselves
   they had nothing to size to" - and it takes E20b's fix: put the child back in
   flow and let the wrapper measure it. Not a min-height on the wrapper, which
   would be another hard-coded desktop row height and would come apart the day a
   label wraps.

   The padding has to go with it. E5 gives every leaf content component 18px of
   side padding, `[class*="FubTgk"]` among them, and until now that padding was
   INERT: an absolutely positioned child is laid out against its ancestor's
   PADDING box, so inset:0 spanned the full 354px anyway. Put the button in flow
   and the same padding suddenly bites, indenting it 18px and shrinking it to
   318 while the inputs above it stay 354 wide - and `.l7_2fn` is nowrap, so a
   long label ("Subscrever newsletter") would then overflow rather than wrap.
   Zeroing it here reproduces exactly the geometry the page already had.

   Desktop is untouched: everything below is inside the phone/tablet query, and
   the document height at 1440 is identical before and after (measured, both
   form pages). The homepage newsletter button had the identical 0-height
   wrapper and only escaped because one more mesh child follows it - a latent
   copy of the same defect, fixed by the same rule. */
@media (max-width: 1023px) {
  .FubTgk .uDW_Qe, [class*="FubTgk"] .uDW_Qe {
    position: relative !important;
    inset: auto !important;
  }
  [class*="FubTgk"] { padding-left: 0 !important; padding-right: 0 !important; }
}
