Skip to content

Latest commit

 

History

History
472 lines (293 loc) · 42.6 KB

css-questions.md

File metadata and controls

472 lines (293 loc) · 42.6 KB
Raw

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」の1぀より倧きい。

等しい特異性の堎合最新のルヌルは重芁なルヌルです。スタむルシヌトに同じルヌルを内郚たたは倖郚に関係なく2回曞いた堎合、スタむルシヌトの䞋䜍のルヌルはスタむルを適甚する芁玠に近く、より具䜓的であるずみなされ、適甚されたす。

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

参考

[↑] 先頭に戻る

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

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

私は非垞にカスタマむズされた、たたは慣習的ではないサむトデザむンを持っおいるずきにリセットを遞択しお、自分のスタむリングをたくさん行う必芁があり、デフォルトのスタむリングを保存する必芁はありたせん。

参考

[↑] 先頭に戻る

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

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

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が理想的な解決策であっおも、私は絶察的なポゞショニング手法を採甚しおいたす。ほずんどの芁玠に察応しおいるため、簡単な手法です。

参考

[↑] 先頭に戻る

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

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

[↑] 先頭に戻る

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

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

[↑] 先頭に戻る

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

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

[↑] 先頭に戻る

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

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

  • all - for all media type devices
  • print - for printers
  • speech - for screenreaders that "reads" the page out loud
  • screen - for computer screens, tablets, smart-phones etc.

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

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

[↑] 先頭に戻る

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

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

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

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

参考

[↑] 先頭に戻る

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

メリット:

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

デメリット:

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

[↑] 先頭に戻る

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

奜きなもの:

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

嫌いなもの:

  • Cassで曞かれた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
Size Fills up the width of its parent container. Depends on content. Depends on content.
Positioning Start on a new line and tolerates no HTML elements next to it (except when you add float) Flows along with other content and allows other elements beside. Flows along with other content and allows other elements beside.
Can specify width and height Yes Yes No. Will ignore if being set.
Can be aligned with vertical-align No Yes Yes
Margins and paddings All sides respected. All sides respected. Only horizontal sides respected. Vertical sides, if specified, do not affect layout. Vertical space it takes up depends on line-height, even though the border and padding appear visually around the content.
Float - - Becomes like a block element where you can set vertical margins and paddings.

[↑] 先頭に戻る

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ず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のようなもの。

参考

[↑] 先頭に戻る

他の方の回答集