ニコニコ大百科

102×102
https://ch.nicovideo.jp/niconicoscience のあれ
記事内参照用URL :

「ソフトウェアトーク劇場のシリーズ一覧」を編集してくださりありがとうございます。

「【百チャレ】スマートフォンから記事が綺麗に見られるように編集しよう2023」にて教えてくださったレイアウトの再計算の仕様について確認したいことがあるのですが、よろしいでしょうか。
私はCSSを十分に理解できていないため、おかしな発言をしているようであれば申し訳ありません。

ぎみっく様の説明について、loading属性を用いた場合でも、画像が読み込まれるまでの間はalt属性に設定されたテキストの表示が優先されるため、レンダリング中にレイアウトの再計算が発生することに変わりはなく、max-widthであらかじめ要素の最大幅を設定しておくことによりサイズを固定すれば、それを回避できる、というように私は理解しました。

https://dic.nicovideo.jp/r/u/126126312/3159930
ただ、こちらの「読み込みが常に失敗する場合」と「span」を確認してくだされば伝わるかと思いますが、インライン要素中に存在するテキストが改行されない状況では、max-widthの指定よりもそちらの表示が優先され、横幅が大きくなります。
そのため、max-widthで要素の最大幅を設定しておくだけでは、レイアウトの再計算による表示の乱れを解決できないのではないかと思いました。

外部サービスを利用していますが、loading属性にlazyを、alt属性に改行不可能なテキストを設定した際の挙動を確認するためのHTMLを作成しましたので、よろしければご確認ください。
https://output.jsbin.com/xumojalexo/1

>>722-724
そうですね。詳しく個々の部分まで細かくみていくと仰る通りです。
ブラウザ側では初期の読み込みをDOMツリーに基づいた全体的なレイアウトを行って
その後に「表示領域に近付いた」トリガーによって遅延読み込み部分を読み込みます。

tableタグは中身に合わせて縮むshrink to fitが原則なので、中身が小さくなれる場合はそれに合わせてtdやtrが小さくなります。

そして、その小さくなった部分から遅延読み込み部分に対応して再度のレンダリング計算がブラウザ側で発生することにより、途中での表のズレが起こります。

遅延読み込み部分が独自のjavascriptによる動作なのは主要各ブラウザがloading属性に完全対応していなかった頃から遅延読み込みを採用していたからで、
挙動としては
・初期状態ではsrcは空　data-srcとして保持
・width、heightは200×200として一旦レンダリング
・width属性、height属性およびstyle属性でのwidth、heightがある場所は上記の200×200を上書きしたサイズで一旦レンダリング
・img画像にalt属性、title属性が付与されている場合、画像代替のalt、titleの表示が優先
(これは、alt、titleに対して遅延処理では無操作のため)

という動作になっています。
(※記事内に貼られた最初のimgタグ画像に対しては、この遅延操作は行われず除外対象になっています)

そして、スマホ版独自の仕様によりimg画像に対してはmax-width: 100%;が付与されることにより、
固定してある幅での表示のはずなのに文字列に置き換わった状態で横幅が変化するので途中での再レンダリングによりズレが発生しています。

この代替文字列は文字列なので指定したフォントサイズやword-breakなどの影響を受けます。

ご指摘される通り、一旦画像が読み込みに失敗した状態を意図的に作り出しているので、loading属性での挙動とは若干異なります。

loading属性自体もブラウザ間でまだ仕様が統一されていない部分もあり、読み込み完了前に代替文字列を表示する/しないの部分も統一されていなかったりバージョンによって変わったり…と、一概に言えないところもあります。

もともとimgタグの画像はiflameタグと同様に置換要素なのですが、上記のような形となっているためにこのようなことが起こってます。

外部での例、ありがとうございます。
インライン要素のspanタグと置換要素のimgタグでの表示の違いが分かりやすいですね。他の方にも伝わりやすいと思います。
ご提示頂いた例でも確認できるかと思いますが、spanタグとimgタグでは折り返し不可能なときの文字の表示が異なりますよね？
私ができますよと言ってたようにwidth、max-widthで明示してやるとはみ出し部分は表示されないのでサイズが固定されるのですが、それはそれで見切れることなってしまいますが…。

さて、スマホへの対応について主眼を移しますと、
公式ブロマガでも遅延読み込みがloading属性へと変更になる改修予定とのアナウンスがされましたが
loading属性のみでの実装だと、最初に挙げさせていただいた200×200で一旦仮レンダリングでサイズ確保しておくような処理がなくなるので
今度はPC版も含めた大百科全体でheightが一旦0で計算されてからの遅延読み込みによる再計算が起こるので、縦のズレが大きく発生してしまいます。

これを、回避するためにwidth、heightを明確に入れると
スマホでmax-width: 100%;の影響により画像の縦横比が変わってしまう例が散見されることになり、運営どうするんだろ？って思っています。

aspect-ratioプロパティが解禁されれば…とも思いますが、loading属性による遅延読み込み時の読み込み前の状態ではwidthとheightで明確に指定していないと反映されないので、
javascriptで読み込み完了前を判定してwidth属性、height属性、style属性のwidth、height関連から縦横比算出してheightを仮置きする…みたいなすこく面倒くさいことをしなきゃいけないような…本当にどうするんだろ？？？

…話がそれましたが、コメントいただきありがとうございます。
私も不勉強なことばかりなので、またご教示いただけたらと思います。
また、ニコニコ大百科はHTML、CSSに不慣れな方も編集されますので、そういった方々も編集しやすいようになるべく簡単な方法で表示できるようにできたらいいなと思っているので、お知恵をお貸しいただけたらと思います。

