しかし、セキュリティ業界ではとっくの昔に、パスワードを定期的に変更するべきでないというのが「常識」になっている。件の総務省のページでも、2017年に米国国立標準技術研究所(NIST)や日本の内閣サイバーセキュリティセンター(NISC)から、パスワードを定期的に変更すべきでないという旨が示されたと指摘されている。
そもそもパスワードというものは、他人に推測されてはいけない一方で、本人が忘れてもいけない。そのような矛盾する条件を満たすパスワードを考え出すのも覚えておくのも、ユーザーにとって負担が大きい。加えて、1つのパスワードを複数のシステムで使い回すのは極めて危険なので、システムごとに異なるパスワードを使わなければならない。ましてそれを定期的に変更しろなどと言われたら、普通の人は、覚えやすいが他人に推測されやすいパスワードを使うか、パスワードを紙に書く。どちらにせよ、かえって安全性が損なわれる。
もちろん、サーバーが攻撃を受けたりしてパスワードが漏れた可能性がある場合は、速やかにパスワードを変えなければならない。しかし、何もないのに定期的にパスワードの変更を要求することは、害のほうが大きい。推測されにくいが覚えやすいパスワードを1度だけ考えて、それをずっと使うのがよい。
その2に続く。
機械翻訳に限らず、人工知能が人間の仕事を奪うのではないかという議論がよくある。機械翻訳についての私の考えでは、品質度外視のボランティアおよびそれに毛の生えたような翻訳は機械にとってかわられるとしても、プロの翻訳家の仕事がなくなることはないだろう。ただし、仕事の内容が変わる(あるいは変える)ことは避けられないだろう。
もちろん、自動車の自動運転でレベル4にあたるような、限定された領域での完全な自動翻訳では、人工知能が人間の翻訳者にとってかわることになる。その場合は翻訳家の仕事はなくなるが、それを実現できるのは、その領域で過去の翻訳が膨大に蓄積されている場合に限られる。
今の人工知能のアルゴリズムでは、領域が少しでもずれてしまうと、とたんにうまくゆかなくなるようだ。たとえば Google の画像認識では、黒人の写真に「ゴリラ」というタグがつけられてしまうという問題がある。これが話題になったのは 2015 年だが、いまだに解決できておらず、現在は「ゴリラ」というタグを削除している。
想像するに、白人の顔に最適化されたシステムでは黒人の顔をうまく認識できず、さりとて白人と黒人の両方に最適化されたシステムを作ることはまだできないということなのだろう。翻訳でいえば、特定のソフトウェアメーカーの製品に最適化された自動翻訳システムを作ることができても、それを別のメーカーの製品に使えるとは限らないということになる。
したがって、新しいメーカーや新しい製品に関する翻訳では、引き続き人手による翻訳が必須となる。ただし、その人力翻訳はますます機械翻訳で支援されるようになるだろう。現在広く行われている機械翻訳+ポストエディットも機械翻訳により支援された人力翻訳であるし、より効率的なシステムが将来できるかもしれない(私は翻訳者として、そういうものがほしいとつねづね思っている)。
ニューラル機械翻訳が登場する前は、欧米語同士の翻訳はともかく、たとえば英日翻訳では、機械翻訳の品質が低すぎて、人力翻訳を機械翻訳で支援しようとしても生産性は全く上がらず、むしろ下がるくらいだったが、ニューラル機械翻訳によって英日翻訳でも機械翻訳が翻訳支援として役立つレベルになった。
しかし、機械翻訳によって翻訳者の処理能力が向上すると、分量当たりの単価は低下する。機械翻訳の支援を利用しない翻訳者にとっては、単価の低下は単純に収入の減少を意味する。そのような翻訳者は生き残ることができないだろう。逆に、クライアントからすれば、分量当たりの単価が下がるのは大歓迎だ。しかし、あまり単価が下がりすぎて、翻訳者の時間当たりの収入が下がるようでは、優秀な翻訳者が仕事を断るから、訳文の品質が低下する。
これはよく考えれば当たり前のことで、機械翻訳を使っても翻訳をするのは人間だから、対価をケチればそれなりの品質しか得られない。そのため、クライアントがある程度の品質を求めるなら、単価はある程度の水準に落ち着くだろう。その水準は、翻訳者にとって時間当たりの単価がいままでと変わらないような水準であるに違いない。
もっとも、現実には、多くの場合クライアント(正確にはソースクライアント、つまり発注者)は訳文を読めないから訳文の品質を判断できず、いきおい単価が安ければ安いほどよいとなりがちだ。ただし、これは機械翻訳とは別の問題で、翻訳一般に対価は(品質も)下がる傾向にある。この方が翻訳業界にとって機械翻訳よりも大きな問題だろう。
自動車の自動運転には、いくつかのレベルがある。現在、公道を走る自動車ではレベル2(部分的な自動運転)までが実用化されており、2018 年にレベル3(特定の条件下での自動運転)を実現した自動車が販売されるという。レベル3までは、人間のドライバーが運転の責任を持つ。機械で対応できるうちは機械が人間の代わりに運転してくれるが、人間は常に運転状況を監視して、機械で対応できなくなったらすぐに運転を換わらなければならない。言ってみれば、機械は人間の運転を支援するにとどまる。
レベル4になると、特定の条件下で機械が運転の責任を持つ。人間は何もしない。現状では、鉱山などのような極めて限定された状況に対応できるシステムが実用化されている。レベル5は完全な自動運転であり、あらゆる条件下で機械が運転する。この実現はだいぶ先になるだろう。
さて、この自動運転のレベルを翻訳に当てはめてみよう。現在多くの翻訳者が使っている翻訳支援ツール(CAT ツール)も、一種の自動翻訳をする。具体的には、入力された原文に対して過去の翻訳のデータベースを検索し、完全に一致する原文があったら、それに対応する訳文を出力する。しかし、原文が文レベルで同一であっても異なる文脈では別に訳さなければならない場合があるので、本来は機械が出力した訳文を人間の翻訳者が逐一チェックしなければならない。原文が同一という条件があることも考え合わせれば、CAT ツールを使用した翻訳はレベル3に相当すると言えるだろう。
実際の翻訳の現場では、原文が過去の原文と完全に一致している場合に、人間の翻訳者が全く作業しないことがある。だからといってレベル4が実現されているとは言えない。人間の作業を省略するのは、訳文が多少不自然になることがあってもかまわないからコストを削減しようということだ。一方、自動車の運転では、不自然な運転は命にかかわる。不自然な運転でもよいからドライバーの負担を軽減しようというのでは、実用化されたとはいえない。
ニューラルネットワーク翻訳を含めたいわゆる自動翻訳でも、現状では訳文の品質が保証されないので、業務としての翻訳では機械に翻訳を任せることはない。機械が訳した訳文を人間の翻訳者が直している。この修正作業を「ポストエディット」と呼ぶ。これにより品質が保証されるが、訳文に責任を持つのは翻訳者だから、自動運転のレベルで言えばやはりレベル3になる。
とはいえ、ニューラルネットワークを使った場合、分野を限定すれば十分な量のデータを集めて十分な学習をさせることができ、人間が何もしなくても済むような品質が得られる場合がある。たとえば Microsoft のサポートサイトでは、以前から人間が翻訳したページと機械が翻訳したページが混在していたが、Microsoft がニューラル機械翻訳を採用した後で機械翻訳されたページは、人間が訳したページとほとんど遜色がない。Microsoft の製品のサポートという限定された分野ではあるが、人間の介入を必要としないという点で、レベル4の自動翻訳が実現されていると言ってよいだろう。
では、レベル5の自動翻訳、すなわちあらゆる分野に対応できる汎用翻訳エンジンはできるだろうか。これまで述べてきたように、不可能とは言わないとしても、極めて難しい。Google 翻訳などは汎用翻訳エンジンを目指しているのかもしれないが、現状の品質は、自動運転で言えばあちこちで交通事故が起こるようなレベルだ。機械翻訳の訳文をそのまま使える場面は、自分が理解できない言語の文章があって、大まかでもよいから意味を知りたいというときに限られる。自分が書いた文章を他言語話者に読んでもらうためには使えない。
その5に続く。
もう何年も前から、すべてのウェブサイトは「常時 SSL 化」すべしと言われている。SSL とはデータを暗号化して通信するプロトコルであり、常時 SSL とは、ウェブサイトの全てを暗号化することだ。実際のところ、SSL には脆弱性が見つかっていて、今では TSL が使われているのだが、それでもウェブの暗号化通信を「SSL」と言うことが多い。
従来は、ユーザーが情報を入力して送信する画面のみ暗号化することが多かったが、ウェブサイトに対する攻撃が巧妙になり、それでは安全が確保できなくなった。Google は、常時 SSL 化を促進するため、常時 SSL 化されていないウェブサイトのランクを下げているし、Chrome で暗号化されていないページにデータを入力しようとすると警告を出すようになった。
かつては、SSL の導入には少なからぬ費用がかかったので、個人のウェブサイトを SSL 化するのは敷居が高かった。しかし、昨年から Let's Encrypt が無料で SSL の提供を始め、SSL 化しない理由がなくなった。
私はウェブサーバーを引越ししたいと考えていて(メールサーバーはすでに FastMail に引っ越した)、そのタイミングで SSL 化しようと思っていたが、引越しのスケジュールが延び延びになっていた。そんな折り、現在使っている Lolipop では数回のクリックだけで Let's Encrypt による SSL 化ができることに気がついて、勢いで設定した。常時 SSL 化のためには、サイト自体の暗号化に加えて、HTTP へのアクセスを HTTPS へリダイレクトする設定が必要だが、これはそれほど難しくない。
しかし、画像の読み込みなどで参照先の URL を変更する必要がある。これはなかなか骨が折れるが、いずれにせよサーバーを引っ越すためにすべてのデータを変換する必要があるので、それに合わせて変更することにする。
まだ五十音の全てをカバーできていないので、今後問題の数を増やすつもりだが、ひとまず人様に見せられる段階になったと思うので、公開する。小さい子供がいる親御さんに活用していただけたらと思う。
「た」は古くは「たり」であり、「たり」は「てあり」の約だとされる。そして、「てあり」は「つ」と「あり」が繋がったものだとされる。「つ」は完了を表す。したがって、「た」の元々の意味は「動作が完了した状態がある」ということだ。「た」の本義は過去ではなく完了であり、だからこそ未来の出来事にも「た」を使える。
一方、英語の過去形も、必ずしも過去の出来事を表すとは限らない。仮定法("If I were you, ..." など)や婉曲表現("I would like to ..." など)でも過去形を使う。英語の過去形は、発話状況から隔たりがあることを示す。過去の出来事が現在から切り離されている場合は過去形を使うが、過去の出来事の影響が現在までおよんでいたら現在完了形を使う。過去の出来事に過去形を使うと、現在からの隔たりが表現される。現在の出来事に過去形を使えば、それが事実と異なることが含意される。これが仮定法だ。また、自分の要望を過去形で言えば、間接的でかしこまった表現になる。
日本語の「た」は完了を表し、英語の過去形は隔たりを表す。両者は元来別物なのだが、過去の出来事を言い表す場合、たまたま日本語では「た」を用い(かつては「き」や「けり」で過去を表したが、今は使われない)、たまたま英語では過去形を用いる。そのため、日本語の「た」と英語の過去形が同じ意味だと思い込んでしまうのかもしれないが、「た」を訳したらいつでも過去形になるわけではないし、その逆も然り。日本語の「た」と英語の過去形は、用法が似ているというだけで、同じ意味ではない。
const e = process.argv[2] || 1;
const l = process.argv[3] || 0;
const size = 200
const pi = Math.PI;
const yoko = e > 1;
const h = yoko ? size / e : size
var x, y, deg, rad;
var coods = `${-l} ${h}\n`;
for ( deg = 90; deg >= -90; deg -= 6 ) {
rad = deg * pi / 180;
x = Math.cos(rad) * size;
y = Math.sin(rad) * size;
yoko ? y /= e : x *= e;
coods += `${x} ${y}\n`;
}
coods += `${-l} ${-h}\n`;
require('fs').writeFileSync('daen.polyline', coods);
引数を1つ増やした。第2の引数は「折り返し」の長さ。
ワークショップで使う展開図は、
node daen.js 0.75 100
として生成した座標ファイルを基にしている。ORI-REVO の画面は以下の通り。
ORI-REVO で楕円の半分を描いてやれば折り方を計算してくれるわけだが、手で入力するのは難しい。ORI-REVO では点列データを読み込むことができるので、点列データを生成するスクリプトを書くことにした。
楕円上の点の座標は、θを媒介変数として、
x = a cosθ
y = b cosθ
と書ける(a と b は 0 より大きい定数)。ORI-REVO に入力する場合、θの範囲は 90°から -90°まで、a と b のうち大きい方の値を 200 とする。a/b の値を e として、変数として与えられるようにしたい。e が 1 なら球、1 より小さいと縦長、1 より大きいと横長になる。
以上でスクプリトが書ける。私はここのところ node.js をいじっているので、node のスクリプトを書いてみた(エラー処理は省略)。
var e = process.argv[2] || 1;
var x, y, deg, rad;
var coods = '';
const pi = Math.PI;
const yoko = e > 1;
for ( deg = 90; deg >= -90; deg -= 6 ) {
rad = deg * pi / 180;
x = Math.cos(rad) * 200;
y = Math.sin(rad) * 200;
yoko ? y /= e : x *= e;
coods += (x + ' ' + y + '\n');
}
require('fs').writeFileSync('daen.polyline', coods);
これを daen.js
という名前で保存しておいて、コマンドラインから
node daen.js 0.75
とかすると、daen.polyline
ファイルが生成される。それを ORI-REVO で開けば、以下のようになる。
その2へ続く
This Wood Pavilion is Supported Entirely Through Origami Folds
木製のパネルをヒンジでつなぐだけで、自然に形ができるとのこと。
この小柄(こづか)は、豊臣秀吉に仕えた金工である後藤栄乗(1577-1617)の作と鑑定されている。したがって、1590年代に作られたことになる。これ以前に知られていた遊戯折り紙の史料は、1699年の雛形本や井原西鶴の好色一代男(1682年)が最も古かったから、遊戯折り紙の歴史がほぼ1世紀遡った。(平安時代に折り紙があったという説には根拠がない。)
後藤家は代々将軍家に仕えた装剣金工であり、この小柄も武家社会から出たものだ。従来、遊戯折り紙の起源は武家の礼法折り紙だっただろうと考えられてきたが、この小柄によって、礼法折り紙が町人に広がるより前に武家社会の中で遊戯折り紙が発生したことが確実になった。
さらに、この折り紙が松とともに彫られていることで、桃山時代にはすでにこれが鶴に見立てられていたことがわかる。
しかし、この小柄をよく見ると、いくつかの疑問がわく。横から見た折り鶴のデッサンが崩れているように見えるのはなぜか、栄乗は同じ図柄を何度も彫ることが多いのに、折り紙を彫ったものが1点しかないのはなぜか、そもそもなぜ鶴ではなく折り鶴なのか。
これらについて、折紙学会の顧問である岡村昌夫さんが見事な謎解きをしている。詳しくは、記事をお読みいただくか、コンベンションに参加していただきたい。マガジンはばら売りをしていないので、1期購読していただく必要があるが、折紙学会の図書館で読むこともできる。
まとめ。
まず、ウェブページの一部または全部でコンテンツの幅が固定されている場合(パソコン向けに 800px とか 1024px とか、あるいはモバイル向けに 320px とか)、2通りの指定がある。
幅が固定されているコンテンツが画面にぴったり収まるよう拡大または縮小して表示する場合、meta
タグの記述は、例えばコンテンツの幅を 800 ピクセルとしたとき、
<meta name="viewport" content="width=800">
となる。この場合、ウェブページは幅 800 ピクセルの viewport 上にレイアウトされ、画面の幅が 800 ピクセルより広ければ拡大して、画面の幅が狭ければ縮小して表示される。拡大縮小の比率はデバイスに依存するから、HTML では指定しない。すなわち、initial-scale
は指定しない。
一方、拡大縮小をせず等倍で表示する場合、次のように指定する。
<meta name="viewport" content="width=device-width,initial-scale=1,shrink-to-fit=no">
ただし、initial-scale=1
がなくてもよい。この場合、画面の幅がコンテンツの幅より広ければ、左右に余白ができる。逆に画面の幅が狭ければ、収まらない部分が画面の右にはみ出る。それをユーザーが見るには、横スクロールする必要がある。
次に、コンテンツの幅を固定せず、画面の幅に合わせて変化させる場合(つまりレスポンシブな場合)、viewport の幅を画面の幅と同じにする。そのための指定は次の通り。
<meta name="viewport" content="width=device-width,initial-scale=1">
この場合でも、initial-scale=1
はなくてもよい。
いずれの場合でも、minimum-scale
、maximum-scale
、user-scalable
は指定しない。これらの指定はユーザビリティを損ねる。
initial-scale
も原則として指定しないが、width=device-width
と指定したときに限り、initial-scale=1
をあわせて指定してもよい(initial-scale=1.0
でもよい)。
これまで長々と説明してきたが、まとめの前に、他によく使われる(しかし通常は使うべきでない)指定について見ておきたい。
まず、minimum-scale
、maximum-scale
、user-scalable
について。これらは、ほとんどすべての場合、ユーザーがウェブページをズームできないようにするために指定する。が、すべてのウェブページはユーザーがズームできるべきだ。したがって、ほとんどすべての場合、これらの指定はするべきでない。
するべきでない指定をする人が多いものだから、Safari はバージョン 10.0 から maximum-scale=1
や user-scalable=no
の指定を無視するようになった。繰り返す。ほとんどすべての場合、minimum-scale
、maximum-scale
、user-scalable
は指定しない。
比較的最近導入された属性に shrink-to-fit
がある。Apple の説明によれば、width=device-width
が指定してあるウェブページで、iPad で画面を2分割したときコンテンツが viewport からはみ出した場合に、デフォルトではコンテンツが収まるように viewport が広くなり、縮小して画面に表示されるが、shrink-to-fit=no
と指定すれば viewport の幅もスケールも変わらず、viewport からはみ出た部分は画面からもはみ出る。
しかし、width=device-width
と指定するならば、viewport の幅がいくつになるかわからないのだから、viewport からはみ出る部分がないようにデザインするべきだ。viewport の幅が狭いときにコンテンツが viewport からはみ出すとしたら、そもそもウェブページの作りが悪い可能性が高い。もし shrink-to-fit=no
と指定したくなったら、その前に width=device-width
の指定が適切かどうか検討した方がよい。width=device-width
と指定したウェブページが適切にデザインされていれば、viewport の幅が狭くなるとコンテンツ領域の幅もそれに応じて狭くなり、コンテンツがはみ出ることはないはずだ。
しかし、viewport が狭いときに、意図的にコンテンツを viewport の外にはみ出させることがあるかもしれない。その場合、viewport からはみ出た部分が画面からもはみ出るのが正しい挙動だ。それならどうして、Safari はコンテンツを画面に収めるように動作することがあるのだろうか。Safari の開発者によれば、それは多数の人が width=device-width
や initial-scale=1
を正しく使用していないからだ。
コンテンツの一部または全部の幅がたとえば 800px で固定されており、画面の幅がそれより狭いとき、ほとんどの人はコンテンツを縮小して画面に収めたいと思うだろう。そのときの適切な viewport の設定は、既に述べたように width=800
だ。width=device-width
(または initial-scale=1
)とすると、画面の幅に収まらない部分が右にはみ出る。本当にそのような表示を意図しているなら、iPad の Split View モードでも右にはみ出させるために width=device-width,initial-scale=1,shrink-to-fit=no
と指定する。
その6に続く。
以上をまとめると、コンテンツ領域の幅が固定されているウェブページでは width=(コンテンツ領域の幅)
と指定する。initial-scale
は指定しない。
これは、モバイル向けにデザインされたウェブページでも同じだ。たとえばコンテンツ領域の幅が 320 ピクセルで固定されている場合、width=320
とする。繰り返すが、initial-scale
は指定しない。この場合、画面の幅が 320 ピクセルよりも広いデバイスでは、画面に合わせて表示が拡大される。
では、width=320,initial-scale=1
と指定したらどうなるだろうか。画面の幅が 320 ピクセルよりも大きい場合、すでに述べたように width
の指定が無視されるから、これは実際のところ initial-scale=1
と指定していることになる。したがって、viewport の幅が画面の幅と同じになり、そこに幅 320 ピクセルのコンテンツをレイアウトするから、デバイスによっては左右に余白ができる。
もっとも、拡大されるより余白ができたほうがよいという考えもあるだろう。それでも width=320,initial-scale=1
はまちがい。拡大を避ける正しい方法は、initial-scale=1
と指定するのが1つ。または width=device-width
とする。これは、文字通り、viewport の幅を画面の幅と同じにするという意味だ。
しかし、モバイル向けページでコンテンツ領域の幅を固定するというのは、いまどき流行らない。たとえば、デバイスを横向きに回転させれば幅が広くなるが、そのときに拡大されたり余白ができたりするのは格好悪い。少なくともモバイル向けのウェブページでは、画面の幅に合わせてレイアウトを動的に変化させたほうがよい。
その場合でも、viewport の幅を画面の幅と同じにすることになる。そのための指定は、先ほどと同様、width=device-width
または initial-scale=1
だ。ところが、一般には、両者を合わせて
<meta name="viewport" content="width=device-width,initial-scale=1">
と指定することが多い。だが、width
と initial-scale
の両方を指定するのは避けるべきではなかったか。どちらか片方だけにするべきではないのか。
width=device-width
と指定した場合に、initial-scale
を 1(あるいは 1.0)以外の値にするのは、確かに不適切だ。
まず、initial-scale
の値が 1 より小さい場合、width
の値と initial-scale
の値との積は、常に画面の幅より小さくなる。ということは、width=device-width
の指定は常に無視される。常に無視される指定をわざわざ書くのは無意味だ。
また、initial-scale
の値が 1 より大きい場合、せっかく画面と同じ幅の viewport にレイアウトしたウェブページを拡大して表示することになるから、ページの右側が画面の外に出る。それを見るためには横にスクロールしなければならない。わざわざそんな表示にする理由はないはずだ。
しかし width=device-width,initial-scale=1
なら、同じ意味の指定を2度書いたまでで、とりわけて問題はない。同じことを繰り返すのは、冗長ではあるが、まちがいではない。古いバージョンの Safari では、デバイスを横向きにしたときに viewport が広がるのではなくスケールが大きくなり、拡大されて表示されるという問題があったが、それは3年前の話で、もう考慮しなくてもよいだろう。
なお、Windows Phone 版の IE は initial-scale
をサポートしていないそうだ。そのため、強いてどちらか片方だけを指定するなら、width=device-width
を指定したほうがよいだろう。
その5に続く。
width
をピクセル数で指定したときに initial-scale
を指定するべきでない理由がもう1つある。
たとえば width=250,initial-scale=1
と指定してみよう。これまで述べてきた方式を適用すれば、幅 250 ピクセルの viewport に合わせてウェブページがレイアウトされて、それが等倍で表示されるから、デバイスの左 250 ピクセル分だけにウェブページが表示され、右端は空白になることになる。あるいは width=500,initial-scale=0.5
と指定した場合、幅 500 ピクセルの viewport に合わせてウェブページがレイアウトされて、それが 50% 縮小されて表示されるから、やはりデバイスの左 250 ピクセル分だけにウェブページが表示され、右端は空白になる、のだろうか。
実際には、そうならない。ただでさえ狭いモバイルデバイスの画面で、右端を空白にするというのはもったいない話だ。こういう場合、すなわち width
の値と initial-scale
の値との積が画面の幅より小さい場合、width
の指定が無視される。無視されるかどうかは、画面の幅に依存するから、ユーザーが使っているデバイスに依存する。そのため、width
と initial-scale
の両方を指定した場合、デバイスによって、意図した表示になるかもしれないし、ならないかもしれない。width=1000,initial-scale=1
という指定でも、タブレットを横向きに使っていれば、width
が無視されるかもしれない。
一方、initial-scale
を指定しなければ、ほとんどの場合に width
の指定が有効になる。「ほとんどの場合に」と書いたのは、スケールにはデフォルトで最大値と最小値が設定されており、そのため指定できる width
の値にもデバイスに依存した最大値と最小値ができるからだ。最大値より大きければ最大値を指定した場合と同じになるし、最小値より小さければ最小値を指定した場合と同じになる。ただし、よほど極端な指定をしなければ、範囲を外れることはない。width=100
とか width=2000
とか指定することはないだろう。
では、width
の指定が無視された場合、あるいはそもそも width
を指定せず initial-scale
のみを指定した場合、viewport の幅はどうなるのだろうか。
このような場合、viewport の幅は画面の幅を initial-scale
の値で割った値になる。たとえば initial-scale=1
なら、viewport の幅は画面の幅と同じになる。initial-scale=0.5
なら viewport の幅は画面の幅の2倍、initial-scale=2
なら viewport の幅は画面の幅の半分になる。いずれの場合でも、viewport を initial-scale
の値で拡大縮小すれば、画面の幅にぴったり合う。
したがって、width=250,initial-scale=1
という指定は initial-scale=1
という指定と同等であり、viewport の幅はデバイスの画面の幅と同じ(iPhone 7 であれば 375 ピクセル)になる。同様に、width=500,initial-scale=0.5
という指定は initial-scale=0.5
という指定と同等であり、viewport の幅はデバイスの画面の幅の2倍(iPhone 7 であれば 750 ピクセル)になる。
その4に続く
では、viewport のデフォルト値を変えたいときはどうするのか。ここで meta
タグの出番だ。HTML で <meta name="viewport" content="...">
と記述することで、viewport のさまざまな属性を設定できる。
前述のとおり、パソコン向けにデザインされたウェブページは、デフォルトで、つまり meta
タグがなくても、モバイルデバイスでそれなりに表示される。しかし、コンテンツを表示する領域の幅を 800 ピクセルとか 1024 ピクセルとか特定の値にしている場合、モバイルデバイスでの表示が残念なことになる。
コンテンツ領域の幅が 1024 ピクセルに設定されているウェブページがあるとする。これを iPhone 上の Safari で表示すると、まず 980 ピクセル幅の viewport に合わせてレイアウトされるので、ページの右端 44 ピクセル分が viewport の外にはみ出てしまう。その状態で縮小されて画面に表示されるから、右端のコンテンツが画面の外にはみ出る。そのコンテンツを見るには、横にスクロールしなければならない。この場合、width=1024
として viewport の幅を 1024 ピクセルに広げてやれば、スケールは小さくなる(縮小率が大きくなる)が、横スクロールの必要がなくなる。
逆に、コンテンツ領域の幅が 800 ピクセルで固定されているウェブページでは、viewport に合わせてレイアウトされた時点で左右に合計 180 ピクセルの余白ができる。それを縮小するから、画面でもやはり余白がある。この場合、width=800
として viewport の幅を狭くすれば、余白がなくなると同時にスケールを大きくできる。
つまり、コンテンツ領域の幅が固定されているウェブページでは、以下のようにして viewport の幅を指定する。
<meta name="viewport" content="width=(コンテンツ領域の幅)">
注意点が2点ある。まず、幅の単位はピクセルだが、単位は書かない。width=1000px
はまちがい。
次に、width
をピクセル数で指定する場合、initial-scale
は指定しない。width=1000,initial-scale=1
はまちがい。いや、まちがいではないけれど、意図した表示にはならないはずだ。
そもそも initial-scale
とは何か。すでに述べたように、モバイルブラウザーは viewport 上にレイアウトしたウェブページを拡大縮小して画面に表示する。そのときのスケールの初期値、つまりスケールが設定されていないときに使用される値が initial-scale
の値だ。
width
をピクセル数で指定する場合、たいていはコンテンツ領域の幅を画面の幅に合わせたいと思っているだろう。viewport の幅をコンテンツ領域の幅と等しく設定していれば、必要なスケールの値は、画面の幅を viewport の幅で割ることで求められる。たとえばコンテンツ領域の幅が 1000 ピクセルで width=1000
と指定した場合、iPhone 7 なら画面の幅が 375 ピクセルだから、スケールが 0.375 のとき画面の幅に過不足なく表示される。ところが、iPhone 7 Plus なら、画面の幅が 414 ピクセルだから適切なスケールは 0.414 だ。指定するべき initial-scale
の値は、デバイスごとに異なる。したがって、HTML で指定してはいけない。width
だけ指定すれば、その値と画面の幅から、適切なスケールの値をブラウザーが計算してくれる。
では、width=1000,initial-scale=1
と指定したら、どう表示されるだろうか。ウェブページが幅 1000 ピクセルの viewport 上にレイアウトされて、等倍で画面に表示される。ということは、iPhone 7 であればページの左 375 ピクセルだけが見えていて、それより右のコンテンツを見るには横にスクロールしなければならない。これは意図した表示ではないだろう。
その3に続く。