Seu navegador em breve será incompatível com esta comunidade. Para continuar participando aqui, atualize seu navegador ou saiba mais.
Aliás, este banner " saiba mais " link para este tópico não segue a configuração de Abrir todos os links externos em uma nova guia. Ele carrega na guia atual.
O Wine está bem desenvolvido neste ponto, acredito. Começou principalmente em círculos de jogos, mas teve ajuda de desenvolvimento ($$$) no passado recente
Aviso: sem experiência recente
Para que você vai usar a sintaxe de cores relativa?
Folha de estilo mais compacta?
Você poderia talvez cancelar o uso planejado da sintaxe de cores relativa?
Embora esses sejam alguns recursos que identificamos que queremos usar hoje, desativar esses navegadores cujos mantenedores depreciaram nos permite explorar outras coisas. Por exemplo, Import maps | Can I use... Support tables for HTML5, CSS3, etc é algo que será habilitado por essa mesma mudança e que pode acelerar o Discourse para 99% dos usuários. Offscreen canvas já é usado para compressão de imagem no Discourse há muitos anos e também fica disponível em todos os navegadores de destino com esta atualização.
Ainda o mesmo aqui.
Alguém encontrou uma solução alternativa?
Já experimentei 5 ou 6 extensões de falsificação de user agent. Existem muitas, mas as que testei não eram realmente boas de usar. E a maioria delas não era por site.
Ainda preciso no Android 9:
E poder usar o Discourse (ler/escrever).
Acho que terei que testar todas as extensões de user agent, uma por uma… 
Não estamos analisando o user agent, então falsificá-lo não ajudará.
Estamos usando a detecção de recursos para os três recursos mencionados no OP. Se o navegador não os suportar, o banner de aviso será acionado.
Você já tentou relatar o problema aos desenvolvedores do Kiwi? Parece que a versão deles do Chromium deve suportar a sintaxe de cores relativas, então talvez eles a tenham desativado? Talvez acidentalmente?
Ah, isso é bom.
Será assim na versão de 1º de maio também, ou vocês testarão versões?
O Kiwi não é mais mantido.
Sim, adicionaremos estes à lista existente de recursos que o Discourse verifica 
Você diz que essa mudança acelerará as coisas para 99% dos usuários — justa observação. Mas, por outro lado, você está completamente cortando o acesso para os restantes 1%. Então, quantas pessoas reais estão nesse 1%?
Se o número parecer desconfortável para postar aqui porque não é tão pequeno quanto soa em termos percentuais, talvez valha a pena reconsiderar se eles realmente são insignificantes o suficiente para cortar o acesso.
A maioria das minhas máquinas é moderna, mas recebi esta mensagem em uma que não pode ser atualizada.
Imagino que a linha de base estará sempre mudando, mas eu gostaria de solicitar, se possível, um fallback limpo para que navegadores não suportados tenham a capacidade mínima de: fazer login, visualizar e criar posts/tópicos, mesmo que não possam usar todos os recursos avançados.
POR QUÊ?? Isso é discriminação contra pessoas que vivem em países do 3º mundo!
Não quebre a internet, ela existe há 35 anos!
Para mim, este problema parece muito maior do que o Discourse. Este é um problema dos fornecedores de hardware, fornecedores de sistemas operacionais e fornecedores de navegadores da web que cortam o suporte, atualizações e upgrades cedo demais. O custo das atualizações precisa ser de um valor monetário mínimo para que todos possam tê-las.
O Discourse e outros desenvolvedores de software (incluindo aplicativos) estão realmente à mercê do ecossistema em que vivemos.
O Discourse será o primeiro site que usarei para bloquear meu navegador (Android), no entanto.
Com base no feedback da comunidade e nas informações adicionais que coletamos sobre o efeito no Windows 7/8, decidimos adiar essa mudança para depois do próximo lançamento estável do Discourse em julho de 2025. Isso dará às comunidades e usuários mais 3 meses para se prepararem para a mudança.
Isso também dará aos administradores auto-hospedados a opção de mudar suas comunidades para o branch estável, que continuará funcionando em navegadores mais antigos até o lançamento seguinte no início de 2026.
Para nos permitir continuar avançando com novas tecnologias, nosso novo “Horizon Theme” já está utilizando alguns desses recursos modernos de navegador. Para sites que executam o Horizon, os usuários de navegadores antigos já estão vendo a visualização basic-html.
Atualizarei o OP aqui de acordo 
Excelente. Posso encorajar você (também conhecido como Discourse) a ver esses tipos de adoções como uma questão de acessibilidade e inclusão?
Obrigado.
Durante esse tempo, por favor, considere também continuar a fornecer uma versão do Discourse que continuará a ser utilizável em equipamentos antigos e que, embora possa não incluir todos os recursos, inclua a capacidade de postar e iniciar tópicos, bem como de ler.
Obrigado! Isso ajuda com certeza e reduz o pânico.
Mas:
ainda são pontos muito válidos.
Acho que o que muitos de nós estamos argumentando não é que recurso X deva ou não ser suportado por versão Y por tempo Z, mas que o Discourse deve oferecer degradação graciosa, talvez algo como um modo simples de HTML + POST HTTP como os primeiros fóruns ofereciam. Idealmente, isso seria priorizado sobre novos recursos, especialmente sobre mudanças cosméticas, mas eu argumentaria também sobre otimizações de desempenho.
Os usuários do Discourse não deveriam ter que escolher entre comunidade e novos recursos — e essa parte parece ser uma questão cultural. Parece que os desenvolvedores querem “avançar um pouco rápido, não muito rápido, quebrar algumas coisas, mas não muitas”. Essa pode ser uma posição perfeitamente razoável para uma empresa de software tomar, mas NÃO é necessariamente a mesma posição que as comunidades Discourse gostariam. Algumas comunidades gostariam de avançar mais rápido, enquanto outras prefeririam um movimento muito mais lento ou nenhum movimento.
Para mim, o Discourse hoje já é “bom o suficiente” e se houvesse uma opção para clientes hospedados escolherem um branch de suporte de longo prazo sem novos recursos adicionados nos próximos 10 anos, apenas correções de segurança críticas, eu escolheria totalmente — mesmo que a nova versão fosse 10x mais rápida. Eu preferiria muito, MUITO mais um fórum lento que todos possam usar do que um que gradualmente perde usuários apenas para fornecer uma experiência mais rápida e brilhante para os sobreviventes.
Mas nem todos concordariam com isso. Esse ritmo seria muito lento tanto para os desenvolvedores (presumo) quanto para outras comunidades Discourse… depende totalmente de sua demografia de usuários e dispositivos. Um fórum para idosos nunca perseguirá os mesmos recursos que um fórum de IA, por exemplo.
Mas eles não deveriam PRECISAR lutar um contra o outro assim. Esses não são objetivos mutuamente exclusivos. A degradação graciosa tem sido um princípio básico desde os primórdios da web, e o Discourse já é suficientemente headless (com várias APIs, e também comprovado por implementações de terceiros como Discorkie) que deveria ser possível fornecer um modo de “HTML simples” com leitura + postagem básica. Não precisa de temas chiques, não precisa de paginação infinita, nem mesmo necessariamente de edição e notificações e todos os outros recursos “nice-to-have”. Só precisa ser uma experiência básica utilizável que permita às pessoas continuarem usando o fórum para sua função pretendida, leitura e postagem. Pode não oferecer nada mais do que uma UX no estilo Usenet dos anos 90 e ainda seria melhor do que cortar as pessoas completamente. Com um pouco mais de tempo de desenvolvimento, poderia oferecer uma interface de usuário da era PHP estilo vBulletin e isso ainda seria uma grande melhoria em relação à situação “Desculpe, você não pode mais postar” (que ainda veremos em julho).
Na minha opinião, o Discourse é (ou deveria ser) acima de tudo sobre comunidade. Não é uma demonstração de tecnologia (mais), e embora minha preferência pessoal seja que seja pensado como um “software estável e chato” que raramente muda… entendo que não é o que os desenvolvedores e outras comunidades Discourse podem querer. Tudo bem. Não é um mainframe de banco 
Mas, inversamente, também não precisa perseguir melhorias constantes de navegador (que nunca acabarão). Entre os dois extremos, um modo HTML básico permitiria aos usuários continuar postando muito depois que seus navegadores se tornarem obsoletos, enquanto também permite um desenvolvimento de recursos mais rápido no branch principal, porque os usuários terão algo para recorrer.
Como bônus, pode realmente permitir que você direcione o tipo de desenvolvimento baseado em janela de tempo que deseja fazer (por exemplo, “suportaremos navegadores de até 2 anos de idade, ou na marca de 95% do caniuse”) em vez de selecionar recursos individuais em todas as permutações possíveis de hardware + SO + navegador + fork. Qualquer coisa mais antiga que esse alvo ainda poderá postar através do modo HTML básico, mas não poderá usar os temas mais recentes, _____, ______, _____ etc. (o que é totalmente bom porque eles provavelmente não se importam com tudo isso de qualquer maneira). Isso o livra de ter que verificar cada recurso em cada navegador… se um usuário não puder usar algum recurso sofisticado, bem, realmente caberá a ele atualizar para um novo navegador. Mas pelo menos eles não seriam expulsos de suas comunidades.
Não tenho certeza sobre isso (pois não conheço a origem do script), mas vi por anos locais que, fazendo um teste simples ao carregar no navegador, usam automaticamente uma versão ou outra, dependendo se o navegador pode suportá-la ou não, e geralmente em modo transparente (os usuários nem veem esse processo).
Tenho certeza de que, tendo o Discourse já uma versão funcional (a que você está usando agora) que não exclui navegadores antigos, é fácil o suficiente colocar um teste simples no início do carregamento do script e condicionar a parte que é carregada para passar ou falhar no teste, como, “teste passou, carregue a versão com todos os novos recursos, teste falhou, carregue a versão antiga” … muitos outros sites já fazem isso há anos, por que tem que ser impossível para o Discourse?
Exercício divertido que acabei de fazer:
O IE 6 do Windows XP dá um erro TLS
O mesmo Windows XP usando um navegador que ainda o suporta (Supermium)
O mesmo Windows XP, agora usando r3dfox
Obrigado pela atualização e pelo adiamento — agradeço. Mas tenho uma pergunta de acompanhamento sobre a justificativa por trás dessa decisão.
Você mencionou dar às comunidades e aos usuários mais tempo para se prepararem para a mudança. Isso implica que o principal impedimento para 1% é o tempo para atualizar seu navegador ou sistema operacional. Que dados você está usando para apoiar essa suposição?
Porque se a maioria desse 1% não consegue atualizar devido a limitações de hardware ou sistema operacional — não apenas procrastinação — então adiar o prazo por alguns meses não os ajuda de fato. Apenas adia o problema sem resolver a questão central.
Portanto, a menos que você tenha dados sólidos mostrando que mais tempo reduzirá significativamente o número de usuários afetados, essa mudança ainda excluirá um grupo significativo de pessoas que não poderão retornar.
Agradeceria uma resposta clara sobre o que seus dados realmente mostram sobre esse 1%.
