Il tuo browser diventerà presto incompatibile con questa community. Per continuare a partecipare qui, aggiorna il tuo browser o scopri di più.
A proposito, questo link “scopri di più” nel banner che rimanda a questo argomento non segue l’impostazione “Apri tutti i link esterni in una nuova scheda”. Si carica nella scheda corrente.
Wine è a questo punto abbastanza ben sviluppato, credo. È iniziato principalmente nei circoli dei giochi ma ha avuto aiuto nello sviluppo ($$$) nel recente passato
Disclaimer: nessuna esperienza recente
Per cosa userai la sintassi relativa del colore?
Un foglio di stile più compatto?
Potresti forse annullare l’uso previsto della sintassi relativa del colore?
Sebbene queste siano alcune funzionalità che abbiamo identificato e che vogliamo utilizzare oggi, l’abbandono di quei browser i cui manutentori hanno deprecato ci consente anche di esplorare altre cose. Ad esempio, Import maps | Can I use... Support tables for HTML5, CSS3, etc è qualcosa che sarà abilitato da questo stesso cambiamento e che potrebbe velocizzare Discourse per il 99% degli utenti. Offscreen canvas è già utilizzato per la compressione delle immagini su Discourse da molti anni e diventa disponibile su tutti i browser di destinazione con questo aggiornamento.
Ancora uguale qui.
Qualcuno ha trovato una soluzione?
Ho già provato 5 o 6 estensioni per lo spoofing dell’user agent. Ce ne sono molte, ma quelle che ho testato non erano molto valide da usare. E la maggior parte di esse non erano per sito.
Ho ancora bisogno su Android 9:
E poter usare Discourse (lettura/scrittura).
Suppongo che dovrò testare tutte le estensioni per user agent, una per una… 
Non stiamo controllando l’user agent, quindi falsificarlo non aiuterà.
Stiamo utilizzando il rilevamento delle funzionalità per le tre funzionalità menzionate nell’OP. Se il browser non le supporta, verrà attivato il banner di avviso.
Hai provato a segnalare il problema agli sviluppatori di Kiwi? Sembra che la loro versione di Chromium dovrebbe supportare la sintassi dei colori relativi, quindi forse l’hanno disabilitata? Forse per errore?
Oh, questo è un bene.
Sarà così anche nella versione del 1° maggio, o testerete le versioni?
Kiwi non è più mantenuto.
Sì, aggiungeremo queste alla lista esistente di funzionalità che Discourse controlla 
Dici che questo cambiamento velocizzerà le cose per il 99% degli utenti — giusto. Ma l’altra faccia della medaglia è che stai completamente tagliando l’accesso al restante 1%.\n\nQuindi, quante persone reali ci sono in quel 1%?\n\nSe il numero ti sembra scomodo da pubblicare qui perché non è così piccolo come sembra in termini percentuali, allora forse vale la pena riconsiderare se sono davvero abbastanza insignificanti da meritarne il taglio dell’accesso.
La maggior parte delle mie macchine sono moderne, ma ho appena ricevuto questo messaggio su una che non può essere aggiornata.
Suppongo che la base di riferimento sarà sempre in movimento, ma vorrei richiedere, se possibile, un fallback pulito in modo che i browser non supportati abbiano la minima capacità di: accedere, visualizzare e creare post/thread anche se poi non possono utilizzare tutte le funzionalità.
PERCHÉ?? Questa è discriminazione contro le persone che vivono nei paesi del terzo mondo!
Non rompere internet, esiste da 35 anni!
Per me questo problema sembra molto più grande di Discourse. Si tratta di un problema dei fornitori di hardware, dei fornitori di sistemi operativi e dei fornitori di browser web che interrompono il supporto, gli aggiornamenti e gli upgrade troppo presto. Il costo degli aggiornamenti deve essere di un valore monetario minimo in modo che tutti possano averli.
Discourse e altri sviluppatori di software (incluse le app) sono davvero in balia dell’ecosistema in cui viviamo.
Discourse sarà il primo sito che userò per bloccare il mio browser (Android), però.
Sulla base del feedback della community e delle informazioni aggiuntive raccolte sull’effetto su Windows 7/8, abbiamo deciso di posticipare questa modifica fino a dopo il prossimo rilascio stabile di Discourse nel luglio 2025. Ciò darà alle community e agli utenti altri 3 mesi per prepararsi alla modifica.
Ciò darà anche agli amministratori self-hosted l’opzione di passare le loro community al ramo stabile, che continuerà a funzionare su browser più vecchi fino al rilascio successivo all’inizio del 2026.
Per consentirci di continuare a progredire con le nuove tecnologie, il nostro nuovo “Tema Orizzonte” sta già utilizzando alcune di queste funzionalità dei browser moderni. Per i siti che eseguono Orizzonte, agli utenti di browser vecchi viene già mostrata la vista basic-html.
Aggiornerò l’OP qui di conseguenza 
Eccellente. Posso incoraggiare te (alias Discourse) a considerare questi tipi di adozioni come una questione di accessibilità e inclusività?
Grazie.
Durante quel periodo, si prega di considerare anche di continuare a fornire una versione di Discourse che rimanga utilizzabile su apparecchiature obsolete e che, pur non includendo tutte le funzionalità, includa la possibilità di pubblicare e avviare thread, nonché di leggere.
Grazie! Questo aiuta sicuramente e riduce il panico.
Ma:
sono ancora entrambi punti molto validi.
Penso che molti di noi stiano sostenendo non se la “funzionalità X” debba o non debba essere supportata dalla “versione Y” per “tempo Z”, ma che Discourse dovrebbe offrire un degrado aggraziato, magari qualcosa come una modalità HTML semplice + POST HTTP come offrivano i primi forum. Idealmente, ciò dovrebbe essere prioritario rispetto alle nuove funzionalità, soprattutto rispetto alle modifiche estetiche, ma sostengo anche che dovrebbe essere prioritario rispetto alle ottimizzazioni delle prestazioni.
Gli utenti di Discourse non dovrebbero dover scegliere tra la community e le nuove funzionalità — e questa parte sembra una questione culturale. Sembra che gli sviluppatori vogliano “muoversi un po’ velocemente, non troppo velocemente, rompere alcune cose ma non troppe”. Questa potrebbe essere una posizione perfettamente ragionevole per un’azienda di software, ma NON è necessariamente la stessa posizione che vorrebbero le community di Discourse. Alcune community vorrebbero muoversi più velocemente, mentre altre preferirebbero un movimento molto più lento o nessuno.
Secondo me, Discourse oggi è già “abbastanza buono” e se ci fosse un’opzione per i clienti ospitati di scegliere un ramo di supporto a lungo termine senza nuove funzionalità aggiunte per i prossimi 10 anni, solo correzioni di sicurezza critiche, la sceglierei totalmente — anche se la nuova versione fosse 10 volte più veloce. Preferirei di gran lunga un forum lento che tutti possano usare piuttosto che uno che perde gradualmente utenti solo per offrire un’esperienza più veloce e brillante ai sopravvissuti.
Ma non tutti sarebbero d’accordo. Quel ritmo sarebbe troppo lento sia per gli sviluppatori (presumo) che per altre community di Discourse… dipende totalmente dai loro dati demografici di utenti e dispositivi. Un forum per anziani non inseguirà mai le stesse funzionalità di un forum sull’IA, per esempio.
Ma non dovrebbero aver BISOGNO di combattere l’uno contro l’altro in questo modo. Questi non sono obiettivi mutualmente esclusivi. Il degrado aggraziato è stato un principio fondamentale fin dai primi giorni del web, e Discourse è già abbastanza headless (con varie API, e anche dimostrato da implementazioni di terze parti come Discorkie) che dovrebbe essere possibile fornire una modalità “HTML semplice” con lettura + pubblicazione di base. Non ha bisogno di temi eleganti, non ha bisogno di paginazione infinita, non ha nemmeno necessariamente bisogno di modifica e notifiche e tutte le altre funzionalità desiderabili. Deve solo essere un’esperienza di base utilizzabile che permetta alle persone di continuare a utilizzare il forum per la sua funzione prevista, leggere e pubblicare. Non può offrire più di un’UX in stile Usenet degli anni ‘90 e sarebbe comunque meglio che tagliare completamente le persone. Con un po’ più di tempo di sviluppo, potrebbe offrire un’interfaccia utente in stile era PHP di vBulletin e sarebbe comunque un enorme miglioramento rispetto alla situazione “Spiacenti, non è più possibile pubblicare” (che vedremo ancora a luglio).
IMHO Discourse è (o dovrebbe essere) soprattutto community. Non è una demo tecnologica (più), e mentre la mia preferenza personale è che sia considerato un “software stabile e noioso” che raramente cambia… capisco che non è quello che gli sviluppatori e altre community di Discourse potrebbero volere. Va bene. Non è un mainframe bancario 
Ma d’altra parte, non ha nemmeno bisogno di inseguire continui miglioramenti dei browser (che non finiranno mai). Tra i due estremi, una modalità HTML di base permetterebbe agli utenti di continuare a pubblicare molto tempo dopo che i loro browser saranno obsoleti, consentendo anche uno sviluppo di funzionalità più rapido sul ramo principale perché gli utenti avranno qualcosa a cui tornare.
Come bonus, potrebbe effettivamente permetterti di gestire il tipo di sviluppo basato su finestre temporali che vuoi fare (ad esempio, “supporteremo browser fino a 2 anni fa, o al 95% del marchio caniuse”) piuttosto che scegliere singole funzionalità in ogni possibile permutazione di hardware + sistema operativo + browser + fork. Qualsiasi cosa più vecchia di quel target potrà comunque pubblicare tramite la modalità HTML di base, ma non potrà utilizzare i temi più recenti, _____, ______, _____ ecc. (il che va benissimo perché probabilmente non gli importa di tutto ciò). Ti libera dal dover ricontrollare ogni funzionalità con ogni browser… se un utente non può usare una funzionalità elegante, beh, sarebbe davvero compito suo aggiornare a un nuovo browser. Ma almeno non verrebbero cacciati dalle loro community.
Non sono sicuro di questo (perché non conosco la fonte dello script), ma ho visto per anni siti che, facendo un semplice test al caricamento nel browser, utilizzano automaticamente una versione o l’altra, a seconda che il browser la supporti o meno, e di solito in modalità trasparente (gli utenti non vedono nemmeno quel processo).
Sono sicuro che, avendo Discourse già una versione funzionante (quella che stai usando in questo momento) che non esclude i vecchi browser, sia abbastanza facile inserire un singolo test all’inizio del caricamento dello script, e condizionare la parte che viene caricata per superare o fallire il test, come, “test superato, carica quello con tutte le nuove funzionalità, test fallito, carica la vecchia versione”… molti altri siti lo fanno già da anni, perché deve essere impossibile per Discourse?
Esercizio divertente che ho appena fatto:
Windows XP IE 6 dà un errore TLS
Stesso Windows XP che utilizza un browser che lo supporta ancora (Supermium)
Stesso Windows XP, ora utilizzando r3dfox
Grazie per l’aggiornamento e per il ritardo, lo apprezzo. Ma ho una domanda di follow-up sulla logica alla base di questa decisione.
Hai menzionato di dare alle community e agli utenti più tempo per prepararsi al cambiamento. Ciò implica che il principale ostacolo per l’1% è il tempo per aggiornare il proprio browser o sistema operativo. Quali dati stai utilizzando per supportare questa ipotesi?
Perché se la maggior parte di quell’1% non può aggiornare a causa di limitazioni hardware o del sistema operativo, non solo per procrastinazione, allora ritardare la data limite di qualche mese non li aiuterà realmente. Si limiterà a rimandare il problema senza affrontare la questione principale.
Quindi, a meno che tu non disponga di dati solidi che dimostrino che più tempo ridurrà significativamente il numero di utenti interessati, questo cambiamento escluderà comunque un gruppo significativo di persone che non saranno in grado di tornare.
Apprezzerei una risposta chiara su cosa mostrano effettivamente i tuoi dati riguardo a quell’1%.
