Skip to content

Latest commit

 

History

History
481 lines (301 loc) · 40.7 KB

css-questions.md

File metadata and controls

481 lines (301 loc) · 40.7 KB
Raw
title
CSS に関する質問

Front-end Job Interview Questions - CSS Questions の回答集です。提案や蚂正のプルリク゚ストは倧歓迎です

目次

CSS セレクタヌの詳现床ずは䜕ですかそれはどのようにはたらきたすか

ブラりザは CSS ルヌルの詳现床に応じお芁玠に衚瀺するスタむルを決定したす。ブラりザは特定の芁玠に䞀臎するルヌルをすでに決定しおいるず仮定したす。マッチングルヌルの䞭で、詳现床は以䞋に基づいおルヌルごずに 4 ぀のカンマ区切り倀 a, b, c, d が蚈算されたす。

  1. a は、むンラむンスタむルが䜿甚されおいるかどうかです。プロパティの宣蚀が芁玠のむンラむンスタむルの堎合、a は 1、そうでない堎合は 0 になりたす。
  2. b は ID セレクタの数です。
  3. c はクラス、属性、擬䌌クラスセレクタの数です。
  4. d はタグおよび擬䌌芁玠セレクタの数です。

埗られる詳现床はスコアではなく、列ごずに倀を比范できる行列です。セレクタヌを比范しお詳现床が最も高いものを刀断するずきは、巊から右に向かっお芋お、各列の最高倀を比范しおください。したがっお、b 列の倀は、c 列ず d 列の倀を䞊曞きしたす。埓っお、0, 1, 0, 0 の詳现床は、0, 0, 10, 10 より䞊です。

等しい詳现床の堎合最埌に䞎えられたルヌルが適甚されたす。内郚たたは倖郚に関係なくスタむルシヌトに同じルヌルを 2 回曞いた堎合、スタむルシヌトのより䞋郚に曞かれたルヌルがより詳现床が高いずみなされ適甚されたす。

私は䜎詳现床の CSS ルヌルを䜜成しお、必芁に応じお簡単に䞊曞きできるようにしおいたす。CSS の UI コンポヌネントラむブラリのコヌドを蚘述する際には、詳现床が䜎いこずが重芁です。詳现床を䞊げるためだけに耇雑すぎる CSS ルヌルを䜿甚したり、!important を利甚させるこずは避けるべきなのです。

参考

[↑] 先頭に戻る

"リセット" ず "ノヌマラむズ" CSS の違いは䜕ですかあなたはどちらを䜿いたすかそしおそれはなぜですか

  • リセット - リセットずは、芁玠のすべおのデフォルトブラりザスタむルを削陀するこずを意味したす。䟋えば、margin、padding、font-size は党お同じ芁玠にリセットされたす。䞀般的なタむポグラフィヌ芁玠のためにスタむリングを再宣蚀しなければなりたせん。
  • ノヌマラむズ - ノヌマラむズでは、すべおのスタむルを削陀するのではなく、有甚なデフォルトスタむルは保持したす。合わせお、䞀般的なブラりザの䟝存関係のバグを修正したす。

私は非垞にカスタマむズされた、たたは䞀般的ではないデザむンのサむトを䜜成する際にはリセットを遞択したす。これらの堎合、自分のスタむリングをたくさん行う必芁があり、デフォルトのスタむリングを保存する必芁がないためです。

参考

[↑] 先頭に戻る

float ずは䜕ですかどのようにはたらきたすか

Float は CSS の䜍眮決めプロパティです。フロヌト芁玠はペヌゞの流れの䞀郚ずしお残り、ペヌゞのフロヌから削陀される position: absolute 芁玠ずは異なり、他の芁玠たずえば、フロヌト芁玠の呚りを流れるテキストの配眮に圱響したす。

CSS の clear プロパティは、left/right/both フロヌト芁玠の䞋に配眮するために䜿甚できたす。

芪芁玠にフロヌト芁玠だけが含たれおいる堎合、その高さは䜕も折りたたたれたせん。これは、フロヌトの埌のフロヌトをコンテナの䞭で、コンテナが閉じる前にクリアするこずで修正できたす。

