/* ============================================================================================ celinesantenaturelle.com - restoration stylesheet ============================================================================================ Everything here is an addition to the site's own inlined Wix CSS, never a replacement. Each section says what was measured, on which page, and why the rule is shaped the way it is. Platform: Wix Thunderbolt, 2022-05/2022-06 generation, DESKTOP payload (formFactor "Desktop", --site-width:980px, zero layout media queries on the content pages). Wix served its phone layout as a separate payload that no archive holds, so the phone view is rebuilt here. ============================================================================================ */ /* ============================================================================================ SECTION A - A PHONE GETS A PHONE LAYOUT ============================================================================================ WHAT WAS WRONG. Every page declares width=device-width, and at 390 the document measured 1025px: the desktop mesh at its fixed 980 plus the "More" overflow menu's items, which Wix lays out at x=879 with their natural width (measured: li#comp-jhpwvpsw10 right edge 1026). So the site scrolled sideways on a phone and two thirds of every page sat off-screen. WHY THE META ALONE WOULD MAKE IT WORSE. #site-root carries min-width:980px (measured, computed style). Release nothing else and device-width CLIPS instead of reflowing - body copy cut mid-sentence with every overflow check green, because Wix's containers are overflow:hidden. The route below is the one proved on the sister Wix sites crescercomsabor.pt and wenou.pt; every selector was re-derived against THIS site's DOM (its hashed class names are a different bundle generation and copying wenou's would have done nothing at all). HOW THE MESH WORKS HERE, measured rather than assumed. #masterPage is a grid; each section is [id^="comp-"]; inside it [data-mesh-id$="-gridContainer"] is a single-column grid whose children are absolutely offset by `left` and sized with a fixed px width. Turning that container into a flex column and dropping left/width/margin puts the components one under another in document order, which is the reading order the page was authored in. AND WHY THE REFLOW STOPS AT THE HEADER. The first attempt applied the mesh rules everywhere and the phone homepage opened on three teasers nobody had ever seen ("Troubles digestifs", "Fatigue", "Detoxification") above a logo four hundred pixels tall. Measured cause: this site's #SITE_HEADER grid holds three components the site parks ABOVE the document - comp-k17m9dgv at document top -3182, comp-k17m9mh2 at -3162, comp-k17n5qzg at -1763 (read in document coordinates with _o5_cel_hdrmap.js, because a viewport-relative rect on a scrolled page says the same thing about a component that is simply at the top). Dropping `margin-top` to stack the mesh is exactly what un-parks them. So the mesh rules below are scoped to #PAGES_CONTAINER and #SITE_FOOTER, the header is rebuilt by name in section B, and the three parked components stay parked. ============================================================================================ */ @media (max-width: 1023px) { /* A1. Release the 980px floor first, or everything below clips instead of reflowing. DO NOT PUT overflow-x:hidden ON html OR body HERE. It was there for one round and it made the phone page unscrollable: this site gives html and body height:844px and lets body own the scroll, the viewport propagating it. Adding overflow-x to html turns html into its own scroll container of exactly one viewport, propagation stops, and window.scrollY stays 0 for ever - measured, by scrolling to 3000 and reading back 0. Every gate stayed green through it, because scrollWidth still equalled clientWidth and the first screen still rendered. The overflow it was hiding is gone anyway once the wrappers below stop being 980 wide. */ #site-root { overflow-x: hidden !important; } #site-root, #SITE_CONTAINER, #masterPage, #SITE_PAGES, #PAGES_CONTAINER, #main_MF, #BACKGROUND_GROUP, #SITE_HEADER, #SITE_HEADER_WRAPPER, #SITE_FOOTER, #SITE_FOOTER_WRAPPER, #soapAfterPagesContainer, #soapBeforePagesContainer, #pinnedTopLeft, #pinnedTopRight, section[id^="comp-"], div[id^="comp-"], [id^="pageBackground_"], [id^="bgLayers_"], [id^="bgMedia_"] { min-width: 0 !important; max-width: 100% !important; } #site-root, #masterPage, #SITE_PAGES, #PAGES_CONTAINER, #main_MF, [id^="pageBackground_"] { width: 100% !important; margin-left: 0 !important; margin-right: 0 !important; } /* A1b. THE FOUR PAGE WRAPPERS BETWEEN #PAGES_CONTAINER AND THE MESH. Measured at 390 after the mesh rules were already in place: div#.Ry26q, div._3CemL, div._3K7uv and div#Container were all still computing width:980px, so every section inside them was 980 wide however wide its own rule said it was. They carry no id worth naming (the id is the Wix page id and differs on all 100 pages), so they are addressed by depth from #PAGES_CONTAINER. */ #PAGES_CONTAINER > div, #PAGES_CONTAINER > div > div, #PAGES_CONTAINER > div > div > div, #PAGES_CONTAINER > div > div > div > div { width: 100% !important; min-width: 0 !important; max-width: 100% !important; left: 0 !important; margin-left: 0 !important; } /* A2. The mesh: one component per row, full width, document order. Two spellings of the same thing: the 2022 template marks the mesh with data-mesh-id, and the newer generation that /blog/ was captured from marks it with an id ending in the same words. Both are listed everywhere below - /blog/ was the one page still 980 wide at 390 because the first version of this section knew only the first spelling. */ #PAGES_CONTAINER [data-mesh-id$="inlineContent"], #PAGES_CONTAINER [id$="inlineContent"], #SITE_FOOTER [data-mesh-id$="inlineContent"], #SITE_FOOTER [id$="inlineContent"] { width: 100% !important; min-height: 0 !important; margin-top: 0 !important; } #PAGES_CONTAINER [id$="inlineContent-gridContainer"], #SITE_FOOTER [id$="inlineContent-gridContainer"], #PAGES_CONTAINER [data-mesh-id$="-gridContainer"], #SITE_FOOTER [data-mesh-id$="-gridContainer"] { display: flex !important; flex-direction: column !important; grid-template-columns: none !important; grid-template-rows: none !important; height: auto !important; /* Wix writes min-height on the mesh container equal to the desktop column's height; the portrait column measured 3162px around a 553px photograph until this line was added, and height:auto could not overrule a min-height. Read off the element, not guessed. */ min-height: 0 !important; width: 100% !important; } #PAGES_CONTAINER [id$="inlineContent-gridContainer"] > *, #SITE_FOOTER [id$="inlineContent-gridContainer"] > *, #PAGES_CONTAINER [data-mesh-id$="-gridContainer"] > *, #SITE_FOOTER [data-mesh-id$="-gridContainer"] > * { grid-area: auto !important; position: relative !important; left: auto !important; right: auto !important; top: auto !important; margin-left: 0 !important; margin-right: 0 !important; margin-top: 0 !important; min-width: 0 !important; width: 100% !important; max-width: 100% !important; align-self: auto !important; justify-self: stretch !important; height: auto !important; flex: 0 0 auto; /* A2e. NEGATIVE MARGIN-BOTTOM IS HOW THE MESH OVERLAPS ITS OWN BANDS. Measured on the homepage at 390: -231px on the opening band, -107px on the hero, -119px on the biography, and five more. In the grid those pull a band up into the one above on purpose; stacked in a column they simply paint one band across the next, and the hero photograph cut "Syndrome post pilule contraceptive" in half. Both margins go and the container below supplies one even rhythm. */ margin-bottom: 0 !important; } #PAGES_CONTAINER [id$="inlineContent-gridContainer"], #SITE_FOOTER [id$="inlineContent-gridContainer"], #PAGES_CONTAINER [data-mesh-id$="-gridContainer"], #SITE_FOOTER [data-mesh-id$="-gridContainer"] { row-gap: 14px !important; } /* A2a. THE WEDGES. Wix pads its mesh with empty spacer divs - data-mesh-id="…-wedge-N" - carrying the px heights that hold the desktop grid apart. As grid rows they cost nothing once their row collapses; as flex children in a column they contribute every pixel. Measured: the portrait's column computed 3162px tall around a 549px photograph with height:auto and min-height:0 both applied, and the missing 2600 were wedges. */ #PAGES_CONTAINER [data-mesh-id*="wedge"], #SITE_FOOTER [data-mesh-id*="wedge"], #SITE_HEADER [data-mesh-id*="wedge"] { display: none !important; } /* A2b. A SECTION MUST BE ALLOWED TO GROW. Wix gives every band a fixed desktop height; stacked into a column the content is three to five times taller and the band would simply cut it off (its own overflow is hidden). Only the section boxes are released - not the background layers, which are dealt with in A4. */ #PAGES_CONTAINER section[id^="comp-"], #SITE_FOOTER section[id^="comp-"], #PAGES_CONTAINER div[id^="comp-"]:not([id^="bgLayers_"]):not([id^="bgMedia_"]), #SITE_FOOTER div[id^="comp-"]:not([id^="bgLayers_"]):not([id^="bgMedia_"]) { height: auto !important; min-height: 0 !important; } /* A2c. THE ABSOLUTELY-POSITIONED INNER COLUMN. Wix wraps each section's children in a div that is position:absolute and therefore contributes nothing to its parent's height; released sections would then be 0 tall and the whole page would collapse into the header. Measured on / , /mentions-legales/ and /post/la-cure-de-jus/: the wrapper is the element that carries data-mesh-id="…inlineContent". */ #PAGES_CONTAINER [data-testid="inline-content"], #SITE_FOOTER [data-testid="inline-content"] { position: relative !important; height: auto !important; } /* A2d. THE COLUMN STRIPS ARE NOT PART OF THE MESH. Wix's multi-column band is a flex row marked data-testid="columns", and its children carry --column-width:980px; the mesh rules above never touch it. Measured at 390 before this rule: the biography strip kept its desktop split, so the portrait held the left half and "Praticienne en réflexologie plantaire" wrapped one or two words per line down a 180px gutter, and the "Pourquoi la naturopathie" strip put every one of its paragraphs in the right-hand half with the left half empty. One column per row instead. */ #PAGES_CONTAINER [data-testid="columns"], #SITE_FOOTER [data-testid="columns"] { display: flex !important; flex-direction: column !important; width: 100% !important; height: auto !important; } #PAGES_CONTAINER [data-testid="columns"] > *, #SITE_FOOTER [data-testid="columns"] > * { width: 100% !important; max-width: 100% !important; min-width: 0 !important; flex: 0 0 auto !important; height: auto !important; /* min-height is the one that actually held it. Stacked, the portrait's column still computed 3162px - the height of its taller sibling - leaving 2600px of blank white between the photograph and the biography, two full phone screens of nothing. height:auto alone did not move it; the value was coming from min-height. */ min-height: 0 !important; } /* A3. Rich text: Wix sizes each text box in px for a 980 column. */ [data-testid="richTextElement"] { width: 100% !important; height: auto !important; } [data-testid="richTextElement"] * { max-width: 100% !important; } [data-testid="richTextElement"] h1, [data-testid="richTextElement"] h2, [data-testid="richTextElement"] h3, [data-testid="richTextElement"] h4 { overflow-wrap: break-word; } /* A3b. Type set for a 980px column is unreadable in a 350px measure: the hero heading is 103px and the strapline 55px. Cap the extremes; anything already small is left alone, so the site keeps its own typographic scale. */ [style*="font-size:103px"], [style*="font-size: 103px"] { font-size: 40px !important; } [style*="font-size:80px"], [style*="font-size: 80px"] { font-size: 34px !important; } [style*="font-size:60px"], [style*="font-size: 60px"] { font-size: 30px !important; } [style*="font-size:55px"], [style*="font-size: 55px"] { font-size: 28px !important; } [style*="font-size:50px"], [style*="font-size: 50px"] { font-size: 26px !important; } [style*="font-size:45px"], [style*="font-size: 45px"] { font-size: 25px !important; } [style*="font-size:40px"], [style*="font-size: 40px"] { font-size: 24px !important; } [style*="font-size:36px"], [style*="font-size: 36px"] { font-size: 22px !important; } [style*="text-align:justify"] { text-align: left !important; } /* A4. THE PHOTOGRAPHIC BANDS. A full-bleed band holds its picture in an absolutely positioned background layer, so once the band is height:auto it has no in-flow content of its own and the photograph disappears - silently, because no gate can see a background that is 0 tall. The layers keep filling their band, and the band keeps a shape rather than a fixed height. */ #PAGES_CONTAINER [id^="bgLayers_"], #PAGES_CONTAINER [id^="bgMedia_"], #SITE_FOOTER [id^="bgLayers_"], #SITE_FOOTER [id^="bgMedia_"] { height: 100% !important; width: 100% !important; } #PAGES_CONTAINER [id^="bgMedia_"] wix-image, #PAGES_CONTAINER [id^="bgMedia_"] wix-image img, #PAGES_CONTAINER wix-bg-media, #PAGES_CONTAINER wix-bg-media img { height: 100% !important; width: 100% !important; object-fit: cover !important; } /* A5. Images. A Wix image component is a fixed box with the stretched to height:100%; at full width with height:auto the box measures 0 and the picture vanishes. Scoped to the page body and the footer: the header's logo and its three 25x25 social marks are too, and the first version of this rule turned them into full-width banners painted across the hero. */ #PAGES_CONTAINER wix-image, #SITE_FOOTER wix-image { display: block !important; height: auto !important; width: 100% !important; } #PAGES_CONTAINER wix-image > img, #SITE_FOOTER wix-image > img { position: static !important; width: 100% !important; height: auto !important; object-fit: contain !important; } /* …except a background layer's image, which must still cover its band. */ #PAGES_CONTAINER [id^="bgMedia_"] wix-image > img { height: 100% !important; object-fit: cover !important; } /* A6. Breathing room on leaf content only. Padding a full-bleed band would show white gutters, because the band paints its colour with an inset:0 layer underneath. */ [data-testid="richTextElement"] { padding-left: 16px !important; padding-right: 16px !important; box-sizing: border-box !important; } } /* ============================================================================================ SECTION B - THE NAVIGATION ============================================================================================ B1 applies at every width and fixes a defect visible on the 1440 screenshot: Wix pins the logo box at the left of the header and starts the menu underneath it, so "Accueil" reads as "eil" with the logo painted over its first four letters. Giving the menu strip a left inset the width of the logo puts the first item back where it can be read. B2 is the phone menu. Wix positions the whole component absolutely and hides everything past "Blog" behind a "More" control whose dropdown is JavaScript this static copy does not have. With the JS frozen, "More" is a control that does nothing and six real pages (Médias, A propos, Contact, Mentions légales, CGV) are unreachable from the menu. Below 1024 the menu becomes a wrapped list of all its items and "More" is removed, so every item is a link that works. ============================================================================================ */ @media (min-width: 1024px) { /* TWO THINGS ARE WRONG WITH THE DESKTOP MENU AND THEY HAVE TO BE FIXED TOGETHER. (1) The logo box is pinned at x=74..318 while the menu band starts at x=230, so the first item sat underneath it and "Accueil" read as "eil" on every one of the 100 pages - visible on the very first desktop screenshot. 318 - 230 = 88, so 96px of inset clears it. (2) "More" is Wix's overflow control and its dropdown is built by JavaScript this static copy does not run: measured, the six items behind it (Médias - Collabs, A propos, Contact, Mentions légales, CGV) laid out at x=879 with height 0. So six real pages, two of them the legal pages, had no route from the menu, and "More" was a control that did nothing. The menu therefore wraps onto two rows inside the same 53px strip - every item a working link, nothing hidden behind a control that cannot open - and "More" goes. Measured after: the twelve items occupy two rows inside the 884px that remain of the 980 band. */ #masterPage #comp-jhpwvpswitemsContainer { padding-left: 96px !important; box-sizing: border-box !important; display: flex !important; flex-wrap: wrap !important; justify-content: flex-end !important; align-content: center !important; white-space: normal !important; } #masterPage #comp-jhpwvpswitemsContainer > li { position: relative !important; left: auto !important; top: auto !important; width: auto !important; height: auto !important; display: block !important; } #masterPage #comp-jhpwvpswitemsContainer > li > a, #masterPage #comp-jhpwvpswitemsContainer > li > div { height: auto !important; } #masterPage [id^="comp-jhpwvpsw"][id$="label"] { padding: 2px 7px !important; line-height: 22px !important; } #masterPage #comp-jhpwvpswitemsContainer > li[id$="__more__"] { display: none !important; } } /* B1b. The menu labels are the site's sage green on white: 2.64:1, well under the 4.5 a 16px label needs. The replacement keeps the hue and the saturation of rgb(141,168,109) and moves lightness only, so the menu still reads as the same green - measured 5.7:1 on white. */ [id^="comp-jhpwvpsw"][id$="label"] { color: rgb(86, 110, 58) !important; } @media (max-width: 1023px) { /* B0. THE THREE PARKED COMPONENTS. Measured in document coordinates at 1440: comp-k17m9dgv sits at -3182, comp-k17m9mh2 at -3162, comp-k17n5qzg at -1763 - all of them above the top of the page, which is how this site keeps six service teasers out of sight while leaving their words in the markup. They are the only components on any page with a document top below zero (enumerated with _o5_cel_hdrmap.js, not guessed). Named explicitly so nothing else in the header can be lost by accident. */ #masterPage #comp-k17m9dgv, #masterPage #comp-k17m9mh2, #masterPage #comp-k17n5qzg { display: none !important; } /* B0b. THE HEADER BAND, REBUILT RATHER THAN REFLOWED. Measured layout at 1440: #SITE_HEADER_WRAPPER is 0px tall and holds three things that all float over the page - #SITE_HEADER (position:fixed, 101px, containing the 980px menu), #pinnedTopLeft (a full-viewport fixed grid whose only child is the 244x64 logo at x=74) and #pinnedTopRight (the same trick for the three 25x25 social marks at x=1257, i.e. 867px outside a 390 viewport). A 22-item menu cannot fit a 101px bar at 390 and a fixed bar tall enough to hold it would cover the page, so below 1024 the wrapper becomes an ordinary stacked block: logo, then the social marks, then the menu, then the page. Nothing is hidden and nothing floats. */ EVERY SELECTOR BELOW IS PREFIXED WITH #masterPage ON PURPOSE. The page's own mesh stylesheet is emitted INSIDE , after this file's , and it contains `#SITE_HEADER { … position: fixed !important … }`. Same specificity, later in the document, so it wins: the first attempt left the header fixed at 1661px tall and the phone homepage screenshotted as a blank white rectangle. Two ids beat one whatever the order. */ #masterPage #SITE_HEADER_WRAPPER { display: flex !important; flex-direction: column !important; position: relative !important; height: auto !important; background: #fff; } #masterPage #SITE_HEADER-placeholder { display: none !important; } #masterPage #pinnedTopLeft { order: 1; } #masterPage #pinnedTopRight { order: 2; } #masterPage #SITE_HEADER { order: 3; position: relative !important; height: auto !important; min-height: 0 !important; } #masterPage [id$="-pinned-layer"] { position: static !important; display: block !important; height: auto !important; width: 100% !important; margin-top: 0 !important; } #masterPage #comp-jbc7vj8u { position: relative !important; left: auto !important; top: auto !important; width: 244px !important; max-width: 88% !important; height: 64px !important; margin: 10px auto 2px !important; } #masterPage #comp-jaw5twrj, #masterPage #comp-jaw5twrj > ul { position: relative !important; left: auto !important; top: auto !important; width: 103px !important; height: 25px !important; margin: 0 auto 6px !important; } /* the header's own background and column strips are sized for the 980 band */ #masterPage #SITE_HEADER > div, #masterPage #SITE_HEADER > div > div { width: 100% !important; max-width: 100% !important; left: 0 !important; right: auto !important; } /* The header's mesh wrapper carries a large NEGATIVE margin-top - that is how Wix parks the three teaser sections above the page. With those sections hidden the margin is still there, and it took the menu 3075px above the document with it. */ #masterPage #SITE_HEADER [data-mesh-id$="inlineContent"] { position: relative !important; height: auto !important; width: 100% !important; margin: 0 !important; top: auto !important; } #masterPage #SITE_HEADER [data-mesh-id$="-gridContainer"] { display: flex !important; flex-direction: column !important; height: auto !important; width: 100% !important; margin: 0 !important; top: auto !important; } #masterPage #SITE_HEADER [data-mesh-id$="-gridContainer"] > * { position: relative !important; left: auto !important; right: auto !important; top: auto !important; margin-left: 0 !important; margin-top: 0 !important; width: 100% !important; max-width: 100% !important; height: auto !important; grid-area: auto !important; } #masterPage #comp-jhpwvpsw, #masterPage #comp-jhpwvpswnavContainer, #masterPage #comp-jhpwvpswitemsContainer { position: static !important; height: auto !important; width: 100% !important; overflow: visible !important; visibility: visible !important; padding-left: 0 !important; left: auto !important; } #masterPage #comp-jhpwvpswitemsContainer { display: flex !important; flex-wrap: wrap !important; justify-content: center !important; padding: 4px 6px 10px !important; white-space: normal !important; } #masterPage #comp-jhpwvpswitemsContainer > li { position: relative !important; display: block !important; left: auto !important; top: auto !important; width: auto !important; height: auto !important; } #masterPage #comp-jhpwvpswitemsContainer > li > a, #masterPage #comp-jhpwvpswitemsContainer > li > div { height: auto !important; } /* 24px is the floor a finger can hit; the labels are 18px tall on their own. */ #masterPage [id^="comp-jhpwvpsw"][id$="label"] { padding: 7px 8px !important; display: block !important; white-space: nowrap; } /* "More" is the desktop overflow control. With the list wrapping there is nothing to overflow, and with the JS frozen it opened nothing anyway - a control that does not work. */ #masterPage #comp-jhpwvpswitemsContainer > li[id$="__more__"] { display: none !important; } } /* ============================================================================================ SECTION C - THE BLOG TEMPLATE ============================================================================================ C1. THE SITE MENU WAS INVISIBLE ON /blog/. Measured: on / the component computes visibility:visible, on /blog/ the very same #comp-jhpwvpsw computes visibility:hidden, because that page was captured from a different Wix bundle whose .hidden-during-prewarmup class is only cleared by the hydration script - which a static copy never runs. The blog index therefore shipped with a header containing nothing but the logo: a page with no way out, which is exactly the "one naked page" the client rejects. Nothing else on any of the 100 pages uses the class. C2. TAP TARGETS. The blog's own category strip renders its links 18px tall (measured 62x18 for "All Posts"), and there are 115 such controls under the 24px floor on /blog/ alone. ============================================================================================ */ .hidden-during-prewarmup { visibility: visible !important; } /* C1b. /blog/ IS A DIFFERENT WIX GENERATION AND ITS SKELETON HAS DIFFERENT NAMES. The other 99 pages hang off div#site-root; this one off div#SITE_ROOT (upper case, and a class of the same name) with min-width:980px on it, plus #SITE_HEADERscreenWidthBackground / centeredContent / bg that the lower-case template does not have. Section A never touched any of them, which is why /blog/ was the one page still measuring 980 wide at 390 after the reflow was working everywhere else. Naming them by prefix rather than by hash keeps this working if the same generation turns up on another page. */ @media (max-width: 1023px) { #SITE_ROOT, #SITE_ROOT > div, [id^="SITE_HEADER"], [id^="SITE_FOOTER"], [id^="PAGES_CONTAINER"], [id^="SITE_PAGES"], [class^="style-"][class*="_bg"], [class*="TPASection"], #content-wrapper { min-width: 0 !important; max-width: 100% !important; width: 100% !important; } /* C1c. THE MARGIN THAT GOES NEGATIVE. This generation centres its 980px band with margin-left: calc((100% - 980px) / 2). Above 980 that is a positive inset; at 390 it computes -295px and drags the header, the menu and the whole article column off the left edge - which is exactly what the first phone screenshot of /blog/ showed, with "…sultations" and "…naires" hanging in the left margin. Measured -295px on #SITE_HEADERbg and on #comp-jhpwvpsw. The same trap is recorded on the sister site wenou.pt. */ #SITE_ROOT [id^="comp-"], #SITE_ROOT [id$="bg"], #SITE_ROOT [id$="centeredContent"], #SITE_ROOT [id$="screenWidthBackground"], #SITE_ROOT [id$="inlineContent"], #SITE_ROOT [id$="gridContainer"], #SITE_ROOT [id$="gridWrapper"], #SITE_ROOT [class*="_bg-center"], #SITE_ROOT [class*="TPASection"] { margin-left: 0 !important; margin-right: 0 !important; } /* C1d. THE LOGO SITS IN A DIFFERENT PLACE ON THIS TEMPLATE. On the other 99 pages the logo and the social marks live in #pinnedTopLeft / #pinnedTopRight, which section B stacks; here they are in #pinnedAfterSITE_HEADER and overlay the header, so the wrapped menu's first row was painted straight through them ("Acc[ueil]" behind the logo box, "[Consult]ations" behind its right edge). #SITE_HEADERinlineContent is an ID that exists only on this generation, so reserving the logo's 64px + the social row's 25px here cannot affect the other template. */ #masterPage #SITE_HEADERinlineContent { padding-top: 82px !important; } /* Wix's off-screen text-measuring rig: a 9183px wide ruler parked at left:-2000px. Harmless on a desktop page, but it is the widest box in the document and there is no reason to keep it. */ .font-ruler-container { display: none !important; } } .blog-header__navigation a, [data-hook^="header-navigation"] a, .blog-navigation-container-font { display: inline-block; padding: 4px 2px; min-height: 24px; } [data-hook="post-list-item-metadata"] a, [data-hook="user-name"] a { display: inline-block; min-height: 24px; } /* C2b. TWO CONTROLS ON EVERY BLOG CARD CANNOT WORK AND SHOULD NOT BE OFFERED. "More actions" ([data-hook="more-button"]) opens a Wix menu whose actions are all editor or member operations, and the like button posts a count to a back end that no longer exists. On a static copy both are 19x19 dead squares - twenty of each on the listing, which is also most of qa_legibility's 109 sub-24px controls there. A control that does nothing is worse than no control. The comment link and the author link stay, because both are ordinary links to a page that exists; they only needed a finger-sized box. */ [data-hook="more-button"], [data-hook="like-button"], .post-footer__like-button, [data-hook="like-button-with-count"] { display: none !important; } [data-hook="post-stats"] a, [data-hook="post-stats"] span > a, .blog-link-hover-color a { display: inline-block; padding: 5px 0; min-height: 24px; } /* C2c. The share row at the foot of an article, and any bare external link in an article body: both sit at 19-23px, just under the finger floor. */ [data-hook="share-button"], [class*="share-button"] button, [data-hook="post-page"] button { min-width: 26px; min-height: 26px; } [data-testid="richTextElement"] a[href^="http"], [data-hook="post-description"] a[href^="http"] { display: inline-block; padding: 2px 0; min-height: 24px; } /* ============================================================================================ SECTION D - LEGIBILITY FIXES THE SITE'S OWN CSS GETS WRONG ============================================================================================ D1. INVISIBLE TEXT, measured 1:1 by qa_legibility on every page. The footer credit line is authored white (rgb(255,255,255)) and the footer behind it is white, so the site's own copyright line has been unreadable on every page. The colour moves to the footer's own body-text grey; no other footer text is touched. ============================================================================================ */ #comp-k0e715wg a, #comp-k0e715wg span, #comp-k0e715wg p { color: rgb(56, 56, 56) !important; } /* D1b. The blocks written for the pages the archive left empty sit inside the site's own mesh, so they inherit its type and colour; they still have to be told to take the whole column, because a Wix grid child defaults to the left of a cell sized for a component that is not there. */ #restore-page-content { justify-self: center !important; align-self: start !important; grid-area: auto !important; width: 100% !important; } /* ============================================================================================ SECTION E - THE AUTHORED 404, AND THREE LAST LEGIBILITY BLOCKERS ============================================================================================ E1. /404.html is a clone of /mentions-legales/ with its content swapped for a
. That div carries no type of its own, so it inherited Wix's CSS reset: measured 10px body copy and 11px-tall links on the one page a lost visitor lands on. Wix's own font stack and colours are used, so the page still looks like the site. ============================================================================================ */ .o5-legal { max-width: 780px; margin: 0 auto; padding: 48px 24px 72px; font-family: futura-lt-w01-book, "Futura", Helvetica, Arial, sans-serif; font-size: 17px; line-height: 1.6; color: rgb(56, 56, 56); } .o5-legal h1 { font-size: 34px; line-height: 1.25; margin: 0 0 20px; color: rgb(56, 56, 56); } .o5-legal h2 { font-size: 24px; line-height: 1.3; margin: 28px 0 10px; } .o5-legal p, .o5-legal li { font-size: 17px; line-height: 1.6; margin: 0 0 12px; } .o5-legal ul { margin: 0 0 18px 22px; list-style: disc; } .o5-legal a { color: rgb(86, 110, 58); text-decoration: underline; } .o5-legal li a, .o5-legal p a { display: inline-block; min-height: 24px; padding: 2px 0; } /* E2. TAP TARGETS THE BLOG WIDGET DRAWS AT 19-23px. The author credit on each listing card and any bare external link inside an article body: real links, finger-sized boxes. */ #PAGES_CONTAINER a[href="/blog/"], #PAGES_CONTAINER a[href^="http"] { display: inline-block; min-height: 24px; padding: 3px 0; } /* E2b. INDEPENDENT REVIEW R1 (2026-08-19): the rule above took the .IHVhk author-credit anchor out of flex flow. That one anchor is not a plain link - Wix's own CSS lays it out as `.IHVhk{display:flex;align-items:center;height:19px}` because it holds TWO children side by side, [data-hook="user-name"] and the "Administrateur" [data-hook="badge"] crown. inline-block dropped the badge onto its own line, where it stretched to the anchor's now-auto width and landed across the date/read-time row on all 20 cards at both viewports (measured by _scripts/_rev_cel_badgeoverlap.js: 20/20 intersecting before this rule). Restore flex and grow height instead of replacing it with a min-height the flex box never needed. */ #PAGES_CONTAINER a[href="/blog/"].IHVhk { display: flex; align-items: center; height: 24px; padding: 0; } /* E3. WHITE TYPE OVER A PHOTOGRAPH THAT IS PALE BEHIND THE WORDS, AT BOTH VIEWPORTS. The hero band paints "J'accompagne les femmes / a retrouver leur equilibre et / leur bien-etre par des moyens naturels" in white script over an olive-branch photograph, with the strapline "Alimentation - Nutrition - Aroma & Phytotherapie - Fleurs de Bach" under it. Measured by qa_legibility against the pixels actually painted behind each line: 1.38:1 at 1440 and 1.04:1 at 390. Both are below the 1.6 the gate calls invisible, and a reader calls them invisible too - the words disappear into the leaves. THE PHOTOGRAPH IS NOT REPLACED AND THE TYPE IS NOT RECOLOURED. A scrim inside the band's own background layer darkens what is behind the words, which is what the site's designer would have reached for; the layer is position:absolute and sits under the content, so the scrim cannot cover the text. Two things this rule got wrong before and must not get wrong again: 1. THE SCRIM GOES ON comp-jaw5ezt9, not on the section comp-jaw5ezs8. The section's own background layer is empty here and the photograph lives in the column inside it; aiming at the section changed nothing and the gate went on reporting 1.04:1. Both are listed, because a scrim over an empty layer costs nothing and the day the payload changes it is the one that still matches. 2. THE WHOLE RULE WAS DEAD FOR A DIFFERENT REASON: the comment above it was closed early, so three lines of English sat in the stylesheet as a bogus selector and CSS error recovery swallowed the @media block behind it. Every gate stayed green about the stylesheet itself and the hero went on measuring 1.04:1. That is why this block is now ONE comment with ONE terminator, and why the rule below is verified by re-running qa_legibility rather than by reading it. 3. z-index:1 ON THE SCRIM PUT IT OVER THE TEXT, NOT UNDER IT. #comp-jaw5ezt9 is the stacking context; inside it bgLayers is position:absolute/z-auto and the mesh that holds the words is position:relative/z-auto, so the words paint above the layer purely by DOM order. Giving the pseudo a POSITIVE z-index lifts it out of that order and above everything. Measured proof: with z-index:1 and .52 black the band went visibly dark and qa_legibility reported the SAME 1.38:1 and 1.04:1 as before, because the scrim was dimming the type by exactly as much as the photograph. No z-index at all is the fix - the pseudo then paints with its parent, under the text. 4. ONE SCRIM, NOT TWO. Listing comp-jaw5ezs8 as well stacked a second .52 veil over the same pixels (~.77 combined) and turned an olive grove into a night scene. The photograph is on comp-jaw5ezt9; that is the only element that gets a scrim. 5. THE SCRIM IS A REAL ELEMENT, NOT A PSEUDO. Wix already ships an empty
inside bgLayers, in front of the media and behind the content - the slot this effect belongs in. Painting it instead of inventing an ::after means the veil is a DOM node with a background-color, which any contrast checker can read; a pseudo-element is invisible to all of them. WHAT THE HERO ACTUALLY MEASURES, by photographing the element's own box and counting pixels (_scripts/_o5_cel_pixels.js): glyphs rgb(248,248,248) over ground clusters rgb(72,72,72) and rgb(88,88,88) - 8.61:1 with this scrim, 3.34:1 without it. The type is #FAFAFA, near-white; the plan's assumption that a DARK grey sat there came from reading the computed colour of an ancestor in a five-deep Wix rich-text nest instead of the span that paints the glyphs. NOT scoped to a media query: the desktop render needs it as much as the phone. */ #bgLayers_comp-jaw5ezt9 [data-testid="bgOverlay"] { background-color: rgba(0, 0, 0, .55); } /* E4. Two controls the blog widget still draws a pixel or two under the finger floor. */ #PAGES_CONTAINER a[class*="_3Bkfb"] { display: inline-block; min-height: 24px; padding: 2px 0; } #PAGES_CONTAINER [role="button"] { min-width: 24px; min-height: 24px; } /* D2. A link that reads exactly like the prose around it. The site sets its own body links to the same grey as the paragraph, which is why qa_legibility reports "links look like plain text" on the homepage, the legal pages and the posts. Underlining them costs the design nothing and is what tells a reader the words are clickable. */ [data-testid="richTextElement"] a[href]:not([class]) { text-decoration: underline !important; } /* ============================================================================================ SECTION F - THE HOMEPAGE PRINTED TWO PARAGRAPHS ON TOP OF EACH OTHER AT EVERY DESKTOP WIDTH ============================================================================================ WHAT A READER SAW. Between the portrait and the pink divider, the biography ("Depuis toujours passionnee par les techniques de bien-etre...") and the right-hand column ("Il est temps de prendre soin de vous !") were painted over each other for 339 vertical pixels - two different texts sharing the same rows, both unreadable. Measured with _scripts/_o5_cel_overlap.js at 1024, 1280 and 1440: identical numbers at all three, because this mesh is width-fixed on desktop. WHY, MEASURED, NOT GUESSED. The archived 2022 page does NOT overlap: rendered from _raw/.../index.html with the network blocked, the right column runs 1459 -> 2667 and the biography starts at 2662. Five pixels of slack - the layout was tuned to the pixel. The restored page adds the client's content-wraparea paragraph to the END of that same right column (comp-jaw9ua3l), which grows it by 407px to 1484 -> 3019 while the biography stayed where the archive put it, at 2680. Proof it is the paragraph and not this stylesheet: with restore-extras disabled in the live page the column still measures 1531px, and the component's text length is 1649 chars against the archive's 1036. HOW THE MESH ACTUALLY WORKS HERE, AND WHY ONE LINE IS THE WHOLE FIX. Read the page's own CSS, not the computed value: #Containerc1dmp's grid is `grid-template-rows: repeat(14, min-content) 1fr`. The fifteen pixel tracks a devtools panel shows are the RESOLVED sizes of those min-content rows, and every component is placed in one row with `grid-area` and then pushed to its real position by its own margin-top. So the rows already grow with their content - the biography's own row is sized by the biography's margin-top plus its height. Push the biography down and row 3 grows by the same amount, and every row after it rides down with it. Nothing else has to be touched, and the layout keeps sizing itself. (The first version of this fix pinned all fifteen tracks to the pixel values it had measured. That worked and was wrong: it froze a content-driven grid into constants that any later edit to any component on the homepage would quietly invalidate. Rewriting the computed value of a shorthand back into the stylesheet is a trap worth naming.) THE NUMBER. The right column now ends at 3019 and the biography began at 2680, so 369px restores the archive's "column ends, biography begins" relationship with a 30px breathing gap: margin-top 1364px -> 1733px. SCOPE. #comp-kaw6svbs exists only on the homepage, and the block is inside min-width:1024px because below that Section A stacks the mesh into a single column and there is no overlap to fix. Re-check with _scripts/_o5_cel_overlap.js after ANY edit to the weave paragraph: its height is what this number is derived from. */ @media (min-width: 1024px) { #comp-kaw6svbs { margin-top: 1733px !important; } } /* E3b. AT 390 THE FIRST LINE OF THE HERO STARTS SIX PIXELS ABOVE THE PHOTOGRAPH. Measured: the band (#comp-jaw5ezt9 and its bgLayers/overlay) runs y=779..1001, and the span that paints "J'accompagne les femmes" has its box at y=773 - the ascenders of a 103px script face set on line-height:0.5em overflow their line box upwards and land on the pale-green section above. A reader sees the top of the first line sitting on the wrong ground; a contrast checker sees an element its scrim does not contain and falls back to the page's white, which is where the stubborn 1.04:1 on the phone came from. The band is height:auto once Section A has stacked the mesh, so padding grows it rather than pushing the strapline out of the bottom. 20/10 was read off the 6px overhang plus the same optical margin the desktop band already has. */ @media (max-width: 1023px) { #comp-jaw5ezt9 { padding-top: 20px; padding-bottom: 10px; } } /* E3c. E3's SCRIM WAS CORRECT AND QA_LEGIBILITY STILL FAILED THE HERO AT 1.38:1, BECAUSE A SEPARATE SCRIPT WAS REPAINTING THE TEXT GREY UNDERNEATH THE SCRIM'S FEET. js/restore-legibility.js (the batch-wide JS nudge, written by o45_legibility_pass.py) runs its own contrast check on every page and moves any text it judges too pale. Its groundOf() walks ANCESTORS looking for a CSS background-image or an opaque background-color; it has no code path for Wix's actual mechanism here, where the photograph is painted by #bgMedia_comp-jaw5ezt9, a POSITIONED SIBLING of the text's container, not a background-image on any ancestor. So it finds nothing, falls back to "the ground is white", scores this span's real #FAFAFA at ~1:1 against that assumed white, and "corrects" it - writing a literal `color: rgb(138, 138, 138)` onto the innermost span's inline style. That happens on every load, after E3's scrim is already in the page, which is why reading the stylesheet found nothing wrong: the defect is a runtime DOM mutation, invisible to anything that does not execute the page. MEASURED with _scripts/_o5_cel_hero_diag2.js, which replays qa_legibility's own MEASURE/COMPARE pipeline and prints the element actually probed: the leaf span's computed style at page-load is `font-size: 103px; color: rgb(138, 138, 138);` - not the `#FAFAFA` in this file's markup - and qa_legibility's photographic ratio for it is 2.5:1 at 1440 (worst-sampled-pixel 1.45:1) and 2.19:1 at 390 (worst 1.37:1), both under the 1.6 the gate calls invisible. The parent span one level up still computes `#FAFAFA`: restore-legibility.js's own loop skips any element whose children carry the text (its ownText check), so the mutation lands on the leaf only. THE FIX STAYS OUT OF THE SCRIPT. restore-legibility.js is shared by the whole batch and correct everywhere it can actually see the ground; teaching it Wix's sibling-layer pattern is real work that belongs to that script's own author, not to a per-site override, and touching a shared file for one site's regression risks every other site that depends on it. A stylesheet rule with !important loads after the script runs and after any of its later re-runs (fonts.ready, the 900ms timeout), and !important beats a plain inline style with no !important of its own - so it wins regardless of when the script fires. Scoped to the leaf span only (four levels deep, the one with no explicit colour of its own to protect): the three ancestors above it keep whatever the script does to THEM (none of them carry text, so none of them are ever touched), and no other element on the page is named by this selector. AFTER: the leaf now computes `#FAFAFA` again and the same probe gives, per title line, 8.24:1 / 8.81:1 / 9.37:1 at 1440 (worst-sampled-pixel 4.72 / 5.88 / 7.05) and 6.97:1 / 7.63:1 / 9.35:1 at 390 (worst 4.54 / 4.61 / 6.39) - close to E3's original 8.61:1 now that the leaf is not being repainted out from under it. qa_legibility.js itself reports 0 INVISIBLE TEXT on / at both viewports after this rule. The tap-target and low-contrast lines still in its report are pre-existing and unrelated to this defect - a nav icon and a card subtitle, neither over a photo. */ #comp-k56krpw6 span span span span { color: #FAFAFA !important; } #comp-k56kx743 span span span span { color: #FFFFFF !important; } /* ============================================================================================ SECTION G - THE WIX BLOG HEADER IS FOURTEEN LINKS TO THE PAGE YOU ARE ON, PLUS A DEAD SEARCH ============================================================================================ MEASURED, on /blog/ and on a post page, at 1440 and 390: * the category menu holds fourteen anchors - All Posts, Recette, Recette Gourmande, Recette Saine, Healthy, Fait Maison, Alimentation, Nutrition, Bien Manger, Naturopathie, Sante, Bebe, Hygiene de vie, Fait Maison - and EVERY href is "/blog/". The real targets were /blog/categories/*, hundreds of near-identical Wix listings that the plan's _note records as deliberately never built. So the menu cannot filter anything: every label leads to the page the reader is already looking at. * seven of those fourteen are also unreachable. The menu's own