ってごめんなさい。
マヨネ～ズさんが提示してくださった例も、私が提示した話もそもそも、ブラウザ間のレンダリングの差異の部分が抜けていましたね。

FireFoxのGeckoエンジンとChromeのBlinkエンジン、SafariのWebkitエンジンでは、そもそもこの文字列として扱っているときの部分に差異が出ます。

分かりやすいようにFireFoxとChromeの両方で、マヨネ～ズさんの挙げてくださった例を見比べると、
双方が言及していたことが理解しやすいかと思われます。

画像の代替なので画像を読み込めなかったとき画像の指定範囲を越えても全部表示しなきゃいけない→FireFox
画像の代替なので画像を読み込めなかったとき画像の指定範囲内におさめなきゃいけない→Chrome

と根本的に別の表示になることがレンダリングエンジンの解釈の差異によって発生しています。
どちらが正しいのかは…どちらも解釈としては正しいので、解釈の不一致でしかないのですが…。

現状の限られた範囲の中で妥協できる範疇において、他の方にも編集しやすい形にするのがベストかなと個人的には。

>>725-729
わかりやすく説明してくださりありがとうございます。

よろしければ、loading属性のみでの実装では不具合が発生する旨について、一つ確認したいことがありますがよろしいでしょうか。
「heightが一旦0で計算されてからの遅延読み込みによる再計算が起こる」という表現をなされていますが、HTML Living Standardを再度確認したところ、lazy設定時は、読み込み前であればwidth、heightなどの設定が要素サイズに適用されるため、閲覧中にネットワークが切断されるようなことがない限り、そのようなズレは発生しないように思えました。
https://html.spec.whatwg.org/multipage/images.html#parsing-a-sizes-attribute

>現状の限られた範囲の中で妥協できる範疇において、他の方にも編集しやすい形にするのがベストかなと個人的には。
私としては、とりあえずoverflow: hidden;を設定したブロック要素で囲んでおくのがベターかと勝手に考えています。
display: inline-block;が使用できれば、レイアウトへの影響を最小限に抑えつつ対策できますが、なかなか難しいところです。

実際にこちらの端末でGecko、Blinkを用いて確認したところ、以下のような結果になりました。
HTMLについては、こちらのソースコードをテキストエディタにコピーして、適当な場所に保存してから開いてください。
https://pastebin.mozilla.org/zPNPF8Cu

Vivaldi 6.1.3035.111

スクロール前
ID 0 = 160x32, ID 1 = 50x100, ID 2 = 50x10, ID 3 = 160x16, ID 4 = 50x10

下方までスクロールした後
ID 0 = 160x32, ID 1 = 160x32, ID 2 = 50x10, ID 3 = 160x16, ID 4 = 50x10

Firefox 102.13.0esr

スクロール前
ID 0 = 160x17, ID 1 = 50x100, ID 2 = 50x10, ID 3 = 160x17, ID 4 = 50x10

下方までスクロールした後
ID 0 = 160x17, ID 1 = 160x17, ID 2 = 160x17, ID 3 = 160x17, ID 4 = 50x10

すみません。width、heightなどによるサイズ指定がない場合の話であることを見落としていました。
変なことを書いてしまいすみません。

現在のJavaScriptによる遅延読み込みの実装ですと、「VOICEROID」の記事のように、記事冒頭に複数の画像が掲載されており、最初からimg要素がビューポートに入っている場合に、一旦全体がレンダリングされてから二つ目以降の画像の読み込みが始まります。
そのため、loading属性による遅延読み込みの実装に切り替えたほうがレンダリング速度を改善できるのではないかといった考えもあり、以前に問い合わせをしていました。

width、heightなどによるサイズ指定がない場合の対応を完全に失念していたことを謝ります。

>>730-732
いえいえ、お気になさらないでください。たしかにそうなんですよね。
一番先頭にあるimgタグの画像にはjavascriptによる遅延読み込みがないので、仰るように読み込みに差が出すぎてしまいます。

今現在はニコニコ大百科の鯖が重い状態なので特に遅延読み込み部分までのレンダリングに時間が掛かっているような感じですね。

今のjavascriptでの遅延読み込みもwidth、heightの指定がない場合、200×200の仮サイズでレンダリングするだけなので問題を完全に解決してるとは言えませんし…。

おにまいのドット絵とても素敵です。これからも頑張ってください！

>>734
紛らわしくて、ごめんなさい

おにまいのドット絵は
Kofumi/小文さん
https://dic.nicovideo.jp/u/9673725
が描かれたものです。
>>im11235569

お邪魔します。

ニコ生の件では大変お世話になり、本当にありがとうございました。
記事内参照用URL :

>>736
義陣華さん、いらっしゃいませ。素敵なイラストをありがとうございます。
どういたしまして、またなにかあればいつでもおっしゃってくださいね。

って、この子（娘？）えっちすぎない？？？

エジソンの記事ちゃんと作れ

ぎみっくさん鳥だったんですねぇ…
猫じゃないですか
記事内参照用URL :

>>739さん、素敵なイラストありがとうございます。
なんですか、このかわいい子は。けしからん（誉めことば）


>>738さん、ごめんなさい…

大変お世話になりました。ありがとうございました！
記事内参照用URL :

>>741 ラーメンとチャーハン食べた奴さん
ありがとうございますm(_ _)m
すごくかわいい～！！！