みなさん、はじめまして。ふうりと申します。
埼玉で、フリーでWeb制作をしています。個人的なBlogとして、Mayunezu Spaceを運営しています。
Dreamweaverが、CSS回りの機能にかなり手を入れてバージョンアップしましたね。Blogブームも手伝って、これからはデザイナーがCSSを使う機会も増えていくのかなと思っていますが、現状、今プロとしてお仕事をされている方であればあるほど、自由にCSSを使えない状況に陥ってはいないでしょうか？
NN4.7でも同じように見えるようにしろ！と言われたら、それだけでかなり大きな制限が出ますけど、私の回りでは、まだ「しろ！」というクライアントが多いです。ということで、Blogのようにデザインの完全分離なんてことは夢のまた夢という世界。こういうのって日本だけなんじゃないの？とかいう声も聞きますが、ホントなんでしょうか？
そんな中、先日、「完全分離」を条件としたコーディングのお仕事を請けました。多分、Blogをやっていなかったら、相当戸惑ったことでしょう(^^; ちょっとでも、「完全分離」の感覚を知っててよかったなと思いながら仕事をしていました。
今回作ったのはクライアントの社内で使うシステムの画面だったんですが、なぜ完全分離を求められたかというと、「ダイナミックに出力されるコードが少なくなるから」だったんですね。HTMLにデザイン的な要素がなければ、その分コードが減るわけだから、エンジニアにとっては楽になるわけです。
デザインをする側にとっては、特にそれがシステムに絡む画面の場合、やはりそのシステムをある程度理解していたほうが作りやすいということはあります（が、説明されてもちんぷんかんぷんなことも多い(^^;）。エンジニアは逆に、デザイナーの立場も分かって画面設計をしたりすべきだ！なんて言われたりもします。でも、これがなかなか分かり合えなくてお互い苦労することも多いです(^^;
今回の仕事で、エンジニアさんは、とても作りやすかったと喜んでくれました。
そのとき、ハッと気づいたんですね。「完全分離」を意識して作れば、あんまりシステムのことが分からなくてもエンジニアさんに喜んでもらえるんだ！って。もしかしたら、今までのお互いの苦労がかなり軽減されるのではないか？と思ったんです。デザイナーは、デザインのことはみんなCSSに書いてしまえばいいわけだし、エンジニアは、難解なテーブルで組まれたHTMLを解読しなくてもよくなるわけですよね。
もっとエンジニアにやさしいデザイナーになるために、CSSでのデザイン（コーディング）をもっと極めよう！と決意した私でした。
CSSをうまく機能させるためには、正しいHTML(XHTML)というのが大前提となります。
したがって、適切なサイト構造設計、画面内要素設計などを経て、最終的に妥当な文書構造を示すHTML要素配置が確定しないことには、CSSでの記述を始めることはできませんし、CSSを記述する前にページの文書構造を完全に把握していなければなりません。
また、HTML(XHTML)の設計とCSSの設計は、まったく別のタスクとして並行作業できるかというと、そういうわけでもなく、常に入り交わるタスクとなるでしょう。ブラウザの実装依存にもとづく制限があるため、文書構造そのものに手を入れる必要も出てくるからです。ですから、CSSの設計をデザイナの役割にするのではなく、HTML(XHTML)およびCSSの設計・実装はすべてエンジニア側であったほうが圧倒的に進めやすいと思います。
デザイナはCSSでどうなるとかではなく、サイト構造および画面内要素配置といった設計書の合意のもとで、エレメントデザインなどから最終的にページデザインへと落とし込んでいけば良いでしょう(サイト構造などの設計書を、デザイナが作ってしまっても良いでしょう)。
そして、デザインの意図や性能、それがもたらす経験価値などなどを、エンジニアは最大限に汲み取り、少なくとも必要とするターゲットブラウザ間で矛盾が生じないようなHTML(XHTML)/CSSを設計・実装するのです(基本構造となる要素配置は既に済んでいることが前提とされるため、ここで実装のためにいじるHTML(XHTML)というのは、CSSの実装に依存して編集すべき個所という意味)。
* かなり端折っていますが、簡単に、HTML+CSSなサイトのワークフローについて書いたもの：
http://w3j.org/articles/cssready/cssready03.html
プロジェクトという観点で考えれば、エンジニアとデザイナの間をつなぐ適切なプロジェクトマネジャーが存在するかどうかが、エンジニアにやさしいデザイナになれるか否かのポイントにもなるのではないでしょうか。
なお、ふうりさんのいう「エンジニア」というのを、いわゆるHTMLを書いたりするコーダーとかマークアップエンジニアとか呼ばれる人であると解釈しましたが、ソフトウェアを実装したりするプログラマとかソフトウェアデザインエンジニアとか呼ばれる人のことであったりすると、少し話が変わってきます。が、おおむね同じです。その場合は、エンジニアには2種類必要で、プログラムコードを担当するプログラマ的エンジニアと、HTML/CSSなどのフロントエンドを担当するエンジニアとがいるという前提となれば良いので、そう読み替えてください。
>そして、デザインの意図や性能、それがもたらす経験価値などなどを、エンジニアは最大限に汲み取り、少なくとも必要とするターゲットブラウザ間で矛盾が生じないようなHTML(XHTML)/CSSを設計・実装するのです
これはつまり、フロントエンド担当のエンジニアは、HTML(XHTML)/CSSおよびウェブページというものに関してのスペシャリストであれ、という意味です。
デザイナが伝えたいことをすべて受け止めて、立ちはだかるブラウザの実装依存やバグの壁を乗り越えられなければならないというか、ようするに此処でいうところの表現でいうと「デザイナにやさしいエンジニア」ということですが。
プロジェクトを成功させ、クライアントおよびそのクライアントまで幸せになってもらうためにも、異なる職種では“お互いに”やさしくなりあう必要があると思うからです。
こんにちは、ふうりさん。
某MLなどなど（いくつかあるらしい）でお世話になっています。アキです。
「スタイルシート・スタイルブック」予約しましたよ～。
こちらをmybloglistに入れました。勉強させてくださいね～。
＞yuuさん
とてもとても丁寧なアドバイス、ありがとうございます！おっしゃっていること、じっくり読みました。サイトも拝見させていただきました。
CSSのあるべき形としてとても理解できますし、そうすべきだと思います。
ただ、私のようなフリーの制作者の場合、デザイナー＝CSSやHTMLの設計者となる場合がとても多いと思うんです。エンジニア側がCSSやHTMLをぜんぜん知らない場合も多いです。つまり、デザイナー＝コーダーという意識のクライアントもエンジニア（ここでは、プログラマの意味で言ってます）も、とても多いということです。
ということで、
> これはつまり、フロントエンド担当のエンジニアは、HTML(XHTML)/CSSおよびウェブページというものに関してのスペシャリストであれ、という意味です。
結局はこれに行き着くのだなと思います。
Web制作のワークフローは、まだとても未成熟で、迷ってばかりで、大どんでん返しがいっぱいのような気がしています（少なくても私の周りでは）。
ただ、実を言いますと、私はここまでのレベルの話をしたわけではなく、「エンジニアさんの力になれた！近づけてちょっとうれしかった」という気持ちを書いたに過ぎなかったりもします(^^;
yuuさんにコメントをいただけて、とてもためになりました。私だけではなく、読んだみなさんもきっとそうだと思います。
本当にありがとうございました！
Good Point. Anyways, this was where i met her. You can join for free as well www.redtricircle.com
My friend told me about your web site and I really enjoyed it. Very nicely done. Very interesting!
Poker
