利用者の「規約を読みました、同意します」はウェブ最大の嘘？

おもしろそうなサービスを見つけました。

Terms of Service; Didn't Read

「みんな読んだとか言って嘘ついてるけど、あなたが同意した規約の中身って、実際はこんな風になってるんだよ」みたいなことが確認できるサービス。

各サービスの各規約ごとに、thumb up/downのアイコンが割り振ってあって、総合評価としてclassA〜classEでレーティングされています（classAが最も良い）。

有名どころでは、

• DuckDuckGo がclassA
• Github がclassB
• Google がclassC
• Delicious/Youtube がclassD

みたいな感じでした。

ちなみにamazonはどうかな、と思って確認してみたら、規約評価の項目は全てthumb downでしたが、classはまだ規約の調査が完了していないので付いていない（No Class Yet）、という扱いみたいです。

レビューの再利用に関する権利

amazonの規約で思い出したのですが、３年ぐらい前に「投稿したレビューの権利が、商用利用も含めてアマゾンに譲渡されることについて知ってるかい？」みたいなブログポストがありました。

Amazon and Book Review Ownership

ちょっと確認したのですが、この件に関する（と思われる）規約の文面は、今はこういう内容です。

お客様がコンテンツの投稿または素材の送信を行った場合、他の取り決めを当サイトが明示していない限り、お客様は、アマゾンに対して、そのようなコンテンツを使用、複製、変更、翻案、公開、翻訳、二次著作物の作成、配布、あらゆるメディア形態で世界中に表示できる、非独占的な、無償の、永続的な、取り消し不可能な、完全なサブライセンスを含む権利を許諾したものとみなします。お客様は、アマゾンとサブライセンスを受けた者が希望すれば、それらに対して、そのようなコンテンツに関連してお客様が送信された名前を使用する権利を許諾したものとみなされます。Amazon.co.jp 利用規約 / レビュー、コメント、コミュニケーション、その他のコンテンツ

ようするに、再利用に関する権利はamazonにあって、amazonはその権利を第三者に対してもライセンスできる、という内容です。

ずいぶんと過激な気もしますが、しかしこれはamazonの商品APIを使うようなマッシュアップ系サービスからしたら、都合が良いはずです。

いちいち全てのレビューについて、それぞれのレビュアーの許諾を得なくてはいけない、となると手続きが大変ですが、この内容なら、アマゾンだけから許諾を得れば良いことになりますし…

ただ、レビューを書いた人たちからしたら、どうか。

もし自分のレビューが「商品のプロモーション」として、なんの相談もなく再利用されたら…もやもやしますよね。

でも規約は、そういうやり方も認めるような内容に読み取れますが、実際どうなんでしょう。

縦書き文庫も「サービスを利用した際に発生した二次的な情報の権利はサイト側に帰属する」などと気楽に書いてますが、アクセスログはともかくとして、レビューはどうするべきなんだろうなあと考えると、悩ましいところではあります（それほどコメントの多いサービスではありませんが）。

box-sizing:margin-box

margin-boxとは

margin-boxとは、ボックスのサイズをmarginも含めて計算するボックスのことです。

つまりmarginが50pxで、widthが200pxなら、コンテントサイズは

200(width) - 50(margin-left) - 50(margin-right) = 100

になります。

ちなみにこのmargin-boxという値は、現在のbox-sizingプロパティでは、有効な値ではありません。

でもcss3 shapesという仕様のshape-outsideというプロパティでは有効な値（それどころかデフォルト値）だったりします。

理由はよくわかりません。

nehan.jsにおけるbox-sizing

ところで nehan.js においては、box-sizingにmargin-boxが指定できます。

というか、margin-boxがデフォルトです。なぜか。

それは、ページ送りの組版では、外側のサイズが固定されているからです。

通常のウェブサイトなら、外側のサイズは「スクロール」という組版に逃げることで、いくらでも拡張できます。

しかしページ送りの組版においては、外側のサイズは絶対です。

つまり内側のコンテンツは、外側に固定されたサイズを、何があってもはみ出さないように配置する必要があります。

そういう「外に余剰サイズを逃すことができない」状況下で、ボーダーの外側に余白を表現したい場合はどうするのか。

答えは簡単。コンテントサイズを削るしかありません。

だからnehan.jsのbox-sizingは、基本的にmargin-boxなのです。

というか、paged mediaにおいては、そうならざるを得ないような気がします。

デザイナーにとっては Safari > Chrome？

Safari V.S. Chrome - via Designer News

デザイナー的にはSafari > Chromeみたいな議論になってて興味深かったです。

理由は画像編集ソフトが出力する「カラープロファイル」とやらを、数あるブラウザの中でSafariだけが正しく反映してくれるから、なんだとか。

で、違いを確認するために用意された画像がこれで、どっちが本当の「青」を出力しているか？ ということらしいけど、なるほど確かに違うものだなあ、と。

どちらが本当の青か？

今までIEとSafariのことをGoogle Chrome Downloaderみたいに思ってましたが、こういうの見ると、全ての分野でChromeが優れているわけではないってことなんでしょうね。

テキストファイルで入稿できるようになりました

使い方は、本文の入力フィールドに、テキストをドラッグ＆ドロップするだけです。

