二〇一七年 卯月 卅日 日曜日
■ 改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その１ [/links]
この記事は書かれてから1年以上経過しています。内容が古くなっている可能性があります。コメントの受付は終了しました。
もう３年近く前になるが、「たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる」という記事を書いた。その内容に大きな間違いはないのだけれど、３年前と今とでは状況が変わっているし、あらためて読み返してみると我ながらわかりにくい記事だと思った。
一方、Google で「meta viewport」と検索して上位に出てくるページを見る限り、３年たってもまだ理解していない人が多いようだ。たとえば「もう逃げない。HTMLのviewportをちゃんと理解する」は、残念ながら理解が中途半端だ。そんなわけで、改訂版を書くことにした。
しかし、わかりやすく説明しようとすると、どうしても長くなる。長くなるので分割する。技術的なことはいいから結論だけ知りたいという人は、まとめだけ読んでもかまわない。
そもそもウェブページというのは、印刷物と違って、ユーザーの環境によって見た目が変わる。特に、ブラウザーのウィンドウの幅に大きく依存する。パソコンのブラウザーで、ウィンドウの幅が 1000 ピクセルなら、ウェブページの横幅が 1000 ピクセルになるようにブラウザーがレイアウトをする。
モバイルデバイスでは、たいていの場合、ブラウザーのウィンドウの幅はデバイスの画面の幅に等しい。それなら、モバイルデバイスのブラウザーは画面の幅に合わせてウェブページをレイアウトするかというと、そうではない。モバイルブラウザーは、viewport の幅に合わせてレイアウトする。では、viewport とは何か。
先ほど「ウィンドウの幅が 1000 ピクセル」と書いたが、この「ピクセル」は物理的な画素の数ではない。最近は高精細のモニターが増えたが、CSS で 1000px と指定してあるものを 1000 個の画素で表示するなら、従来のモニターでは大きく、高精細のモニターでは小さく表示されることになる。それでは困るので、高精細のモニターでは、1000px の長さを、たとえば 2000 個の画素を使って表示する。その場合、1px が 2 画素にあたることになる。
CSS で指定する「ピクセル」（px）は、センチメートルやインチと同じような長さの単位だと考えるとよい。このような「ピクセル」を「CSS ピクセル」と言ったりする。で、ウェブデザインの文脈では、モバイルデバイスの幅も CSS ピクセルで測らなければならない。
最近のモバイルデバイスは画素数が非常に大きくなっているが、CSS ピクセルで測った幅はそれほど大きくない。たとえば iPhone 7 で 375 ピクセル、iPhone 7 Plus だと 414 ピクセルだ。パソコン向けにデザインされたウェブページを幅 375 ピクセルでレイアウトするなら、見づらくなるに決まっている。そこで viewport が登場する。
viewport というのは、ユーザーには見えない仮想的なウィンドウであって、その横幅は、デフォルトではパソコンのブラウザーの一般的なウィンドウの幅と同じ程度（iPhone 版 Safari では 980 ピクセル）に設定されている。そのため、パソコン向けにデザインされたウェブページを viewport に合わせてレイアウトすると、十分適切なレイアウトになる。
この段階では、ウェブページは viewport の上にレイアウトされている。しかし、viewport はユーザーには見えないから、レイアウトしたウェブページを画面に表示しなければならない。そのとき、ブラウザーは、viewport 上のウェブページを拡大したり縮小したりして画面に表示する。その拡大縮小の比率を、この記事では「スケール」と呼ぶことにする。
スケールのデフォルト値は、viewport 上でレイアウトされたウェブページを縮小して画面の幅にぴったり収めるような値だ。iPhone 7 なら、幅 980 ピクセルのウェブページを縮小して幅 375 ピクセルの画面で表示することになるから、デフォルトのスケールは約 0.38 だ。その結果、全体的なレイアウトはパソコンのブラウザーで見た場合と同等になるが、文字や画像は、パソコンで見る場合と比べておよそ３分の１の大きさで表示される。
これでは文字が読めないと思ったユーザーは、ピンチアウトしたり要素をダブルタップしたりして表示を拡大できる。このとき、レイアウトは変わらない。なぜなら、viewport の幅が変わらないからだ。画面の表示を拡大しようと縮小しようと、viewport 上のウェブページは変わらない。ユーザーが操作しているのは、スケールの値だ。ユーザーが表示を拡大したとき、スケールが大きくなっている。viewport 上のウェブページの大きさが変わらなくても、スケールが大きくなると、画面上では大きく表示される。
その２に続く
[この記事だけを読む。] [このカテゴリをまとめて読む。] [最新の記事を読む。]
二〇一七年 弥生 卅一日 金曜日
■ Flexbox でウィンドウに中央配置する２つの方法の比較 [/links]
この記事は書かれてから1年以上経過しています。内容が古くなっている可能性があります。コメントの受付は終了しました。
ここ２年ほど、ブログを細々と更新するだけで、私のウェブサイトをほったらかしにしていたら、新しい仕様がどんどん使えるようになっていて、すっかり浦島太郎になってしまった。自分のウェブサイトをいつまでも古いまま置いておくわけにもゆかないので、勉強を始めた。
新しい仕様の中でも使い勝手がよいものに、CSS の Flexible box（Flexbox）がある。要素を横に並べて高さを揃えたり上下左右の位置を揃えたりが簡単にできる。
Flexbox は、コンテンツ全体をブラウザウィンドウの中央に表示するのにも使える。従来はいろいろ面倒なことをしなければならなかったが、Flexbox を使うと簡単にできる。
次のような HTML があるとする。
<body>
<div id="container">
... コンテンツ
</div>
</body>
ここで、コンテンツをウィンドウの中央に表示するには、まず body 要素の高さをウィンドウいっぱいにする（幅は自動的にウィンドウの幅になる）。そのためには、html 要素と body 要素の両方に height:100%; と指定する。次に、body 要素を Flexbox の親要素にする。
html {
height: 100%;
}
body {
height: 100%;
display: flex;
}
この後は２つの方法がある。１つは、body 要素に justify-content:center; と align-items:center; を指定する。つまり、こうなる。
html {
height: 100%;
}
body {
height: 100%;
display: flex;
justify-content: center;
align-items: center;
}
Flexbox を解説しているウェブページを見ると、この方法を紹介しているところが多い。たいていの場合はこれでうまくいくのだけれど、実はうまくない場合がある。子要素（この場合 #container）の幅または高さが親要素よりも大きい場合だ。
上記の指定では、親要素と子要素の中心がそろえられる。子要素の方が大きいと、収まらない部分は上下または左右に均等にはみ出る。下や右にはみ出た部分はスクロールすれば見えるが、上や左にはみ出た部分はどうしても表示されない。これでは困る。MDN のページに詳しい説明がある。
もう１つの方法は、子要素に margin:auto; を指定する。つまり、こうする。
html {
height: 100%;
}
body {
height: 100%;
display: flex;
}
#container {
margin: auto;
}
子要素の幅または高さが親要素より大きい場合は、左右または上下のマージンの値は 0 になる。一方、子要素の幅または高さが親要素より小さければ、左右または上下のマージンが等しくなり、中央に配置される。これなら、子要素が小さくても大きくても問題なく表示される。
ところが、例によって IE にバグがある。子要素の高さを明示的に指定しない場合、上下のマージンが常に 0 になり、上下方向に中央配置されない。子要素で height を指定してやればよい話だが、要素の幅や高さを指定しなくてもよいのが Flexbox の肝だ。
というわけで、どちらの方法にも問題がある。しかし、第１の方法の問題はユーザーがコンテンツを見れないことであるのに対し、第２の方法の問題は、いまや少数派となった IE で見た目がよろしくないということだから、前者の方が深刻だ。私は、自分のウェブサイトで IE をサポートする気がさらさらないので、第２の方法を使おうと思う。
[この記事だけを読む。] [このカテゴリをまとめて読む。] [最新の記事を読む。]
二〇一七年 如月 十九日 日曜日
■ 米国のテレビで折り紙ドキュメンタリー [/origami]
この記事は書かれてから1年以上経過しています。内容が古くなっている可能性があります。コメントの受付は終了しました。
以前作成された、主に 2014 年の 6OSME に取材したドキュメンタリーは、ドイツ語版とフランス語版しかなかったが、このたびそれをもとにした英語版ドキュメンタリー "The Origami Revolution" が米国のテレビ曲 PBS で放送された。3 月 1 日まで PBS のサイトで公開されているが、日本からでは再生できない。VPN サービスを使っているなら、米国のサーバーを経由すれば見れる。
・・・と思ったら、YouTube にもあった。これが期間限定かどうかは不明。
[この記事だけを読む。] [このカテゴリをまとめて読む。] [最新の記事を読む。]
二〇一七年 睦月 廿一日 土曜日
■ ニューラルネットワークとディープラーニングで翻訳はどうなる・その３ [/language]
この記事は書かれてから1年以上経過しています。内容が古くなっている可能性があります。コメントの受付は終了しました。
その２から続く
ディープラーニングは画像認識で大きな成果をあげている。画像認識では、機械は「教師あり学習」という方法で学習する。「教師」は、ある画像について、これは犬だとか猫だとかと教える。あるいは、機械の判断に対して正解か不正解かを教える。
画像認識であれば、ほとんどの人が教師役になれる。しかし翻訳では、教師役になれる人が少ない。画像認識でたとえれば、犬か猫かではなく、オーストラリアン・シェパードなのかボーダー・コリーなのか、あるいはシャルトリューなのかロシアンブルーなのかを教えるようなレベルが求められる。それができる人を集めて機械に教えるとなると、学習にコストがかかる。コストを削減するためにクラウドソーシングに頼ったりすると、品質が確保できない。
それを言うなら、囲碁だって、教師役になれる人は少ない。それでも、Google の AlphaGo は世界トップレベルの棋士を相手に連戦連勝している。どうして機械が囲碁を学習できるかというと、機械が勝ち負けを判定できるからだ。コンピューターが自分自身を相手に対局すると、こう打ったときは勝つ、こう打つと負けるというデータが膨大に得られる。それを学習することで AlphaGo は強くなった。このような学習方法は「強化学習」と呼ばれる。
では、翻訳で強化学習ができるだろうか。翻訳には原文の解釈と訳文の表現の２段階があるが、表現には正解がない。ある原文に対する「正しい」訳文は、いくつも考えられる。しかも、それらのどれを使ってもよいわけではない。囲碁なら、対戦相手がどんな人であっても、勝ちは勝ちだし負けは負けだ。ところが翻訳では、想定される読者が変われば適切な訳文も変わる。だから、機械で正誤を判定するのは難しい。
ターゲット言語が日本語の場合、それが顕著だ。日本語には正書法がない。たとえば、「たとえば」を「例えば」と書いてもよいし、「コンピューター」を「コンピュータ」と書いてもよい。数字には漢数字とアラビア数字があり、デジタルデータならアラビア数字でも全角と半角がある。さらに常体（である調）と敬体（ですます調）という２つの文体もある。
翻訳の現場では、クライアントから「このスタイルで」と言われる場合もあるが、何も言われなくても、まともな翻訳家なら、特許の明細書には全角アラビア数字を使うし、ユーザーマニュアルは敬体で訳す。また、特許では正確さを優先し、マニュアルではわかりやすさを優先する。映像翻訳なら、吹き替えでは口の動きを合わせるし、字幕では文字数を少なくする。
その点で、翻訳は囲碁よりも自動車の運転に近い。運転にもやはり正解がない。だから自動運転はまだ実用にいたっていない。もっとも、運転では事故を起こさず目的地に着くというわかりやすい基準があるが、翻訳にはそれもない。機械にとっては、翻訳は運転より学習が難しい。自動翻訳が自動運転より先に「実用化」されているのは、自動運転が人命にかかわるのに対し自動翻訳がそうではないからだ。実際には、自動翻訳より自動運転の方が実用レベルに近い。
その４に続く。
[この記事だけを読む。] [このカテゴリをまとめて読む。] [最新の記事を読む。]
二〇一六年 師走 廿四日 土曜日
■ A Happy New Year か Happy New Year か [/language]
この記事は書かれてから1年以上経過しています。内容が古くなっている可能性があります。コメントの受付は終了しました。
「あけましておめでとう」を英語で何と言うか。多くの日本人が A Happy New Year だと答えるだろうが、それは誤りで Happy New Year が正しいと言う人が増えた。Merry Christmas や Happy birthday には A がつかないので、Happy New Year にも A をつけてはいけないと言うのだ。
それはそれでなるほどと思うが、こんなページを見つけた。
「某カトリック系学校」の英語話者に聞いたところ、ほぼ全員が「どっちでもいい」という反応だったという。
考えてみれば、英語圏には年賀状なるものがない。「あけましておめでとう」に対応する挨拶もない。それを英語で何と言うのが正しいのか、と聞かれても、「知らん、どうだっていい、好きにしろ」というのが素直な反応だろう。どのみち、日本人が日本人に言うことしかないのだから。
（上記のページには「『A』を付けた場合どういう意味になるかと言うと、文面としてみれば『よいお年を！』的なニュアンスになるようです」とあるが、そんなことはない。英語圏で「あけましておめでとう」という挨拶を使うことはないが、「よい〜を」という挨拶は頻繁に（１日に何度も）用いる。だから英語としては「よいお年を！」的なニュアンスになるわけで、A があるかないかは関係ない。）
日本人が長年慣用的に A Happy New Year と使ってきたのだから、それが正しい英語でいいのだ。「A がないほうがネイティブっぽい」と言うならその通りだが、「A がついているのは間違い」と言い出すのは、英語至上主義か、その裏返しの英語コンプレックスの表れだろう。
そもそも、なぜ日本人から日本人に送る年賀状に英語でメッセージを書こうとするのだろう。英語を習い始めたばかりの中学生なら、英語で書いてみたい、英語で書いたほうがかっこいい、と思うのもわかる。日本語を習っている米国人なら、ホリデーカードを日本語で書きたいと思うかもしれない。しかし、それを日本人宛てに出すことはあっても、日本語を知らない米国人宛てに出すことはないだろう。
A をつけるかつけないかと悩むくらいなら、素直に日本語で書けばよいのではないか。
カテゴリ
[/language] (98)
[/links] (254)
[/mac] (114)
[/music] (36)
[/origami] (406)
[/this_blog/ajax] (7)
[/this_blog/blosxom] (4)
[/this_blog/history] (12)
[/this_blog/perl] (9)
最新記事
◇ パスワードについてのあなたの常識はもはや非常識かもしれない・その１ [/links]
◇ ニューラルネットワークとディープラーニングで翻訳はどうなる・その５ [/language]
◇ ニューラルネットワークとディープラーニングで翻訳はどうなる・その４ [/language]
◇ HTTPS 対応 [/links]
◇ ひらがな・カタカナ学習ウェブアプリ [/links]
◇ 日本語の「た」と英語の過去形 [/language]
◇ ORI-REVO で回転楕円体を折る・その２ [/origami]
◇ ORI-REVO で回転楕円体を折る・その１ [/origami]
◇ 折り紙建築 [/origami]
◇ 折鶴に松図小柄 [/origami]
◇ 改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その６ [/links]
◇ 改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その５ [/links]
◇ 改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その４ [/links]
◇ 改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その３ [/links]
◇ 改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その２ [/links]