/* RIBONDI — cabecalho fixo e animacao de entrada, sem JS de terceiro.

   O sticky do Elementor Pro era o jquery.sticky.min.js: media a posicao a cada
   scroll, trocava a classe e cravava position:fixed com um placeholder para
   compensar o buraco que o elemento deixava no fluxo. position:sticky faz o
   mesmo nativo, sem listener de scroll, sem reflow e sem o salto que aparecia
   no instante em que o cabecalho colava. */

.elementor-1616 .elementor-element.elementor-element-4b5784a{
  position: sticky;
  top: 0;
  /* Acima do conteudo, abaixo do lightbox (99999). */
  z-index: 999;
}

/* ---- entrada ao aparecer na tela ----

   Tudo aqui esta atras de `html.rb-js`, classe que o rb-scroll.js poe como
   primeira coisa que faz. A razao e simples: o estado inicial destas regras e
   opacity:0, e conteudo escondido por falha de script e conteudo perdido. Se o
   arquivo nao carregar, se der 404, se um erro de parse impedir a execucao -
   a classe nunca entra, nenhuma destas regras vale, e a pagina aparece inteira
   sem animacao. Numa landing de conversao esse e o modo de falhar certo.

   Isso cobre "o script nao rodou". O outro buraco - rodou, mas o
   IntersectionObserver nunca entregou - e coberto no proprio rb-scroll.js, por
   uma rede de seguranca que revela tudo se nada tiver sido entregue a tempo. */

/* A transicao mora no estado REVELADO, nunca no escondido. Se ela estivesse na
   regra que esconde, a sequencia seria: a pagina pinta visivel (html.rb-js
   ainda nao existe), o script poe a classe, e o conteudo animaria de visivel
   para invisivel em 0,8 s antes de voltar - um flash as avessas, visto pelo
   visitante. Declarada so aqui, esconder e instantaneo e acontece antes da
   primeira pintura; a animacao existe apenas no sentido que interessa. */

html.rb-js [data-rb-fade]{
  opacity: 0;
}
html.rb-js [data-rb-fade].rb-visivel{
  opacity: 1;
  transition: opacity .8s ease;
}

/* Deslocamento NEGATIVO, e nao positivo. Duas razoes, e a segunda e a que
   importa: o motion_fx original tinha direction "negative", e um elemento de
   largura cheia empurrado para a DIREITA aumenta o scrollWidth do documento -
   a pagina inteira ganha rolagem horizontal ate ele ser revelado. Medido: com
   +6vw a pagina sobrava 29 px em 375, 44 px em 768 e 84 px em 1440, sempre
   exatamente 6vw da viewport. Para a esquerda isso nao acontece, porque em
   texto da esquerda para a direita o navegador nao cria area rolavel antes da
   origem. */
html.rb-js [data-rb-desliza]{
  transform: translateX(-6vw);
}
html.rb-js [data-rb-desliza].rb-visivel{
  transform: none;
  transition: transform 1.2s ease;
}

/* Quem pediu menos movimento ve o conteudo parado e inteiro. O rb-scroll.js
   tambem revela tudo de imediato nesse caso; a regra aqui garante que nao
   exista sequer um quadro com o conteudo deslocado. */
@media (prefers-reduced-motion: reduce){
  html.rb-js [data-rb-fade],
  html.rb-js [data-rb-desliza]{
    opacity: 1;
    transform: none;
    transition: none;
  }
}

/* ---- entrada escalonada ----

   O container ganha data-rb-stagger e os filhos entram um apos o outro. O
   atraso de cada um vem da variavel --rb-atraso, escrita pelo rb-scroll.js no
   carregamento; o resto e transicao de CSS, entao a animacao roda no
   compositor sem o JS precisar acordar a cada item.

   As mesmas duas redes do fade valem aqui: tudo esta atras de html.rb-js, e o
   observer revela em ate 3s mesmo se emudecer. */

html.rb-js .rb-stagger-item{
  opacity: 0;
  transform: translateY(18px);
}
html.rb-js [data-rb-stagger].rb-visivel .rb-stagger-item{
  opacity: 1;
  transform: none;
  transition: opacity .55s ease var(--rb-atraso, 0ms),
              transform .55s ease var(--rb-atraso, 0ms);
}

@media (prefers-reduced-motion: reduce){
  html.rb-js .rb-stagger-item,
  html.rb-js [data-rb-stagger].rb-visivel .rb-stagger-item{
    opacity: 1;
    transform: none;
    transition: none;
  }
}