ドラッグ＆ドロップすると、テキストのエンコーディングを確認するダイアログが開きます。

元ファイルのエンコーディングを選択してOKを押すと、ドロップしたテキストの内容が、そのまま本文の入力フォームに展開されます。

ただしこの機能、古いブラウザでは利用できません。

投稿画面を開いて、もし本文の入力フォームの下に以下のような表示が出ていたら使えます。

標準の入力フォームを改良しないといけないなあと思っていたのですが、この方式なら、執筆は使い慣れたエディターで進め、投稿するときはファイルを放り込む、というやり方ができます。

シリーズ単位で作品をまとめることが出来るようになりました

シリーズ単位で複数の作品をまとめることが出来るようになりました。

縦書き文庫ヘルプ：シリーズを作成する

作品一覧だけでなく、表紙や登場人物なども一緒に表示されるので、シリーズ作品のエントリーページとして最適です。

これに伴い、プロフィールページのメニューに「シリーズ」が追加されました。

またシリーズに所属する作品は、作品タイトルのヘッダ部分で、シリーズへのリンクが貼られます。

これまでシリーズ物の閲覧性が悪かったわけですが、これでかなり改善されたのではないでしょうか。

サムネールが画面に収まらない場合について

埋め込みサムネールを使う人が、モバイルとの兼用をどうするのかっていうのが課題だったわけですが。

今まではサイズの部分にレスポンシブな感じでパーセントを指定することをおすすめしてきたわけですが、よくよく考えたらもっと簡単な解決策がありました。

それは「画面に収まらない時はリンク（＋表紙）を代わりに表示する」というものです。

小さい画面でサムネールを出しても仕方ないですし…

今後は例えばサムネール（800x600）をiphoneなどで閲覧した場合、サムネール部分が解像度に収まらないので、タイトルリンク（と、設定されていれば表紙）に置き換わって表示されます。

ただし、2014年8月25日以前のサムネールは、タイトルと表紙ではなく、URLのリンク（http://...みたいなリンク）として表示されてしまいます。

これが嫌な人は、新しいコードを取得して貼りつけ直してください。

backbone.touch.jsでモバイルデバイスの「クリック」を高速にする

クリックが遅い？

おそらく世間的には常識的な内容なんでしょうが、モバイル用フロントエンドの初学者には新鮮なことだったので書き残しておきます。

実はモバイル用のビューアーを書いていて、前から「なんかクリックが遅い？」と気になっていたのです。

ずっと「シミュレーター経由だからかなあ」とか思っていたんですが、なんとなく不安でモヤモヤしてました。

で、そんなときにたまたま、backbone.touch.jsというライブラリを見つけて「ああなるほど」と感心しました。

https://github.com/nervetattoo/backbone.touch

ここのドキュメントによると、タッチデバイスって、クリックイベントが300msぐらい遅れて発火するらしいのですね。

なので、backbone.touch.jsは、Backbone.View.prototype.delagateEventsを上書きして、clickを使って書かれたハンドラが「touchstart/touchend」を使ったハンドラに自動的に置き換わるようにしちゃおう、というライブラリなのだそうで。

じゃあどうやってtouchstart/touchendでクリックを判定するかというと、touchstartした座標を覚えておいて、touchendした位置がそこから殆どずれていなかったら「それってクリックだよね」っていう判定処理をしているみたいです。

クリックが遅れる理由

そもそもモバイルデバイスでクリックイベントが遅れる理由ですが、画面を触るという点について意味が被る「クリック」と「タッチ」を区別するためなんでしょう。

よくよく考えたら「そりゃそうだ」と合点しました。

スマホ自体を持っていないので、そういうイメージそのものを、これまで考えつかなかったです。

やっぱり一つぐらいタッチデバイスを持ってたほうがいいのかなあと、改めて思いました。

デフォルトのジェスチャー判定を抑止

ちなみにソースを覗いて気になったのは、touchendの発生時、対象がAタグとかBUTTONタグなら、デフォルトのtouchendイベントの発火を抑制してる箇所です。

これはおそらく、モバイルブラウザで表示されるAとかBUTTONタグには、デフォルトで同じような「クリックみなし」のジェスチャー判定が、すでにバインドされているからなんだと思います。

なので、ダブル発火を防ぐためにpreventDefaultしている、と。なるほど〜！

なんにせよ、backbone.jsを使ってクリックを扱うロジックを「click」で統一させたいなら、backbone.touch.jsを読み込むだけで勝手に置き換えてくれるのは便利です。

実際シミュレーター経由で試したら、ちゃんとクリックが高速反応してて感動しました。

モバイル用のビューアーで表示設定の変更ができるように

モバイル用のビューアーが、表示設定の変更に対応しました。

新しいビューアーはこういう見た目になっていますが、

左上のアイコンをクリックすると、表示設定の画面になります。

縦書き、横書きの切り替え、フォントサイズの変更、明朝ゴシックの切り替えなどが設定できます。

あとは内部的なことですが、今まではデスクトップ用のビューアーを無理やりモバイル用にしていたので、使わないコードが大量にロードされていました。

しかし今回モバイル用のビューアーを完全にリライトしたことで、全体のファイルサイズを約1/4まで圧縮できました。

これで初回ロードも少しは速くなるんじゃないかなと思います。