私はあまりにも頻繁にアカデミックなアプローチを取る傾向があり、自分の開発において厳格な原則に固執する傾向がありますが、現実には、もう少し慎重でなければ、プロジェクトをより早く完了できたはずです. 適切な実用性を見つけようとしています。
私は、(私の言葉で)「コンテンツ構造には厳密に HTML を使用し、残りは CSS マジックに任せる」というサイトを設計するために「禅」のアプローチを取りたいと考えています。これは実際にどれほど実用的ですか？私が遭遇する問題の 1 つは、最初にサイトを開発 (機能するように) し、後で戻って設計したいということです。構造的にサイトの流れをどのようにしたいかはわかっていますが、CSS レイアウト、グラフィックス、またはその他のデザイン要素で遊んでさえいません。ここで正しいアプローチは何ですか？
それは絶対に実用的であり、無限の利益をもたらします。実際、それはまさに CSS と、コンテンツとレイアウトの分離が設計されているものです。
上記の正しいアプローチは、さまざまなチームがさまざまなタスクを目前に進められるようにすることです。これには (おそらく) 非常にラフな初期グラフィック デザインと、「#viewport」、「.user」などの名前付け規則の文書化され、共同で合意されたセットが必要です。
マークアップ チームは通常、バックエンド主導で設計チームをわずかにリードしますが、必要に応じてマークアップを変更したり、設計者の管理下に置いたりするのに十分な柔軟性を維持する必要があります。
これは私の 0.02 ドルですが、1 人が両方の役割を担っている場合は、最初にマークアップ/バックエンドを先導し、必要に応じて設計段階、マークアップ、設計を繰り返し行っていると思います。
あなたが従いたいアプローチは正しいものです。たった2つのこと：
（私の英語で申し訳ありません。スペルの修正は大歓迎です。）
現在 XHTML を使用しない理由については、http://www.webdevout.net/articles/beware-of-xhtmlで説明されています。要約すると、XHTML は、そのように提供しない限りサポートされず、古いブラウザーを対象とする場合 (ほとんどの機能がまだ未熟でしばらくの間大幅に変更されていないときに実装されていることを考えると、どの IE バージョンも古いものです)、選択の余地はありませんが、 HTMLとして提供します。
XML が提供する機能 (SVG、MathML など) を必要としない場合を除き、HTML を使用してください。HTML に勝る重大な利点はなく、よりセマンティックになり、より優れた CSS サポート (さらには少なくなります) が得られます。しかし、より広い互換性が得られ、レイアウトがより予測可能になります (たとえば、表のセルは HTML の行の最初のセルから継承できますが、XML ではそのようなことはなく、XHTML のどこかに例外があるかどうかさえわかりません)。
バリデーターは、HTML と同じように XHTML を書くのに役立ちません。厳密なものを使用すると、嘘をついてHTMLだと言うと、brタグで/について大騒ぎするのは何だろうと疑問に思うことさえあります。(XHTML を HTML として提供する場合、Firefox ビュー ソースは明るい赤で表示されます)。もっと多くの例を見つけることができると確信しています。
これは非常に実用的で、HTML の見栄えの良さに驚かれることでしょう。私は CSS リセット ファイルを使用して作業を開始するのが好きで、個人的にはYUI リセットが気に入っています。考慮すべきもう 1 つの Zen 項目は、目立たない JavaScriptの使用です。これにより、コードのさまざまなレイヤーがさらに分離されます。jquery、prototype、dojoなどの JavaScript ライブラリがこれに役立ちます。
それは可能であり、あなたのサイト (そして少なくともあなたの Web デザインのスキル) は、そのためにはるかに優れていると思います. しかし、それには特定の学習曲線もあります。多くの人が持っているよりも、XHTML/CSS 仕様をより完全に理解する必要があります。
HTML を検証できるようにすることは、ほんの始まりにすぎません。ああ、ページをレンダリングするときは、すべてのブラウザーが厳密モードで実行されていることを確認してください。
もちろん、IE をサポートするための回避策が必要になりますが、それはいくつかの方法で実行できます。まず、IE は条件付きコメントをサポートしているため、IE のバグを修正するためだけに特別な CSS スタイルシートを含めることができます。
場合によっては、JavaScript も少し必要になる場合がありますが、ほとんどの一般的な機能には必要ありません。
Sure, you can do that, but be prepared that it WILL NOT render under IE. On a recent web project, the majority of our front-end defects were fixing stuff in IE that already worked fine in Firefox. Maybe this will change in IE8, but I doubt it. In some cases we even had to write some javascript that would be executed on IE only to work around things that couldn't be done with just CSS.
理論的には良さそうですが、サイトのレイアウトを 100% CSS で作成することはできません。CSS を適用する何かを用意するために、まだいくつかのマークアップを使用する必要があります。とはいえ、この方法を使用すると、理想にかなり近づけることができます。私は、真の CSS の第一人者が実際に必要とするマークアップがどれほど少ないかに常に驚かされます。
あなたが本当に探している「禅」アプローチに近いのは xslt です。アプリが xml データを生成し、xslt がその xml を html/css に変換することで機能します。これには xslt を学習する必要があり、ページを生成するプロセスに別の複雑なレイヤーが追加されますが、探している分離が追加されます。理想的な世界では、プログラマーは xml データの生成についてのみ心配する必要があり、デザイナーはそのデータを使用してビジュアルを生成できますが、xslt はほとんどのデザイナーが処理できるよりも技術的であるため、そのように機能することはめったにありません。ほとんどの場合、プログラマーは xslt を生成することになり、目的を達成できなくなります。
私にとって有効なアプローチの 1 つは、最初に HTML を構造化してから、同じファイル内のタグに最小限の CSS を追加することです (適切なレイアウトなどを作成するのに十分です)。構造に満足したら、CSS を別のファイルに取り出したり、CSS を完全に作り直したりできます。これは私にとって適切なバランスをとっています。これはまだ軽量のプロセスですが、インライン CSS を見つけて置き換えるという潜在的な問題を回避できます。
理論的にはそうです。実際には、ブラウザーの違いにより、違いに対処するために JavaScript を少し追加する必要がある場合があります。
さて...何かの利点は、それを行うことの実用性とは異なります。IE や、不可能なことをやりたがる面倒くさいクライアントのことを忘れていませんか?
あなたが使用している厳密な DTD に例外を設けて、合理的なブラウザー セットで動作させ、Web サイト/Web アプリの利害関係者を喜ばせなければならないと言いたくなりました。
私は標準マニアであり、DTD ルールに 1 つでも違反しない Web サイトを構築できれば、私ほど嬉しい人はいないでしょう。しかし、4年経っても実用化できていません。
確かに、私が開発しようとしている Web サイトの要件を考え出すのであれば、それは可能かもしれませんが、それに対応するためにビジネス ルールを曲げる必要があります。私を信じてください、それが可能な唯一の方法です。