ホームページ  >  記事  >  ウェブフロントエンド  >  CSS の一般的な注意事項、アドバイスとガイダンス_html/css_WEB-ITnose

CSS の一般的な注意事項、アドバイスとガイダンス_html/css_WEB-ITnose

WBOY
WBOYオリジナル
2016-06-24 11:58:53793ブラウズ

多くの人々と大規模で長期的なプロジェクトに取り組む場合、すべての開発者が次のルールに従うことが非常に重要です:

+ **CSS を保守可能に保つ**

+ **コードを保持する明確で簡単である **

+ **コードをスケーラブルに保つ**

この目標を達成するには、多くの方法を使用する必要があります。

このドキュメントの最初の部分では、構文、形式、CSS 分析について説明します。2 番目の部分では、CSS の作成と計画に対する方法論、思考フレームワーク、態度から始まります。

## 目次

* CSS ドキュメント分析

* 概要

* 単一ファイルと複数ファイル

* 目次

* 章タイトル

* コード順序

* ルール分析

* ネーミング仕様

* JavaScript フック

* I18n

* アノテーション

* アノテーションの拡張使用法

* 準変更されたセレクター

* コードタグ

* 継承タグ

*書かれたCSS

* 新しいセクションを追加

* オブジェクト指向CSS

* レイアウト

* インターフェースサイズ

* フォントサイズ調整

* 略語

* ID

* セレクター

* 過度に変更されたセレクター

*パフォーマンス

* セレクターの継承

* `!重要`

* マジックナンバーと絶対比例

* 条件判定

* デバッグ

* 前処理

---

## CSS ドキュメント分析

どのような文書を作成する場合でも、統一されたコメント、統一された構文、統一された命名規則など、統一されたスタイルを維持するために最善を尽くす必要があります。

### 一般

線幅は 80 バイト未満に保つようにしてください。結局のところ、コメント内のグラデーション関連の構文と URL は例外としてカウントされる可能性があります。この部分については何もできません。

私はタブ インデントの代わりに 4 つのスペースを使用し、ステートメントを複数の行に分割する傾向があります。

### 単一ファイルと複数ファイル

スタイルを 1 つの大きなファイルとして記述することを好む人もいますが、それは悪いことではありません。以下のルールに従えば、問題は発生しません。 Sass に移行してから、スタイルを多数の小さなファイルに分割し始めました。それも悪くない。どちらの方法でも、以下のルールが適用されます。 2 つの書き込み方法は、ディレクトリとブロックのタイトルが異なるだけです。

### ディレクトリ

CSS の先頭に、たとえば次のような目次を書きます:

/*-------------- --- ------------------*

$CONTENTS

*--------------------- --- ------------*/

/**

* CONTENTS......あなたも読んでいます!

* RESET....................リセットのデフォルトを設定します

* FONT- FACE.....ブランドフォントファイルをインポート

     */

このディレクトリは、このファイルにどのようなコンテンツが含まれているかを他の開発者に伝えることができます。このディレクトリ内の各項目には、対応するブロックと同じブロック タイトルが付けられます。

より大きな単一ファイルの CSS を保守している場合、対応するブロックも同じファイル内に存在します。一連の小さなファイルを作成している場合は、ディレクトリ内の各項目に対応する @include ステートメントが必要です。

### ブロック タイトル

目次はブロックのタイトルに対応する必要があります。次の例を参照してください:

/*-------------------------------------- -------*

$RESET

*--------------------------------*/

ブロック タイトル プレフィックス `$` を使用すると、([Cmd|Ctrl]+F) コマンドを使用して、検索をセクション ヘッダーに限定しながら `$[SECTION-NAME]` を見つけることができます。

大きなファイルを保守している場合は、次のようにブロック間に 5 つの空行を残します:

/*------ --- ---------------*

$reset

-----------*/

[私たちのリセット

スタイル]

/*-------------- ------------------------ --*

$FONT-FACE

*---------------- --------------------*/

これらの大きなギャップは、大きなファイルをすばやくめくるときにチャンクを区別するのに役立ちます。

@include で接続された CSS のコピーを複数保持している場合は、このように空白行を残さずに、各ファイルのヘッダーにタイトルを追加するだけです。

## 順序

これにより、CSS 略語の最初の C の意味を最大限に活用できるようになります。

綿密に計画された CSS は次のように配置する必要があります:

