viewport の理解が難しいのは viewport が実は多義語だから説
<meta name="viewport">
で言ってる viewport って結局なんなんだって話です。
viewport の解説記事は世に数あれど、どれを読んでもすぐに理解が揮発してしまう病に悩まされていたのですが、最近になってその原因が viewport の多義性にあったんじゃないかと思い当たりました。実は多義語である viewport に関する色々な言及を方々で目にするうちに、viewport って結局なんだったんだっけ……?になりがちなんじゃないかと。
そこで本稿では異なる意味の viewport をきちんと呼び分けながら <meta name="viewport">
の典型的な挙動を再確認することを試みます。
viewport とは
さて、巷では viewport という語は少なくとも次の 4 つの意味で使われているようです:
- layout viewport の略称
- visual viewport の略称
- https://www.quirksmode.org/mobile/metaviewport/ が言うところの ideal viewport。つまり、
initial-scale=1
の下でのページロード直後の visual viewport。 - (2, 3 から派生して?) モバイル端末の物理的な画面領域のこと (参考)
<meta name="viewport">
が言う viewport はまさに layout viewport のことですが、<meta name="viewport">
の設定がブラウザ*1のレンダリングにどう影響するのかを語るためには layout viewport と visual viewport (と、本当は ideal viewport) に触れなければなりません。
<meta name="viewport">
とレンダリング
以下、initial-scale=1
を仮定します。通常 initial-scale
は 1 であるべき*2ですし、1 以外のケースを想定すると話がとてもややこしくなるので。また、ページロード直後についてのみ考えます。言い換えると、ズームについて考慮しません。理由は同上。 <meta name="viewport">
を自身で設定するに際しての理解としては、この仮定の下でも問題ないはずです。
まず、html, CSS, JS は layout viewport をこの宇宙の大きさだと思って動き、layout viewport に文書を"レンダリング"します。もちろんこれは比喩ですが、つまり例えば <meta name="viewport" content="width=300">
によって layout viewport の width を 300px と定めたならば、CSS での 100vw は 300px を意味しますし、media query から見た screen width はいつでも 300px ですし、 JS の window.innerWidth の値も 300 です*3 。
次に、そうして"レンダリング"を終えた layout viewport を実際にブラウザの表示領域、すなわち visual viewport に"投影"します。visual viewport は端末と環境に固有の大きさ*4*5を持ちます。もし layout viewport と visual viewport の大きさが異なるならば、”投影”時にブラウザは layout viewport を拡大縮小して visual viewport の大きさに近づけようとします*6。
device-width, device-height
ところで、<meta name="viewport">
の中ではdevice-width, device-height というキーワードが有効ですが、これがまさに visual viewport の大きさ*7です。
width=device-width
を設定すると visual viewport と layout viewport の幅が一致するので、投影時の拡大縮小が発生しませんし、media query は端末ごとに異なる値を受け取れるのでレスポンシブに設計されているサイトではその恩恵に預れます。
デモ
本稿の執筆にあたってブラウザの実際の挙動を確認するためにデモを書いたので参考までに。
https://github.com/penpenpng/viewport-demo
雑感
- viewport が多義語だから~とかじゃなくって、やっぱ viewport がそもそもムズい。どうにか簡単にまとめようとしたら仮定まみれになってしまった。
- 世の記事を読んでも理解が揮発するのは、そもそもムズい viewport をなんとか簡単に説明するために細かいところをぼんやりとごまかしているから。
- viewport まわりの話の中で出てくる長さの単位はすべて CSS Pixel だということを強く意識しておくとより理解しやすくなるなとも感じた。気が向けば CSS Pixel の話も書くかも。
参考
- https://developer.mozilla.org/en-US/docs/Glossary/Visual_Viewport
- https://developer.mozilla.org/en-US/docs/Glossary/Layout_viewport
- https://developer.mozilla.org/ja/docs/Web/CSS/Viewport_concepts
- https://developer.mozilla.org/ja/docs/Web/HTML/Viewport_meta_tag
- https://design-spice.com/2012/09/05/resolutio/
- https://qiita.com/ryounagaoka/items/045b2808a5ed43f96607
特に、以下がとても詳しいです:
*1:以後断りのない限りモバイルブラウザを指します。PC ブラウザは原則として meta タグによる viewport の設定を反映することはありません。
*2:個人の意見。そうでない場合があったら教えてください。
*3:width に設定した値が極端に小さかったり大きかったりする場合はこの限りではないようで、環境依存の値でクリップされることがあります。が、わざわざそんな値を設定することはおそらくないと信じて本稿では無視して話を進めます。
*4:厳密に言えば、端末と環境に固有の大きさを持っているのは ideal viewport の方で、visual viewport のサイズはユーザのズーム操作によって変化します。ズームすると CSS pixel の大きさが変化するからです。しかし本稿の仮定のもとでは visual viewport は固定値です。
*5:ideal viewport は iPad の Split View で表示されている場合などには変化し得ます。
*6:MDN などによると layout viewport と visual viewport の width が一致するように layout viewport を拡大縮小するそうですが、実際に実験してみると必ずしもそうではないようだったので表現を濁しています。追記: quirksmode によるとどのように拡大縮小されるかは環境に依存するようです。
*7:本稿の仮定の下で。
AHK で Ctrl の単押しを Esc にマップする (Windows)
タイトルの通り。
なんでそんなことしたいの
主に vim で使いたいので。
AutoHotKey (AHK) とは
キー押下をジャックして色々できるやつです。
典型的な用途はキーの入れ替えかと思いますが、本当に色々できるので詳しくは公式のドキュメントを読んでください。
使い方の概要
- インストールします。
.ahk
の拡張子でスクリプトを書きます。- 2 のファイルをダブルクリックして起動すると常駐ソフトが起動しあれやこれやしてくれるようになります。ショートカットを作ってスタートアップフォルダに入れておくといいでしょう。
AHK で Ctrl の単押しを Esc にマップするスクリプト
スクリプトの文法については素晴らしい記事が既にたくさんありますので省略するものとして、ここには結論だけを残しておきます。
以下のスクリプトで左 Ctrl の単押しが Esc に置き換わります。ただし Ctrl + F1
は機能しなくなるので注意。
LControl & F1::return LControl::Esc
なぜこれが動作するのかについては こちら
おまけ
無変換キー + hjkl で カーソル移動する
sc07B & h::Left sc07B & j::Down sc07B & k::Up sc07B & l::Right
無変換キー + Space で 半角/全角 キーを送信する
sc07B & Space::sc029
CapsLock を左 Ctrl にあてる
長屋クイズアリーナ4を作ろうかと思っています
告知したいことは標題で終わりです。
以下「開発運営の雑感」「なぜ NQA4 を作るのか」についてつらつら書きますが、まあただの日記ですんでお暇な方だけどうぞ。
開発運営の雑感
文中に「長屋クイズアリーナ」が頻出して鬱陶しいので以下 NQA で通しますが、みなさんは「長屋クイズ」って呼んであげてくださいね。 僕が Twitter で検索するときに困るので。全部読んでるぞ。
さて、NQAβ がいつ生まれたのかは忘れてしまった*1ので正確なところは分かりませんが、僕はかれこれ3年くらい長屋を運営してるらしいです。
3年???マジ???
3部屋動いてんのビビる pic.twitter.com/ztUim7yAFp
— ぽーまん (偽物) (@penpen_png) 2017年2月3日
うわっ、マジだ。
NQAβ の頃は友達の友達がギリ知ってる程度のツールでしたし、ご覧の通り多くて3部屋開くかどうかといったところでしたが、誰が言いふらしたのか、最近は休日には30部屋ほど開くようになりました。
加えて、NQA を会場とした企画が立ったり、バーチャルな配信者さんの配信に登場したり、NQA で使える物理ボタンが作られたりと、NQA が世に受け入れられている様を実感できる出来事も増えて開発者としては喜ぶことしきりです。 本当にありがとうございます。
今後も趣味の範囲で頑張っていきますんでよろしくお願いします。
なぜ NQA4 を作るのか
なぜ NQA3 をアップデートするのではなく NQA4 を作るのか。 その理由の大本は大きく分ければ2点です。
- 今構想中のルールを NQA3 に実装しようとすると、サーバーサイドに大きな改修が必要
- スマートフォンへの真面目な対応を考えると、クライアントサイドに大きな改修が必要
ちょっぴり技術的な話になるので噛み砕きますが、大雑把な話 NQA は2つのプログラムが協調する形で動いています。 それぞれサーバーサイドのプログラム・クライアントサイドのプログラムと呼ばれるものです。
で、今後実装したい機能のことを考えると両方とも大きく作り変える必要があります。 しかし、2つのプログラムは協調しているので、片方を修理するときにはもう片方との整合を取る必要があり、もう片方の修理に取りかかれば既に修理したはずのもう片方との整合性に気を払う必要が出てきます。 それならばいっそ作り直した方が……というのが NQA4 を作る理由です。
以前 NQA3 が完成した直後あたりに書いたエントリやらでは「使いやすくするように頑張りました」みたいなことを言ってましたが、まあ実際使ってみれば不便なところが目につくようになってきました。 作り直しついでにそのへんも改善していきたいと思っています。具体的には、
- 入室ごとに個人設定をやり直すのは不便
- メニュー項目がアイコンだけだとやっぱり分かりづらい
- チャット解答の人とボイス解答の人を簡単に区別する仕組みがほしい
- 解答時、スルー時のカウントを取りたい
- 問題数限定のカウントを取りたい
- ルール提示はゲーム開始前に任意で行いたい
- ボード採点方法が分かりづらい
- ボード正誤判定後にやんややんや言う時間がほしい
- バグを検出する手段が整っていないので対応が遅れる
とか。
しばらく特に不満が聞こえてこなかったので油断してましたが、自分で使ってると出るわ出るわといった感じです。 ユーザの不満の声って思っていたより開発者に届かないなというのが、NQA 開発を通して得た学びのひとつですね*2。
今のうちに使いづらいポイントをアピールしておくと 4 では直っているかもしれません。 でも、あんまりたくさん届くと泣いてしまうのでいじめないでください……。
NQA4 はいつ完成するのか
そんなわけで今は NQA4 の設計をやっているところですが、いつ完成するのかはまったくわかりません。 やりたいことが多い割に、学生のときほどは時間が取れませんから*3。 1年はかかるんじゃないかなと思っています。 しばらくの間 NQA3 のアップデートペースはがたんと落ちると思いますが、どうかお目溢しを……。
ところでまだ作ってもいないのにこんなこと言うのはアレですが、ナンバリングタイトルをナンバリングしない人*4の気持ちがちょっとわかってきました。 4まで続くと NQA4 って名付けるのちょっと味気ないなって思っちゃいますね。DQやFFは偉いよ。