Tu navegador pronto será incompatible con esta comunidad. Para seguir participando aquí, actualiza tu navegador o obtén más información.
Por cierto, este enlace del banner “obtén más información” a este tema no sigue la configuración de Abrir todos los enlaces externos en una nueva pestaña. Se carga en la pestaña actual.
Creo que Wine está bastante bien desarrollado en este momento. Comenzó principalmente en círculos de juegos, pero ha tenido ayuda en el desarrollo ($$$) en el pasado reciente.
Descargo de responsabilidad: sin experiencia reciente.
Si bien esas son algunas de las características que hemos identificado que queremos usar hoy, eliminar esos navegadores cuyos mantenedores han dejado de admitir nos permite explorar otras cosas. Por ejemplo, Import maps | Can I use... Support tables for HTML5, CSS3, etc es algo que se habilitará con este mismo cambio y que podría acelerar Discourse para el 99% de los usuarios. El lienzo fuera de pantalla ya se utiliza para la compresión de imágenes en Discourse desde hace muchos años y también estará disponible en todos los navegadores de destino con esta actualización.
Sigue igual aquí.
¿Alguien ha encontrado una solución?
Ya probé 5 o 6 extensiones de suplantación de agente de usuario. Hay muchas, pero las que probé no eran realmente buenas de usar. Y la mayoría no eran por sitio.
Todavía necesito en Android 9:
Extensión Violentmonkey
Extensión Stylus
Herramientas WebDev
Menú contextual Copiar texto del enlace
Y poder usar Discourse (leer/escribir).
Supongo que tendré que probar todas las extensiones de agente de usuario, una por una…
No estamos mirando el agente de usuario, así que falsificarlo no ayudará.
Estamos utilizando la detección de características para las tres características mencionadas en el OP. Si el navegador no las admite, se activará el banner de advertencia.
¿Has intentado informar del problema a los desarrolladores de Kiwi? Parece que su versión de Chromium debería admitir la sintaxis de color relativa, ¿así que tal vez la deshabilitaron? ¿Quizás accidentalmente?
Dices que este cambio acelerará las cosas para el 99% de los usuarios — bastante justo. Pero el lado negativo es que estás cortando completamente el acceso para el 1% restante.
Entonces, ¿cuántas personas reales hay en ese 1%?
Si el número parece incómodo de publicar aquí porque no es tan pequeño en términos porcentuales, quizás valga la pena reconsiderar si realmente son lo suficientemente insignificantes como para cortarles el acceso.
La mayoría de mis máquinas son modernas, pero acabo de recibir este mensaje en una que no se puede actualizar.
Supongo que la línea de base siempre se moverá, pero solicitaría, si es posible, una opción de reserva limpia para que los navegadores no compatibles tengan la mínima capacidad de: iniciar sesión, ver y crear publicaciones/hilos, incluso si luego no pueden usar todas las funciones avanzadas.
Para mí, este problema parece mucho mayor que Discourse. Es un problema de los proveedores de hardware, los proveedores de sistemas operativos y los proveedores de navegadores web que cortan el soporte, las actualizaciones y las mejoras demasiado pronto. El costo de las actualizaciones debe ser de un valor monetario mínimo para que todos puedan tenerlas.
Discourse y otros desarrolladores de software (incluidas las aplicaciones) están realmente a merced del ecosistema en el que vivimos.
Basándonos en los comentarios de la comunidad y la información adicional que hemos recopilado sobre el efecto en Windows 7/8, hemos decidido retrasar este cambio hasta después del próximo lanzamiento estable de Discourse en julio de 2025. Esto dará a las comunidades y usuarios 3 meses más para prepararse para el cambio.
Eso también dará a los administradores autoalojados la opción de cambiar sus comunidades a la rama estable, que seguirá funcionando en navegadores antiguos hasta el siguiente lanzamiento a principios de 2026.
Para permitirnos seguir avanzando con nuevas tecnologías, nuestro nuevo “Tema Horizon” ya está utilizando algunas de estas características de navegador modernas. Para los sitios que ejecutan Horizon, a los usuarios de navegadores antiguos ya se les muestra la vista HTML básica.
Durante ese tiempo, por favor, consideren también continuar proporcionando una versión de Discourse que siga siendo utilizable en equipos antiguos y que, aunque puede que no incluya todas las funciones, sí incluya la capacidad de publicar y crear hilos, así como de leer.
Creo que lo que muchos de nosotros argumentamos no es si la “característica X” debe o no ser compatible con la “versión Y” durante un “período Z”, sino que Discourse debería ofrecer una degradación elegante, tal vez algo como un modo de HTML plano + HTTP POST como ofrecían los primeros foros. Idealmente, eso tendría prioridad sobre las nuevas funciones, especialmente sobre los cambios cosméticos, pero yo argumentaría que también sobre las optimizaciones de rendimiento.
Los usuarios de Discourse no deberían tener que elegir entre la comunidad y las nuevas funciones — y esa parte sí parece una cuestión cultural. Parece que los desarrolladores quieren “moverse un poco rápido, no demasiado rápido, romper algunas cosas pero no demasiadas”. Esa podría ser una posición perfectamente razonable para una empresa de software, pero no es necesariamente la misma posición que querrían las comunidades de Discourse. Algunas comunidades querrían moverse más rápido, mientras que otras preferirían mucho más lento o ningún movimiento.
Para mí, Discourse hoy en día ya es “suficientemente bueno” y si hubiera una opción para que los clientes alojados eligieran una rama de soporte a largo plazo sin nuevas funciones durante los próximos 10 años, solo correcciones de seguridad críticas, la elegiría totalmente, incluso si la nueva versión fuera 10 veces más rápida. Preferiría, MUCHO, un foro lento que todos puedan usar que uno que gradualmente pierda usuarios solo para ofrecer una experiencia más rápida y brillante para los supervivientes.
Pero no todos estarían de acuerdo con eso. Ese ritmo sería demasiado lento tanto para los desarrolladores (presumo) como para otras comunidades de Discourse… depende totalmente de su demografía de usuarios y dispositivos. Un foro para gente mayor nunca perseguirá las mismas funciones que un foro de IA, por ejemplo.
Pero no deberían NECESITAR luchar entre sí de esa manera. Estos no son objetivos mutuamente excluyentes. La degradación elegante ha sido un principio básico desde los primeros días de la web, y Discourse ya es lo suficientemente “headless” (con varias API, y también demostrado por implementaciones de terceros como Discorkie) como para que sea posible proporcionar un modo de “HTML simple” con lectura y publicación básicas. No necesita temas elegantes, no necesita paginación infinita, ni siquiera necesita necesariamente edición, notificaciones y todas las otras funciones deseables. Solo tiene que ser una experiencia básica utilizable que permita a las personas seguir utilizando el foro para su función prevista, leer y publicar. No necesita ofrecer más que una experiencia de usuario al estilo Usenet de los 90 y aún así sería mejor que cortar a la gente por completo. Con un poco más de tiempo de desarrollo, podría ofrecer una interfaz de usuario de la era PHP al estilo vBulletin y eso seguiría siendo una gran mejora con respecto a la situación de “Lo sentimos, ya no puedes publicar” (que todavía veremos en julio).
En mi opinión, Discourse es (o debería ser) ante todo sobre la comunidad. No es una demo técnica (ya no), y aunque mi preferencia personal es que se considere como un “software estable y aburrido” que rara vez cambia, entiendo que eso no es lo que los desarrolladores y otras comunidades de Discourse pueden querer. Eso está bien. No es un mainframe bancario Pero, a la inversa, tampoco necesita perseguir mejoras constantes de navegadores (que nunca terminarán). Entre los dos extremos, un modo HTML básico permitiría a los usuarios seguir publicando mucho después de que sus navegadores queden obsoletos, mientras que también permite un desarrollo de funciones más rápido en la rama principal porque los usuarios tendrán algo a lo que recurrir.
Como extra, podría permitirle dirigirse al tipo de desarrollo basado en ventanas de tiempo que desea realizar (por ejemplo, “soportaremos navegadores de hasta 2 años de antigüedad, o el 95% de caniuse”) en lugar de seleccionar características individuales en todas las permutaciones posibles de hardware + sistema operativo + navegador + fork. Cualquier cosa anterior a ese objetivo aún podrá publicar a través del modo HTML básico, pero no podrá usar los últimos temas, _____, ______, _____ etc. (lo cual está totalmente bien porque probablemente no les importe todo eso de todos modos). Le libera de tener que verificar cada función con cada navegador… si un usuario no puede usar alguna función elegante, bueno, realmente dependerá de él actualizar a un nuevo navegador. Pero al menos no serían expulsados de sus comunidades.
No estoy seguro de esto (porque no conozco la fuente del script), pero he visto durante años lugares que, haciendo una simple prueba al cargar en el navegador, usan automáticamente una versión u otra, dependiendo de si el navegador puede soportarla o no, y generalmente en modo transparente (los usuarios ni siquiera ven ese proceso).
Estoy seguro de que, teniendo Discourse ya una versión funcional (la que estás usando ahora mismo) que no excluye a los navegadores antiguos, es lo suficientemente fácil poner una prueba simple al inicio de la carga del script, y condicionar la parte que se carga a pasar o fallar la prueba, como, “prueba superada, carga la que tiene todas las nuevas funciones, prueba fallida, carga la versión antigua”… muchos otros sitios ya hacen esto desde hace años, ¿por qué tiene que ser imposible para Discourse?
Gracias por la actualización y la demora; se agradece. Pero tengo una pregunta de seguimiento sobre el razonamiento detrás de esta decisión.
Mencionaste dar a las comunidades y a los usuarios más tiempo para prepararse para el cambio. Eso implica que el principal obstáculo para el 1% es el tiempo para actualizar su navegador o sistema operativo. ¿En qué datos se basan para apoyar esa suposición?
Porque si la mayoría de ese 1% no puede actualizar debido a limitaciones de hardware o del sistema operativo, no solo por procrastinación, entonces retrasar la fecha límite unos meses no les ayuda realmente. Simplemente pospone el problema sin abordar la cuestión central.
Por lo tanto, a menos que tengan datos sólidos que demuestren que más tiempo reducirá significativamente el número de usuarios afectados, este cambio seguirá excluyendo a un grupo importante de personas que no podrán regresar.
Agradecería una respuesta clara sobre lo que muestran realmente sus datos sobre ese 1%.