Questo argomento è dedicato alla raccolta di feedback, concentrandosi principalmente su eventuali problemi relativi all’UX, per l’esperimento in corso in cui le emoji non influiscono più sull’ ‘altezza della linea’ e rispettano anche l’impostazione della dimensione del testo dell’utente nei post, nei messaggi e nelle chat.
Ad esempio, puoi trovare un esempio, qui…
Senza l’esperimento alla dimensione del testo utente più piccola (la differenza più drastica):
^ Sembra esserci un’interruzione di riga prima di “Ad esempio,”, mentre non c’è.
Perché è un esperimento e non una semplice correzione di bug?
Potrebbe esserlo, ma ci sono potenzialmente problemi nascosti presenti su diversi dispositivi, browser e sistemi operativi. Safari, ad esempio, visualizza la proprietà di stile di transform: scale(x) come sfocata date particolari combinazioni di cifre e font-size, con l’alternativa webkit che è grow – ma questa proprietà aggiunge uno spazio marginale all’altezza della linea, a differenza della proprietà più ampiamente adottata. Questo argomento esiste per lanciare una rete che catturi eventuali bug, prima di adottare il supporto.
Ho fatto alcuni test su diverse piattaforme e browser; finora sembra buono!
Che ne dici di applicare una logica simile all’emoji nel titolo?
Vedo gli amministratori personalizzare il loro tema e aumentare la dimensione del carattere.
Confermato. Questo è stato risolto specificamente con la chat.
Ma per post/messaggi, cercherò una soluzione per quel selettore. Deve essere abbastanza ampio da catturare emoji in markup dinamici <li></li> (come esempio) o qualsiasi markup, ma specificamente non certe cose.
Questo esperimento è attualmente in pausa/disabilitato 2024-01-02T06:00:00Z fino a nuovo avviso, per diagnosticare problemi di rendering con Safari correlati alla proprietà transform: scale(x); le emoji potrebbero apparire sfocate in casi casuali, dove potrebbero apparire nitide in un post, il successivo potrebbe apparire sfocato senza uno schema riproducibile.
Generalmente il rendering era stato considerato per Safari, ma poiché questa incoerenza è più difficile da aggirare, questo esperimento richiederà una correzione più coerente per poter procedere con l’implementazione e supportare ancora la versione webkit di Safari. Sto pensando di reimplementare la proprietà alternativa grow di webkit specificamente per Safari. Anche se questo consuma una porzione dell’altezza della linea, questo può essere mitigato.
