台詞記法で、吹き出しの有無を選べるようになりました。
声に出す台詞はspeak
を使います。
[speak taro これは声に出して言う台詞!]
心のなかの台詞はthink
を使います。
[think taro これは心のなかの台詞…]
実際に表示させるとこんな風になります。
詳細は縦書き文庫ヘルプ | 台詞記法についてを参照のこと。
台詞記法で、吹き出しの有無を選べるようになりました。
声に出す台詞はspeak
を使います。
[speak taro これは声に出して言う台詞!]
心のなかの台詞はthink
を使います。
[think taro これは心のなかの台詞…]
実際に表示させるとこんな風になります。
詳細は縦書き文庫ヘルプ | 台詞記法についてを参照のこと。
おもしろそうなサービスを見つけました。
「みんな読んだとか言って嘘ついてるけど、あなたが同意した規約の中身って、実際はこんな風になってるんだよ」みたいなことが確認できるサービス。
各サービスの各規約ごとに、thumb up/downのアイコンが割り振ってあって、総合評価としてclassA〜classEでレーティングされています(classAが最も良い)。
有名どころでは、
みたいな感じでした。
ちなみにamazonはどうかな、と思って確認してみたら、規約評価の項目は全てthumb downでしたが、classはまだ規約の調査が完了していないので付いていない(No Class Yet)、という扱いみたいです。
amazonの規約で思い出したのですが、3年ぐらい前に「投稿したレビューの権利が、商用利用も含めてアマゾンに譲渡されることについて知ってるかい?」みたいなブログポストがありました。
Amazon and Book Review Ownership
ちょっと確認したのですが、この件に関する(と思われる)規約の文面は、今はこういう内容です。
お客様がコンテンツの投稿または素材の送信を行った場合、他の取り決めを当サイトが明示していない限り、お客様は、アマゾンに対して、そのようなコンテンツを使用、複製、変更、翻案、公開、翻訳、二次著作物の作成、配布、あらゆるメディア形態で世界中に表示できる、非独占的な、無償の、永続的な、取り消し不可能な、完全なサブライセンスを含む権利を許諾したものとみなします。お客様は、アマゾンとサブライセンスを受けた者が希望すれば、それらに対して、そのようなコンテンツに関連してお客様が送信された名前を使用する権利を許諾したものとみなされます。Amazon.co.jp 利用規約 / レビュー、コメント、コミュニケーション、その他のコンテンツ
ようするに、再利用に関する権利はamazonにあって、amazonはその権利を第三者に対してもライセンスできる、という内容です。
ずいぶんと過激な気もしますが、しかしこれはamazonの商品APIを使うようなマッシュアップ系サービスからしたら、都合が良いはずです。
いちいち全てのレビューについて、それぞれのレビュアーの許諾を得なくてはいけない、となると手続きが大変ですが、この内容なら、アマゾンだけから許諾を得れば良いことになりますし…
ただ、レビューを書いた人たちからしたら、どうか。
もし自分のレビューが「商品のプロモーション」として、なんの相談もなく再利用されたら…もやもやしますよね。
でも規約は、そういうやり方も認めるような内容に読み取れますが、実際どうなんでしょう。
縦書き文庫も「サービスを利用した際に発生した二次的な情報の権利はサイト側に帰属する」などと気楽に書いてますが、アクセスログはともかくとして、レビューはどうするべきなんだろうなあと考えると、悩ましいところではあります(それほどコメントの多いサービスではありませんが)。
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
にmargin-box
が指定できます。
というか、margin-box
がデフォルトです。なぜか。
それは、ページ送りの組版では、外側のサイズが固定されているからです。
通常のウェブサイトなら、外側のサイズは「スクロール」という組版に逃げることで、いくらでも拡張できます。
しかしページ送りの組版においては、外側のサイズは絶対です。
つまり内側のコンテンツは、外側に固定されたサイズを、何があってもはみ出さないように配置する必要があります。
そういう「外に余剰サイズを逃すことができない」状況下で、ボーダーの外側に余白を表現したい場合はどうするのか。
答えは簡単。コンテントサイズを削るしかありません。
だからnehan.jsのbox-sizing
は、基本的にmargin-box
なのです。
というか、paged mediaにおいては、そうならざるを得ないような気がします。
Safari V.S. Chrome - via Designer News
デザイナー的にはSafari > Chromeみたいな議論になってて興味深かったです。
理由は画像編集ソフトが出力する「カラープロファイル」とやらを、数あるブラウザの中でSafariだけが正しく反映してくれるから、なんだとか。
で、違いを確認するために用意された画像がこれで、どっちが本当の「青」を出力しているか? ということらしいけど、なるほど確かに違うものだなあ、と。
今までIEとSafariのことをGoogle Chrome Downloaderみたいに思ってましたが、こういうの見ると、全ての分野でChromeが優れているわけではないってことなんでしょうね。
シリーズ単位で複数の作品をまとめることが出来るようになりました。
作品一覧だけでなく、表紙や登場人物なども一緒に表示されるので、シリーズ作品のエントリーページとして最適です。
これに伴い、プロフィールページのメニューに「シリーズ」が追加されました。
またシリーズに所属する作品は、作品タイトルのヘッダ部分で、シリーズへのリンクが貼られます。
これまでシリーズ物の閲覧性が悪かったわけですが、これでかなり改善されたのではないでしょうか。
埋め込みサムネールを使う人が、モバイルとの兼用をどうするのかっていうのが課題だったわけですが。
今まではサイズの部分にレスポンシブな感じでパーセントを指定することをおすすめしてきたわけですが、よくよく考えたらもっと簡単な解決策がありました。
それは「画面に収まらない時はリンク(+表紙)を代わりに表示する」というものです。
小さい画面でサムネールを出しても仕方ないですし…
今後は例えばサムネール(800x600)をiphoneなどで閲覧した場合、サムネール部分が解像度に収まらないので、タイトルリンク(と、設定されていれば表紙)に置き換わって表示されます。
ただし、2014年8月25日以前のサムネールは、タイトルと表紙ではなく、URLのリンク(http://...みたいなリンク)として表示されてしまいます。
これが嫌な人は、新しいコードを取得して貼りつけ直してください。
おそらく世間的には常識的な内容なんでしょうが、モバイル用フロントエンドの初学者には新鮮なことだったので書き残しておきます。
実はモバイル用のビューアーを書いていて、前から「なんかクリックが遅い?」と気になっていたのです。
ずっと「シミュレーター経由だからかなあ」とか思っていたんですが、なんとなく不安でモヤモヤしてました。
で、そんなときにたまたま、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を読み込むだけで勝手に置き換えてくれるのは便利です。
実際シミュレーター経由で試したら、ちゃんとクリックが高速反応してて感動しました。