.clearfix ハックは、巧劙な CSS 疑䌌セレクタ:afterを䜿っおフロヌトをクリアしたす。芪にオヌバヌフロヌを蚭定するのではなく、クラス clearfix を远加したす。次に、この CSS を適甚したす

.clearfix:after {
  content: ' ';
  visibility: hidden;
  display: block;
  height: 0;
  clear: both;
}

あるいは、芪芁玠に overflow: auto たたは overflow: hidden プロパティを䞎えるず、子芁玠の䞭に新しいブロック曞匏蚭定コンテキストが確立され、子芁玠を含むように展開されたす。

参考

[↑] 先頭に戻る

z-index ずは䜕かず、スタックコンテキスト(スタック文脈)がどのように䜜られるのかを教えおください。

CSS の z-index プロパティは、重なっおいる芁玠の垂盎方向の積み重ね順序を制埡したす。z-index は static ではない position 倀を持぀芁玠にのみ圱響したす。

z-index 倀がなければ、芁玠は DOM に珟れる順番でスタックされたす同じ階局レベルの䞋䜍のものが䞀番䞊に衚瀺されたす。静的でない䜍眮付けの芁玠およびそれらの子芁玠は、HTML 階局に関係なく、垞にデフォルトの静的配眮を持぀芁玠の䞊に衚瀺されたす。

スタックコンテキスト(スタック文脈)は、䞀連のレむダヌを含む芁玠です。ロヌカルスタッキングコンテキストでは、その子の z-index 倀はドキュメントルヌトではなく、その芁玠に盞察しお蚭定されたす。そのコンテキスト倖のレむダヌ、぀たりロヌカルスタッキングコンテキストの兄匟芁玠は、レむダヌ内にレむダヌを眮くこずはできたせん。芁玠 B が芁玠 A の䞊に座っおいる堎合、芁玠 C の子芁玠は芁玠 B よりも高くなるこずはありたせん。

各スタッキングコンテキストは自己完結型です。芁玠の内容が積み重ねられた埌、芁玠党䜓が芪スタッキングコンテキストの積み重ね順に考慮されたす。いく぀かの CSS プロパティは、1 未満の opacity、none ではない filter、none でない transform のような新しいスタッキングコンテキストを匕き起こしたす。

参考

[↑] 先頭に戻る

ブロック敎圢文脈Block Formatting Context: BFCずその仕組みを教えおください。

ブロック敎圢文脈Block Formatting Context: BFCは、ブロックボックスが配眮された Web ペヌゞのビゞュアル CSS レンダリングの䞀郚です。フロヌト、絶察配眮芁玠、inline-blocks、table-cells、table-caption、visible 以倖の overflow を持぀芁玠その倀がビュヌポヌトに䌝播された時を陀く曞匏蚭定コンテキストをブロックしたす。

BFC は、以䞋の条件の少なくずも 1 ぀を満たす HTML ボックスです。

  • float の倀は none ではありたせん。
  • position の倀は static でも relative でもありたせん。
  • display の倀は table-cell、table-caption、inline-block、flex、inline-flex です。
  • overflow の倀は visible ではありたせん。

BFC では、各ボックスの巊端が包含ブロックの巊端に接したす右から巊ぞの曞匏蚭定、右端からのタッチ。

BFC が厩壊したずきに隣接するブロックレベルボックス間の垂盎マヌゞンです。詳しくは collapsing margins を読んでください。

参考

[↑] 先頭に戻る

clear を行う手法にはどのようなものがあり、それぞれどのような状況に適しおいたすか

  • 空の div メ゜ッド - <div style="clear:both;"></div>
  • Clearfix メ゜ッド - 䞊蚘の .clearfix クラスを参照しおください。
  • overflow: auto たたは overflow: hidden メ゜ッド - 芪は新しいブロック曞匏蚭定コンテキストを確立し、float された子を含むように展開したす。

倧芏暡なプロゞェクトでは、ナヌティリティ .clearfix クラスを䜜成し、必芁な堎所で䜿甚したす。子䟛が芪よりも背が高く、それほど理想的でない堎合、overflow: hidden は子䟛をクリップするかもしれたせん。

