Googleリーダーのインターフェイスが変更になっているのに気づきました。
デフォルトの状態ででもすっきりしてムダがなくなった感じがします。
ただデフォルトのままではショートカットがうまく機能せずに読みにくくて仕方がありません。
いつも「古い順」つまりリスト表示の下から上に向かって「k」キーを押しながら読んでいます。でもこれがうまくいかなくて、長いエントリがあるとリストの最上段まで上がってしまいます。それをまたいちいちスクロールダウンさせなければならず、かなりのストレスになります。
それにいままで使っていたカスタムCSSが効かなくなってしまいした。class名やid名の変更があったためと思います。
またカスタマイズ用CSSを作成しなければならないと考えると気分が沈むなぁ。
CSSを書く時のツールは、今はほとんどDreamweaverをつかっているわけですが、ちょっと込み入ったCSSを記述するときかぎって「CSSEdit」に頼ることが最近多くなってきた。
サイト全体のhtmlのディレクトリ配置や画像リソースの管理も含めて仕事をするときにはドリがなくては話にならない。新規ラウンチの時だけじゃなく、ひさしぶりに頼まれた更新作業もドリでサイト管理をちゃんと設定してあれば、すぐにサイトの全体像を把握することができる。
でもCSS記述に限った場合、Dreamweaverはどうも使いにくい。記述した結果をプレビューに反映させるのにワンクリック必要でリニアな感じがしないのだ。できることはどちらもほとんど同じなのに、軽快さと頻繁なプレビューのしやすさでCSSEditに分がある。
属性パネルがタブでコンパクトにまとめられているのも使いやすい。
Dreamweaver CS3ではメニューパネルも新しくなっているみたいだから、CSSEditの使い勝手のよさが反映されているといいのだけど。
コーディングばっかりな一日。
しかもよそ様が記述したソースコードを公開側から落としてきて、ローカルディレクトリに再現、そして解析、再設計の計画、やっと記述、という段取り。
今回の計画では XHTML 1.0 Strict に移項しようという計画のため、スケルトンの設計だけで二日も費やしたりして、よくいわれる通り、一から記述するより2倍ぐらいの手間と時間がかかってしまうことになって悪戦苦闘中。
サイト全体での属性名とページデザインの関連を統計立てて整理してくれるツールってないのかな。
膨大な属性名がサイトのどこでどう使われているのかを解析するだけでアタマとカラダの大部分のエネルギーを消費してしまっています。
voice-family: "\"}\""; voice-family: inherit; width: 162px;}
こんなハックを実際に使っているのを初めて見ました。
調べてみるとどうやらIE5.x対策のハックのようですけど、そういうのも含めてもうきれいにしたいので無難にXHTML側に条件分岐でCSSを振り分ける方針。これを決断するだけで半日かかってます。
サイトのオモテ側の基本デザインを変更せずに裏側だけをリビルドする作業なんて本来的にはNGだと思う。
しかし実際には、クライアントの部署間の問題や、予算、次年度の計画などと絡まってこちらの思惑通りにはいかない。改修にかかる予算と手順の説明や根回しだけでも会議が空転する。手探り状態なこっちの状態を相手に気づかれないように配慮している、ということを察知してくれる気遣いが欲しい。四面楚歌ですか。
ボックスモデルの設計はデザインワークそのものだ。いままでとこれからを全部テーブルに出さなくちゃ。
XHTMLとCSSの関係をまとめたフォーマットを決めるための支援ツールが欲しい。意思決定はこっちがするから、移行前の旧サイトのソースコードを分析して論理的に整理された情報が手に入るリバースエンジニアリングなツールがあれば、再設計の計画が立てやすいのに。
バージョン1.6のときにちょっとだけ使ったことがあるMac向けCSSオーサリングツール「CSSEdit」。
最新版のバージョン2がリリースされました。
美しいアプリケーションです。
数文字入力すると補完してくれるコードセンスが妙に賢い。
ライブプレビューできるX-ray機能が使いやすい。
ブラウザで見ているページのCSSをその場で編集。
たしかに機能的にはCSSエディタに必須のもので改めて書き出すと目新しさは感じないかもしれない。
このアプリケーションのもっとも評価すべき点は、使い勝手。
直感的に気持ちよく操作できるということ。使っていると、小さな仕掛けや心憎い配慮がいたるところに隠れていて気持ちいい。
Dreamweaverとうまく共存して使っていけたら、と考え実戦投入してみようと思う。
JavaScript開発用IDEということで気になる存在の「Aptana」。
コード補完やリファレンスをポップアップしてくれるのは当然としても、InternetExplorerとFirefoxに対応しているかどうかまで親切に教えてくれるのはちょっとうれしい。
動作が不安定、というより、まだまだレビュー程度の使い方しかできない完成度ですけど、安定して、ちゃんと日本語にも対応したら、手放せなくなりそうな予感がいっぱいで期待感いっぱいのツールです。Dreamweaverの牙城を崩す力を秘めているかも。
こんなサイトも用意されていて、やる気もいっぱいです。
Ajax開発ツール、と言い切るのはちょっとオーバーかも。
もう開催が始まって10回目にもなる恒例イベントとなった「CSS Nite」。第10回目が先日銀座のApple Storeで行われた。
何回か「行きましょう」とお誘いを頂いたにもかかわらず、タイミングが合わずいまだ参加できていない。
出席した人の話を聞くと、回を重ねるごとに内容も深く濃くなってきているらしいし、スタッフの方々の積極的なアクションも好評だそうだ。
主宰している鷹野さんの公式サイトでもイベントの前後にきっちりとフォローを行っている。
銀座のアップルストアはキャパ的に決して恵まれていないので、会場の様子をストリーミグしたり、当日のプレゼンデータを公開したり、同時録音した音声をポッドキャストしたり…。
出たくても出られなかった人にとってみたら至れり尽くせりのフォローっぷりには頭が下がる。
プレゼントも増えて、もっと大きなムーブメントになっていきそうなテーマイベントになってきた。
［CSSのTips忘れないうちにメモ］
overflow:の値にscrollを指定すると、ページ内にスクロールバーが表示される。先日初めて仕事で使う機会があった。いまままで、こういうキワものっぽいことはしないようにしていたし、ブラウザ依存性が高い気がして、敬遠していたのだ。
そして実際につかって見てどうだったか。
やはりそれなりにブラウザ依存性が高い。overflow:scroll;だけでは、まず希望したとおりにはならない。親階層をdivでくくってそれなりの設定が必要だ。float: width: height: margin: padding: など配置コントロールを明示的に指定してやって予期せぬ崩れを防止する細かい調整がいる。
ただし、ページ内にスクロールバーが入るのは、インターフェイスとして考えると決して褒められるやり方ではないし、第一カッコわるい。今回はクローズドな環境（企業内）のコンテンツでターゲットブラウザがほぼ把握できるというレギュレーションのなかでの仕事だったので採用となったが一般のWebページで使うには、それなりの覚悟がいるということはまちがいない。
［CSSのTips忘れないうちにメモ］
IEというブラウザはフォント関連の指定方法にクセがある。
特に注意したい有名なクセに、テーブル内でフォントの指定が効かない、というのがある。これは有名なTipsだから知っている人も多いのではないでしょか。
一般的に考えて、親要素であるbodyでフォントスタイルを指定すれば、テーブルの中のセルにも同じフォントスタイルが適用されると考えるだろう。
しかしIE（互換モード）ではそうはならずに、テーブルの中のセルはデフォルトのフォントスタイルが適用されてしまう。
忘れずにthやtdエレメントでもfontstyleの指定を行えばいいのだけど、つい忘れてしまいがち。
IE互換モードで継承されないプロパティには、以下のようなものがある。
font-stye: font-size: font-weight: color: text-decoration: text-transform: letter-spacing: line-height: がある。互換モードでテーブルを一部使用するようなサイトの場合は忘れないようにしたい。
［CSSのTips忘れないうちにメモ］
4種類ある疑似クラス。「link」と「visited」はどちらかの状態しか発生しないが、「hover」と「hover」は補完的な状態にある。そして、「link」「hover」「hover」が同一条件となる場合があるはず。
とすると、起こりえる状態が重なったときに、疑似クラス同士の優先順位は指定できないので、記述した順番にスタイルが適用されることになる。
つまり、疑似クラスには指定する順番が論理的にあってしかるべきかもしれない。
たとえば、a:hoverがa:linkやa:visitedより先に指定されていると、a:hoverで設定したスタイルは次に記述したスタイルで更新され、リンクにカーソルが重なったときに意図した通りに表示されなくなる。
同様に、a:visitedのあとにa:hoverで指定したスタイルは後で記述したスタイルで上書きされ、リンク部分のスタイルが意図しないものになる。
疑似クラスはa:link、a:visited、a:hover、a:active、の順に記述するようにしよう。
［CSSのTips忘れないうちにメモ］
center要素や「align="center"」によるセンタリングは、HTML4では非推奨となっています。
CSSでインラインレベル要素をセンタリングするには、「text-align: center」を指定しますが、ブロックレベル要素をセンタリングするのにはtext-alignは使えない。表記そのものがインラインっぽいし。この場合は「margin: 0 auto」を指定します。
しかし、IE6で「margin: auto」でセンタリングを行うには、ブラウザの表示モードを標準モードに指定しておく必要があります。IE6の互換モードではIE5.xやNN4.xなどと同様に「margin: auto」の指定は無効になります。
ちなみに、text-alignをブロックレベルで使用してもセンタリングされるのはWindows版IEのバグじゃないだろうか。親切設定ともいえるし、もしtransitionalで記述しているなら「text-align: center」でも問題ない。