CSS Nite LP2に行って来た。
12/8に北青山 TEPIAで行われたCSS Nite LP2に行って来ました。CSS Niteは回を重ねるごとに風格のあるセミナーになってきましたね。
今回は豪華に12セッションを3会場で同時に進めるかない豪華なセミナーでした。
さらに今回は、セミナーと同時に発行された書籍がセミナーと連動するという面白い試みでした。書籍の企画に合わせたのかCSSよりはDreamWeaver寄りのセッションが多かったです。
実際にセミナーの中で「ここは書籍の~ページを見てください」とかはなされる場面があり、また、聞けなかったセッションをあとで書籍で確認できるので、いい連動の方法だと思います。
推測になりますが、以前に、CSS Niteの拡張版イベントの「Web標準の日」で、後日セミナー内容をmp3で配信して、費用を払って参加した方からクレームがついた事をうけて、書籍をセミナーにバンドルしたのかもしれません。
僕個人としては、この手の情報は速報性と会場で聞くということが大事だと思うので、後の音声や動画資料の配布には異議はないのですが。
と。前置きはさておき、今回は下の4セッションを受けてきました。
コンポーネントベースのWebサイト設計と構築
小久保浩大郎氏
「抽象化」という言葉を使い、意識的に文書構造と外観を分離する事と、それをどうやって作業フローに組み込んでいくかという、現場よりの実践的な話でした。
多分、開発で言うところのクラス設計の話になるかな、と思います。
「CSSの抽象化」のような技術的な話かな?とも思いましたが、もっと現場よりの話でした。
大規模サイトの作業を前提としていたので、設計の工程と明文化を重視し、サイトで使われる見出しやリスト、あるいはナビゲーションといったページ要素を「コンポーネント」というパーツにまとめてHTMLコード込みのドキュメントに落とし込み、後工程でのぶれをできるだけ減らしていこうアプローチです。
サイト構築のフローの中で、HTMLのコーディング部分は「原稿さえあればすぐにできる」という印象がつきまとってしまったり、そもそもHTMLコーディングが何であるか理解されにくい場合が多いのですが、それを「マークアップ」という言葉を用いて、うまくフローに納めているのは、bAの経験がなせる技ですね。
非常に参考になりました。
DreamWeaver使いが知っておきたいセキュリティ
太田良典氏
「脆弱性」は「ぜいじゃくせい」と読みます。ここが大事、とのことです。
僕も「きじゃくせい」はよくきいていましたが、「もうじゃくせい」とか「ぼうじゃくせい」は初めて聞きました。日本語って難しいですね。
個人でのIPA届け出数日本一の太田さんによる、セキュリティの話です。
WebSigでの話題と多少重複する内容もありましたが、Dreamweaverでデータベース込みの動的なページを簡単に作れるのは知らなかったので参考になりました。
デザイナー向けの話なのでそれほど突っ込んだ話ではなく、フォースフル･ブラウジングとSQLインジェクションの説明を簡単に説明されていました。
これならいける? DreamWeaverで始めるCSSレイアウト
こもりまさあき氏
DreamWeaverを使ったクラス・ID付けと、CSSでのレイアウトを実演するという、どちらかというと「これからCSSを導入しよう」というくらいの初心者向けのセッションでした。
DreamWeaverでの作業を見られるのはよかったのですが、もう少し突っ込んだ話をしてくれてもよかった…ような気もします。
デジタルアセットマネジメント
境祐司氏
今までテーブルレイアウトを使ってページを作成していた製作会社が、フルCSSレイアウトの作成方法にスタイルを切り替えるためのコンサルテーションを、実際の資料を用いて解説していました。
スニペットを活用して作業の効率化を図る、というのが落としどころですが、そこに至るまでのドキュメントの作り方と、教育方法という点が、とても参考になりました。
一枚絵をFireworksでスライスしてテーブルレイアウトのページを作るという方法に慣れている人からすれば、CSSを用いたコーディングは謎が多くてまどろこっしくてたまらないと感じているように思います。
そこを、現状分析と図解資料を多用して説得・あるいは納得させ、10日間で一通りコーチングするという、ハタから見ると結構強行軍なスケジュールと内容の実例でした。
実際のところ、古くから続いているサイトやサービスがビジネスとしてうまく回っている場合、CSSレイアウトに切り替える事に必要性を感じないという人は今でも結構多いので(本当に必要ない場合もありますが)、その人たちを説得するための方法として覚えておこうと思います。
あと、今回のセミナーの企画を行っていたスイッチの鷹野氏の娘さんの映像(パーティって何?という映像)がセッションの合間合間に挿入されるのが印象的でした。
そしてセッションの合間に、その鷹野氏が、「社内で『こんなに頑張ってまでイベントをする必要はない』と突き上げを食らっている」と、冗談混じりにぼやいていましたが、CSSのようなあまり日の目を見る機会のない技術にフォーカスして定期的にイベントの場所があるのはとても有り難いので、続いて欲しいと切に願います。
もっと場当たり的にCSSを直す方法
前のエントリーを見て思ったのですが、なんとなく筋道立てて書こうとしているところが言い訳臭くてダメですね。
そういう訳で、本当に場当たり的に、後のメンテナンスのことなど考えずに、今ここにある問題をしのぐためにCSSを直す方法を書いてみました。
問題箇所をすべて洗い出す。
校正部門とかチェッカーのバイト君とか後輩を泣かせて、各種ブラウザと画面解像度、その他必要な条件での表示確認を行います。
自分で確認すると、今まで見慣れているページなのでどうしても見落とす箇所がありますし、なにより大変なので、できるだけ理由を付けて人にやらせましょう。
問題箇所はバグ対応システムか表に記入してもらい、あとで修正漏れや見落としがないようにします。
人間自分が楽をするのが一番です。
cssファイルをすべて印刷する
cssをページの要素やブラウザごとにモジュール化している場合、非常に見通しが悪くなっていますので、まずは全部印刷し、机に広げて眺めてみます。
そして、適当にあたりを付けて修正しなければいけない箇所をピックします。
インデントのずれやコメントの記述漏れなどに目が行ってしまいますが、今回は場当たり的な対処療法なので見なかったことにします。
とりあえず枠で囲う
下記のユニバーサルセレクタを追加
*
{
border:solid 1px #f00;
}
この状態で、意図せずに枠からはみ出ているブロックがある、枠が表示されない、ブロックの形が意図しているものと違うなどの問題があった場合、そこのクラスやIDのスタイル指定に問題があります。
本当は別の場所に問題がある場合も多々ありますが、ここでは「木を見て森を見ず」方法で進めます。
とりあえず絶対配置にしてみる
floatで悩む問題はこれですべて解決します。他にいろいろ問題が出てくる場合も多々ありますが気にしません。
とりあえずブロック要素を増やしてみる
子要素が親要素を突き抜けたり、marginやpaddingが意図したとおりに表示されない場合は、divタグなどでネストを増やして様子を見ます。それでもだめならもう一重。
度が過ぎるといわゆるdiv厨という奴になりますが気にしません。
あきらめてテーブルレイアウトにする
(表層的には)クライアントの望むものは、構造化された文章のwebページではなく、PCのブラウザでレイアウトが崩れないwebページです。
と、自分に言い聞かせてテーブルレイアウトを取り入れましょう。
フルCSSスタイルの過渡期の頃に言われていた「ハイブリッド型」というスタイルです。
再確認
すべて修正が終わったら、また校正部門かチェッカーのバイト君か後輩を泣かせて確認を行います。
校正の人って、仕事が細かくて地味で神経を使うのに色々文句を言われて大変ですよね...。
場当たり的にCSSを直す方法
気がつけばもう12月です。皆さんいかがお過ごしでしょうか。
会社の近くではイルミネーションとかイベントとかいろいろあるようですが、自分はインドア派なので関係ありません。か、関係ないって言ったら関係ないんだからね！
さて本題。
ここ最近スタイルシートをガリガリ書いたり修正したりとんでもない不具合に頭を抱えたりしていますが、多少作業の流れのようなものが見えてきたので、忘れないうちに書いておきます。
「明日の9時までにデータを納品したければ行けないけどIEとfirefoxで表示が違うのが直らない」とか「昨日旧にIE5に対応してほしいとクライアントに言われた」という場合には役に立つかもしれません。
時間がある場合は文書設計とCSSの構成設計を見直してください。それが一番まっとうで確実です。
1.原因の切り分け
- CSS表記ミス。そもそもバリデーションが通っていない
- HTMLの記述ミス。link要素の書き間違い、クラス・ID名の間違い
- ブラウザの不具合・バグ
css validatorやfirefoxのextensionであるfirebugやIEのDOM inspectorや2ch CSS バグスレッドなどを使用して不具合の場所を特定します。新しい不具合であれば、mixiに質問を投稿するという手もあります。
概ねIE5.x系のバグだったりしますが、まれにIDとクラスを間違えて書いていたとか、importでCSS内に読み込むCSSが読まれていなかったりする場合もありますので、まずはCSSをいろいろ触る前に原因を特定しましょう。
それでも見つからない場合は、スタイルの指定をひとつひとつコメントアウトなどで外したり、枠線を追加してみて原因を絞り込んでいきましょう。
2.修正の方針を立てる
- (動的ページの場合)ページの生成時にブラウザ判定を行ってlink要素の出し分けを行ってブラウザ分岐する
- javascriptを使ってブラウザ分岐する
- 条件分岐コメントを使ってブラウザ分岐する
- hackを使ってブラウザ分岐する
- html文書を修正した上で上記どれかでブラウザ分岐する
- あきらめてクライアントへの言い訳を考える
分岐の必要のないようなCSSをかけるのがベストで、その次にhackで対応するのが一番楽ですが、hackは文法的に正しくない場合が多いので、閲覧条件に依存しない分岐方法がベストです。というと、動的生成か条件分岐コメント位しかありませんね。
最後の「あきらめてクライアントへの言い訳を考える」は、案件の最初の段階でターゲットユーザーとブラウザを明確に決めた上でHTMLの構造設計を行っていればまず出てこない言葉ですが、そのあたりがぼんやりしたまま作業に入ってしまうと納期直前や検収時に突然「このページNN4.7で見れないんだけど」とか言われてしまうので注意です。
3.修正
直してブラウザで見て、の繰り返しです。
firefoxのWeb Developerを使うとリアルタイムで修正結果が表示に反映されるので便利です。
また、importを階層化したりhackを使うと、Dreamweaverのプレビューは全く当てにならなくなるので、最初からブラウザで確認した方が後でがっかりしなくてすみます。
4.検証
全部修正したら、改めて対象ブラウザですべて確認します。