OTCHY.NET

Cron Builder を作るにあたって、初めてちゃんと HTML5＋CSS3 を使ってみたので、その雑感などをメモ程度に書いてみます。

HTML5

header、footer、nav

分かりやすくていいです。ソースが見やすくなります。
早くエディタ側の対応が進んで、見やすく色分けしてくれるようになると嬉しいですね。

section

Cron Builder みたいなウェブアプリの場合、使いどころにちょっと悩みます。今回はタブの中身で使ってみました。article 要素に至っては、使いどころがないです。
ブログとかニュースサイトなら綺麗にハマるんだと思いますが、ウェブアプリの場合、新規追加の要素を無理して使う必要はないですよね。

header とか section って、ブロック要素じゃないの？

header、footer、section を最初、名前が違うだけのdiv のつもりで使ってたら、Chrome は意図通り表示されたのに、Firefox はブロック要素として振る舞っていませんでした。(未確認ですが inline-block ぽい？)
display: block して事なきを得ましたが、この辺って正しくはどうあるべきなんでしょう？(Fx 3.6 が実は HTML5 に対応していないだけ？？)

div

せっかくだから、div 要素を使わずにやってみようと思って始めましたが、結局挫折。少し凝ったことをやろうとすると、やっぱり「論理的な意味を持たない枠」が必要になるので、そこは結局 div にしました。
まあ、無しにするのは難しいですが、div は確実に減らせます。div が減ると class とか id の指定も減らせて、CSS のセレクタが綺麗になるのが嬉しいところです。

その他 canvas、video、audio など

派手派手しい要素は全然使ってません。

CSS3

:hover

CSS3 じゃないけど、IE が a 要素にしか対応してなかったので、気分としては CSS3。a 要素以外にも色々使うと、スマートに書けます。
よく li の中に a を入れて…ってやってましたが、今回、タブを表す li 要素に直接 :hover したら HTML がスッキリしました。気持ちいい。
onclick イベントも jQuery の後乗せで li に直接付与して実現してて、a 要素の使用は本当の意味でページ遷移する時だけです。意味的にも綺麗で精神的によろしい。

border-radius

言わずと知れた角丸。もはや定番という意識です。
Fx 3.6 はまだベンダープレフィックスが必要なのがちょっと意外でした。Fx 4.0 では要らなくなるのかな？

text-shadow

実装されたのが昔だけあって、抜群の安定感。Cron Builder ではロゴにあたる部分で使用してます。
最近、本文に微妙にずらした text-shadow をかける例を見かけますが、やりすぎると見にくくなるので気を付けたいところですね。
調子に乗って、5px 5px 5px とか離しすぎでぼかしすぎの影を付けると、雰囲気が一気に 90 年代テイストになりますｗ

box-shadow

影繋がりで次は box-shadow。こっちは最近の実装なので、Chrome も Firefox もベンダープレフィックスが必要です。でも、ルール自体はシンプルなので使い勝手はブラウザに寄らず同じでした。
inset (内側の影) を指定すると窪んだ感じを表現できます。
Cron Buider では、border-radius と box-shadow: inset を組み合わせて使っていて、同じ事を CSS3 無しでやろうと思ったら、画像はいくつも必要だし、マークアップも汚くなってしまいます。今回、一番 CSS3 の恩恵を感じた部分はここでした。

グラデーション

最後はこれです。仕様未決定でしたっけ？ベンダープレフィックスどころか、実装によってそもそも書式が全然違うし、それらも複雑です。
オンライン上に色々とグラデーション CSS のジェネレータがありますが、グラデーションの指定はジェネレータが無いと書けないと思います。

その他

アニメーションとか回転とかは使ってません。CSS3 を考えた人達が「CSS3 すげーんだぜ！」って言いたい気持ちは分かるんですが、やりすぎじゃないかなぁと思ってます。昔懐かしい blink とか marquee の匂いを感じるんですがどうなんでしょう？

ざっとこんなところです。
全般的にみて、マークアップが綺麗になるケースが多く、それに伴い CSS のセレクタも分かりやすくなるケースが多かったので、将来的には主流になっていくと思いました。
jQuery 使ってると、CSS セレクタが分かりやすい＝jQuery が分かりやすいっていう事なので、特に助かりますね。