[↑] 先頭に戻る

CSS スプラむトずは䜕ですかペヌゞやサむトに実装する方法も合わせお説明しおください。

CSS スプラむトは、耇数のむメヌゞを 1 ぀の倧きなむメヌゞに結合したす。これは䞀般的にアむコン甚の技術ですGmail が䜿甚しおいたす。それを実装する方法

  1. スプラむトゞェネレヌタを䜿甚しお、耇数の画像を 1 ぀にたずめ、適切な CSS を生成したす。
  2. それぞれのむメヌゞは、background-image、background-position ず background-size プロパティが定矩された、察応する CSS クラスを持ちたす。
  3. そのむメヌゞを䜿甚するには、察応するクラスを芁玠に远加したす。

利点:

  • 耇数のむメヌゞに察する HTTP リク゚ストの数を枛らすスプラむトシヌトごずに 1 回のリク゚ストが 1 回だけ必芁。しかし、HTTP2 では耇数のむメヌゞを読み蟌むこずはもはや倧きな問題にはなりたせん。
  • 必芁なたでダりンロヌドされないアセットの事前ダりンロヌド。䟋えば、:hover 疑䌌ステヌトにのみ珟れるむメヌゞ。点滅は芋られない。
参考

[↑] 先頭に戻る

ブラりザ固有のスタむリングに関する問題を解決するにはどうすればいいですか

  • 問題を特定しお問題のブラりザを特定したら、その特定のブラりザが䜿甚されおいるずきにのみロヌドする別のスタむルシヌトを䜿甚したす。この手法では、サヌバヌ偎のレンダリングが必芁です。
  • これらのスタむリングの問題を既に凊理しおいる Bootstrap のようなラむブラリを䜿甚しおください。
  • ベンダヌプレフィックスをコヌドに自動的に远加するには、autoprefixer を䜿甚したす。
  • Reset CSS たたは Normalize.css を䜿甚しおください。

[↑] 先頭に戻る

機胜の少ないブラりザに察しおは、どのようにペヌゞを提䟛したすかどのようなテクニック/プロセスを䜿甚したすか

  • グレヌスフル・デグラデヌションGraceful degradation - 最新のブラりザヌ甚のアプリケヌションを構築し、叀いブラりザヌでは機胜し続けるこずを保蚌する習慣。
  • プログレッシブ・゚ンハンスProgressive Enhancement - 基本レベルのナヌザヌ゚クスペリ゚ンスのためのアプリケヌションを構築するが、ブラりザヌがそれをサポヌトするずきに機胜拡匵を远加するプラクティス。
  • 機胜のサポヌトを確認するには、caniuse.com を䜿甚しおください。
  • 自動ベンダヌ接頭蟞挿入のための*オヌトプレフィクサヌ。
  • Modernizr を䜿った機胜の怜出

[↑] 先頭に戻る

コンテンツを芖芚的に隠すスクリヌンリヌダヌのみ利甚可胜にする方法にはどのようなものがありたすかいく぀か教えおください。

これらの技術はアクセシビリティa11yに関連しおいたす。

  • visibility: hidden しかし、芁玠はただペヌゞの流れにあり、ただ空間を占めおいたす。
  • width: 0; height: 0 芁玠が画面䞊のスペヌスを党く占めないようにしお、それを衚瀺しないようにしたす。
  • position: absolute; left: -99999px 画面の倖偎に配眮したす。
  • text-indent: -9999px これは block 芁玠内のテキストに察しおのみ機胜したす。
  • メタデヌタ たずえば、Schema.org、RDF、JSON-LD を䜿甚したす。
  • WAI-ARIA Web ペヌゞのアクセシビリティを向䞊させる方法を指定する W3C の技術仕様。

WAI-ARIA が理想的な解決策かもしれたせんが、私は absolute による䜍眮決定手法を採甚しおいたす。泚意すべきこずが少なく、ほずんどの芁玠に察応しおいる簡単な手法だからです。

参考

[↑] 先頭に戻る

グリッドシステムを䜿甚したこずがありたすか䜿ったこずがあるなら、あなたはどのグリッドシステムが奜きですか

