レイアウト崩れはエミュで起きてるんじゃない！スマホで起きてるんだ！（自戒）

— 実機検証はホント大事 —

スマホ表示でのレイアウト崩れに気づかないという、HTML/CSSを日常的に扱っている人間として“あるまじきミス”を犯しました。なので、『Google Chrome Developer Tools』や『Blisk browser』に甘えず実機検証をすべき…という、自分への戒め記事をしたためます。

教えてもらうまで気づかなかった。
…そんな自分にショックを隠せないのであーる。

…あらま。

てか、実機確認してなかったんやね。

TL;DR

『Google Chrome Developer Tools^[*1]』や『Blisk browser^[*2]』のような、Windows・Macでスマホ表示を確認できる便利なツールはある。だけど、最終的には、『iPhone』や『Google Pixel』で実機検証をしておこう。

…という、自分への戒めあーる。

“スマホ表示でのレイアウト崩れ”という凡ミス

ご指摘を受けるまで気づかなかったのですが、スマートフォン（iPhone）で閲覧すると、<table>タグにおけるレイアウト崩れが発生しており、記事内の表がまったく見ることができない状態になっていました。

申し訳ないのであーる。
そして、教えてくれてありがとうなのであーる！

ちなみに、実際のレイアウト崩れについては、上画像のような感じ。それはもう、見事に表のセルがひしゃげています。

ありとあらゆるデバイスで実機検証をしたわけではありませんが、『Google Chrome（Blink系Webブラウザ）』ではレイアウト崩れが生じないっぽいのですが、『Safari（WebKit系Webブラウザ）』では、上画像のようなグチャグチャな表示になっておりました。

これは…読めないですわね。

実は、レイアウト崩れの“兆候”はあったんだけど、「ちゃんとGoogle Chromeで表示されてるから大丈夫でしょ」って、高を括っていたんだよねー。

一番ダメなパターンやね。

んごご…んごんご……。

余談ですが、レイアウト崩れの原因は、<th>タグにwidth: calc((100% - 120px)/2)のような記述をスタイルシートにしていたためでした。

Markdown → HTML の変換を考えると、表組みは<table>タグでやるのが視認性も良く、かつソースコードも綺麗なのですが、min-heightプロパティを当てるのに、擬似要素（疑似要素）が必要だったりで結構厄介だったりします。

これから表組みは<table>じゃなくて、<div>とdisplay: flex;で段組みに変更しようかなー。

アクセシビリティ的にどうなのでしょうね？（Flexboxは便利なので、気持ちは分かりますが）

…うーむ。

エミュレーションは過信禁物 ＋ 実機検証の必要性

今回のレイアウト崩れを事前に防げなかった理由。それは、スマートフォンでの表示を実機検証していなかった、これに尽きるのです。

うーん、凡ミスやね。

そうはいっても、記事を投稿する前に、毎回スマートフォンでどのように表示されるのかというチェックについては、『Google Chrome Developer Tools』や『Blisk browser』で確認していました。（実際、レイアウト崩れをやらかしているので、弁解の余地ナシですが）

とどのつまり、スマートフォン版サイトを、PCでエミュレーションして確認していたわけです。しかしながら、HTMLレンダリングエンジンの差異や、スマートフォン実機でのみ生じる特殊な挙動、これらをチェックしきれていなかったというわけなのです。

このような作業のフローにおいて、ついついスマートフォンでの表示確認を怠り、PC側でやってしまいたくなるのです。

その理由は至極単純で、エミュレーションである程度確認できてしまうことと、スマートフォンでの実機検証が億劫だから。

ただ、今回のレイアウト崩れの一件で、やはりエミュレーションばかりに頼らず、要所要所でスマートフォン実機での確認が必須であるということを、改めて実感しました。

最初のころは入念にチェックしてたんだけど…ね。

変に慣れているからこそ生じるミス、というわけですね。

iPhoneとGoogle Pixelはリファレンス機として必須

このブログは『デベロッパーブログ』…ではなく、『ガジェットブログ』なので、最後にガジェット的なネタに絡めて話すと、やはり『iPhone』と『Google Pixel』という2つのデバイスは、リファレンス機として絶対に必要なのです。

いくら、PC上でのエミュレーションが便利とはいっても、スマートフォン固有の問題やバグがある時点で、やはり実機検証というのは必須。加えて、タッチインターフェースでのスムーススクロール等のUI/UX確認というのも必要になってきます。

理想は、全部のデバイスにおいて実機検証をすべき、ということなのかもしれません。ですが、そうなってくると膨大な予算も必要ですし、作業効率も悪く、そしてキリがない。

したがって、メジャーなスマートフォンOSである、『iOS（iPadOS）』と『Android』のリファレンス機である、『iPhone』と『Google Pixel』については、少なからず持っておくべきだという結論に至るわけです。

ま、iOS/iPadOSについては、選択肢が『iPhone』と『iPad』しか存在しないから（＝ 純正しかないから）、ここは気にしなくてもいいのであーる。

反対に、Androidスマートフォンは選択肢が豊富だから、Google純正の『Pixel』を持つべきってなるわけやね？

うぬ。そういうことですな！

iPhone 13 mini (256GB)

Apple(アップル)

• Amazonで探す
• 楽天市場で探す
• Yahoo!ショッピングで探す
• Apple Store（Amazon）

まとめ「iPhoneとPixelで要実機検証」

「スマートフォンサイトのレイアウト崩れの確認は、『iPhone』と『Google Pixel』で実機検証しておこう」…に尽きるのです。（再度の自戒）

そうそう、レイアウト崩れ修正済みの記事については、Twitterのこのツリーにぶら下げておきます。なので、併せて確認してくださると幸いです。

基本だよ、ワトソン君。初歩だよ初歩。

この記事で紹介したガジェット

• Apple｜iPhone 13
• Google｜Google Pixel 6

おまけ

アイキャッチに合わせて『踊る大捜査線』ネタにしようと思ったけど、普通になってしまったのであーる。

観たことあるのでして？

うぬ、ない！！

だめだこりゃ。

で、暗転して次のコントにいくわけですな！？

いや、それはドリフやから。（そっちは観たことあるのね……）

おわり

^*1Google Chrome Developer Tools：Google Chromeに搭載されているデベロッパーツール↩
^*2Blisk browser：開発者向けのWebブラウザ↩