s that start at `opacity:0` (inline style, intentional -- that's the "before" state of the reveal), and a scroll-linked timeline is supposed to animate each one to `opacity:1`. Confirmed live that this timeline is not completing correctly for any of the 7 instances -- calling `ScrollTrigger.refresh()` did not fix it, ruling out a simple stale-layout-position cause, and this held across every instance, in and out of the viewport, so it isn't one broken widget instance. Because the letters' hidden state is a plain inline `opacity:0`, a broken or never-firing timeline leaves that heading's text permanently invisible rather than just un-animated -- on "East Africa's Finest Produce Delivered Globally.", the specific sentence reported missing, only stray fragments of a couple of early letters were ever visible. This is a JavaScript animation bug in the parent theme, so it can't be fixed from this CSS file -- fixing the actual GSAP/ScrollTrigger timeline requires organify/assets/js/theme.js (and/or split-text.js), which is parent-theme code this child theme doesn't include and this session doesn't have a copy of. What CAN be done from here, safely and reversibly, is a CSS safety net: force every split-text letter to its final, fully-visible state unconditionally, so the heading text is always readable regardless of whether the JS timeline ever runs. This trades away the fly-in-per-letter animation (headings now simply appear already-visible, the same effect the existing `prefers-reduced-motion` block below already gives motion-sensitive visitors) in exchange for guaranteeing no heading is ever silently blank. Verified live: patching this exact rule into the page's CSSOM took every one of the 7 instances from a handful of visible letters to 100% (50/50, 22/22, 52/52, 25/25, 31/31, 44/44, 68/68), confirmed both by script and by screenshot of the About Us section showing the full "East Africa's Finest Produce Delivered Globally." line. See the rule at the end of this file. 3.0.7 — fix: the blanket `p, li, span, td { font-family: var(--font-sans) !important; ... }` rule (added in an update this session didn't make -- see note below) was silently breaking every icon rendered through a bare tag: Font Awesome (used by the Sign Up / Login form's username, password, email and eye-toggle icons), Elementor's eicons, this theme's flaticon/caseicon sets, and Material Icons all work by pointing a plain or at their own icon font via ordinary, non-!important CSS (e.g. Font Awesome ships `.fa, .far, .fas { font-family: "Font Awesome 5 Free"; }` with no !important at all, relying on class-selector specificity alone). A same-or-lower-specificity rule carrying !important always beats that regardless of how specific the other selector is, so forcing every to Poppins didn't just make icons render in the wrong font -- Poppins has no glyph at the private-use codepoint Font Awesome's CSS requests (e.g. content:"\f234" for the username icon), so the browser fell back to a visible empty-box glyph. Confirmed live (xcado.africa/my-account/): the icon span's computed font-family was "Poppins" instead of "Font Awesome 5 Free", while the underlying content:"\f234" declaration itself was intact and unaffected -- this was a font-family collision, not a missing icon font file (Font Awesome's CSS and .woff2 files all loaded fine over the network). Fix: narrowed the selector to exclude any span whose class contains "icon" or "fa-", which covers every icon-font convention in use on this site without hardcoding brittle exact class names. No property values changed. NOTE ON SCOPE: this file was already at 3.0.6 on the live site when this fix was made -- a 3.0.6 changelog entry (below) documents a functions.php change (item 14, the asset-version stripper) that this session did not make. That functions.php change is NOT included here: this update was pulled directly from the live site's current style.css and should be installed as a style.css-only replacement, not as a full theme-folder overwrite, so it doesn't revert whatever functions.php currently has. 3.0.6 — fix: functions.php's version-string stripper (item 14, "Remove version strings from asset URLs") was undermining XCADO Speed Kit's Cache module rather than helping it. That stripper predates Speed Kit's Cache module entirely -- it was written back when nothing on this site gave static assets a long-lived Cache-Control header, so removing ?ver= just meant one fewer query string to vary on. Once Speed Kit's Cache module started sending long max-age (and optionally immutable) headers for every CSS/JS asset site-wide, by file extension, this function kept stripping the ?ver= query arg that is the ONLY thing telling a browser (or an immutable cache) that a file changed -- exactly the failure mode Speed Kit's own README documents in its 2.3.0 changelog entry for a theme stylesheet enqueued with no version string, except this function was actively manufacturing that bug for every core script and every other plugin's asset on the site, not just one theme file. See functions.php's own updated comment on item 14 for the full reasoning; this changelog entry exists so the CSS file's own version history doesn't go silent on a change that only touches functions.php. Fix: xcado_strip_ver() now checks whether Speed Kit's Cache module is actually turned on (XSK_Settings::get( 'cache_enabled' )) and stands down entirely when it is, leaving ?ver= alone for Speed Kit's own asset auto-versioning module to manage correctly (it rewrites this theme's ?ver= to the file's real on-disk modified time, rather than removing it). 3.0.5 — fix: Elementor heading/typography overrides (H1-H6, and several component titles built from heading tags) were silently ignored across the whole site, most visibly on the homepage H2/H3s. Nine separate CSS rules pinned font-size/font-weight/color/etc. with `!important` on selectors that either were, or shared specificity with, live heading tags: the bare h1-h6 defaults, the combined heading-default rule, the hero-slider heading rule, the mobile-breakpoint h1-h3 duplicate, WooCommerce's own h2 product title, the team-member h3/h4 name rule, the testimonial-author h5 rule, the blog post-title h3 rule, and the footer widget h3/h4 rule. `!important` beats CSS specificity AND Elementor's inline `style="..."` output regardless of how specific Elementor's own generated selector is, so every one of these structurally could not be overridden from the Elementor editor no matter what was set there -- the value would save, and the live page would keep showing the old size/weight/color anyway. All nine had `!important` removed; none of the actual values changed, and every one still wins its normal cascade position (verified: each was already at least as specific as the bare heading defaults it needs to beat). See the comment left at each fixed rule for the specific reasoning. 3.0.5 — fix: the site's ENTIRE heading typeface (Montserrat, vs. Poppins for body copy) depended on one inline