タイムラインを見ていると「flexとgridの使い分けがよく分からないよ」という人が多く散見されるので、今回は僕が普段意識していることを皆さんに紹介します。 これから紹介することはあくまで僕のやり方で、絶対的な正解とかではないので参考程度に留めておいてください。実装において頻出するレイアウトをサンプルに、どのように考えてレイアウトを組んでいけばよいかを自分なりに説明できたらなと思います。 はじめに僕がレイアウトを組む上で大事にしていること、および意識していること。それは、レイアウトに変化が起こった際に崩れが生じないことはもちろん、将来的な変更に対して柔軟に対応できることです。 極論を言ってしまえばgridは使わなくても大抵のレイアウトは組めてしまいます。Internet Explorerに苦しめられていたあの頃を思い出してみてください。現在でもgridは難解だからflexだけ使用するって方

kiso.css - 日本のWebサイトのための「基礎」となるリセットCSS kiso.css は、日本のWebサイトのための「基礎」となるリセットCSSです。日本語に最適化しつつ、アクセシビリティやカスタマイズのし易さを重視しています。 tak-dcxi.github.io kiso.cssは、単なるスタイルのリセットを超えて「より良いデフォルト」を提供することを目指したリセットCSSです。その名が示すように、Webサイト構築の「基礎」として機能します。 有用なUAスタイルシートは活かしつつ、独自のスタイルも追加しているため、厳密には「リセットCSS」の定義から外れるかもしれません。しかし、類似のCSSが一般的に「リセットCSS」として紹介されている現状を踏まえ、検索性を考慮して本記事でもそのように呼称します。 kiso.cssはdestyle.cssやUA+を参考にしつつ、独自性も加え

昨今では「margin不要論」を唱える方々が目立つようになっています。margin不要論者の意見としては、主に以下のような点が挙げられます。 marginの相殺が厄介であること相殺を防ぐためにmarginを上下どちらに付けるかという宗教論争が起こりやすいことgapやpaddingで余白を設計すればmarginを使う機会が減るこれに関しては、以下の記事がよくまとまっていますので、ぜひご覧ください。 私がマージンをできるだけ使いたくない理由 - Qiita はじめに突然ですが、皆さんはCSSのmargin（マージン）をよく使いますか？私はマージンを多用しないように気をつけています。というより、あまりマージンと関わりたくないと思っています。今回の記事… qiita.com 私個人としては、marginは未だに現役であり、有効活用できる場面は多いと考えています。 とはいえ、レイアウト目的でmarg

約1年前、JavaScriptを使用したdetails要素のアニメーションの実装方法についての記事を投稿しました。しかし、その後の CSS の進化により <details> 要素の開閉アニメーションが CSS のみで実装可能になりました。 正確には、開く際のアニメーションは以前から CSS で実現できましたが、閉じる際のアニメーションは open 属性が即座に削除されるという仕様上、 JavaScript なしでは不可能でした。 この度、 details-content 疑似要素がサポートされたことにより、 CSS のみで閉じる際のアニメーションも実現できるようになりました。 ::details-content - CSS: Cascading Style Sheets | MDN The ::details-content CSS pseudo-element represents th

上記のような実装はよく見かける手法ですが、この実装はアクセシビリティ的な問題を孕んでいます。 それは「強制カラーモード」下での挙動であり、background-color は強制カラーモード下では明示されたシステムカラー以外はブラウザで指定された値に強制的に上書きされてしまう点です。 つまり、上記のような実装では強制カラーモード下ではボタンの背景色もろとも同一のシステムカラーに置き換えられるため、mask-image で設定したアイコンは消失してしまいます。 あくまで「装飾」的なものであればそこまで問題にはならないかもしれませんが、チェックボックスやラジオボタン、アイコンのみのリンクなどで背景色を前景色として使用するケースも存在し、その場合は強制カラーモード下では可視化されず利用できなくなります。これに関してはアクセシビリティを強みとしている制作会社のWebサイトでも見受けられ、強制カラー

先月からXにCSSテクニックを定期的に投稿しているので、それのまとめです。 テキストの中央寄せだからといって text-align:center を指定したほうが良いかは考えたほうがいい ポストを別枠で表示する和文をtext-align:centerで中央寄せすると複数行になった際に見栄えが悪くなるケースが多いです。 inline-size:fit-contentとmargin-inline:autoでセンタリングすることで、1行の場合は中央寄せ、複数行の場合は左寄せといった実装が可能となります。

