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

レイアウト崩れはエミュで起きてるんじゃない!スマホで起きてるんだ!(自戒)
サイト内の外部リンクはアフィリエイト広告を含む場合があります(詳細はプライバシーポリシーを参照)
記事のポイント
  • エミュじゃ気づかないレイアウト崩れがある!
  • スマホでも実機検証は本当に重要なのである!
  • iPhoneとPixelをリファレンス機として持つべき!

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

スマホ表示でのレイアウト崩れに気づかないという、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は便利なので、気持ちは分かりますが)

二条ねこ

…うーむ。

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

HTML5とCSS3

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

さたえり

うーん、凡ミスやね。

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

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

PCでコーディング → PCで確認(エミュ含む) → スマートフォン実機で確認

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

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

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

二条ねこ

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

まの

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

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

iPhoneドット絵

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

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

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

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

二条ねこ

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

さたえり

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

二条ねこ

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

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

総括画像

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

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

二条ねこ

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

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

おまけ

二条ねこ

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

まの

観たことあるのでして?

二条ねこ

うぬ、ない!!

さたえり

だめだこりゃ。

二条ねこ

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

さたえり

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

おわり


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