webkitでのレンダリング時の絵文字の問題 - HTMLのレンダリング方法に関する問題

Appleデバイスや/またはwebkitベースのブラウザを使用している多くのユーザーが、フォーラムが使用不能になるほどトピックをスクロールする際に問題を報告しています。

例として、ビデオで撮影したものはこちらです: https://streamable.com/15yari

かなりの調査を行った結果、最も可能性の高い原因は、webkitが画像のサイズ変更をどのように処理しているか…穏便に言うと…ひどいということです。

しかし、それが、レンダリングされたHTMLで絵文字がどのように表示されるかに気づいたことにもつながり、設定ミスをしていないか、またはこれを防ぐことができたかもしれないので、いくつか明確にしたいことがあります。

緑色で絵文字の元のサイズが見えます。

青/シアン/その他の色で、Discourseがコンテンツを調理する際にデフォルトで追加される属性が見えます。

赤色で、私が書いたプラグインによって追加されたCSSが見えます。このプラグインは:

  • 絵文字をインポートします(かなりの数があります)。
  • すべてが「20x20」ではないため、適切にレンダリングされるようにカスタムCSSを追加します。

さて、簡単なテストを実行しました。そのトピックのDBのcookedフィールドからすべての width="20" height="20"を削除し、ユーザーに再度試してもらい、トピックを視覚化するように依頼しました。スクロール、返信、誰かが新しい投稿を追加している場合でも、絵文字を使用しないように、レンダリングされたHTMLにこれらの2つの属性が再度挿入されないようにしました。

どうやら、これがwebkitでの問題を引き起こしていた原因のようです。すべての報告によると、これらの2つの属性が削除された後、スクロールの問題はなくなりました。

では、Discourseがこれらのパラメータを追加するのを防ぐ方法はありますか?なぜDiscourseは、すべての絵文字が「20x20」であると仮定し、さらにHTML属性でそれを強制するのではなく、CSSを使用するのでしょうか?

ありがとうございます。

iPadでは再現できましたが、Chromeデスクトップでは再現できませんでした。

上にスクロールすると、タイムラインが前の投稿に戻り、それを通り過ぎてタイムラインをさらに上に移動するのが困難になります。

しかし、一貫して再現するのは難しいです。投稿#1955で詰まりましたが、それを上にスクロールして通り過ぎることができた後、下にスクロールしてもう一度上にスクロールしても、もうブロックされませんでした :thinking:

新しい絵文字が「遅延読み込み」され、サイズ属性がレンダリングされるたびに発生するためです。

レンダリングされると、問題は発生しなくなります。しかし、返信が多く、絵文字がかなり使用されているトピックをスクロールすると、この動作が常に発生し、Discourseの使用が不可能になります。

カスタムテーマで「修正」できましたが、デフォルトテーマ、またはさらに良いことに、投稿を調理する関数で対処する必要があると思います。単純なCSSを使用するのではなく、これらのサイズ関連のHTML属性が適用される理由がわかりません。

すべてのiOSブラウザがwebkitを使用しているため、主にAppleデバイスの問題になることを付け加えておきます。ただし、私は専門家ではないので、これは参考程度にしてください。さらなるテストが必要です。

「いいね!」 1

これは、すべての標準化されたUnicode絵文字が正方形に収まるように設計されており、サイトがテキストや他の絵文字と並べて使用するのに適したサイズで絵文字を表示したいと想定しているためです。もしこのティーポットが50x50だったら、行間にこのような大きな隙間ができてしまいます。

元々追加された際の詳しい説明があります。

また、 Multimedia: Images - Learn web development | MDN からの補足情報もあります。

画像のwidthheight属性がHTMLの<img>要素に含まれている場合、ブラウザは画像が読み込まれる前に画像の縦横比を計算できます。この縦横比を使用して、画像を表示するために必要なスペースが予約され、画像がダウンロードされて画面に描画される際のレイアウトシフトが軽減または防止されます。レイアウトシフトの軽減は、優れたユーザーエクスペリエンスとウェブパフォーマンスの主要な要素です。

この10年間、開発者のベストプラクティスとして画像のHTML<img>要素のwidthheight属性を省略することが推奨されてきましたが、縦横比のマッピングにより、これらの2つの属性を含めることが開発者のベストプラクティスと見なされています。

とはいえ、デフォルトのサイズ設定がすべての絵文字に適合しないという、もっともな例を挙げていただきました。あの古い乾杯の絵文字は幅が3倍なので、正方形にきれいに収まりません。他のアプリでもすべての絵文字を正方形に制限しているのは珍しくないので、私たちの動作もそれほど異常ではありません(SlackやDiscordも同様です)。しかし、カスタム絵文字の寸法をオプションで設定できるようにすることも検討できます。

「いいね!」 2

CSS側では簡単に実装できます。

img.emoji {
  width: auto; /* width: 20px; を置き換え */
  height: 20px;
  vertical-align: text-bottom;
}

(説明については DEV: add native lazy loading for emojis by rr-it · Pull Request #15830 · discourse/discourse · GitHub を参照してください。)

より難しいのは「カスタム絵文字」と絵文字のレンダリングの部分です。

  • カスタム絵文字には、絵文字ごとに aspect-ratio(または代替として heightwidth)の追加属性が必要です。
  • 絵文字のレンダリングでは、カスタム絵文字が aspect-ratio を使用して width をそれに応じて変更する必要があります – height20px のままです。

カスタム絵文字の迅速かつ簡単なアプローチ:
カスタム絵文字の img タグでは、height="20" のみ設定し、width はまったく設定しない – これにより、aspect-ratio/widthheight を設定する利点を捨てます。
CSS: img.emoji { width: auto; }

「いいね!」 2