Emoji-Problem bei der Darstellung auf Webkit - Problem mit der Darstellung von HTML

[Crius]

Wir haben viele Benutzer, die Apple-Geräte und/oder Webkit-basierte Browser verwenden und Probleme beim Scrollen durch die Themen melden, bis hin zur Unbrauchbarkeit des Forums.

Ein Beispiel, auf Video festgehalten hier.

Nach einiger Recherche scheint die wahrscheinlichste Ursache darin zu liegen, wie Webkit… wie drücke ich mich milde aus… Müll bei der Bildgrößenänderung ist.

Das hat jedoch auch dazu geführt, dass ich bemerkt habe, wie die Emojis im “gekochten” HTML gerendert werden, und ich hätte gerne eine Klärung, weil ich vielleicht eine Konfiguration übersehen habe, die ich hätte vornehmen können, um dies zu verhindern.

In Grün sehen Sie die ursprüngliche Größe des Emojis.

In Azur/Cyan/was auch immer die Standardattribute sind, die von Discourse beim “Kochen” des Inhalts hinzugefügt werden.

In Rot die CSS, die von dem von mir geschriebenen Plugin hinzugefügt wurde, das:

• die Emojis importiert (es sind ziemlich viele)
• etwas benutzerdefiniertes CSS hinzufügt, damit sie richtig gerendert werden, da nicht alle “20 mal 20” sind.

Nun habe ich einen einfachen Test durchgeführt. Ich habe aus dem cooked-Feld in der Datenbank für dieses Thema alle width="20" height="20" entfernt und die Benutzer gebeten, es erneut zu versuchen und das Thema zu visualisieren, zu scrollen, zu antworten, auch wenn jemand neue Beiträge hinzufügt, aber ohne Emojis zu verwenden, um diese beiden Attribute nicht erneut in das gerenderte HTML der Emojis einzufügen.

Anscheinend war das die Ursache für die Probleme bei Webkit, da alle Berichte, die ich erhalten habe, bestätigen, dass es keine Probleme mit dem Scrollen gibt, seit diese beiden Attribute entfernt wurden.

Gibt es also eine Möglichkeit, Discourse daran zu hindern, diese Parameter hinzuzufügen? Warum geht Discourse davon aus, dass jedes Emoji “20x20” sein wird und erzwingt dies über HTML-Attribute anstatt über CSS?

Vielen Dank

[Canapin (Coin-coin le Canapin)]

@Crius

Wir haben viele Benutzer, die Apple-Geräte und/oder Webkit-basierte Browser verwenden und Probleme beim Scrollen durch die Themen melden, bis zu dem Punkt, an dem das Forum unbenutzbar wird.

Ich konnte es auf meinem iPad reproduzieren, aber nicht auf Chrome Desktop.

Ich scrolle nach oben und die Zeitleiste geht zum vorherigen Beitrag zurück, was es schwierig macht, daran vorbeizuscrollen und weiter nach oben in der Zeitleiste zu gelangen.

Aber ich habe Schwierigkeiten, es konsistent zu reproduzieren. Ich hing bei Beitrag Nr. 1955 fest, aber nachdem ich nach oben scrollen konnte, blockierte es mich nicht mehr, wenn ich wieder nach unten ging und erneut nach oben scrollte

[Crius]

Der Grund dafür ist, dass dies jedes Mal geschieht, wenn ein neues Emoji “lazy loaded” wird und die Größenattribute gerendert werden.

Sobald es gerendert ist, tritt das Problem nicht mehr auf. Aber wenn man sich durch ein Thema mit vielen Antworten bewegt, in denen Emojis häufig verwendet werden, wird man dieses Verhalten ständig sehen, und es wird die Nutzung von Discourse unmöglich machen.

Wir haben es in unserem benutzerdefinierten Theme “behoben”, aber ich denke, dies sollte auch im Standard-Theme angegangen werden, oder noch besser, in der Funktion, die die Beiträge verarbeitet, da ich keinen Grund sehe, warum diese größenbezogenen HTML-Attribute angewendet werden sollten, anstatt einfaches CSS zu verwenden.

Ich möchte hinzufügen, dass jeder Browser für iOS Webkit zu verwenden scheint, so dass dies hauptsächlich ein Problem für Apple-Geräte sein wird. Ich bin jedoch kein Experte dafür, also nehmen Sie dies mit Vorsicht. Weitere Tests wären erforderlich.