lhという単位に見慣れない方もいるかと思われますが、これは現在のline-heightと同じ長さを表す新しく登場した単位です。この例ではline-heightはフォントサイズの1.5倍なので、もし1remが16pxであれば1lhは24pxとなります。 この場合、行の高さと文字の高さの負の差は1em - 1lh、つまり16px - 24pxで-8pxです。それを片方の値を算出するために2で割ると-4pxになります。したがって、margin-block: calc((1em - 1lh) / 2)は、書式のブロック方向（横書き時：上下）にそれぞれハーフ・レディングの大きさ（今回では4px）分のネガティブマージンを設定するということになります。 従来の上下の余白を打ち消す方法との比較lhが登場するまではSassの@mixinなどを使用して以下のような関数を定義し、ハーフ・レディングを打ち消す方法

少しの記述・工夫でユーザビリティやアクセシビリティを向上させるHTML/CSSテクニックを独断と偏見で集めてみました。最近クローズドな場所で登壇を行ったのですが、そちらで話した内容を纏めたものにいくつか内容を追加したものとなります。 原則的にこのブログで取り入れられている手法だったり過去の記事で触れた手法を紹介したものです。 button要素には touch-action:manipulation を指定するiOS限定の話ではありますが、button要素をつい連続でタップすると画面が拡大表示されてしまい非常に煩わしいです。 ポストを別枠で表示するそのため、パンおよびズームのジェスチャーは有効にしつつダブルタップ時のズームなどの標準外の追加的なジェスチャーを無効にするtouch-action:manipulationを指定して誤作動を防止しておくと良いでしょう。

主題と副題のマークアップの方法に関しては度々Xでも話題になっていて、例えば次のポストの返信やリポストを見ると、人によって以下のような様々なアプローチがあることがわかります。 参考：過去に話題になったポスト ポストを別枠で表示する見出し要素（h1〜h6）の中に主題と副題の両方を含めるこの場合の副題はspanではなくstrongやsmallを使うと言った意見も見られる主題をh1要素でマークアップし、副題は隣接するh2要素を使う疑似要素とcontent:attr()を使って副題を表示するこのブログのトップページでも主題+副題が用いられていて、いくつかのマークアップ方法を検討した結果「hgroupの中に主題のh1要素と副題のp要素を含める」方法を選択しました。

最近次のようなポストをしましたが、主に不透明度を伴う色の指定に現在でもrgba()関数を使用している方が多い印象です。 ポストを別枠で表示する今年に投稿されているCSSの技術記事でもrgba()関数を使用したサンプルコードが散見されますが、現在rgba()関数はレガシーな指定とされています。 rgba()関数使っている人、全員時代に取り残されています過去のCSSでは色を指定する方法の一つとしてrgba()関数が使用されてきました。この関数はRGB値とアルファ値（不透明度）を組み合わせて色を表現するために用いられます。

次の実装例のように、テキストを1文字ずつspan要素で区切ってアニメーションする際の注意点と実装例について纏めたメモ書きです。 実装例テキストアニメーションの実装例（英文）

グレースケール表示での確認を追加したほうがいい理由アクセシビリティの確保のため色に依存したデザインは、色覚に特性を持つ方や高齢者など、色の見え方に差がある利用者にとって識別が難しくなる場合があります。特に、要素のフォーカス状態やホバー状態の判別を色の変化のみで実装されることが多いですが、利用者によっては要素の状態変化が認識できなくなります。 そういった場合に備えてグレースケール表示でも情報が正しく伝わり、ユーザビリティが損なわれていないことを確認することはアクセシビリティ確保のために重要です。ウェブアクセシビリティの国際的なガイドラインであるWCAGでも適合レベルAの達成基準として定められています。 Web Content Accessibility Guidelines (WCAG) 2.1 Web Content Accessibility Guidelines (WCAG) 2.1

スムーススクロールの実装メモです。このブログの見出しのページリンクやトップへ戻るボタンで使われている実装と同じものになります。 そもそもスムーススクロールは必要か？という議論は置いておいて、現在ではCSSのみでスムーススクロールの実装はできますが、当ブログではそれを使用せずにJSで実装を行っています。 スムーススクロールのコードと実装例スムーススクロールの実装例

タブやアコーディオンの非表示コンテンツにはdisplay:noneがよく用いられますが、hidden="until-found"を利用するほうがメリットがあります。 hidden=“until-found”で非表示にしたコンテンツはページ内検索でアクセスできるuntil-foundはhidden属性に新たに追加された属性値です。 hidden - HTML: ハイパーテキストマークアップ言語 | MDN hidden グローバル属性は 列挙型属性であり、ブラウザーがその要素の中身を表示すべきではないことを示します。例えば、 要素がまだ、あるいはもはや関連性がないことを示す論理型属性です。例えば、ログイン処理が完了するまで使用できないページの要素を非表示にするために使用することができます。 developer.mozilla.org 従来のhidden属性とは違い、until-found"属