私は float ベヌスのグリッドシステムが奜きです。なぜなら、既存の代替システムフレックス、グリッドの䞭でも最も倚くのブラりザをサポヌトしおいるからです。ブヌトストラップで長幎䜿甚されおおり、動䜜するこずが蚌明されおいたす。

[↑] 先頭に戻る

メディアク゚リやモバむル固有のレむアりト/CSS を䜿甚したり実装したこずはありたすか

はい。䞀䟋は、ピル型ナビゲヌションを、特定のブレヌクポむントを越えた固定底のタブ型ナビゲヌションに倉換するこずである。

[↑] 先頭に戻る

SVG のスタむリングに぀いおは詳しいですか

いいえ...悲しいこずに。

[↑] 先頭に戻る

screen 以倖の @media プロパティの䟋を挙げられたすか

はい、@media プロパティには screen も含めお぀の皮類がありたす。:

  • all - 党おのデバむス
  • print - プリンタヌ
  • speech - ペヌゞを読み䞊げるスクリヌンリヌダヌ
  • screen - コンピュヌタスクリヌンやタブレット、スマヌトフォンなど

print メディアタむプの䜿い方の䟋:

@media print {
  body {
    color: black;
  }
}

[↑] 先頭に戻る

効率的な CSS を曞くにために避けるべき "萜ずし穎" にはどんなものがありたすか

たず、ブラりザがセレクタを右端キヌセレクタから巊に䞀臎させるこずを理解しおください。ブラりザはキヌセレクタに埓っお DOM 内の芁玠をフィルタリングし、芪芁玠を走査しお䞀臎を刀定したす。セレクタヌチェヌンの長さが短いほど、ブラりザヌはその゚レメントがセレクタヌず䞀臎するかどうかを刀別するこずができたす。したがっお、タグセレクタずナニバヌサルセレクタであるキヌセレクタは避けおください。それらは倚数の芁玠にマッチし、ブラりザは芪がマッチするかどうかを刀断するために倚くの䜜業をする必芁がありたす。

BEM (Block Element Modifier)の方法論では、すべおが単䞀のクラスを持ち、階局が必芁な堎合はクラス名にも焌き付けられるこずが掚奚されおいたす。セレクタは効率的か぀簡単にオヌバヌラむドできたす。

どの CSS プロパティがリフロヌ、再描画、および合成をトリガするかに泚意しおください。可胜であれば、レむアりトトリガヌリフロヌを倉曎するスタむルを曞くのは避けおください。

参考

[↑] 先頭に戻る

CSS プリプロセッサを䜿甚するメリットずデメリットには䜕がありたすか

メリット:

  • CSS のメンテナンス性が向䞊したした。
  • ネストされたセレクタを曞きやすい。
  • 䞀貫したテヌマ蚭定のための倉数。異なるプロゞェクト間でテヌマファむルを共有できたす。
  • ミックスむンは繰り返し CSS を生成したす。
  • あなたのコヌドを耇数のファむルに分割する。CSS ファむルも分割するこずができたすが、そのためには各 CSS ファむルをダりンロヌドするための HTTP リク゚ストが必芁です。

デメリット:

  • 前凊理のためのツヌルが必芁です。再コンパむル時間が遅くなるこずがありたす。

[↑] 先頭に戻る

䜿甚したこずのある CSS プリプロセッサに぀いお奜きなものず嫌いなものを教えおください。

奜きなもの:

  • 䞻に䞊蚘の利点。
  • Less は JavaScript で曞かれおおり、Node でうたくいきたす。

嫌いなもの:

  • C++ で曞かれた LibSass のバむンディングである node-sass を䜿っお Sass を䜿甚したす。ノヌドのバヌゞョンを切り替えるずきに、頻繁に再コンパむルする必芁がありたす。
  • Less では、倉数名の先頭に @ が付いおいたす。これは @media、@import、@font-face ルヌルなどのネむティブ CSS キヌワヌドず混同するこずがありたす。

[↑] 先頭に戻る

非暙準フォントを䜿甚する Web サむトを実装するにはどのようにしたすか

font-face を䜿っお font-weight の font-family を定矩しおください。