1. **リセット** すべてのルート

2. **要素の型** クラスなしの `h1`、`ul` set Wait

3. **オブジェクトと抽象コンテンツ** 最も一般的で基本的なデザイン パターン

4. **サブ要素** オブジェクトによって拡張されたすべての拡張子とサブ要素

5. **修正* ※例外あり

このように、CSSを順番に書いていくと、各ブロックはその前のブロックのプロパティを自動的に継承することができます。このようにして、コードの相互にオフセットする部分を減らすことができ、いくつかの特別な問題を軽減し、より理想的に設計された CSS 構造を形成することができます。

これについて詳しくは、Jonathan Snook の [SMACSS](http://smacss.com) を強くお勧めします。

## CSS ルールセット分析

[selector]{

}

[セレクター] {

ハイフン (-) 連結下記の BEM 命名法を除く

* インデント 4。スペース;

* 宣言はアルファベット順ではなく関連性順に分割されます。

* DOM を反映するようにインデントされます。最後の宣言の末尾にあるセミコロン。

例:

.widget{

- webkit-border-radius:4px;

d Border-Radius: 4px;

}}

ウィジェット見出し {

FONT-SIZE : 1.5rem;

LINE-Height: 1;

COLOR:# BADA55;

`.widget-Heading` が `.widget; であることがわかります。 ` 子要素、なぜなら前者は後者より 1 レベルインデントされます。これにより、開発者はこれらのスタイルを読むときに情報にすばやくアクセスできるようになります。

また、`.widget-Heading` の宣言が関連性に従って配置されていることもわかります。 `.widget-Heading` はテキスト要素であるため、最初にフォント関連のスタイル宣言を追加し、次にフォント関連のスタイル宣言を追加します。その他。

以下は複数行に分割しない例です:

.t10 { width:10% }

.t20 25% } /* 1/4 */

.t30 { width:30% }

.t33 { width:33.333% } /* 1/3 */

.t40 { width:40% }

.t5 0 { width:50 % } /* 1/2 */

.t60 { 幅:60% }

.t66 { 幅:66.666% } /* 2/3 */

.t70 { 幅:70% }

.t75 { 幅:75% } ,,,, ( https://github.com/csswizardry/inuit.css/blob/master/inuit.css/partials/base/_tables.scss#L88))、CSS を 1 行に配置すると、コードをよりコンパクトにできます。

## 命名規則

通常、クラス名はハイフン (-) で接続します (`.foo_bar` や `.fooBar` の代わりに `.foo-bar` など) が、ここでは BEM (ブロック、エレメント、モディファイア) という命名法を使用します。

BEM この命名法により、セレクターがより標準化され、より明確になり、よりセマンティックになります。

命名法は次の形式に従います:

.block{}

.block__element{}

.block--modifier{}

ここで:

* `.block` は を表します基本的な抽象要素。

* `.block__element` は `.block` のサブ要素全体を表します。

* `.block--modifier` は `.block` の異なる状態を表します。

例:

.person{}

.person--女性{}

.person__hand{}

.person__hand--left{}

.person__hand--right{}

この例で説明する最も基本的な要素は人であり、この人は女性である可能性があります。また、人間には人間の体の一部である手がありますが、その手にも左手と右手のように状態が異なることもわかっています。

このようにして、親要素に基づいてセレクターの名前空間を指定し、それが子要素 (`__`) なのか、それとも別の状態 (`--`) なのかを伝えることができます。

したがって、`.page-wrapper` は独立したセレクターです。これは、子要素や他の要素の他の状態ではないため、標準の名前です。ただし、`.widget-Heading` は他のオブジェクトに関連しているため、`.widget` の子要素である必要があるため、これを使用する必要があります。名前が「.widget__Heading」に変更されました。

BEM の命名法はきれいではなく、非常に冗長ですが、名前を通じて要素の機能と要素間の関係をすぐに学ぶことができます。同時に、BEM 構文内の繰り返し部分は、gzip 圧縮アルゴリズムに大きなメリットをもたらします。

BEM 命名法を使用するかどうかにかかわらず、再利用性を向上させるために、単語を増やしたり減らしたりせずに、クラスの名前が適切に付けられていることを確認する必要があります (`.ui-list` や `.media` など)。 )。これから拡張される要素の名前は、できるだけ正確である必要があります (たとえば、「.user-avatar-link」)。適切に記述されたコードは gzip で効果的に圧縮できるため、クラス名の数や長さについて心配する必要はありません。

### HTML のクラス

読みやすさを確保するには、HTML マークアップ内のクラス名を 2 つのスペースで区切ります。例:

スペースを追加すると、複数のクラスを使用するときに読みやすく、見つけやすくなります。

### JS フック

** CSS スタイルを JavaScript フックとして決して使用しないでください。 **JS の動作とスタイルを混在させると、それらを別々に扱うことができなくなります。

JS を特定のタグにバインドする場合は、JS 固有のクラスを作成します。簡単に言えば、「.js-toggle」や「.js-drag-and-drop」のように、接頭辞「.js-」を付けて名前空間を区切ることです。これは、競合による問題を引き起こすことなく、クラスを介して JS と CSS の両方をバインドできることを意味します。

上記のタグには 2 つのクラスがあり、そのうちの 1 つを使用してこの追加スタイルを指定できます。をソートされたテーブル列に追加し、別の列を使用してソート機能を追加します。

### I18n

私 (Harry Roberts、この CSS ガイドライン文書の原著者) はイギリス人ですが、常に color< の代わりに colour と綴ります。 ;/ i> ですが、統一性を保つために、CSS ではアメリカ式のスペルを使用する方が良いと思います。 CSS やその他のほとんどの言語はアメリカ式スペルで記述されているため、「.colour-picker{}」に「color:red」と記述すると統一性が欠けてしまいます。私は以前、次のような 2 つのスペルを同時に使用することを推奨していました:

.color-picker,

.colour-picker{

}

しかし、最近、大規模な Sass プロジェクトに参加しました。このプロジェクトには多くの色変数 (`$brand-color`、`$highlight-color` など) があり、各変数に対して 2 つのスペルを維持するのは非常に困難であり、検索と検索に 2 倍の作業負荷がかかります。交換する。

したがって、統一性を保つために、すべてのクラスと変数には、参加しているプロジェクトの通常のスペルを使用して名前を付けてください。

## コメント

行幅が 80 バイト以下のブロックコメントを使用します:

/**

* これは docBlock スタイルのコメントです

*

* これはコメントの長い説明、コードの詳細については

     * detail. We limit these lines to a maximum of 80 characters in length.

     * 

     * We can have markup in the comments, and are encouraged to do so:

     * 

       

           

Lorem

       

     * 

     * We do not prefix lines of code with an asterisk as to do so would inhibit

     * copy and paste.

     */

 

 

    /**

     * 这是一个文档块(DocBlock)风格的注释。

     *

     * 这里开始是描述更详细、篇幅更长的注释正文。当然,我们要把行宽控制在 80 字以内。

     *

     * 我们可以在注释中嵌入 HTML 标记,而且这也是个不错的办法:

     *

       

           

Lorem

       

*/

自分にとって明確で理解できる内容でも、他の人にとってはそうではない可能性があるため、コードをコメントにできるだけ詳しく説明してください。コードの一部を記述するたびに、それを詳細に説明する特別なコメントを記述する必要があります。

### コメントの拡張使用法

コメントには、次のような高度な用途があります:

* 準変更セレクター

* コードタグ

* 継承タグ

### # 準変更されたセレクター

たとえば、`.nav{}` を記述できる場合は、`ul.nav{}` を記述しないようにしてください。セレクターを過度に変更すると、パフォーマンスに影響し、クラスの再利用性に影響し、セレクターのプライバシーが高まります。これらは避けるべきものです。

しかし、場合によっては、クラスの使用範囲を他の開発者に伝えたい場合もあります。 `.product-page` を例にとると、このクラスはルート コンテナのように見えます。これは `html` 要素または `body` 要素である可能性がありますが、`.product-page` のみに基づいて決定することはできません。

セレクターの前に準変更を追加して (つまり、前の型セレクターをコメントアウトして)、計画したクラスのスコープを記述することができます:

/*html*/.product-page{}

このようにして、再利用性に影響を与えることなく、クラスのスコープを正確に知ることができます。

他の例は次のとおりです:

/*ol*/.breadcrumb{}

/*p*/.intro{}

/*ul*/.image-thumbs{}

Likeこれにより、コードのプライバシーに影響を与えることなく、クラスのスコープを知ることができます。

#### コードタグ

新しいルールを作成する場合は、それにタグを追加できます。例:

/**

* ^ナビゲーション ^リスト

     */

.nav{ }

/**

* ^グリッド ^リスト ^テーブル

     */

.matrix{}

これらのタグを使用すると、他の開発者が関連するコードをすばやく見つけることができます。開発者がリストに関連する部分を見つける必要がある場合、「^lists」を検索することで、「.nav」、「.matrix」、およびその他の関連部分をすばやく見つけることができます。

#### 継承タグ

オブジェクト指向の考え方を CSS の記述に適用すると、CSS の 2 つの部分が密接に関連していることがよくわかります (1 つはベース、もう 1 つは拡張)。 2か所に分かれています。継承タグを使用すると、元の要素と継承された要素の間に密接な関係を確立できます。これらはコメント内で次のように記述されます:

要素の基本スタイル内:

/**

* theme.css の `.foo` を拡張します

     */

.foo{}

要素の拡張スタイル内:

/**

*base.css の `.foo` を拡張します

     */

.bar{}

このようにして、遠く離れた 2 つのコード間に緊密な接続を確立できます。

---

## CSS の作成

前の章では主に CSS を計画する方法について説明しました。これらは簡単に定量化できるルールです。この章では、より理論的なことと、私たちの態度や方法について探っていきます。

## 新しいコンポーネントの作成

新しいコンポーネントを作成するときは、CSS の処理を​​開始する前に HTML 部分を作成します。これにより、どの CSS プロパティを継承できるかを正確に判断し、重複や無駄を避けることができます。

最初にマークアップを作成すると、データ、コンテンツ、セマンティクスに集中してから、必要なクラスと CSS スタイルを追加できます。

## オブジェクト指向 CSS

私はオブジェクト指向 CSS の方法でコードを書きます。コンポーネントを構造 (オブジェクト) と外観 (拡張機能) に分けます。次の分析のようにします (これは単なるメモであり、例ではないことに注意してください):

.room{}

.room--kitchen{}

.room--bedroom{}

。部屋 -- バスルーム{}

家にはたくさんの部屋があり、それらはすべて床、天井、壁、ドアが含まれているという共通の特徴を持っています。これらの共有部分を抽象クラス「.room{}」に入れることができます。しかし、他にも特徴的な部屋もあります。キッチンには床タイルがあったり、寝室にはカーペットがあったり、バスルームには窓がなくても寝室には窓があったり、壁の色が部屋ごとに異なっていたりすることもあります。オブジェクト指向 CSS の考え方により、同じ部分を構造部分に抽象化し、より具体的なクラスを使用してこれらの機能を拡張し、特別な処理メソッドを追加することができます。

したがって、多数の特別なモジュールを作成する代わりに、これらのモジュール内で繰り返されるデザイン パターンを見つけて抽象化し、それらを再利用可能なクラスに作成し、それをベースとして使用して、特別な拡張モジュールを作成することに熱心に取り組む必要があります。状況。

新しいコンポーネントを作成するときは、コンポーネントを構造と外観に分割します。構造部分を記述するときは、再利用性を確保するために最も一般的なクラスを使用し、外観を記述するときは、より具体的なクラスを使用してデザイン メソッドを追加します。

## レイアウト

すべてのコンポーネントの幅を宣言せず、その親要素またはグリッド システムによって決定させます。

**絶対に身長を宣言しないでください**。高さは、画像や CSS スプライトなど、寸法がすでに固定されているものにのみ使用してください。高さは `p`、`ul`、`div` などの要素で宣言しないでください。必要に応じて `line-height` を記述すると、より柔軟になります。

グリル システムは本棚として理解する必要があります。最初に本棚を作ってからそこに物を置くのと同じように、本棚自体がコンテンツとして含まれているのではなく、コンテンツが含まれています。サイズを宣言するのではなく、グリッド システムを要素の他のプロパティとは別に扱うことで、レイアウトが容易になり、フロントエンドの作業がより効率的になります。

グリル システムにはスタイルを追加しないでください。これらはレイアウトのためだけです。グリルシステムの内側にスタイルを追加します。いかなる状況でも、ボックス モデル関連のプロパティをグリッド システムに追加しないでください。

## UI サイズ

私は、パーセンテージ、`px`、`em`、`rem` や単純に何も設定しないなど、UI サイズを設定するために多くのメソッドを使用します。

理想的には、グリッド システムはパーセンテージで設定する必要があります。上で述べたように、列とページの幅を固定するためにグリッド システムを使用しているため、要素のサイズは無視できます。

フォント サイズを定義するために rem を使用し、古いブラウザと互換性があるように px で補っています。これにより、em と px の利点を組み合わせることができます。以下は非常に美しい Sass Mixin です。base-font-size を別の場所で宣言すると、それを使用して古いブラウザと互換性のある rem と px を生成できます。

@mixin font-size($font-size){

font-size:$font-size +px;

font-size:$font-size / $base-font-size +rem;

}

サイズが px で固定されている画像や CSS スプライトなど、固定サイズの要素でのみ px を使用します。

### フォント サイズ

フォント サイズを宣言するために、グリッド システムの原則に似たいくつかのクラスを定義します。これらのクラスは、二重のタイトル サイズ設定に使用できます。これについては、[CSS での実践的なフォント サイジング](http://csswizardry.com/2012/02/pragmatic-practical-font-sizing-in-css) を参照してください。

## 略語

**CSS 略語は注意して使用する必要があります。 **

`background:red;` のような属性を記述するのは非常に簡単ですが、これを記述することの意味は `background-image:none; background-repeat:repeat; を宣言することです。同時に;`。ほとんどの場合、これによって問題が発生することはありませんが、一度でも問題が発生した場合は、略語をやめるかどうかを検討する価値があります。これを「background-color:red;」に変更する必要があります。

同様に、`margin:0;` のようなステートメントは確かに簡潔ですっきりしていますが、それでもできるだけ明確に記述する必要があります。単に下部の `margin` を変更したい場合は、より具体的に `margin-bottom:0;` と記述するのが最善です。

次に、宣言する必要がある属性も明確に記述する必要があり、略語によって他の属性に影響を与えないようにする必要があります。たとえば、下の `margin` だけを変更したい場合は、他のマージンもクリアしてしまう `margin:0` を使用しないでください。

略語は良いものですが、乱用しないように注意してください。

## ID

セレクターの処理を始める前に、次の文に留意してください:

** CSS では ID を決して使用しないでください。 **

HTML では、JS やアンカーの位置決めに ID を使用できますが、CSS ではクラスのみを使用する必要があり、ID はまったく必要ありません。

Class の利点は再利用性であり、プライバシーの度合いは高くありません。プライバシーは問題を引き起こしやすいため、プライバシーを減らすことが重要です。 ID のプライバシーはクラスの **255** 倍であるため、CSS では決して使用しないでください。

## セレクター

セレクターは常に短く効率的にしてください。

ページ要素の位置によって配置されたセレクターは理想的ではありません。たとえば、「.sidebar h3 span{}」などのセレクターの位置は相対位置に依存しすぎるため、スパンを h3 とサイドバーの外側に移動してスタイルを維持するのは困難です。

複雑な構造を持つセレクターはパフォーマンスに影響します。セレクターの構造が複雑になればなるほど (たとえば、「.sidebar h3 spa」は 3 層、「.content ul p a」は 4 層)、ブラウザの消費量は多くなります。

スタイルをその位置から独立させて、セレクターをシンプルかつ明確に保つようにしてください。

全体として、セレクターはできるだけ短くする必要があります (たとえば、構造の 1 つのレイヤーのみ) が、クラス名は単純すぎてはなりません。たとえば、`.user-avatar` の方がはるかに優れています。 `.usr-avt`。

**覚えておいてください:** クラスが意味論的であるかどうかは問題ではなく、それが合理的であるかどうかに注意を払う必要があります。クラス名が意味論的であることを強調するのではなく、時代遅れではなく、合理的な名前を使用することに重点を置いてください。

### 過剰に変更されたセレクター

前述したように、過剰に変更されたセレクターは理想的ではありません。

過剰に変更されたセレクターは、`div.promo` のようなセレクターです。 `.promo` を使用するだけでも同じ効果が得られる可能性があります。もちろん、要素タイプを使用してクラスを変更する必要がある場合もあります (たとえば、`.error` を作成し、それをさまざまな要素タイプで異なる表示にしたい場合、たとえば、`.error{ color:red; }` ` div .error{padding:14px;}`) ですが、ほとんどの場合は避けるべきです。

過剰に変更されたセレクター、`ul.nav li a{}` の別の例を見てみましょう。前に述べたように、`.nav` がリストであることがわかっているので、`ul` をすぐに削除できます。そして、`a` が `li` になければならないことがわかるので、このセレクターを` .nav a として書き換えることができます。 {}`。

### セレクターのパフォーマンス

ブラウザのパフォーマンスは日々向上しており、CSS のレンダリングはますます高速になっていますが、それでも効率に注意を払う必要があります。この問題は、不連続でネストされていないセレクターを使用し、グローバル セレクター (`*{}`) をコア セレクターとして使用せず、ますます複雑になる CSS3 の新しいセレクターの使用を回避することで回避できます。

翻訳メモ、コア セレクター: ブラウザはセレクターを右から左の順に解析します。右端の要素はスタイルが有効になる要素であり、コア セレクターです。

## CSS セレクターを使用する目的

セレクターを使用して要素を見つけるよりも、スタイルを追加したい要素にクラスを直接追加する方が良い方法です。例として「.header ul{}」のようなセレクターを見てみましょう。

この `ul` がこの Web サイトのサイト全体のナビゲーションであると仮定します。これはヘッダー内にあり、これまでのところヘッダー内の唯一の `ul` 要素です。 `.header ul{}` は機能しますが、良いアイデアではなく、すぐに時代遅れになり、非常に曖昧です。ヘッダーに別の「ul」を追加すると、たとえこれが私たちが想定していた効果ではない場合でも、このナビゲーション部分用に作成したスタイルが適用されます。これは、以前の影響を相殺するために、多くのコードをリファクタリングするか、後の「ul」用に多くの新しいスタイルを作成する必要があることを意味します。

セレクターは、この要素のスタイルを設定する理由に適合する必要があります。 「この要素が .header の下の ul であるため、ターゲットにしているのか、それともサイト ナビゲーションであるためなのか?」と考えて、セレクターをどのように使用するかが決まります。

コア セレクターが型セレクターではなく、高レベル オブジェクトや抽象セレクターでもないことを確認してください。たとえば、CSS には「.sidebar ul{}」や「.footer .media{}」などのセレクターは絶対にありません。

明確な式: 親要素ではなく、スタイルを設定する要素を直接見つけます。 HTML が変更されないとは考えないでください。 **CSS を使用して、ご都合主義ではなく、必要な要素を直接ヒットします。 **

完全な内容については、私の記事 [Shoot to kill; CSS selector インテント](http://csswizardry.com/2012/07/shoot-to-kill-css-selector-intent/) を参照してください。 )

## `! important`

`! important` は補助クラスでのみ使用してください。たとえば、特定のルールを**常に**有効にしたい場合は、`.error{ color:red! important }` を使用して優先度を高めることもできます。

`! important` を積極的に使用することは避けてください。たとえば、複雑な CSS を作成するときにこれをショートカットとして使用しないでください。前の部分をクリーンアップしてリファクタリングし、セレクターを短くし、他の部分を圧倒する ID の使用を避けてください。

## マジックナンバーと絶対位置決め

マジックナンバーは「たまたま影響を及ぼした」数字を指しますが、これは根本的な原因ではなく症状を治療するだけであり、拡張性が欠けているため、非常に悪いです。

例: `.dropdown-nav li:hover ul{ top:37px; }` ここでの 37px は魔法の数字であるため、ドロップダウン メニューを下に移動することは決して良い考えではありません。 37px が有効になるのは、この時点で `.dropbox-nav` の高さがたまたま 37px であるためです。

この時点では、`.dropdown-nav li:hover ul{ top:100%; }` を使用する必要があります。つまり、`.dropbox-down` がどれほど高くても、ドロップダウン メニューは移動します。 100%ダウン。

コードに数字を入力するときは、よく考えてください。キーワードに置き換えることができる場合 (例: 「上から下に引っ張る」を意味する「top:100%」)、またはより良い解決策がある場合は、直接の数字を避けるようにしてください。

CSS に残すすべての数字は、約束したが守りたくないものです。

## 条件判定

IE 専用に書かれたスタイルは基本的に回避可能 唯一 IE 用に特別な処理が必要となるのは、IE がサポートしていないコンテンツ (PNG など) を扱うことだけです。

つまり、CSS をリファクタリングすると、すべてのレイアウトとボックス モデルを IE と追加互換にする必要がなくなります。つまり、基本的に `