CSS をテーマにするのはいいけれど @tDiary
構造が気持ち悪い。とりあえず tDiary の話。はてなにも言えるけどはてなはソースを変えられない時点で「諦め」があるので論外。
tDiary には CSS によるテーマ機能があって、(たぶん) それがウリなんだろうけど、そのせいで構造が変えにくい。「変えにくい」ってのはテーマを使いたいからでなく、スキンファイル (構造を決定するファイルってことにしてください。CSS は含みません。) が難読になっていたり、プラグインの吐くソースがキモかったりする。「どうせテーマを使ってもらうんだから構造は決めうち。スキンファイルは開発側が編集できればいいや」みたいな。
俺が tDiary を使っていたとき、そういう気に入らない構造の部分をざっくり修正して使っていたんだけど、バージョンアップしようと思ったときに死んだ。そしていろいろあって tDiary を使うのをやめた。使うのはやめたけど ML は読んでる。なんとなく。
少し前に「form 要素直下に input 置くと validator に怒られるので div で囲う」みたいなメールが流れてた。あはははって感じ。
誰もが納得できる構造にするのが一番いいんだけどそれは難しい。だから、スキンファイルをシンプルに。変なソースがあってもユーザが修正できるように。スキンファイルを編集しても別なところでエラーがでないように。バージョンアップのときにスキンファイルを変えなくてもいいように。
ちなみに「誰もが納得できる構造」であれば CSS によるテーマってのはすごく素敵なもんなんだよなぁ。というかおかしいんだよ。「誰もが納得できる構造」って何なんだ。
まぁでも、こんないちいちキモイ構造がどうとかいうのは strict ヲタクぐらいなもんだろう。
そもそもカテゴリが違うといえど blosxom はよろしいな。構造?なにソレ?ていうかボク HTML なんて知らないよ、みたいな。バージョンアップしねぇじゃんとかは禁句らしい。
放任したほうが楽ちん。やりたい人は tDiary 互換フレーバーとかあるしなぁ。よくわからんセクションになってるのは俺の頭が悪いうえに今眠いからです。
関連エントリー
- section/@datetime についてのメモ section/@datetime が存在しなくても問題ないようにしよう。そうすれば tDiary のデータをもっとスマートに移行できる。た...
- 日記とか tDiary のデータを楽チンにインポートできないかなぁと思ってデータファイル見ていたのだけど、二年前の日記とかキモすぎて段々へこんでくる。...
- tDiary -> blosxom 移行するならどうやってデータを移そう? セクションごとにファイルを切って、日付をファイル名にして、そのファイルの更新時間もデータにある更新時...
- Taglibro! への移行 tDiary やめてこっちへ。とりあえず /nulog/ でアクセスされたときは、/d/latest に飛ばしてます。 これからやろうと思う...
- CSS の色空間は sRGB のはずだけど… Chrome, Firefox, Safari で調べたところ、 Chrome: カラーマネジメントされない ( sRGB は適用されない)...