[↑] 先頭に戻る

CSS セレクタにマッチする芁玠がどれなのか、ブラりザがどのように決定しおいるかを説明しおください。

この郚分は䞊蚘の効率的な CSS の蚘述に関するものです。ブラりザはセレクタを右端キヌセレクタから巊に䞀臎させたす。ブラりザはキヌセレクタに埓っお DOM 内の芁玠をフィルタリングし、芪芁玠を走査しお䞀臎を刀定したす。セレクタチェヌンの長さが短ければ短いほど、ブラりザがその芁玠がセレクタに䞀臎するかどうかを刀断するこずができたす。

たずえば、このセレクタ p span では、ブラりザはたずすべおの <span> 芁玠を芋぀け、その芪をルヌトたですべおトラバヌスしお <p> 芁玠を探したす。特定の <span> に぀いおは、<p> が芋぀かるず盎ちに <span> がマッチし、マッチングを止めるこずができたす。

参考

[↑] 先頭に戻る

疑䌌芁玠に぀いお説明し、それらがなんのために䜿われおいるかを詳しく話しおください。

CSS 疑䌌芁玠はセレクタに远加されたキヌワヌドで、遞択した芁玠の特定の郚分をスタむルするこずができたす。マヌクアップ(:before, :after)を倉曎しなくおも、マヌクアップ(combined with content: ...)ぞの芁玠の远加やデコレヌション(:first-line, :first-letter) に䜿甚できたす。

  • :first-line ず :first-letter を䜿っおテキストを装食するこずができたす。
  • 䞊蚘の .clearfix ハックで、clear:both でれロスペヌスの芁玠を远加するために䜿甚されたす。
  • ツヌルチップの䞉角圢の矢印は :before ず :after を䜿いたす。䞉角圢は実際には DOM ではなくスタむリングの䞀郚ずみなされるため、懞念の分離を促したす。远加の HTML 芁玠を䜿甚せずに CSS スタむルだけで䞉角圢を描画するこずは、実際には䞍可胜です。
参考

[↑] 先頭に戻る

ボックスモデルがなんであるかのあなたの理解ず、異なるボックスモデルでレむアりトをレンダリングするために CSS でブラりザに指瀺する方法を説明しおください。

CSS ボックスモデルは、ドキュメントツリヌ内の芁玠に察しお生成され、芖芚的な曞匏蚭定モデルに埓っおレむアりトされた長方圢のボックスを蚘述したす。各ボックスは、内容領域䟋えば、テキスト、画像などおよび任意の呚囲の「パディング」、「ボヌダヌ」および「マヌゞン」領域を有する。

CSS ボックスモデルは、次の蚈算を行いたす。

  • ブロック芁玠がどれくらいのスペヌスを占めるか。
  • 枠線や䜙癜が重なるかどうか、たたは折りたたむかどうか。
  • ボックスの寞法。

ボックスモデルには次の芏則がありたす。

  • ブロック芁玠の倧きさは、width、height、padding、border および margin によっお蚈算されたす。
  • height が指定されおいない堎合、ブロック芁玠は含たれおいる内容ず同じくらい高くなりたすフロヌトがない限り、以䞋参照。
  • width が指定されおいない堎合、フロヌトのブロック芁玠は、その芪の幅から padding の幅に収たるように展開されたす。
  • 芁玠の height は内容の height によっお蚈算されたす。
  • 芁玠の width は内容の width によっお蚈算されたす。
  • デフォルトでは、padding ず border は芁玠の width ず height の䞀郚ではありたせん。
参考

[↑] 先頭に戻る

* { box-sizing: border-box; } によっお䜕が起きたすかその利点は䜕ですか

  • デフォルトでは、芁玠には box-sizing: content-box が適甚され、コンテンツサむズのみが考慮されたす。
  • box-sizingborder-box は、芁玠の width ず height がどのように蚈算されるかを倉曎し、border ず padding も蚈算に含めたす。
  • 芁玠の height は、コンテンツの height + 垂盎 padding + 垂盎 border 幅によっお蚈算されたす。
  • 芁玠の width は、コンテンツの width + æ°Žå¹³ padding + æ°Žå¹³ border 幅によっお蚈算されたす。

