`.elementor-invisible { visibility: hidden }` holds them there until
elementor-frontend's GlobalHandler takes the class off and swaps in
`animated ta_fadein`, and that handler sits at the end of the footer script
stack. Measured on /contact-us/: 90 scripts, frontend.min.js finished at
2.57s, load at 3.68s. So the fade does not start when the header paints —
it starts two to three seconds later, and until then the header is a blank
white bar. That wait is the complaint, not the fade.
inc/mfr-embed-chrome.php stops the script stack throwing. This starts the
fade at paint instead, by declaring it in CSS, where nothing has to load
first:
- ta_fadein is the theme's own, from veto/skins/default/css/__plugins.css
(`opacity: 0 -> 1`), at the 1s `.animated` gives it and the `ease` that
`.ta_fadein` does. Same fade, same timing — only sooner.
- It is declared identically for both states, the `elementor-invisible` the
header paints in and the `animated` Elementor swaps in later. The
computed animation is the same either way, so the swap does not restart
it: the fade runs once, from paint, and Elementor arriving mid-fade is
invisible rather than a replay.
- No fill mode, matching the theme, which leaves it off `.animated`
deliberately ("to prevent conflicts with masonry, isotope, submenu").
Nothing needs it: these rows are opaque at rest.
Scoped to the header's own top-level rows, so entrance animations elsewhere
on the page are untouched, and the sticky row is left out of it entirely.
That one is not held back by `elementor-invisible` in the first place —
trx_addons collapses it with
`.sc_layouts_row_hide_unfixed:not(.sc_layouts_row_fixed_on) { height: 0 }`
— and it fades in on scroll, by which time the scripts are long loaded.
The phone row carries no animation and was never hidden.
-------------------------------------------------------------- */
.top_panel .elementor > .e-con.elementor-invisible:not(.sc_layouts_row_fixed),
.top_panel .elementor > .e-con.animated:not(.sc_layouts_row_fixed) {
visibility: visible;
-webkit-animation: ta_fadein 1s ease;
animation: ta_fadein 1s ease;
}
/* The sticky row still waits for its scripts, but it has nothing to show
until someone scrolls. Visible here only so that it is not left behind
`visibility: hidden` if they never arrive. */
.top_panel .elementor > .e-con.sc_layouts_row_fixed.elementor-invisible {
visibility: visible;
}
/* The phone header has its own version of the same wait, and it is not this
class. Its row carries no animation, so the bar and the logo paint on time;
what is missing is the hamburger. The nav widget is printed with the hide
inline —
— and the only thing that clears it is NavMenu.js, in trx_addons'
elementor-widgets/.../NavMenu/assets/NavMenu.js:
$widgetContainer.css({ visibility: 'inherit', opacity: 'inherit' });
which runs off a `frontend/element_ready/trx_elm_nav_menu.default` hook it
registers on `elementor/frontend/init`. So on a phone the menu is
unreachable for as long as the footer scripts take, and on a request that
throws before them there is no way into the menu at all.
The same two values NavMenu.js would have set, so it has nothing left to do
when it arrives. Revealing the widget early shows the hamburger and nothing
else: the slide-out it belongs to is `display: none` until it is opened, and
the full-screen overlay beside it is `pointer-events: none` — checked with
elementFromPoint at 375px, which still reaches the page underneath.
`[style*="hidden"]` keeps this to the containers that ship hidden, which
here is the phone one; `!important` because the hide is inline. */
.top_panel .trx-addons-nav-widget-container[style*="hidden"] {
visibility: inherit !important;
opacity: inherit !important;
}