前に書いたtapestryネタで、面白いレスをいただいたのですが、割と重要な話なので新しいエントリとしてレスを書きたいと思います。

デザイナーの作るHTMLを壊したくないWeb開発者のために
ただ、デザイナーがHTMLをコーディングする際にjwcidのコードも埋めるわけですが、これが正しく行われているかどうかのチェックが難しいと感じています。
プログラム言語ならばコンパイルエラーなどで記述ミスなどはすぐに知ることができますが、デザイナー側だけでTapestryの作業を完結することができず、結局プログラマがHTMLに手を入れてしまうという状態が身近には多いです。

これを書いた頃とは僕の感覚は変わってきていて、この件の結論から言うと、「jwcidはエンジニアが足せば良い」かなと思っています。

デザイン段階でのHTMLでのコーディング行程と、後の動的コードを埋め込む行程は、どんなフレームワークを使おうが使うまいが異文化技能を持った人同士の連携となるのが現実だと思います。作る会社が違っていて、責任範囲、組織が分離していることも多々あるでしょう。

エンジニアサイドの視点では、昔からフォームのname属性を画面設計書に書いても守られないとかそういうジレンマがあったと思います（多分）。まったくそれと同じ論理なのですが、僕は当時からエンジニアには、そういうところの遵守をコーダーに期待するなと言っていました。彼らは彼らで責任を持たなくてはいけないところが多々ありますから、ビジュアルに影響のないname属性ぐらいは良いでしょ別に・・・と。

特にjwcidと言ったものは完全に開発都合の話なので、そういうのはエンジニアが責任を持つのが一番精神的によろしいのではないかと。全体としてはエンジニアが改造したHTMLをフィードバックしてデザイン修正できればそれで御の字なのかなと。現実的にはこれが難しいですね。

昨今、CSS+XHTMLでdivやimgのIDがお互いのクロスポイントとして共有が必要とされる時代になっていて、良いもの最新の流行のものを作ろうと思ったら、デザイン、HTML、制御、サーバサイドの完全分業はもはや無理です。

というかクライアントサイドに踏み込まないで済まそうとするのは諦めてください！！と全てのWebエンジニアに強く言いたいぐらいです。

このエントリを書いた当時の発想では、サーバサイドとはせいぜい「フォーム繋がり」、必要なところは後からリライトで済むことを想定していましたが、今はエンジニアがDOM+JavaScriptを普通に使って、style属性を書き換える時代ですから、もっと深いつながりが必要になります。

つまり結局のところ、エンジニアがHTMLを直すのは免れないのかなと。できればCSSは直さずに済ませたいですね・・・ぐらいの勢いです。

このエントリを書いた当時と完全に変わっている点として、Ajaxをはじめとする高度なJavaScirpt記述が求められるようになってきたために、コーディング行程でデザインを実現するためのidの使い方、CSSの書き方が、エンジニア行程にとって無視できなくなってきたこと。結局、あとから制御するためにdivを追加せざるを得なかったり。そのdivのためにCSSを追記しなくちゃいけなかったり。

そういう意味で方法論は２つあって、
・完全な画面設計書を作成し、idを事前設計しそれを誰かが遵守する。（djodjoさんはこういうプロセスを取られているかと。）

もう一つは、
・そういうことは諦める。結局、タグの書き方、CSSの元となるid,場合によってはidとclassの使い方を制限しなくてはいけないケースもありうるが、デザイン実現とAjaxまで考えてやれる奴がいるのか？または、そういう技能を持った人が時間的にフォローできるのか？と。

この画面設計書を書く人に求められる能力は、デザインとIAとエンジニアリングの設計者の両方の技能が必要ですが、なんというか、そんな奴いないわけですよ。
アクセシビリティ実現のためのタグ構造化を設計することでさえ相当難しいのに、さらに先の動的制御の行程までふまえたHTML設計ができますか？ということになってしまうと思います。

業務アプリであれば、今までは割とシンプルなフォーム繋がりでいけたと思いますが、今後、ユーザビリティを考えてAjaxやらレイヤーのウインドウを使ったりすると、現状の経験度からすると、かなり難易度が高い人が多いのではないでしょうか。僕も例外ではなく、まだそれを計算づくで設計するほどの経験値はないです。

もうちょっと経てば、WinFormのようなウインドウアプリを実現するJavaScriptフレームワークが出て、VisualStudioのようなツールで全部面倒見たりできるようになると思いますが、まだまだプリミティブなJavaScript、DOMを考えながら作ることは必要です。また、そんなツールが出てきて、どうやってデザインと結びつけるのよ・・・と。結局、エンジニアが手作業で反映するんじゃないでしょうか。

長々と書いてアレなんですが、結局のところは現状のWebトレンドを追うためには、「すごく人のスキルに依存する」時代になっているなぁと思いますし、そのためには個々がスタンドアローンにプロフェッショナルである必要がある、と。

つまり、
・デザイナは、Webアプリケーション実現を考えたデザインをする（CSSの複雑度＝ブロック要素のidへの依存性を構築してしまうのは、この人だし）
・コーディングする人は、できるだけ独立性の高いCSS記述を心がける・・・で良いのかな。あまり断言できないけど。エンジニア視点からだと、tableタグ汚染とかbodyタグ汚染とか（このレベルでマージンを記述されて、tableを追記すると変な隙間があいて戸惑うとか）をどう解決するか？ってのがあります。
・エンジニアは、コーディング、デザインからCSSを理解し、うまくコントロールする。

理想的にはこれらの関係が、あるべきベストプラクティスに従っていけば、役割間の調整で苦労することはないですが、そのベストプラクティスが、少なくとも僕は、まだ模索中ですね。こういうのがマネジメントも含めて組織のノウハウ、力だと思います。まずは、HTMLコーダー（いわゆるマークアップエンジニアですね）の重要性の再認識からだと思います。