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まで圧縮できました。

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

Google Analyticsの埋め込みに対応

Google Analyticsの埋め込みに対応しました。

アカウント管理の「プロフィール編集」から設定できます。

入力欄には、GoogleAnalyticsのプロパティID（UA-123456-89 みたいなやつのことです）を設定します。

設定すると、各小説ページヘのアクセス（自分自身のアクセスは除く）がGoogle Analyticsに送信されます。