Muito reptiliano!
Adicione um rotacionado em cerca de 60 graus no sentido anti-horário 180 graus no eixo y e você terá os olhos de um ressuscitado
Adicione uma imagem espelhada que foi rotacionada em torno do eixo y para duas imagens (olhos)
Vá Discourse um rex
sim, não consigo tirar isso da cabeça e definitivamente preciso sair mais
Eu configurei um carregador de monociclo aqui! https://unicyclist.com
Legal!
A animação original foi feita por mim apenas com CSS, e pedi ao Gemini para “converter” (por assim dizer) em SVG.
Na tela de carregamento de https://unicyclist.com, a barra de carregamento parece se estender além do plano de fundo.
Obrigado. Um usuário relatou isso. Houve algumas peculiaridades do SVG (?) que fizeram a imagem aparecer… Estranha, quando carregada em uma postagem, mas não na tela de carregamento.
Por exemplo, esta versão mais antiga:
Parece completamente quebrada aqui, mesmo quando clicamos nela (mostra uma barra de carregamento dupla…).
Mas parece boa quando usada como tela de abertura (splash screen).
Eu perguntei estupidamente ao Gemini para “corrigir”, o que criou o SVG que postei e parece OK, mas aparentemente certos usuários têm um problema em relação à barra de progresso. Eu suponho que seja isso que você vê:
Eu não tenho nenhum problema no Chrome/Firefox do Windows ou no Chrome do Android.
Eu não sei se há algum tipo de relação entre o Discourse e esses problemas.
Então, para manter o tópico, além de animações que não são CSS, há algo a ser observado quando queremos usar um SVG animado para uma tela de abertura?
Eu utilizo clipPaths em meus SVGs para evitar que elementos transbordem.
Talvez instruir o Gemini da seguinte forma seja eficaz:
A barra de carregamento neste SVG está se estendendo para além do fundo. Por favor, modifique-a para garantir que ela permaneça dentro dos limites do fundo usando um clipPath.
Muito obrigado pelo recurso, eu também tentei, ainda não estou totalmente satisfeito, mas estou corrigindo 
Abri uma implementação de rascunho relacionada separadamente, mas a ideia mais ampla é simplesmente um possível acompanhamento para este recurso:
A abordagem atual com um único SVG usando var(--primary), var(--secondary) e var(--tertiary) ainda é o caminho mais limpo e simples para a maioria dos sites, especialmente onde o mesmo SVG precisa apenas adaptar suas cores.
O caso de uso que estava explorando é o caso extremo em que uma tela de splash no modo escuro precisa de um ativo genuinamente diferente ou de um tratamento óptico distinto, em vez de apenas recolorir o mesmo SVG. Por exemplo, um cabeçalho escuro para usuários logados pode funcionar melhor com um tratamento de logotipo/fundo transparente específico, enquanto a visualização de splash/login anônimo pode precisar de um fundo carvão ligeiramente diferente ou de um SVG ajustado para melhor contraste.
Portanto, a ideia não é substituir a abordagem atual baseada em variáveis, mas fornecer uma válvula de escape para sites onde a arte da tela de splash no modo escuro realmente precisa diferir da arte da tela de splash no modo claro/padrão.
Agradecemos feedback sobre se isso deve ser implementado como uma configuração separada splash_screen_image_dark ou se a abordagem atual de único SVG + variáveis de cor deve permanecer como a única rota suportada.
Inicialmente, tentei usar SVG animado para a tela de splash. Embora isso funcione no desktop, percebi que, no mobile, animar caminhos complexos ou elementos internos do SVG diretamente resulta em travamentos e até mesmo na paralisação da animação.
Para garantir uma experiência fluida, mudei a lógica da animação para um contêiner HTML padrão (div) envolvendo o SVG. Ao aplicar as animações CSS (transform, scale, opacity) ao wrapper div em vez do SVG, os navegadores mobile podem usar a aceleração por hardware de forma muito mais eficiente, sem travamentos.
Fico me perguntando se a função poderia ser estendida para o formato WebP animado ou se ela está estritamente vinculada a transformações CSS.
Quero dizer, arquivos GIF são pesados, mas o WebP é um padrão comum e sem perdas nos dias de hoje. Consigo reduzir animações de 5 segundos, com 200x200px e 15 FPS, para 50/100 kB. É possível reduzir ainda mais para 2/3 segundos em um loop.
É possível oferecer suporte a variantes de modo escuro/claro?
Sempre que altero o SVG, a interface relata um erro durante o envio, mas o arquivo está lá e funciona normalmente.
Respondendo a mim mesmo, pois estava sendo bobo. Basta referenciar as variáveis CSS do esquema de cores do Discourse no SVG; ele renderiza a animação para o modo claro/escuro conforme necessário.
Vejo que o tamanho foi mencionado. Há planos para suportar uma versão um pouco maior da animação de abertura?
Estou cortando todo o espaço em branco ao redor da animação, então espero que isso crie a impressão de uma imagem maior.
