全国各地に「再構築」の春風が吹き、インターネット上では一時「div+CSS」が「流行」となり、数え切れないほどのWebサイトが独自の「再構築」を始めている。しかし、これらのさまざまな Web サイトのソース コードを開くと、笑いが起こることがよくあります。
6 層または 7 層のネストを含む div レイアウト、テーブルのないテーブル、純粋な div+a で構成されるページ、数百ものプレゼンテーション層クラスが見られます...最近では、宣伝する数冊の本を除いて、標準に関する本がますます増えています。 「高度なテクニック」について述べたとしても、本の最初の数章でそのような文章、つまり「構造と表現の分離」を強調しない人はほとんどいないでしょう。しかし、これらの本の読者のうち、最初の数章を真剣に読んだ人はどれだけいるでしょうか?それとも、退屈な構造の説明をスキップして、一見高度なレイアウトテクニックやハックに飛び込みたいですか?
実際、div+CSS という用語は最初からあまりにも多くの人を誤解させており、すぐに成功したいという心理がこの現象の元凶です。テーブルレイアウトのWebページ制作に慣れている人が標準に触れる第一歩は、やみくもにCSS技術を求めてさまざまなレイアウトを実現するのではなく、考え方を変える努力をすることです。
以下では、私の個人的な経験に基づいて、標準に準拠した考え方について説明します。その多くは、標準に触れたばかりの XDJM にとって役立つことを願っています。
1. 「コードの保存」はマーケティングツールであり、目的ではありません
「div レイアウトを使用すると、テーブル レイアウトよりも多くのコードを節約できます。」 この文を多くの本や Web サイトで目にしました。この文自体は確かに正しいです。「コードの節約」は Web ページの標準化の利点の 1 つです。ただし、それはあくまで「メリットの一つ」であって「唯一のメリット」ではなく、それが目的ではないことを覚えておいてください。 「コードを保存する」ということは、頑固な上司を説得するためによく使われるマーケティング戦略です。 Web ページの標準化の目的は「構造とパフォーマンスの分離」だけであり、決してコードを節約するためにコードを節約することではありません。私はかつて、サイドバーと Web サイトのメインコンテンツさえも同じ表示形式を持っていたため、統合クラスを使用しました (これを教える本はまだいくつかあります)。ただし、これは、ID を個別に命名するよりもコードを節約できます。これは、コードの優れた構造が失われることです。適切な構造を失うと、次のような影響が生じます。 1. ソース コードが読み取れなくなります。 2. Web サイトの保守コストが不明瞭になります。想像してみてください。リンクの色など、特定のコンテンツのプレゼンテーションが必要に応じて変更されると、ページのソース ファイルを変更してクラスを追加する必要があり、その作業負荷は単に ID を調整するよりもはるかに大きくなります。グループ化。そしてこのままでは構造はますます悪化し、元に戻すのが難しい悪循環が形成されてしまいます。
ID の命名時に別の状況が発生しますが、これも私の間違いです。当時は「コードを節約する」ために、メインメニューは「mm」、2番目のメニューは「m2」、3番目のメニューは「m3」という名前になりました。 Web ページが大幅に縮小されたため、他の同僚が引き継ぐのが困難になり、手間を省こうとしましたが、私自身も疲れました。同様に、ファイルやフォルダーの名前を単純化しすぎるのもよくありません。たとえば、「Website Reconstruction」では、すべての画像を「i」ディレクトリに保存することが推奨されています。非常に簡略化されたディレクトリ構造を詳細に説明し、他の制作スタッフ、開発者、さらには知識豊富な上司を含む関係者全員がそれを理解して実装できるようにしてください。そうしないと、不必要なトラブルが増えるだけです。
2.IDはスナイパーライフル、クラスは両刃の剣
優れた Web ページ構造を実現するには、ID とクラスの両方を熟達する必要があります。いわゆる「両手で握る、両手が強くなければなりません」。 ID はスナイパー ライフルのようなもので、スタイルをロードしたい要素を正確に見つけるのに役立ちます。クラスは、軽量でより柔軟に操作できる騎士の剣です。この 2 つを組み合わせることで、優れた構造のページを実現できます。そして豊かなパフォーマンス。しかし、現在では ID がクラスによって完全に置き換えられるという間違った見解が存在しています。実際、これはクラス全体を開いたときに ID を見つけることができないということです。この現象の原因は様々ありますが、根本的な原因はテーブル時代から受け継がれている「クラス=CSS」という概念が根強く残っていることです。クラスの方が ID より多用途で柔軟であるのは事実ですが、優れた Web ページ構造を構築する上でクラスの効果は ID よりもはるかに低いことも認識しておく必要があります。 id には必須の一意性があるため、id を通じて必要なモジュールを簡単に取得できますが、クラスにはこの利点がありません。モジュールに一意のクラス名を定義できますが、Web ページのスタイルを変更できるのはプロデューサー自身だけであることが前提となります。それ以外の場合は、スタイルが同じであることを確認して、前のクラスを直接適用する少し怠け者を探します。その結果、Web ページに「gonggao」または「xinwen」と呼ばれるモジュールが 12 個以上あることがわかります。 HTML コメントを大量に追加しない限り、この結果は明らかに私たちが望んでいる結果ではありません。さらに、前述したように、ユニバーサル クラスを通じて保存されたコードは、個別に定義された各クラスで無駄にされなければなりません。
ID はスナイパーライフルであり、クラスは両刃の剣です。
3. すべてのコンテンツが「コンテナ」として div を必要とするわけではありません
メインメニューには <div id="mainnav"><ul> または <ul id="mainnav"> を使用する必要がありますか?これはゲームの問題です。今のところ、私ですら、この質問に明確に答えられる人はいません。確かに、<div id="mainnav"> に <ul> 要素が 1 つしか含まれていない場合、この div は少し冗長に見えますが、ゴージャスなデザインに合わせるために、タグのレイヤーが 1 つ増えると、変更が 1 つ増えることになります ( aタグでspanを使用する人もいます）。元の属性を持たない div の固有の利点は、他のタグに匹敵しません。この命題で 1 つのことを説明したいだけです。つまり、<div id="mainnav"><ul> に加えて、<ul id="mainnav"> この書き方もあることを認識する必要があります。また、優れた構造とセマンティクスを備えており、ネストの層が排除されています。華やかなアートにこだわらなくてもいいなら、構造ももっとシンプルにできないだろうか？
この命題は実際には、「すべてのコンテンツがコンテナとしてブロック要素を必要とするわけではない」、「すべてのリンクがコンテナとして他の要素を必要とするわけではない」、たとえば多くのページにある「その他」のように拡張できます。 「<div class="more"><a>」と書く人もいれば、<p><a> や <strong><a> と書く人もいます。これらの「コンテナ」に <a> タグのみが含まれている場合でも、コンテナは存在する必要がありますか?直接書くと<a class="more">構造が壊れてしまいますか？セマンティクスが欠落するのでしょうか?レイアウトに影響はありますか？考え方が違えば、違うものが得られるかもしれません。
4. 職場の「構造と性能の分離」を実現する
この点について、インターネット上の多くの専門家は、まずエディタを開いて構造を完全に書き出してから、CSS に移動してパフォーマンスを書き、すでに書かれた構造には触れないようにすることを提案しています。
しかし、書籍を読むことを主な学習方法としている人にとっては、標準に関する書籍の多くは段階的に教えており、構造と表現を段階的に組み合わせる必要があるため、理解するのが困難です。いくつかの本にはこの点に関する示唆が含まれていますが、いくつかの短い文章では、読書プロセス中の微妙な効果にははるかに劣ります。制作スタッフが構造を十分に把握できている場合、構造とパフォーマンスを同時に書いても、結果にはあまり影響を与えません。しかし、私の経験では、構造とプレゼンテーションを同時に記述するよりも、構造とプレゼンテーションを分離する作業方法の方がはるかに効率的であると同時に、ページ上の要素を見逃すことも容易ではありません。
もちろん、いわゆる「構造とパフォーマンスの分離」は、パフォーマンスを完全に無視するという意味ではありません。パフォーマンスを考慮する場合は、CSS セレクターが構造を破壊することなくできるだけ多くのコンテンツを選択できるようにする必要があります。 。クラスをどこに追加するか、またはクラスを区別するためにどのラベルを使用するかは、人それぞれの意見があると思います。異なる設計ドラフトを結合する場合、場合によっては対応する変更を加える必要があります。ただし、これらの変更はすべて、コードの構造と可読性を損なわないという同じ前提を持っている必要があります。
さらに、視覚ツールは悪魔であることを認識する必要があります。ビジュアル インターフェイスで表示される効果は、多くの場合、実際のブラウザの効果とは何千マイルも離れています。私たちが本当に互換性を持たせたいのは、エディターのビジュアル インターフェイスではありません。
5. CSS は万能薬ではありません。CSS なしで生活することも不可能ではありません。
CSS1.0 の時代と比較して、CSS はより多くのことを実現できますが、CSS は常にテクノロジーを上回っています。場合によっては、一部の効果を実現するために JS や他の言語を組み合わせる必要があります。 。また、CSS のみに依存するよりも JS を使用する方がはるかに簡単で、コードがより適切に構造化されている場合もあります。最も典型的な例はドロップダウン メニューです。このようなときは、よりシンプルで合理的な方法を使用するように自分自身、または上司や顧客を説得する必要があります。 DOM は Web ページ標準の重要なコンポーネントでもあるため、JS を使用することで Web ページの効率が低下したり、標準でなくなったりするわけではありません。むしろ、これが JS の最大の誤解です。そうは言っても、今日の時代では、デザインを行う人はインタラクションと制作について少しは知っておく必要があり、制作をする人もデザインとプログラミングを理解する必要があり、今の時代ではこれまで以上に関連する知識が求められています。 、特に JS のようなフロントエンド テクノロジを使用すると、この方法でのみ、あなたと同僚の共同作業が向上し、個人の成長の見通しが明るくなります。
「CSS がありません」とは、さまざまな不明な理由で Web サイトが CSS ファイルのロードに失敗することを指します。これがコードの品質をテストするのに最適な時期です。 CSS を使用しなくても Web ページが良好な可読性を維持している場合、この成果は W3C 検証に合格することよりもはるかに誇りに値します。