[↑] 先頭に戻る

CSS の display プロパティずは䜕ですかその䜿い方の䟋をいく぀か挙げるこずができたすか

  • none, block, inline, inline-block, table, table-row, table-cell, list-item

TODO

[↑] 先頭に戻る

inline ず inline-block の違いは䜕ですか

比范のために block も䞊べたす。

block inline-block inline
サむズ 芪芁玠の幅ず同じになる。 芁玠によっお倉わる。 芁玠によっお倉わる。
ポゞショニング 新しい行から始たり、隣に芁玠を䞊べられない。(floatを䜿う堎合を陀く) 他の芁玠ずフロヌし、隣に芁玠を䞊べるこずができる。 他の芁玠ずフロヌし、隣に芁玠を䞊べるこずができる。
width ず height の指定ができるか はい はい いいえ、蚭定をしおも無芖される。
vertical-align を指定できるか いいえ はい はい
マヌゞンずパディング 䞊䞋巊右に指定できる。 䞊䞋巊右に指定できる。 巊右のみ指定可胜。䞊䞋に指定をしおもレむアりトに圱響はない。 border ず padding が芁玠の呚りに芖芚的に珟れおいおも、䞊䞋のスペヌスは line-height によっお決たる。
フロヌト - - 䞊䞋の margins ず paddings を蚭定できる block 芁玠のようになる。

[↑] 先頭に戻る

position が relative、fixed、absolute、static の芁玠の違いは䜕ですか

配眮された芁玠は、蚈算された position プロパティが relative、absolute、fixed たたは sticky のいずれかである芁玠です。

  • static - デフォルトの䜍眮です。芁玠は通垞どおりペヌゞに流れたす。top、right、bottom、left、z-index プロパティは適甚されたせん。
  • relative - 芁玠の䜍眮は、レむアりトを倉曎するこずなく、それ自䜓に察しお盞察的に調敎されたすしたがっお、配眮されおいなかった芁玠の隙間を残したす。
  • absolute - 芁玠は、ペヌゞのフロヌから削陀され、もしあれば、最も近い䜍眮にある祖先に察しお指定された䜍眮に眮かれたす。絶察配眮されたボックスは䜙癜を持぀こずができ、他の䜙癜ず䞀緒に折り畳たれるこずはありたせん。これらの芁玠は他の芁玠の䜍眮に圱響したせん。
  • fixed - 芁玠は、ペヌゞのフロヌから削陀され、ビュヌポヌトに察しお指定された䜍眮に配眮され、スクロヌルするず移動したせん。
  • sticky - スティッキヌポゞショニングは、盞察䜍眮ず固定䜍眮のハむブリッドです。芁玠は、指定されたしきい倀を超えるたで、盞察的な䜍眮ずしお扱われたす。その時点で、fixed の䜍眮ずしお扱われたす。
参考

[↑] 先頭に戻る

ロヌカルや本番環境で、どの既存の CSS フレヌムワヌクを䜿甚しおいたすかたた、どのように倉曎/改善しおいたすか

  • BootStrap - 緩やかなリリヌスサむクル。BootStrap4 は、ほが 2 幎間アルファになっおいたす。広く䜿甚されおいるように、スピナヌボタンコンポヌネントを远加したす。
  • Semantic UI - ゜ヌスコヌド構造により、テヌマのカスタマむズが非垞に難しくなりたす。慣習的でないテヌマ蚭定システムでカスタマむズするのは面倒です。ベンダラむブラリ内のハヌドコヌドされた蚭定パス。BootStrap ずは違っお、倉数をオヌバヌラむドするためにうたく蚭蚈されおいたせん。
  • Bulma - 非セマンティックで䜙蚈なクラスやマヌクアップが必芁です。䞋䜍互換性がありたせん。バヌゞョンをアップグレヌドするず、埮劙な方法でアプリが壊れおしたいたす。

[↑] 先頭に戻る

CSS の Flexbox や Grid の仕様で遊んだこずはありたすか

はい。Flexbox は䞻に 1 次元レむアりトを意味し、Grid は 2 次元レむアりトを意味したす。

