3 posts tagged “css”
CSSのルールほげほげ言ってた前回、ものっそい途中で終わってましたので、続きを…。
と、いうわけで、W3Cマニアと実際のガリガリ作らなきゃならないWeb制作の現場とはかなり意見と価値観の相違があったりするわけです。
さらにハケン全盛のこのご時世、DTDってなに？ CSSってなに？レベルの派遣さん達が運営できるようなマニュアル作りor設計をしなければならないわけですね。
そうしてW3Cマニア達はストレスを貯めていくわけです。
というのが前回までに書いた部分（内容合ってたっけ…適当かもしれませｎ）。
じゃあどうやって設計していったら、アクセシビリティを落とさず、ソースレベルで満足いくものができるのか？
こちらが聞きたい！
んですが、とりあえず私の意見を。
8：2方式を用いればいい。
これって何？ってところですが、ミツエーリンクスさんのソリューションの基本理念です。もろパクりです。
でも公開しているのだし、「これはいい！」と思ったらパクらせていただかなければ損です。（公言するのは別として）
ミツエーリンクスさんのご説明をそのまま拝借します。
8：2方式は、弊社のソリューション開発思想です。お客様のニーズは、80％まではパッケージで対応できますが、要求項目を最適化するためには、20％のカスタマイズが必要です。弊社は、8：2方式によって、お客様独自のソリューションをスピーディに達成いたします。
また弊社は、お客様が必要とするソリューションをお客様それぞれに合わせて開発するというソリューション開発思想をもちます。したがって、全てのソリューションは、部分的なカスタマイズおよびシステム拡張が可能であることが特徴です。
と、いうことだそうです。
詰まるところ、8割テンプレ、2割オリジナリティってことですね。
基本設計・骨組みといった部分は完全にテンプレです。
あと2割はトップページやユーザーへの配慮・デザインなどの部分で完全にテンプレには当てはまらない部分ですね。
9～10割テンプレでいこうと思うと失敗します。テンプレ作成の時点で今後発生し得るパターンを全て洗い出すのは容易ではないし、レアパターンへの対応などいくらでも考えられるので無駄なものをたくさん作ってしまう結果になってしまいます。
そういう意味で8：2方式はかなり効率良く、また、クライアントにとっても作成手順が明確で資料も出しやすく、コストも減るという一石四鳥くらいなナイス方式なわけです。
というわけで、「8：2方式」おすすめです。
具体的にどう活用するかというところですが、これはどんな場面でも使えます。
例えばWebのお仕事一式これでいけちゃいます。
- 営業（コンペ含む）
- 企画・提案
- システム設計
- デザイン設計
- XHTML・CSS設計
納期は迫る。でもソースぐちゃぐちゃ。とりあえず仕上げて納品。だが、運用できないゾ！とクレームが来る…。
小さいサイトならそのあたりで困る事も、破綻することもないでしょう。しかし、デザインがページごとに異なるような中規模～のプロジェクトは単純ではないのです。破綻せずにソースを書ききれるクレバーな頭が欲しい所ですが、ないものねだりしても仕方がないのです。（デザインの時点である程度まとめておけ、というのは言いっこなしです。どうにもならないプロジェクトもあるのです）しかも、一人がクレバーでもちゃんとした設計書を書いておかないと複数人で作った時、ぐちゃぐちゃになって誰も把握できない状態になることは明確ですね。
このような問題も8：2方式で解決していけます。
まずはマークアップ設計の概念をパーツ単位に落とし込んではどうでしょう？
無茶苦茶なデザインの表現をリクエストされない限り、default.cssと基本的なマークアップを施したファイルだけ最初に用意しておけば、パーツ単位で組み込んでいけばCSSも（X)HTMLもポンポンはめていくだけで完成してしまいます。これなら誰が組み込んでもソースに狂いは出ないし、新規のCSSが無駄に増えていくこともない。とてもシンプルで効率的です。
このdefault.cssと基本マークアップだけ作り上げる力さえあれば、巨大サイト構築も怖くありません。むしろどんどん受注したくなりますね。会社はウハウハ。これぞ会社と社員のwin-winな関係を築くものではないですか？（とか言ってみる）
そういえばCSSのルール、というタイトルの割にどこにもCSSのルール書いてません。
これはタイトルの付け方のミスですね…。
近いうちにCSSのルールに関する記事をPostしたいと思います。（また次回か…）
blurblue.comというドメインを再取得*1してからしばらく経つのですが、まだデザインできていません。
ですので、CSSは完全削除。
なんかもうこれはこれで行き着いている気がします。
ブラウザ標準。デフォルト表示。デザイン一切無し。
とか言ってますが、近日中にデザインしようと思ってます。
なんだかんだCSS云々言っているサイトに限ってOperaで崩れていたりするサイトが多いので、デザインの質もさることながらコーディングの質もマックスでいこうかなと。まずはそこを目標とします。
まだコンテンツも決めかねていたりはします。
CSS系のtipsをPostしていこうというのは決めているのですが、こちらのVoxとの記事の切り分けをどうしようかと。
どっちかというとVoxにtipsをPostして、日記系はBlurBlue-Noteに書こうかなとも思ったりします。
というのも、Voxはトラックバックができないから…。
うまいこと切り分けてる人いないでしょうかね。
Vox内にはすごい数のBlogやらSNSやらを抱えている人が多いような気がするんで、ちょっと探してPostもできたらいいなとか思います。
*1：以前いた会社では社員１人づつに好きな.comドメインを与えてくれてたので、blurblue.comを取得したのですが、辞めたため削除されていたのです。
CSSNiteのサイトで益子氏の当日資料がアップされていました。
益子氏と私のCSSソースの書き方や考え方などは似てる部分が多い。
というのも教科書を読んだこともあるので少なからず影響は受けているからかもしれないけど。
ちなみに
「font-sizeのサイズ指定はemで！」
というのは賛成しかねる。「％じゃいけないんだっけ？」みたいなところだ。
ついでに言うと
* { font-size: 1em;}
としてしまうと、ユーザーがフォントサイズを変えたとき、一気に大きくなったり小さくなったりする問題があったと思うし。（益子氏はユニバーサルセレクタはsmallなどとしていますが）
ちなみに私は%派です。
まぁ、概ね納得なんですけど、いつも思うのが（益子氏に限らず）CSSマニアな人や構造マニアやその手のコミュニティなんかで叫ばれている「完全なる文書構造と意味を付加したID/classの設定。それに対するIDを前提としたCSSのエレガントな書き方」には最近飽き飽きしてきている。
一言いいたいのは「じゃあ、そのエレガントなソース・文書構造の知識をデザインを重視されてしまった、巨大ECショップのマークアップやCSSコーディングに対してフルに活用できるのか？」ということ。
結論としては、経験上無理に近い。
少なからずマークアップエンジニアと呼ばれる職種にいる私としては、なるべくエレガントなソースを書こうと思うし、これでもかってくらい文書構造を考えたりする。
が、元々築き上げてきたワイヤーフレームを無視したデザインに対してクライアントがGOサインを出してしまった場合、我々コーディング部隊としてはどうやって意味のある構造を保ちながらCSSを活用してサイト構築をしていくか…。
大抵そういうデザインはトーン&マナーがあまりうまくない。というかグリッドすら守られていなかったりする。
『potision使わなきゃ表現できんよ！』
なんてことはザラ。最終的にスタイルが増え過ぎちゃって、「誰が解説書書くんですか…？」みたいなノリになってしまう。
しかも、運営が入るとまた話が別。
いかにHTMLも理解しておらず、いまだに<font size=5 color=RED>とか書いちゃうような人たちに使いやすく作るか…。
例えば2カラムのコンテンツエリアを
<div id="contents">
<div id="content">メインコンテンツ</div>
<ul id="localNavi">
<li id="home"><a href="/">ホーム</a></li>
<li id="menu1"><a href="/menu1">めにゅー１</a></li>
</ul>
</div>
とした場合、多分、li～/liをコピペしていけばメニューが増えていくことはわかってくれるだろうが、突然contentsエリア幅いっぱいのバナーを表示したい！とか思ってしまった担当者が取る行動は、
-
メインコンテンツ部分にimgを挿入。横にはみ出てしまい制作会社にクレームの電話。「意味わからん。ちょっと画像入れただけでページが壊れた！」
-
なぜかtableをメインコンテンツ部分に挿入の上imgを挿入。以下1番と同じ。
-
contentsの外にtable＋imgを挿入。レイアウトは希望通りいった。完。
さて、これで良いのだろうか…。
否
良いわけがないのである。
あらかじめどんなレイアウト変更が発生するのか？というところを要件定義書に明記しておかなければならない。
しかし問題の多い案件は、早くもこの段階で問題が発生する。
- 要件定義にポイントを明記しきれない
- FIXした要件定義の内容を運営チームが存在すら知らない上、「素晴らしいCSSでとても運営はやりやすくなるリニューアルだ」と思いこんでいる。（その思いこみ自体はイイが、制作者の常識を越えたラインでなんでもできると思いこんでいるのが問題）
- 要件定義がFIXしているのにも関わらず、開発に入った後かなり時間が経ってから要件変更が入る
などなど…。「アルアル」的なものをちょこっと書いてみました。
運営チームというものに知識を求めてはいけない。最悪、HTMLのHの字も知らない大学1年生なんかをバイトで雇ってソースを書かせてしまったりするからだ。（そんな場合の事を考慮していたら何もできないのでふつう考慮しないが）
上記は大げさだとしても、fontタグを挿入できるくらいの人なら理解できる程度のカスタマイズ方法を明記すべきかな、と思う。
．．．．うう 最近寝ないで仕事し続けてたりするのでもうダウンします。
続きはまだ今度。
