2020-03-26

safe-area-insets が本当に使われているとは思えない

Webの仕様はいろんな議論の末にできるものではあるけれど、ある種の企業の都合が発生する場合はそうではない。例えばノッチがついたデバイスがリリースされることが決まった場合、ノッチをどうWebの仕様で盛り込むか?と考えた時、企業の都合 (iPhone Xのリリース日までにはどうにかしたいとか) が多々発生するし、そういうことに依存した仕様ってのは実装も含めて適当なことがたまにある。

ノッチ部分を除いた表示エリアを定義できるsafe-area-insetsというものがCSS Environment Variables Module Level 1で定義されてるのだが、これについてWebKit Blogで、Designing Websites for iPhone Xで解説されている。ようはノッチが含まれないエリアをマージンなどで指定すれば、ノッチのエリアにコンテンツが配置されないようにできる機能。

これがBlinkでの実装がどうなるかというと、フルスクリーン表示のみこのsafe-area-insetsが適用される模様で、WebKitのようにデバイスを回転した場合にちゃんと適用されるわけではない模様。動作をテストする限り、彼らはこれはフルスクリーンでのみ適用するような実装をしてしまってる。

また、Android特有の話にはなるのだけど、フルスクリーン表示をしようとして、 System UI visibilityを変更しようとしても、ちゃんと色々考慮しないとデバイスによってはちゃんとステータスバーが簡単に消えないものがあったりする。Blinkは、もしこのステータスバーが消えてなかったとしても、safe-area-insetsが適用してしまうようで、WebKit Blogのようなサイトを作ったとしても、ノッチとは関係ない変な空白ができてしまうことになる。(OPPO A5とGalaxy S10でテストした限り、間抜けな感じになる。これらでテストする限り、ステータスバーが消えない)

だからこのsafe-area-instes、これがマトモに使われてるとは思えない。無駄な空白が空いてしまうし、フルスクリーンではない時に逆にノッチ領域を除外できないし。一番使われているであろうWebブラウザでね。

それよりも当然バグとして報告はしてあるんだけど、バグと認めさせる (=というよりも、まずフルスクリーンの時にステータスバーが消えてないのがまず大きな問題の一つ) のは面倒ではあったけど、おそらくすぐ直るとは思ってないから、この動作大丈夫なのと本当に思ってる。

なお、Firefox Previewはviewport-fit値はまだ見てないけど、Firefox Preview NightlyであればWebKit Blogのサンプルはちゃんと動作するはず。