Flexbox は、コンテナ内の芁玠の垂盎方向のセンタリング、スティッキヌフッタヌなど、CSS の倚くの䞀般的な問題を解決したす。ブヌトストラップず Bulma は Flexbox をベヌスにしおいたす。Flexbox を詊しおみたしたが、flex-grow を䜿っおいく぀かのブラりザの非互換性問題Safariに遭遇したした。そしお inline-blocks ず % で幅を蚈算するコヌドを曞き盎さなければなりたせんでした。

グリッドは、グリッドベヌスのレむアりトを䜜成するための最も盎芳的なアプロヌチですより良いが、ブラりザのサポヌトは珟時点では広くはありたせん。

参考

[↑] 先頭に戻る

りェブサむトをレスポンシブでコヌディングするこずずモバむルファヌストでコヌディングするこずの違いを説明できたすか

TODO

[↑] 先頭に戻る

レスポンシブデザむンはアダプティブデザむンず䜕が違いたすか

応答性ず適応性の䞡方の蚭蚈では、さたざたなデバむス間でナヌザヌ゚クスペリ゚ンスを最適化し、異なるビュヌポヌトサむズ、解像床、䜿甚状況、制埡メカニズムなどを調敎したす。

レスポンシブなデザむンは、柔軟性の原則 - すべおのデバむスで芋た目がよくなる単䞀の流䜓りェブサむト - で動䜜したす。レスポンシブなりェブサむトは、メディアク゚リ、フレキシブルグリッド、および反応性の高いむメヌゞを䜿甚しお、倚数の芁因に基づいお柔軟に倉化するナヌザヌ゚クスペリ゚ンスを䜜り出したす。1 ぀のボヌルが成長したり、収瞮しお耇数の異なるフヌプに収たるようにしたす。

アダプティブ・デザむンは、プログレッシブ・゚ンハンスメントの珟代的定矩にもっず䌌おいたす柔軟なデザむンではなく、デバむスやその他の機胜を怜出し、あらかじめ定矩された䞀連のビュヌポヌトサむズやその他の特性に基づいお適切な機胜ずレむアりトを提䟛したす。サむトは䜿甚されおいるデバむスのタむプを怜出し、そのデバむスのプリセットレむアりトを配信したす。1 ぀のボヌルがいく぀かの異なるサむズのフヌプを通過する代わりに、フヌプサむズに応じおいく぀かの異なるボヌルを䜿甚できたす。

参考

[↑] 先頭に戻る

Retina 察応を行ったこずはありたすかもしあるなら、い぀どのようなテクニックを䜿いたしたか

私は Retina ディスプレむを扱うために高解像床のグラフィックスディスプレむサむズの 2 倍を䜿甚する傟向がありたす。より良い方法は @media only screen and (min-device-pixel-ratio: 2) { ... } のようなメディアク゚リを䜿甚し、background-image を倉曎するこずです。

アむコンに぀いおは、解像床に関係なく非垞に鮮明に衚瀺されるため、可胜であれば svgs ずアむコンフォントを䜿甚するこずを遞択したす。

もう䞀぀の方法は JavaScript を䜿っお、<img> src 属性を window.devicePixelRatio 倀をチェックした埌、より高解像床のバヌゞョンに眮き換えるこずです。

参考

[↑] 先頭に戻る

position: absolute の代わりに translate() を䜿甚するべき堎合はありたすかその逆の堎合もありたすか理由も合わせお教えおください。

translate() は CSS の transform の倀です。transform や opacity を倉曎しおも、ブラりザのリフロヌや再描画は行われず、コンポゞションのみがトリガされたす。transform はブラりザに芁玠の GPU 局を䜜成させたすが、絶察配眮プロパティを倉曎するず CPU を䜿甚したす。したがっお、translate() はより効率的であり、より滑らかなアニメヌションのためのペむント時間を短瞮したす。

translate() を䜿甚するず、芁玠は絶察䜍眮を倉曎するのずは異なり、元のスペヌスを䜿いたすposition: relative のようなもの。

参考

[↑] 先頭に戻る

他の方の回答集