Chrome 88やEdge 88でのfont-size: calc(2ch)
利用しているフォントの「0」のグリフ幅によって変わるch単位は、実装されて久しい。これを、font-sizeプロパティーでcalc()やclamp()など計算するCSS関数を通して使うと、Chrome 88やEdge 88で想定より大きくなってしまうバグがあるようだ。Firefox 85やSafari 14では問題なく、またwidthプロパティーなどでなら発生しない。 .test .raw { font-size: 2ch; } .test .calc { font-size: calc(2ch); } このようなコードで再現する。同じ大きさ(16px前後)になるはずだが、Chrome 88やEdge 88で.calcの方が倍の大きさになってしまう。例えばNoto Sans CJK JPだと、17.76pxのはずが35.52pxになった。 2度計算してしまっているような気がするが、3chに
スクロールバーの幅
スクロールバーの幅を知りたいことはままある。CSSで拾えれば最高なのだけど……というところで、calc(100vw - 100%)で拾えることがわかった。ただこれで拾えるかどうかはその要素の親に依存するので、いつでもどこでも使えるわけではない。せめてJavaScriptでは扱えるようにしてみたい。 Demo: Get Scrollbar Width with JavaScript ボタンをクリックするとスクロールバーの幅がダイアログで表示される。オーバーレイのスクロールバーの場合は0pxになり、そうでない場合はスクロールバーの幅が返る。body要素の幅が100%であることが条件になるが、まず大丈夫だろう。 仕組みは単純なものでwidthプロパティーをcalc(100vw - 100%)にした要素をbody要素の子に突っ込んで、計算済みスタイルを拾うというだけだ。overflowプロパティー
普通のHTMLの書き方
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
2018年のウェブフォントについて
少しの間Noto Sans Japaneseを利用していたが、すぐに止めた。やはりFOITが気になる。かといってFOUT強制も苦肉の策という印象しかない。……このような記事を書いていたら、先にうまくまとまったfont-displayデスクリプターについての記事が広まっていたので、そちらを読むのが良い。 他が高速・即時化しつつある現在、1MBくらいを超えるウェブフォントはどうにもならない。動的なサブセット化はわからなくもないが、労多くして……という印象だ。自前で作るのも難しいし、安心して任せられる速さの提供者は知らない。 回線の状況(種別ではなく)に応じてうまいこと切り替える仕組みを導入しなければならないだろう。そうなるとデバイスから「今、回線あんま速くないです……」といった動的な情報を得たいが、プライバシーにかかわるので難しい。残る可能性はfont-displayデスクリプターのみだ。 @
SVGアイコンのサイズと位置
ヘッダーのリンクにはSVGの虫眼鏡のアイコンを流用した。vertical-alignプロパティーで文字位置と、line-heightとfont-sizeプロパティーの値を使って文字サイズと、それぞれ揃うように調節している。 $ratio-text-size-header: 0.79412; $line-height-header: 2.125; .global-navigation svg { height: (1 / $ratio-text-size-header / $line-height-header * 100%); vertical-align: text-bottom; } 文字サイズはem単位で拾えるが、そのまま使うと「あれっ？」となることが多々ある。行ボックスという概念があるためだ。そのためこのように文字サイズの係数と行の高さの係数を使い、行ブロックに対して文字がどれくら
遅延読み込み用のぼやけた画像
Mediumでとある記事を高速にスクロールして読んでいたら、さりげなく画像を遅延読み込みしていることを知った。読み込み発火のタイミングがうまいのかあまり遅延読み込みの存在を感じさせないのもすごいと思ったが、プレースホルダー画像の実装方法が良さそうだった。単純に元の画像を幅30px程度まで小さくしてそれをブラウザーにリサイズさせることでぼやけた画像をプレースホルダーとして表示しているだけだが、十分に機能していそうで目から鱗だった。 画像の遅延読み込みはなかなか曲者で、読み込むタイミングやプレースホルダーとしている画像が悪いと大きくユーザーにストレスを与える。プレースホルダーでよく使われるローディング画像は読み込み中のインジケーターではあるが、同時に何か遅いことをやっていますというネガティブな印象も与えてしまう。ユーザーはローディング画像を見るとスクロールを止めなくてはならないのかと感じること
NovaフォントとProフォント他
Windows 10ではデフォルトでもいくつか新しいフォントが加わっているが、欧米向けには特別に新たなフォントが提供されている。それらはオプション機能から機能の追加を選択し、ヨーロッパ各国語追加フォントを探してインストールすると使えるようになる。 Arial Nova Georgia Pro Gill Sans Nova Neue Haas Grotesk Rockwell Nova Verdana Pro 追加されるのは以上の6ファミリーだ。Novaフォントはウェイトの充実はあるものの正直期待外れで、Neue Haas Groteskも高DPI環境下なら……という程度であまり魅力的ではない。 その一方でGeorgia ProとVerdana Proはかなりのクオリティに感じる。Georgia ProはGeorgiaが元々優れていたためあまり違いは感じないが、見やすさを失わずにヒゲ(セリフ
プレースホルダーのスタイルにおけるノーマリゼーション
テキスト入力コントロールにplaceholder属性を使って入力例を表示することができるようになってから、もうかなりの年月がたった。悪用されてもいるが、わかりやすいフォームには不可欠になりつつある程度には浸透したと言ってよいだろう。ただMozilla Developer Networkのグローバル・ナビゲーションに設置されている検索フォームのようにそのスタイリングに失敗しているケースはままある(Chrome 43だと入力済みかどうかまったく判断できない)。そういった失敗を極力減らすためには、Firefoxのようにopacityプロパティーを使ってノーマライズしてやるのが良いだろう。 ではFirefoxの挙動に合わせるようにノーマリゼーションする場合はどのようにCSSを書くことになるのだろうか。 Firefoxではユーザー・エージェントCSSでopacityの値に0.54を指定している(以前
下方向にもCSS Transitionでスムーズにスクロール
少し前のCSS Transitionを使ったスムーズにスクロールしてトップに戻る機能という記事では、CSS Transitionを使ってスムーズにスクロールさせるためにbody要素のmargin-topプロパティーを負の値を設定した。これはとにかく上方向へのスクロールにしか使うことは出来ない。下方向にスムーズにスクロールさせるためにはまた別のアプローチが必要になるようだ。 何かしらのCSSプロパティーを使い、body要素を上方向にずらすということになる。つまりtransformプロパティーでtranslate()やtranslate3d()を使いY方向のマイナスへ動かすのが向いているようだ。あとはtransitionプロパティーを組み合わせるだけでスムーズにスクロール(しているように見せる)ことができる。 Demo: Scroll Down Smoothly with CSS Transi
CSS Transformによるセンタリングのベスト・プラクティス
上下左右のセンタリングには様々な手法が編み出されてきた。最近はCSS Transformを使う方法がメジャーになりつつある。コンテナーとセンタリングしたい要素のサイズが共に不明でもうまくいくところなど、そこそこ万能感があるのがポイントだろうか。このCSS Transformによるセンタリングは左下に動かしてから右上に戻すパターンと、その逆の右上に動かしてから左下に動かすパターンがある。どちらでも理論的には上手くいくが、ベスト・プラクティスとなりうるのは後者だけだろう。 Demo: Centering Unknown with CSS Transform (top/left) このデモは実際に不具合が起こりうるパターンになっている。センタリングする要素をtopとleftプロパティーで動かした後、transform: translate(-50%, -50%)で元に戻しているわけだが、Inte
Infield Top Aligned Labelパターン
Why Infield Top Aligned Form Labels are Quickest to Scanという記事を読んだ。Infield Top Aligned Labelとは上記スクリーンショットのように入力ボックス内の上端に置かれたラベルのことだ。記事ではラベルと入力ボックスを上下に並べるごく一般的なパターンとプレースホルダーをラベル代わりにするゴミ大人気のパターンと比較している。確かにわかりやすく、スムーズにフォームを埋められそうな印象を受ける。 記事では紙媒体の書類でもこのようになっていることがよくあり、それがメタファーとして機能することも強く後押しすると書かれており、なるほどと感じた。書類やテスト(もう記憶はあやふやだが)などの詰め々々のフォームにはあまり良い印象はないが、間違いなく慣れてはいるので、わかりづらさとは無縁だろう。それを考えると効果的なラベル・レイアウトだ
CSS Font LoadingとFont Face Observer、Web Font Loader
CSS Font LoadingとFont Face Observer、Web Font Loader ウェブ標準であるCSS Font Loadingが気軽に使えるようになるにはまだまだ時間がかかりそうだ。そのポリフィルであるFont Loaderは動作が不安定かつ開発が止まっており信用できない。代替技術としてはポリフィルと同じ開発者が積極的にコミットしているFont Face Observerと、広く使われているWeb Font Loaderがある。同じフォントの読み込みを検知する場合、この三者ではどのようにコードが変わってくるのだろうか。 以下のコード例では、自前でホスティングしているOpen Sansの読み込みが完了・失敗したらbody要素にクラスを振るという単純なケースを書き分ける。 CSS Font Loading仕様はPromiseによる実装で、読み込み待ちはPromiseで
max-widthを否定するクエリー
モバイル・ファーストが浸透して久しくなり、めっきりmin-widthクエリー以外を見かけることはなくなった。そんな中、not (max-width: 768px)という書き方を見かけて、なるほどなと思った。現状のブラウザーにおける実装(と安定した仕様)では768pxを含まずそれより大きいという表現がmin-widthでは書くことができないが、notキーワードとmax-widthを組み合わせることで実現できる。 Demo: Negation of max-width query 特定のデバイスや解像度を強く意識したクエリーの是非はとりあえず脇へ置いておいて、iPhone 5s以下やらiPad Airやら一般的なノートブックやらを意識してクエリーを書くことはままある。多くの場合はそれら特定のデバイスのサイズからを区切りにしてクエリーを書くわけだが、それらのサイズまでで書くとなると少し曖昧な記述
位置を固定した要素のすたっきんぐ・こんてきすと？
Chrome 22で隠し設定にposition: fixedされた要素配下でのz-indexプロパティーの扱われ方を仕様に準拠する形へ変えるものが用意された……とか言われてもStacking Contextsの仕様を読んでもまったくわからなかったので簡単なテストを書いて理解した。 HTMLは以下のような形。 <div class="red"></div> <div class="fixed"> <div class="green"></div> </div> <div class="blue"></div> これをCSSで赤緑青に色分けして、z-indexプロパティーを赤緑青の順にする。 .red { position: absolute; z-index: 1; background-color: red; } .fixed { position: fixed; } .green { p
Pure CSSな吹き出し
Twitterで「CSSで吹き出し作るのブクマし忘れててどこにあったか忘れた……」とかつぶやいたらe_luckさんがImage-free CSS Tooltip Pointers - A Use for Polygonal CSS?を探してきてくれた。このエントリでは枠線をつけるために入れ子になっていたりちょっとわかりづらかったので、ものすごく単純化して解説してみようとかなんとか。 Pure CSSな吹き出しのサンプル: Speech Bubbles とりあえず、吹き出しの尻尾を左下に出すもの(サンプル内では4つめのサンプル)を例にして説明していく。HTMLコードは以下のようなもので、bubbleというクラス名を振ったdiv要素がコンテナ、bodyというクラス名を振ったp要素が吹き出しのベース、tailというクラス名を振った空のdiv要素が尻尾になる。 <div class="bubble
フルスクリーンでオーバーレイの検索ボックス
増えてきたフルスクリーンでオーバーレイの検索ボックスだが、まだこれといった無難な実装方法はないように見える。今だとvw/vh/vmin/vmax単位を使ってレイアウト、:target擬似クラスを使ってトグルという形にすれば、ほぼCSSで実現できそうだ。 Demo: Fullscreen Overlay Searchbox デモではShow Searchboxというリンクをクリックすると検索ボックスが表示され、検索ボックスの左上にある✖をクリックすると閉じることができる。実際のウェブサイトではリンクの代わりに虫眼鏡のアイコンでも使ってやれば良いだろう。 マークアップ <aside id="search" class="searchbox"> <h1>Search this site</h1> <form> <input class="query" placeholder="Enter sea
OOCSSの欠点とEvery Declaration Just Onceのもたらすもの
昨日も少し書いたEvery Declaration Just Onceアプローチ(以下EDJOと略す)について、皆が目を瞑っているOOCSSの欠点、CSSが持つ特徴、HTMLとの兼ね合いという点からもう少し書いてみたい。これについては未だ誰ともちゃんと議論していない。機会があったらこの記事をベースにでも誰かと話してみたい。 上記Googleの文書は、主にパフォーマンスの観点で書かれている。どうしても長くなりがちな定義を分散して書くよりも、能動的に短くすることができるセレクターを分散して書いた方が、プロダクションにおいてリリースされるCSSファイルのサイズを小さくすることが可能だろうというものだ。同時にこの文書の筆者は自身のブログで、より自然にCSSを書くための手法(原文: 「The Natural Way of Writing CSS」)としてこのEDJOという手法について述べている。 僕
“マークアップ”するということ ～ HTML5勧告に寄せて ～
HTMLを適切な要素を使って書いていくことは実はそれほど難しくはない。しかし過剰に要素を使わずに、かつスタイリングすることも意識して、と適切に“マークアップ”するのはなかなかの修練を必要とする。いったい“マークアップ”するということはどういうことなのだろうか、そしてどのような思考の元に行えば良いのだろうか。 HTML5での変化 著作権表示のマークアップ small要素 footer要素とsmall要素 p要素とdiv要素 footer要素とp要素 スタイリングとの兼ね合い マークアップするということ HTML5での変化 コンテンツに則した素直な形でマークアップできること。 HTML5で変わることや変わったことは多くあるが、それらをおおまかに俯瞰するとこのような言葉に集約できる。そのために様々な要素や属性が追加され、既存の実装をなるべく壊さない形で要素の意味に変更が加えられた。これらの変化は
ウェブ・フォントの読み込み - Weblog - Hail2u.net
ウェブ・フォントも完全に行き渡り、今はどう効率的に配信するかについて多くの時間を割くようになった。Google Fontsの低め安定路線を見限り、TypeKitやFonts.comへ鞍替えする人々も増えた。それと同時に自前でホスティングする人々も徐々にその数を増やしており、どれが最適解なのか一応の結論が出るにはもう少しかかるだろう。まず、ウェブ・フォントの読み込みにおいてどのようなアプローチがあり、どのようなメリット、そしてデメリットがあるのだろうか。 TypeKit等に頼るにしろ、自前でホスティングするにしろ、もちろん最終的にはウェブ・フォントをブラウザーに送りつける必要がある。読み込みとはまさにその部分の話だ。話がややこしくなるので、多様な実装を意識した安全な書き方などについては触れない。 普通に@font-face定義を利用 @font-face定義をただ普通に書く場合のメリットは、
安全な@font-faceの書き方
Translation of: Bulletproof @font-face syntax 最も優れた@font-faceの定義方法を解説させて貰おう: @font-face { font-family: 'Graublau Web'; src: url(GraublauWeb.eot); src: local('Graublau Web Regular'), local('Graublau Web'), url(GraublauWeb.otf) format('opentype'); } 最後になぜこの方法が最も優れたものなのかは説明することにして、最初に他の方法の欠点を解説することにしたい。もちろん、問題の中心になるのはIEが.eotフォントが必要なのに対して、他のブラウザでは.ttfか.otfを必要とすることである。それでは順に解説していこう。 条件付コメントによる方法 <style
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
