/* Theme Name: Astra Child Theme URI: https://tinashah.org Description: Child theme for tinashah.org. Exists so CSS survives Astra updates. Author: DTI Template: astra Version: 1.0.0 Text Domain: astra-child */ /* ------------------------------------------------------------------------ W19 · 2026-09-21 · RESTORE THE ANIMATED-HEADLINE LINE HEIGHT MEASURED, not guessed. On the live site the rotating/highlighted text inside an Animated Headline computes to 18px line-height - it inherits from its own heading. On Box A it computes to 80px, because a NEWER Elementor generates an extra rule: .elementor-widget-animated-headline .elementor-headline-dynamic-text { line-height: var( --e-global-typography-primary-line-height ); } and the Primary global typography's line height is 80px, meant for the big hero headline. Live's stylesheet does NOT contain that rule at all (it was generated on 2026-09-08 under Elementor 4.1.1 / Pro 4.0.4; live now runs 4.2.3 / 4.2.1, so live is rendering from stylesheets its own plugin version no longer produces). ⛔ CORRECTED 2026-10-10 (CHANGES-MADE.md §107): the version explanation in the sentence above is WRONG - see the correction in the next block. Live's stylesheets were regenerated by its own Elementor 4.2.3 on 2026-10-06 and still lack this rule; the cause was ONE setting Box A lacked. Effect on the rebuilt page: nine card headings became 3-4x taller, words spread down the card, and the section grew by 237-605px depending on screen width. This restores the inherited value, which is what live shows. ⚠ NARROWED 2026-09-21: .elementor-widget-animated-headline .elementor-headline was REMOVED from this list. Neutralising it flattened the hero headline from its own 72px to an inherited 111.43px and made the hero 39px too tall. Only the DYNAMIC TEXT inside it needs the earlier fix. REVERSAL: delete this block from the child theme's style.css. ------------------------------------------------------------------------ */ /* ⛔ RETIRED 2026-10-10 (queue step 3, agent SW, CHANGES-MADE.md §107) - COMMENTED OUT, NOT DELETED. Box A got Elementor's "Disable Default Fonts" on 2026-10-10 (§106), so Elementor no longer writes the 80px rule this countered. To switch it back on, remove this comment's opening and closing marks. body .elementor-widget-animated-headline .elementor-headline-dynamic-text { line-height: inherit; } END OF RETIRED RULE */ /* ------------------------------------------------------------------------ W19 · 2026-09-21 · NEUTRALISE ELEMENTOR'S WIDGET-LEVEL GLOBAL TYPOGRAPHY MEASURED. Today's Elementor writes widget-wide rules that push the "Primary" global typography (Playfair, weight 900, line-height 80px - meant for the big hero headline) onto every heading, animated headline, icon-box title AND NAVIGATION MENU LINK that does not set its own. ⛔ THE FULL LIST, read off the generated CSS rather than guessed - the first version of this block named only four of them and MISSED THE MENU, which is why the footer came out 1,275px tall on a phone with its links 100px apart: .elementor-widget-heading .elementor-heading-title .elementor-widget-animated-headline .elementor-headline .elementor-widget-animated-headline .elementor-headline-dynamic-text .elementor-widget-icon-box .elementor-icon-box-title .elementor-widget-icon-box .elementor-icon-box-title a .elementor-widget-navigation-menu a.hfe-menu-item .elementor-widget-navigation-menu a.hfe-sub-menu-item MEASURED ON THE FOOTER MENU: Box A 80px line-height / 100px per item. LIVE 18px line-height / 38px per item. Same font, same size, same padding. Live's stylesheet sets NO line-height on those links at all - it inherits - which is exactly what restoring `inherit` reproduces. The approved page's stylesheet contains ZERO of them, and so does the live site's - both were generated by Elementor 4.1.1 and have never been regenerated (live still runs stylesheets dated 2026-09-08 while its plugin is 4.2.3). ⚠ SO THIS IS NOT A BOX A FAULT. It is what the live page will ALSO look like the next time anything regenerates its CSS. Tested and ruled out: it is NOT the 4.2.3 -> 4.2.4 step; 4.2.3 on Box A produces the same rules. The change happened between 4.1.1 and 4.2.x. ⛔⛔ CORRECTED 2026-10-10 (queue step 3, agent SW; CHANGES-MADE.md §106 and §107; evidence: research/W19-AGENT-REPORTS/ppcc-standard-20261010/LR-live-regen-risk.md). THE TWO CLAIMS ABOVE ARE WRONG. They are kept, not deleted, so the record of the mistake survives: (1) ~~"both were generated by Elementor 4.1.1 and have never been regenerated"~~ - 4.1.1 is the version the PPCC page was last SAVED with, not the one that wrote its stylesheet. Live's stylesheets were regenerated by its own Elementor 4.2.3 on 2026-10-06 (18:45-19:52 UTC) and they STILL contain none of these rules. (2) ~~"THIS IS NOT A BOX A FAULT ... what the live page will ALSO look like the next time anything regenerates its CSS ... The change happened between 4.1.1 and 4.2.x"~~ - it WAS a Box A fault: ONE site setting, Elementor's "Disable Default Fonts" (option elementor_disable_typography_schemes = yes), which live has and Box A never got (§41 carried the kit, the experiments and Astra's settings - not Elementor's site options). With it on, Elementor does not write these widget-wide "Primary" rules at all (core/files/css/post.php, build_global_controls_and_values). The 4.2.3 test could not tell version from setting because Box A lacked the setting on every version. Live after its regeneration, measured 2026-10-10: headings 1.0 x / 1.25 x their size, none at 80px. Box A got the setting on 2026-10-10 (§106) and the rules below were RETIRED the same day (§107) - commented out, not deleted. Elements that set their own typography are scoped per element and outrank these, so they are untouched. Only the ones that were meant to inherit are restored. REVERSAL: delete this block from the child theme's style.css. ------------------------------------------------------------------------ */ /* ⛔ THE `body` PREFIX IS LOAD-BEARING, NOT DECORATION. Elementor's rules have the SAME specificity as these and are enqueued AFTER the child theme, so a plain copy of the selector LOSES the tie and changes nothing. The first attempt at the menu fix did exactly that: the CSS was on the box, the file was loaded, and the footer was still 1,275px tall. `body` adds one element to the selector and wins by specificity rather than by order. */ /* ⛔ RETIRED 2026-10-10 (CHANGES-MADE.md §107) - COMMENTED OUT, NOT DELETED. With "Disable Default Fonts" on (§106) the rules it countered are no longer written, and this `inherit` was itself the cause of the loose headings measured on every page (1.857 x the font size instead of live's 1.0 / 1.25). To switch it back on, remove this comment's opening and closing marks. body .elementor-widget-heading .elementor-heading-title, body .elementor-widget-icon-box .elementor-icon-box-title, body .elementor-widget-icon-box .elementor-icon-box-title a { font-weight: inherit; line-height: inherit; font-family: inherit; } END OF RETIRED RULE */ /* W19 · 2026-10-10 (CHANGES-MADE.md §108) - THE ONE HEADING THE RETIREMENT ABOVE LEFT WRONG. PPCC's "Build Confidence" was an h2 on the approved page (Astra gives h1-h6 `line-height: 1em`) and was promoted to the page's

on 2026-09-23 (§56). Without the `inherit` rule it took Astra's h1 setting, a FIXED 40px (`.elementor-widget-heading h1.elementor-heading-title{line-height:40px}`): a 90px heading in a 40px line at 1920, crowding the header and the line below. This gives an Elementor h1 heading that sets NO line height of its own the same 1 x its size as every other heading level - the approved look. `body` makes it outrank Astra's rule; Elementor's own per-element setting still outranks this one (Executive's h1 sets its own line height at every width and is unchanged). */ body .elementor-widget-heading h1.elementor-heading-title { line-height: 1em; } /* ⛔ THE MENU NEEDS A VALUE, NOT `inherit`. MEASURED on LIVE: the footer link computes line-height 18px against font-size 18px - exactly 1. Its parent list item computes 25.4px on BOTH sites, so the link is NOT inheriting on live either; the menu plugin's own styling gives it 1. `inherit` here would produce 25.4px and leave the footer too tall - which is why this one is set explicitly and the others are not. */ /* ⛔ RETIRED 2026-10-10 (CHANGES-MADE.md §107) - COMMENTED OUT, NOT DELETED. With "Disable Default Fonts" on (§106) Elementor no longer gives menu links the 80px Primary line height; the menu plugin's own styling gives them 1, as on live. To switch it back on, remove this comment's marks. body .elementor-widget-navigation-menu a.hfe-menu-item, body .elementor-widget-navigation-menu a.hfe-sub-menu-item { font-weight: inherit; font-family: inherit; line-height: 1; } END OF RETIRED RULE */ /* ======================================================================== W19 · 2026-09-23 · FAULT 1 — HALF A MEGABYTE OF ICON FONT FOR EIGHT SMALL SHAPES MEASURED on the rebuilt PPCC page, twice (2026-09-21 audit, re-measured 2026-09-23): elementskit.woff 464,672 b drawing 3 glyphs fa-solid-900.woff2 156,496 b drawing 4 glyphs eicons.woff2 108,000 b drawing 1 glyph ------------------------------------------------------ 729,168 b for EIGHT small shapes The 464 KB file is the single heaviest thing a visitor downloads on this page — 3.5x heavier than the video — and it is there to draw an 11x20px submenu chevron seventeen times. ⛔⛔ WHAT MUST NOT BE DONE ABOUT IT, AND IT IS WRITTEN DOWN BECAUSE IT LOOKS OBVIOUS: DO NOT UNINSTALL OR DEACTIVATE ElementsKit. research/W19-MIGRATE-CLEAN.md records that W1 established removing it BREAKS THE SITE NAVIGATION ON EVERY PAGE — it supplies an icon font used INSIDE core widgets, which a widget-type census structurally cannot see. Both things are true at once: the plugin is load-bearing, AND 600 KB is being spent on one arrow. ★ WHAT THIS DOES: research/W19-REBUILD/subset_icon_fonts.py cuts each REAL font file down to the glyphs actually drawn, renames the family, and writes the result into this theme: elementskit.woff 464,672 b -> fonts/elementskit-subset.woff2 592 b fa-solid-900.woff2 156,496 b -> fonts/fa6-subset.woff2 892 b eicons.woff2 108,000 b -> fonts/eicons-subset.woff2 2,348 b ------------------------------------------------------------------------ 729,168 b -> 3,832 b (-725,336) ★★ AND THE REASON THIS CANNOT BREAK A PAGE NOBODY HAS BUILT YET — read it before "tidying": ONLY THE CLASSES NAMED BELOW ARE POINTED AT THE SUBSET. Any other ElementsKit / Font Awesome / eicon glyph still asks for its ORIGINAL family, so the original font still downloads on the page that needs it and that icon still draws correctly. The worst case of a glyph this list forgot is that ONE PAGE KEEPS TODAY'S WEIGHT. The worst case is NOT an empty square. ⚠ WHEN A NEW PAGE IS BUILT: run the icon census (eleven_probe.py reports it), and if it names a glyph that is not below, add it to subset_icon_fonts.py and re-run. Missing one costs bytes, never correctness. ⚠ `font-weight: 100 1000` is load-bearing, not tidiness. Font Awesome's own CSS asks for weight 900. A single face declared at the default weight 400 would be SYNTHETICALLY EMBOLDENED by the browser and the icon would come out fatter than it is today. A weight RANGE matches exactly and switches synthesis off. REVERSAL: delete this block, the w19_subset_fonts() array in functions.php, and the three files in fonts/. The original fonts are untouched inside their plugins and come straight back. ======================================================================== */ /* ⛔ W19 · 2026-09-25 · SPEED STEP 1, F11 - THE THREE @font-face RULES THAT STOOD HERE NOW LIVE IN functions.php (w19_subset_fonts / w19_subset_fontface_css) AND ARE PRINTED AS INLINE CSS RIGHT AFTER THIS STYLESHEET, with the same families, weights and font-display. WHY: a relative `url('fonts/x.woff2')` in this file carries NO version - this stylesheet's own `?ver=` does not travel to it - so a re-cut subset reached a returning visitor only after the 30-day browser cache ran out. From PHP, each font URL carries a hash of its own content. ⛔ Do not add an @font-face for a child-theme font back into this file. Add a line to the array. */ /* ⛔⛔ THE SELECTORS BELOW LOOK ABSURD AND THE REPETITION IS THE WHOLE POINT. MEASURED, TWICE. The first version was `body .icon-down-arrow1::before { font-family:'ek-subset' !important }` and it CHANGED NOTHING. `!important` was not enough: ElementsKit ships .ekit-wid-con .icon::before { font-family: elementskit !important; } which is TWO CLASSES and also !important. Against it, `body .icon-down-arrow1::before` is one element + one class, and CLASSES OUTRANK ELEMENTS - so the plugin won and the 464 KB font kept downloading while every automated check said the rule was present and parsed. ★ Chrome's own devtools protocol settled it: CSS.getMatchedStylesForNode listed BOTH rules as `important=true` and the plugin's on top. ⚠ A rule being IN the stylesheet, PARSED, and !important still does not mean it WINS. Ask the browser which one applies. Repeating the class (`.x.x`) raises specificity to two classes without depending on the element carrying any other class, and `html body` puts it ahead on top of that. */ html body .icon-down-arrow1.icon-down-arrow1::before, html body .icon-right-arrow.icon-right-arrow::before, html body .icon-menu-button-of-three-horizontal-lines.icon-menu-button-of-three-horizontal-lines::before, html body .icon-arrow-right.icon-arrow-right::before, html body .icon-management.icon-management::before, html body .icon-business.icon-business::before, html body .icon-Target.icon-Target::before, html body .icon-brain.icon-brain::before, html body .icon-tick.icon-tick::before, html body .icon-graph-2.icon-graph-2::before, html body .icon-laptop.icon-laptop::before, html body .icon-consult.icon-consult::before { font-family: 'ek-subset' !important; } /* ⛔ W19 · 2026-10-10 (CHANGES-MADE.md §109) - `.icon-arrow-right` ADDED above. The glyph list was cut from PPCC's icons only; the census of every published page, pop-up and template on Box A found Home's icon list drawing it three times, so Home downloaded the whole 464,672-byte elementskit.woff for three arrows. elementskit-subset.woff2 re-cut with it: 592 -> 636 bytes. */ /* ⛔ W19 · 2026-10-13 (agent SITE, CHANGES-MADE.md - the SITE icon-font section) - EIGHT MORE ElementsKit glyphs ADDED above (management, business, Target, brain, tick, graph-2, laptop, consult): the census of every published page after the remaining-pages wave found About (365) and Corporate Training (459) drawing them as font glyphs, so both pages downloaded the whole 465,370-byte elementskit.woff. Codepoints read from the plugin's own ekiticons.css. elementskit-subset.woff2 re-cut with them: 636 -> 3,712 bytes. ElementsKit names its family on ::before only (.elementor-widget .icon::before), so no element rule is needed - the same as the four above. */ html body .fa-rocket.fa-rocket::before, html body .fa-plus.fa-plus::before, html body .fa-minus.fa-minus::before, html body .fa-arrow-right.fa-arrow-right::before { font-family: 'fa6-subset' !important; } html body .eicon-close.eicon-close::before, html body .eicon-play.eicon-play::before, html body .eicon-chevron-left.eicon-chevron-left::before, html body .eicon-chevron-right.eicon-chevron-right::before, html body .eicon-caret-down.eicon-caret-down::before { font-family: 'eicons-subset' !important; } /* ⛔ AND THE ELEMENT ITSELF, NOT ONLY ITS ::before - MEASURED, BECAUSE THE FIRST ROUND MISSED IT. After the ::before overrides landed, `elementskit.woff` stopped downloading (464,972 bytes saved, confirmed on the network) but `fa-solid-900.woff2` and `eicons.woff2` kept coming down. The reason: Font Awesome's `.fas` and Elementor's `.eicon-close` declare the family on the / ELEMENT as well, and Chrome still fetches a face that any laid-out element claims. These elements carry NO TEXT - the glyph is drawn by the ::before, which is already on the subset - so pointing the element at the subset too cannot change a single pixel. */ html body i.fa-rocket, html body i.fa-plus, html body i.fa-minus, html body i.fa-arrow-right { font-family: 'fa6-subset' !important; } /* ⛔ W19 · 2026-10-10 (CHANGES-MADE.md §109) - A FOURTH SUBSET, found by the all-pages census: every Thank You page carries the Header Footer Elementor scroll-to-top button, an drawn from ELEMENTOR'S OWN Font Awesome 5 - the whole 78,196-byte fa-solid-900.woff2 for one chevron. fonts/fa5-subset.woff2 (572 bytes) holds exactly that FA5 glyph, so nothing changes shape. The element rule is there for the same reason as the Font Awesome 6 one above. */ /* ⛔ W19 · 2026-10-13 (agent SITE) - `fa-quote-left` ADDED: Testimonials (386) draws 16 quote marks as - Elementor icon widgets holding the old Font Awesome 4 value, drawn from this same FA5 solid font (`.fa,.fas { font-family: 'Font Awesome 5 Free' }` on the ELEMENT, hence the element rule) - so the whole 78 KB fa-solid-900.woff2 downloaded there for one shape. fa5-subset.woff2 re-cut: 572 -> 644 bytes. ⚠ Elementor's inline-SVG icons (class e-fas-quote-left) are not elements and are not touched. */ html body .fa-chevron-up.fa-chevron-up::before, html body i.fa-chevron-up, html body .fa-quote-left.fa-quote-left::before, html body i.fa-quote-left { font-family: 'fa5-subset' !important; } html body .eicon-close.eicon-close, html body .eicon-close.eicon-close use, html body .eicon-play.eicon-play, html body .eicon-play.eicon-play use, html body .eicon-chevron-left.eicon-chevron-left, html body .eicon-chevron-right.eicon-chevron-right, html body .eicon-caret-down.eicon-caret-down { font-family: 'eicons-subset' !important; } /* ======================================================================== W19 · 2026-09-23 · FAULT 10 — "EIGHTEEN COLOUR-CONTRAST FAILURES" ⛔⛔ MOST OF THEM WERE NOT REAL, AND THIS IS WRITTEN DOWN RATHER THAN QUIETLY DROPPED. The audit of 2026-09-21 listed eighteen. On 2026-09-23 each named row was re-measured against the PIXELS THE BROWSER ACTUALLY PAINTS instead of against computed CSS, and the majority dissolved. Three separate instrument faults, all of the same family: 1 · THE GREY SOCIAL ICONS — "Elementor's default grey #69727D on brand-coloured circles, reading as blank discs", five of them, one at a ratio of exactly 1.00. ⛔ NOT REAL. The first child of each social button is `Facebook` — invisible text for screen readers. THAT is what carries the grey. The glyph a person sees is a sibling `` whose computed `fill` is `rgb(255,255,255)` — white, and always was. ★ PROVEN TWICE, INDEPENDENTLY: (a) `fill` reads white before any change was made, and (b) a screenshot of the footer taken with the PRE-SESSION stylesheet injected back in came out BYTE-IDENTICAL to the current one — md5 3e8fb5a6ab31d690, 326,545 bytes, both. A change that alters nothing on screen cannot have fixed a visible fault. 2 · THE FOOTER'S CONTACT ICONS — "salmon rgb(252,121,120) on blue, 1.46". ⛔ NOT REAL, same cause. They are `` painting with `fill: rgb(255,255,255)`. `color` is inherited and never used. 3 · "ALL FOOTER TEXT — white on rgb(41,130,244), 3.75, needs 4.5". ⛔ NOT REAL. rgb(41,130,244) is the footer section's `background-color`, but Elementor paints `> .elementor-background-overlay { background-color:#070101; opacity:0.7 }` on top of it. The colour a visitor actually sees, sampled from the screenshot, is rgb(17,40,74): 0.3 × (41,130,244) + 0.7 × (7,1,1) = (17.2, 39.7, 73.9) ✓ to the pixel White on rgb(17,40,74) is 14.7:1. It is one of the best-contrasted things on the page. ⚠ An earlier version of this file changed that blue to #2170DB to "fix" the 3.75. It was removed: it fixed nothing, it was a visible design change nobody asked for, and it did not even apply — Elementor's own selector `.elementor-element.elementor-element-f401a42` carries three classes and outranked it. ★ THE LESSON, because it will happen again on the other seventeen pages: A CONTRAST CHECKER THAT READS CSS IS READING WHAT THE PAGE DECLARES, NOT WHAT THE PAGE SHOWS. It cannot see that a colour belongs to invisible text, that an SVG paints with `fill` and ignores `color`, or that a 70%-black overlay sits between the text and the background it was compared against. `research/W19-REBUILD/eleven_probe.py` has been corrected for all three. ✅ WHAT WAS REAL, AND IS FIXED: · the hidden H1 at ratio 1.00 — dealt with by making it stop being an H1 (fault 2), not by recolouring invisible text; · "Skip to content" at 2.58 — salmon rgb(252,121,120) on white. This one is genuine: it is the FIRST thing a keyboard user meets, it is invisible until focused, and when it appears it is unreadable. Fixed below. ======================================================================== */ body .skip-link, body .skip-link:focus, body a.skip-link.screen-reader-text:focus, body a.screen-reader-text:focus { background-color: var(--e-global-color-tffffff) !important; color: var(--e-global-color-t10233f) !important; outline: 3px solid var(--e-global-color-t2170db); outline-offset: 2px; } /* ======================================================================== W19 · 2026-09-23 · FAULT 9 / FAULT 8 — CONTROLS TOO SMALL TO TAP MEASURED 2026-09-23 (with the instrument corrected first — its first version counted eight 1x1 `.elementor-screen-only` spans, which are screen-reader text nobody taps, and chevrons inside menu links, where the finger hits the link): 10 real failures — carousel pagination dots at 11x11 and 7x7. the popup's close button at 15x15 (27x27 on a phone). WCAG 2.2 wants 24px; 44px is comfortable on a phone. The before/after carousel is this page's strongest proof — if people cannot drive it on a phone they see slide one and leave. ★ THE DOT STAYS THE SIZE IT IS. What grows is the INVISIBLE AREA AROUND IT, via ::after. A bigger dot would be a design change; a bigger target is an accessibility fix. ⚠ AND THE HALF THAT IS EASY TO MISS: WCAG's own exception says an undersized target passes if a 24px circle around it does not touch the next one. Enlarging the hit areas WITHOUT spacing the dots would simply make neighbouring targets overlap and the wrong slide would open. So the spacing goes up too — and that IS a small visible change: the dots sit further apart. ======================================================================== */ /* ⚠ MEASURED, AND THE FIRST ATTEMPT ONLY DID HALF THE JOB. `body .swiper-pagination-bullet { margin: 0 7px }` left the dots 13px and 23px apart centre to centre, so the 24px tap areas OVERLAPPED and a thumb could open the wrong slide. WCAG 2.5.8's own spacing exception is the standard here: a 24px circle round one target must not reach the next one. 9px each side puts the 7px dots 25px apart and the 11px dots 29px apart. ⚠ It is a visible change: the dots sit further apart than they did. */ html body .swiper-pagination-bullet, html body .elementor-swiper .swiper-pagination-bullet { position: relative; margin-left: 9px !important; margin-right: 9px !important; } html body .swiper-pagination-bullet::after { content: ""; position: absolute; left: 50%; top: 50%; width: 26px; height: 26px; transform: translate(-50%, -50%); border-radius: 50%; /* invisible, but it is what the finger lands on */ background: transparent; } /* The only lead form on the page is inside a popup, and the popup was closed by a 15px button. */ body .dialog-widget .dialog-close-button, body .elementor-popup-modal .dialog-close-button { min-width: 32px; min-height: 32px; display: -webkit-box; display: -ms-flexbox; display: flex; -webkit-box-align: center; -ms-flex-align: center; align-items: center; -webkit-box-pack: center; -ms-flex-pack: center; justify-content: center; cursor: pointer; } body .dialog-widget .dialog-close-button:focus-visible, body .elementor-popup-modal .dialog-close-button:focus-visible { outline: 3px solid var(--e-global-color-t2170db); outline-offset: 2px; } /* ======================================================================== W19 · 2026-09-23 · FAULT 7 — the FAQ is now keyboard-operable (assets/w19-a11y.js). Focus has to be VISIBLE or "you can reach it with Tab" is a claim nobody can act on. ======================================================================== */ body .uc_ac_box > .uc-heading[role="button"] { cursor: pointer; } body .uc_ac_box > .uc-heading[role="button"]:focus-visible { outline: 3px solid var(--e-global-color-t2170db); outline-offset: 2px; } /* ======================================================================== W19 · 2026-09-23 · FAULT 4 + 5 — CSS BACKGROUNDS BECOME REAL PICTURES. inc/w19-photos.php puts a real where an inline background-image was. ⛔ THE BACKGROUND IS NOT JUST HIDDEN, IT IS GONE FROM THE HTML. If it were only covered, the browser would still download both files and this would COST weight instead of saving it. ======================================================================== */ .elementor-carousel-image.w19-imgified { position: relative; background-image: none !important; overflow: hidden; } .elementor-carousel-image.w19-imgified > img.w19-cimg { position: absolute; top: 0; left: 0; width: 100%; height: 100%; display: block; border-radius: inherit; } /* the play button and anything else in the slide stays ABOVE the picture */ .elementor-carousel-image.w19-imgified > *:not(img.w19-cimg) { position: relative; z-index: 1; } /* ------------------------------------------------------------------------ The nine card photographs. The container used to BE the picture; now it holds one. ⛔⛔ THE CONTAINER HAS NO CLASS OF MINE ON IT, AND THAT IS NOT AN OVERSIGHT. `_css_classes` was written into the container's settings and Elementor 4.2.4 DID NOT PRINT IT - the container renders as class="elementor-element elementor-element-bddba2b e-con-full e-flex e-con e-child" and nothing else. Measured in the served HTML: `w19-cardbox` appears 0 times. Without it the absolute positioning never applied, the picture fell into the flow, and the cards on a 1440 desktop DOUBLED IN HEIGHT with the photograph shrunk to a thumbnail in the corner. `look.py` reported 0 faults for that page - it measures crop and weight, not "does this card still look right". ★ ONLY THE SCREENSHOT CAUGHT IT. Again. So the container is reached through `:has()`, from the one class Elementor DOES print - the one on the image widget's own wrapper. ⚠ `:has()` needs Chrome 105+/Safari 15.4+/Firefox 121+ (all 2022-2023). The fallback below keeps the picture sane if a browser ignores the rule. ------------------------------------------------------------------------ */ .e-con:has( > .w19-card-photo ), .elementor-element:has( > .w19-card-photo ) { position: relative; overflow: hidden; } .elementor-widget-image.w19-card-photo { position: absolute; top: 0; left: 0; right: 0; bottom: 0; width: 100%; height: 100%; margin: 0; padding: 0; z-index: 0; } .w19-card-photo .elementor-widget-container, .w19-card-photo figure, .w19-card-photo picture.w19-cardpic { display: block; width: 100%; height: 100%; margin: 0; } .w19-card-photo img { width: 100%; height: 100%; display: block; object-fit: cover; /* The desktop slot is near-square and the picture is square, so centre is right. On a phone a DIFFERENT, already letterbox-shaped file is served by , so there is nothing left to crop there. */ object-position: 50% 50%; } /* Everything else in the card - the spacer that gives it height - stays above. */ .e-con:has( > .w19-card-photo ) > .elementor-element:not( .w19-card-photo ) { position: relative; z-index: 1; } /* ======================================================================== W19 · 2026-09-23 (second pass) · THE LAST 108,300 BYTES OF ICON FONT. ⛔⛔ `eicons.woff2` KEPT DOWNLOADING AFTER FIVE GLYPHS WERE SUBSET, and the previous session recorded the cause as UNRESOLVED. It is resolved now, and the reason it hid is worth more than the bytes: THE ELEMENT THAT PULLS IT HAS NO `eicon-` CLASS ON IT. Elementor Pro's own custom-frontend.min.css says, on a SELECTOR: .elementor-field-group .elementor-select-wrapper::before { content:"\e92a"; font-family: eicons } .elementor-message::before { content:"\e90e"; font-family: eicons } Every override written so far was class-based (`html body .eicon-caret-down.eicon-caret-down::before { … }`), so it could never reach a rule that names the family directly on a different selector. ★ An override keyed on a CLASS cannot see a rule keyed on a SELECTOR. ⛔ AND WHY THREE SESSIONS MEASURED ZERO AND BELIEVED IT: the one