Dieses Thema widmet sich dem Sammeln von Feedback, hauptsächlich zu UX-bezogenen Problemen, für das laufende Experiment, bei dem Emojis die ‘Zeilenhöhe’ nicht mehr beeinflussen und die Benutzereinstellung für die Textgröße in Themenbeiträgen, Nachrichten und im Chat berücksichtigen.
Sie finden hier zum Beispiel ein Beispiel…
Ohne das Experiment bei der kleinsten Benutzereinstellung für Textgröße (der dramatischste Unterschied):
^ Es scheint einen Zeilenumbruch vor „Zum Beispiel,“ zu geben, während keiner vorhanden ist.
Warum ist das ein Experiment und keine einfache Fehlerbehebung?
Das könnte sein, aber es gibt potenziell versteckte Probleme auf verschiedenen Geräten, Browsern und Betriebssystemen. Safari rendert beispielsweise die Styling-Eigenschaft von transform: scale(x) bei bestimmten Ziffern- und font-size-Kombinationen unscharf, wobei die Webkit-Alternative grow ist – aber diese Eigenschaft fügt der Zeilenhöhe einen geringfügigen Abstand hinzu, im Gegensatz zur weiter verbreiteten Eigenschaft. Dieses Thema dient dazu, alle Fehler zu erfassen, bevor die Unterstützung übernommen wird.
Ich habe ein paar Tests auf verschiedenen Plattformen und Browsern durchgeführt; es sieht bisher gut aus!
Was ist mit der Anwendung einer ähnlichen Logik auf das Emoji im Titel?
Ich kann sehen, dass Administratoren ihr Thema anpassen und die Schriftgröße erhöhen.
Bestätigt. Dies wurde speziell mit dem Chat behoben.
Für Beiträge/Nachrichten suche ich jedoch nach einer Lösung für diesen Selektor. Er muss breit genug sein, um Emojis in dynamischen <li></li> (als Beispiel) oder beliebiger Markup-Sprache zu erfassen, aber insbesondere nicht bestimmte Dinge.
Dieses Experiment wurde bis auf Weiteres pausiert/deaktiviert 2024-01-02T06:00:00Z, um Rendering-Probleme mit Safari zu diagnostizieren, die mit der transform: scale(x)-Eigenschaft zusammenhängen. Emojis können in zufälligen Fällen unscharf erscheinen, wo sie in einem Beitrag scharf gerendert werden können, der nächste kann unscharf erscheinen, ohne ein reproduzierbares Muster.
Im Allgemeinen wurde das Rendering für Safari berücksichtigt, aber da diese Inkonsistenz schwerer zu umgehen ist, wird dieses Experiment eine konsistentere Lösung benötigen, um mit der Implementierung fortzufahren und weiterhin die Webkit-Version von Safari zu unterstützen. Ich neige dazu, die alternative grow-Eigenschaft von Webkit speziell für Safari neu zu implementieren. Auch wenn dies einen Teil der Zeilenhöhe verbraucht, kann dies gemildert werden.