スタンダードな使い方をしている限り、ブラウザ間の挙動の違いもほとんど無いので楽に作れます。
え？IE？もちろん、全力で無視してます。
body 直下に以下の条件付きコメントを入れているのが、せめてもの良心でしょうか。

<!--[if IE]>
<div style="padding: 5px; border: 3px solid #f00; background: #fee; color: #f00; font-size: 10pt;">
IE では一切動作確認していません。恐らく動作しません。
</div>
<![endif]-->

cron の書式ってなんであんなに覚えにくいんでしょうか。
たまにしか書かないせいもあるし、欧米風の日付順でパラメータが並んでいるせいかもしれません。

いずれにせよ、cron 書く度に毎回「cron 設定」でぐぐって解説ページを開いたりするのがいい加減嫌になったので、そう思う人間は自分だけではないはずと、GUI でお気楽に書式を組み立ててくれるサービスを探してみました。
ところが、唯一見つかった CronMaker の出来がどうにもイマイチだったので、「無ければ作る！」の精神で作っちゃいました。

それがこちら！
Cron Builder (短縮 URL は http://otchy.net/cb )

たぶん、使い方は直感的に分かるんじゃないかと思います。
もちろんいつも通り、IE には未対応です。
しばらくはちょこちょこ修正とかすると思いますので、不具合とかあったら教えて下さい。

それと今回、昨今のトレンドにのって、HTML5 ＋ CSS3 で書いてみました。
今時のブラウザはずいぶん表現力が上がってますね。

ZERO Compress は究極の圧縮率 0% を達成したファイルアーカイバです。
どんなファイルも 0 KB に圧縮します。
以下に利用イメージを紹介します。もちろん、画像はコラじゃありません。

利用イメージ

画像ファイル “Winter.jpg” を圧縮することにします。ファイルサイズは 104 KB です。
常識的に考えれば、jpg ファイルは圧縮したところで圧縮率は大したことがないでしょう。

このように、zeroc.vbs に対して、圧縮したいファイルをドロップします。

すると、Winter.jpg.zero という 0KB に圧縮されたファイルが作成されます。

元のファイルは要らないので消してしまいましょう。

では、きちんと解凍できるか確認です。Winter.jpg.zero ファイルを今度は unzeroc.vbs にドロップします。

おおおおお！元のファイルが再現しましたね！

念のためファイルを表示させてみても元通りです。可逆圧縮なので、バイナリエディタで比較したって大丈夫ですよ。

実際に使ってみる

Download

上記のリンクより zip をダウンロードすると実際に試すことが出来ます。
詳細については、同梱の readme.txt を参照して下さい。

もちろん

そんなことは理論的に不可能なのでタネがあります。ジョークツールですのでそのつもりでどうぞ～。
唯一の有用そうな使い道として、もしかしたら、見つかると都合の悪いファイルを隠すのにも使えるかも!?

readme.txt を読めば、制限事項の内容でタネがばれる気がしますし、vbscript なのでソース読めばそれこそ確実ですが、反響が大きかったら解説書きます。

Twitter をやっていると、色々なユーザをフォローするにあたって大きく 2 つの方針があるように思います。

まず 1 つ目は、フォロワの発言を基本的に全部読めるように厳選して TL を構築する方針です。Twitter を始めた当初はこういうパターンの使い方が多いのではないでしょうか？メッセンジャー的、あるいは SNS 的使い方と言えます。
これを厳選 TL と呼びましょう。

そして 2 つ目は、もっとフォロワの範囲を拡大して、未読の発言が流れていっても気にしない方針です。フォロワが増えていくにしたがって、全部の発言を追えなくなると、どこかのタイミングでこういうターニングポイントがやってくる人が多そうです。開き直って、どんどんフォロワーを増やし続けるパターンも見受けられます。これは、ストリーミング的な使い方で、雰囲気としては TV のザッピングに似ていますね。
こちらは、ストリーム TL と呼ぶことにします。

もちろん、厳選 TL とストリーム TL の境界は曖昧でその中間的な状態という場合も多いでしょう。

さて、「知らない人をフォローすること」と独創性 | WIRED VISION という記事とか、フォロワがいっぱいいて Twitter 充している人なんかを見ていると、Twitter の一番面白い使い方は、ストリーム TL ではないか、という気がしてきます。
だけど、せっかく構築した自分の厳選 TL に大量のフォロワを追加して、ストリーム化させてしまうのには躊躇する人も多いのではないでしょうか？

自分自身、すでにある程度ストリーム化した TL にはなっていますが、ざっくりと議論を追ったりは出来る厳選 TL 的な要素も残っています。ストリーム TL の面白さを追求してみたいとは思うのですが、これ以上フォロワを増やすと厳選 TL の要素が無くなって完全なストリーム TL になってしまうので、それは避けたいという気持ちもあります。

ではどうすればいいでしょう？

サブ垢の利用

まず思いつくのは、もう1つのサブアカウントを取得して、目的別に使い分けるという事です。この方法は、厳選 TL とストリーム TL をそれぞれ綺麗に分離することが出来ます。マルチアカウントに対応したクライアントアプリを使えば、TL を見るには困らなさそうですが、ちょっとした問題があります。

ストリーム TL からザッピングして、ちょっと返信を付けたり、RT したりしたい時は、やはりメインのアカウントでやりたいのですが、その度にいちいちアカウントを切り替えるのは面倒です。あるいは、ストリーム TL で気に入ったユーザがいたから厳選 TL に組み込みたい時なども面倒ですね。
とかく、複数のアカウントを使い分けて何かするというのは面倒になりがちなので、この方法はボツです。

非フォローリストの利用

これが本命です。
今の Twitter には、「リスト」というユーザをグループ分けする機能があるのですが、このリストに追加するユーザについては、自分でフォローしている必要がありません。

そこで、フォローしないままリストにどんどんユーザを追加して、そのリストをストリーム TL として参照します。この場合、ホーム TL (＝厳選 TL) とストリーム TL が混在することなく存在し、また、自分のアカウントは 1 つなので、返信や RT を行ったり、厳選 TL に組み込んだりするのもスムーズですね。

さらに、リストの設定にはプライベートモード (自分以外に非公開) というものも存在するので、「フォローするまでもない」と判断したことを本人に知られたくない場合や、ストーｋ 恥ずかしがり屋なあなたも安心です。

ところで、確かに気になる発言はあるものの、Tweet の絶対数が少なくてあっさり見落としてしまうような人を、確実に補足するにはどうしたらいいのでしょうか？
この場合、流し読み前提のストリーム TL は適当ではありません。

ユーザ RSS の利用

そこで出てくるのが ユーザ RSS です。RSS とは何かについては、ここでは言及しませんが、Twitter では一人一人のユーザごとに、そのユーザの発言だけが含まれる RSS が生成されています。
具体的には、以下のような URL です。

http://twitter.com/statuses/user_timeline/{userId}.rss

{userId} の部分には、対象となるユーザのユーザ ID (数値) もしくはスクリーンネームが入ります。ユーザ ID はやや専門的になるので置いておいて、スクリーンネームは各ユーザのプロフィールページの URL などに含まれる、ユーザを個々に識別できる英数字の文字列のことです。

この RSS を任意の RSS リーダに登録して購読すれば、そのユーザの全ての発言を漏れなく拾うことが可能になります。(*1)

これまた本人には知られないないですし、しかも Google リーダーなどに登録してしまえば、過去の発言の検索性も上がるので、情報源として Twitter を利用したい場合は非常に助かります。ストーｋ 恥ずかしがり屋のあなたには、願ったり叶ったりな状況になりますね。

そんなわけで、新たなフォロワを増やすことなく、気になる人を補足する方法を 2 つほど紹介しました。Twitter の使い方に正解などは無いと思っていますが、自分好みの使い方をする上での一助となれば幸いです。

*1 厳密に言えば、RSS リーダーのクロール速度を、ユーザの発言速度が上回った場合に取りこぼしが発生する可能性があります。