[awesomerobot (Kris)]

@Crius

Warum geht Discourse davon aus, dass jedes Emoji „20x20“ ist?

Das liegt daran, dass alle standardisierten Unicode-Emojis in ein Quadrat passen sollen, und wir gehen davon aus, dass Websites möchten, dass ihre Emojis konsistent in einer Weise skaliert werden, die neben Text und anderen Emojis funktioniert wenn dieser Teekessel 50x50 wäre, würde er eine riesige Lücke zwischen den Zeilen hinterlassen, wie diese:

@Crius

erzwingen über ein HTML-Attribut anstatt CSS zu verwenden?

Es gibt eine gute Erklärung von der Zeit, als es ursprünglich hinzugefügt wurde:

Add lazy loading for emojis

Personally I think it is like a good manner to always add width and height attributes to img elements on point where the img-element is generated. That is the place where I might know for sure which exact image-file I’m putting in. CSS is far away from the actual image-file. On top the browsers use this extra info about the image size to calculate aspect-ratio before loading the image file - and before CSS parsing. For this case the emojis are used in many different places - and sometimes def…

Mit unterstützenden Details von Multimedia: Images - Learn web development | MDN

Wenn die Attribute width und height eines Bildes in einem HTML-Element <img> enthalten sind, kann das Seitenverhältnis des Bildes vom Browser berechnet werden, bevor das Bild geladen wird. Dieses Seitenverhältnis wird verwendet, um den benötigten Platz für die Anzeige des Bildes zu reservieren, wodurch eine Layoutverschiebung reduziert oder sogar verhindert wird, wenn das Bild heruntergeladen und auf dem Bildschirm angezeigt wird. Die Reduzierung von Layoutverschiebungen ist eine wichtige Komponente für eine gute Benutzererfahrung und Web-Performance.

…

Während Best Practices für Entwickler aus dem letzten Jahrzehnt möglicherweise empfohlen haben, die Attribute width und height eines Bildes in einem HTML-Element <img> wegzulassen, gelten diese beiden Attribute aufgrund der Seitenverhältniszuordnung als Best Practice für Entwickler.

All das gesagt, Sie haben ein vernünftiges Beispiel für einen Fall, in dem die Standardgröße nicht für alle Emojis funktioniert … dieses alte Cheers-Emoji ist 3x so breit, also passt es nicht gut in ein Quadrat. Es ist nicht ungewöhnlich, dass andere Apps alle Emojis auf Quadrate beschränken, also sind wir mit unserem Verhalten hier nicht zu ungewöhnlich (sowohl Slack als auch Discord tun dies zum Beispiel) … aber alternativ könnten wir in Betracht ziehen, benutzerdefinierten Emojis optional Dimensionen zuzuweisen.

[rrit (Ayke)]

@awesomerobot

[…] die Standardgröße funktioniert nicht für alle Emojis… dieses alte Cheers-Emoji ist 3x so breit, daher passt es nicht gut in ein Quadrat.
[…] wir könnten erwägen, benutzerdefinierten Emojis optional Dimensionen zu geben.

Von der CSS-Seite ist dies leicht zu implementieren:

img.emoji {
  width: auto; /* ersetzt width: 20px; */
  height: 20px;
  vertical-align: text-bottom;
}

(Siehe DEV: add native lazy loading for emojis by rr-it · Pull Request #15830 · discourse/discourse · GitHub für die Erklärung.)

Die schwierigere Arbeit liegt im Teil „benutzerdefinierte Emojis“ und im Rendern von Emojis:

• Benutzerdefinierte Emojis benötigen ein zusätzliches Attribut für jedes Emoji: aspect-ratio (oder alternativ height und width).
• Das Rendern von Emojis muss das neue Attribut aspect-ratio verwenden, damit benutzerdefinierte Emojis die width entsprechend variieren können – height bleibt bei 20px.

---

Schneller und einfacher Ansatz für benutzerdefinierte Emojis:
Setzen Sie für benutzerdefinierte Emojis img-Tags nur height="20" und setzen Sie width überhaupt nicht – verzichten Sie damit auf den Vorteil, aspect-ratio/width und height festzulegen.
CSS: img.emoji { width: auto; }