line-heightのハーフ・レディングを打ち消す`calc((1em - 1lh) / 2)`をCSS変数に定義しておくとよい – TAKLOG
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テクニック集 – TAKLOG
少しの記述・工夫でユーザビリティやアクセシビリティを向上させるHTML/CSSテクニックを独断と偏見で集めてみました。最近クローズドな場所で登壇を行ったのですが、そちらで話した内容を纏めたものにいくつか内容を追加したものとなります。 原則的にこのブログで取り入れられている手法だったり過去の記事で触れた手法を紹介したものです。 button要素には touch-action:manipulation を指定するiOS限定の話ではありますが、button要素をつい連続でタップすると画面が拡大表示されてしまい非常に煩わしいです。 ポストを別枠で表示する そのため、パンおよびズームのジェスチャーは有効にしつつダブルタップ時のズームなどの標準外の追加的なジェスチャーを無効にするtouch-action:manipulationを指定して誤作動を防止しておくと良いでしょう。
タブやアコーディオンの非表示コンテンツにはhidden="until-found"を使うべし – TAKLOG
タブやアコーディオンの非表示コンテンツにはdisplay:noneがよく用いられますが、hidden="until-found"を利用するほうがメリットがあります。 hidden=“until-found”で非表示にしたコンテンツはページ内検索でアクセスできるuntil-foundはhidden属性に新たに追加された属性値です。 hidden - HTML: ハイパーテキストマークアップ言語 | MDN hidden グローバル属性は 列挙型属性であり、ブラウザーがその要素の中身を表示すべきではないことを示します。例えば、 要素がまだ、あるいはもはや関連性がないことを示す論理型属性です。例えば、ログイン処理が完了するまで使用できないページの要素を非表示にするために使用することができます。 developer.mozilla.org 従来のhidden属性とは違い、until-found"属
Webサイト制作で役立つChrome拡張機能5選 – TAKLOG
私が使用しているChrome拡張機能でWeb制作で役立つものを5つピックアップしました。今年度からWebサイト制作のキャリアが始まる方は参考にしてください！ PixelParallel「PixelParallel」は任意の画像を簡単にブラウザ上にオーバーレイ表示できる拡張機能です。デザインカンプをオーバーレイ表示することで実際のページとのデザインの差異を確認できます。 デザインをコードに落とし込む際に皆さんはどのようにコーディングするでしょうか？多くの人はデザインツールの画面を横に並べて、実際のページと比較しながら作業しているでしょう。 この方法だと余程の鑑識眼がない限り細かいズレが起こっていることに気付けないパターンが多いです。ピクセルパーフェクトの是非に関しては荒れそうなので今回は省略しますが、細かいズレが積もり積もってデザインを忠実に再現していないと判断されるのはもったいないです。
横スクロールバーの発生源を素早く特定する方法と最新の防止策 – TAKLOG
横スクロールバーの発生源はデベロッパーツールのConsoleですぐに特定できる横スクロールバーの発生源の特定方法として有名なのは全称セレクタですべての要素にoutlineを付与して確認する方法だと思われますが、次のスクリプトをデベロッパーツールのConsoleに貼り付けて確認したほうが手っ取り早いです。
当ブログのレスポンシブコーディングについて – TAKLOG
当ブログのレスポンシブコーディング施策のまとめです。 メディアクエリよりもコンテナクエリを優先する前回の記事でも触れたようにメディアクエリを一切使わずレスポンシブコーディングしました。 僕がメディアクエリを使用しなかった理由は以下の点が気になっていたからです。 各コンポーネントの状態変化をウィンドウのサイズに依存させるのは都合が悪い。実装者はウィンドウのサイズとにらめっこしながらデザインを調整する必要があり、非常に面倒。ある程度の的確な位置・間隔でブレイクポイントを用意するコーディングは効率的だが、全ての画面サイズで完璧な表示を実現するのが難しい。必ずどこかしらのサイズで見た目を妥協しないといけなくなってくる。ウィンドウのサイズではなく各コンポーネントのサイズを基準にデザイン調整するなら、どのように配置されるかを細かく考える必要がなくなる。代わりに、それぞれのコンポーネントが含まれるコンテ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dialog要素を使用したモーダルウィンドウの実装例 – TAKLOG
あなたが教わってるそのCSSテクニックはもう古い – TAKLOG
【令和最新版】Google Fontsの読み込み最適化の結論 – TAKLOG