何かで役立つかもしれないスクロールバーのTips。 スクロールバーのCSSの仕様スクロールバーの見た目を変更するCSSには現在2つの方法があります。 W3Cが定めた標準のプロパティを使用する-webkit-ベンダープレフィックスがついたプロパティを使用する2024年3月現在、W3C仕様のプロパティを使用する方法はSafariが、-webkit-ベンダープレフィックスを使用する方法はFirefoxが非対応となっています。 ただし、異なるブラウザ間での動作を統一するための「Interop 2024」というプロジェクトの項目にScrollbar Stylingが追加されたことで、将来的にはSafariもW3Cの標準プロパティをサポートし始め、スクロールバーの見た目を変更する方法はW3Cの標準に統一される可能性が高いです。また、-webkit-ベンダープレフィックスを使用する方法は将来的には廃止さ

当ブログのレスポンシブコーディング施策のまとめです。 メディアクエリよりもコンテナクエリを優先する前回の記事でも触れたようにメディアクエリを一切使わずレスポンシブコーディングしました。 僕がメディアクエリを使用しなかった理由は以下の点が気になっていたからです。 各コンポーネントの状態変化をウィンドウのサイズに依存させるのは都合が悪い。実装者はウィンドウのサイズとにらめっこしながらデザインを調整する必要があり、非常に面倒。ある程度の的確な位置・間隔でブレイクポイントを用意するコーディングは効率的だが、全ての画面サイズで完璧な表示を実現するのが難しい。必ずどこかしらのサイズで見た目を妥協しないといけなくなってくる。ウィンドウのサイズではなく各コンポーネントのサイズを基準にデザイン調整するなら、どのように配置されるかを細かく考える必要がなくなる。代わりに、それぞれのコンポーネントが含まれるコンテ

display:flexを使用した例では揃えたい要素(ここではタイトルとします)にflex:1を適用して、その部分が可変のスペースを吸収するように設定しています。display:gridを使用した例ではgrid-template-rowsを使い、タイトル部分を1frとすることでそのコンテンツが残りの空間を埋めるように設定しています。この方法であれば一箇所のコンテンツの高さを揃えつつ並べることができますが、複数箇所の高さを揃えることができません。また、flex:1もしくはgrid-template-rowsで1frを指定した部分以外が不均一になると、全体の高さが一致しなくなるリスクがあります。 全体の高さが一致しなくなってしまったカードの表示例従来の方法で複数箇所の高さを揃えるにはセマンティックではないtable要素を使用するか、JSで高さを調整するしかアプローチがありませんでした。現在では

CSSにおけるinfinityとはCSSのcalc()関数で利用できる無限大(infinity)を扱う値です。 とは言っても至極当たり前ですがinfinityで文字通り無限大の大きさを描いたら大変なことになってしまうので各プロパティで上限はあります。 例えばwidthにcalc(infinity * 1px)を指定した要素の横幅をgetBoundingClientRect().widthで取得すると「33554428」となります。calc(infinity * 1em)でも同様の数値となるのでwidth height margin paddingなどの大きさの上限が33554428pxを超えることはありませんし、後述するz-indexも上限値である2147483647を超えることはありません。 実質的に各プロパティの上限値を取得する値だと考えても差し支えないと思います。 z-indexでの

hoverメディア特性には@media (hover: hover)と@media (any-hover: hover)の2種類があります。 @media (hover: hover): 主な入力デバイスがhoverに対応している場合に適用する@media (any-hover: hover): 入力デバイスのいずれかにhoverに対応している入力デバイスが含まれる場合に適用する少し前までは@media (hover: hover) and (pointer: fine)で「主な入力デバイスがhoverに対応していて、かつマウスのような正確なポインターがあるデバイスの場合」にのみhoverを適用するやり方を行っていましたが、この方法ではiPadのMagic Keyboardのカーソル操作でhoverが適用されないようです。 そのため、Magic Keyboardが接続されている時のみhov

横スクロールバーの発生源はデベロッパーツールのConsoleですぐに特定できる横スクロールバーの発生源の特定方法として有名なのは全称セレクタですべての要素にoutlineを付与して確認する方法だと思われますが、次のスクリプトをデベロッパーツールのConsoleに貼り付けて確認したほうが手っ取り早いです。