meta要素のname=color-schemeについて
ダーク・モードへ適応するなら、フォーム関連要素の色も切り替えるよう、CSSを書くだろう。しかし、それだけでは、例えばテキストエリアで出てくるスクロールバーが明るいままなので、かなり浮いてしまう。meta要素でname=color-schemeを適切に設定すると、そういったスクロールバーの色も含めたあらゆるものの色を暗く(明るく)できる。 書き方は特に難しくない。ダーク・モードへ適応しようと、prefers-color-schemeメディア・クエリーを使って、明るい背景と暗い背景を切り替えるなら、以下のようにHTMLファイルのhead要素以下に書けばいい。viewportと似たようなものだ。 <meta name="color-scheme" content="light dark"> lightとdarkの順序は、逆でも意味は変わらない。これだけでユーザーのOSやブラウザーでのダーク・モー
普通の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デスクリプターのみだ。 @
スタイル・ガイド
はじめに このウェブサイトのHTMLや、CSS、JavaScriptについては、ほぼすべてをこのページで解説しています。それぞれに例も用意してあるので、挙動も確認できます。おおむね挙動の確認を優先しているため、言葉が足らなかったり、更新されていなかったりすることもあるので、詳細は開発者ツールなどを駆使してください。 このページのマークアップやスタイル、スクリプトには、おかしいところが多くあります。その多くは、解説や例を作る上でのやむを得ない事情によるもので、他のページではちゃんとしています。例示で使われている妙な文章は、雑記の過去記事からランダムに選択された文を組み合わせたものです。特に意味はありません。 また、このウェブサイトの完全なソース・コードをGitHubで公開しています。どのように生成されているかや、どのようなツールを利用しているかなどは、そちらを参照してください。 アイコン o
SVGOでSVGをインライン化
SVGをインラインでHTMLに含める場合、SVGOを通した方が良い。HTMLファイルのサイズへ与える影響が大きいからだ。しかしデフォルトの設定だと、色々消えたり消えなかったりするのでそこそこ設定が必要になる。特にimg要素のalt属性に近いtitle要素のid属性とそれを参照するaria-labelledby属性は残さなければならない。 SVGOの設定はYAMLで書き、CLIに--configオプションでそのファイル名を渡して実行する。 $ svgo --config=.svgo.yml -o - src/img/logo.svg YAMLでの設定は以下のようにした。 plugins: - cleanupIDs: false - removeUnknownsAndDefaults: unknownAttrs: false - removeXMLNS: true SVGの要素から参照されてい
遅延読み込み用のぼやけた画像
Mediumでとある記事を高速にスクロールして読んでいたら、さりげなく画像を遅延読み込みしていることを知った。読み込み発火のタイミングがうまいのかあまり遅延読み込みの存在を感じさせないのもすごいと思ったが、プレースホルダー画像の実装方法が良さそうだった。単純に元の画像を幅30px程度まで小さくしてそれをブラウザーにリサイズさせることでぼやけた画像をプレースホルダーとして表示しているだけだが、十分に機能していそうで目から鱗だった。 画像の遅延読み込みはなかなか曲者で、読み込むタイミングやプレースホルダーとしている画像が悪いと大きくユーザーにストレスを与える。プレースホルダーでよく使われるローディング画像は読み込み中のインジケーターではあるが、同時に何か遅いことをやっていますというネガティブな印象も与えてしまう。ユーザーはローディング画像を見るとスクロールを止めなくてはならないのかと感じること
ページごとのCSS - Weblog - Hail2u.net
HTTPS＋HTTP/2時代なのでCSSを連結しなくても大丈夫だよ、といった風の記事をよく見るようになった。僕はそういった推測や検証は概ね間違っていると考えている(そのうち検証したい)のだが、一方で小さいウェブサイトではそれなりにうまくいくとも考えている。まずは色々やってみようと、このウェブサイトでCSSを論理的な単位で作るように(分割するわけではない)した。 論理的な単位といっても、ウィジェットごとにCSSを作るのはいかにも小さすぎると感じた。様々なツールもそのような利用の仕方を想定されていないため、それぞれのウィジェットで同じコードを何度も書く必要が出てきたりもするだろう。そういうものをうまくまとめても結局はそのまとめたものを参照するコードが必要になる。 感覚としてはページ(の種類)ごとくらいに分けるのがわかりやすそうだ。例えばウェブログの記事ではこの3種が読み込まれることになる。 c
ファビコン・カンニング・ペーパー
Translation of: favicon-cheat-sheet ファビコンのサイズや形式についての読むと頭が痛くなる偏執的なカンニング・ペーパーです。以下のURLを参考にしました: rel="shortcut icon" considered harmful · Mathias Bynens <-- special thanks @mathiasbynens Everything you always wanted to know about touch icons · Mathias Bynens <-- special thanks @mathiasbynens Jonathan T. Neal | Understand the Favicon Favicon - Wikipedia, the free encyclopedia Making a Good Favicon -
2015年に見限ったCSS - Weblog - Hail2u.net
去年はCSSグラデーションを見限ったような気がする。CSSグラデーションは便利ではあるものの、実装の差がいまいち想像しづらく思ってもみない結果になることがよくある。SVGでやった方が結果からもテクスチャであるという面からも安定という印象だったため、去年からほとんど使わなくなった。今年はtext-shadowとletter-spacingプロパティー、そして::selection擬似要素を見限った。 text-shadowプロパティー 文字に影を付けるプロパティーだが、あまり有効に使える場面がない。エンボスやべベルの代わりにするには貧弱すぎることや透過しかできず合成モードを持たないことあたりが足を引っ張っている。もちろんいわゆるなんちゃってフラットデザインというレベルだと文字に影を付ける必要がほとんどないことも影響がある。 実際に今年作った・見たウェブサイトで使った・使われていたというのは記
CSS、レイアウト、現在、未来 - Weblog - Hail2u.net
floatプロパティーで柔軟なレイアウトを行うことは可能だが、それには熟練と標準化されていない知識が必要になる。Flexible Box Layoutは標準化されていないという問題は解決するが、限られた矩形を基準にレイアウトをすること由来の独特のおまじないという熟練は必要になる(heightプロパティーの工夫)。レイアウトには様々なパターンがあり、Flexboxが解決するのはその一部分でしかない。 問題はFlexboxの能力(とCSSにおける様々な単位の汎用性)が意外に高く、cross sizeが想定されているパターン以外にも流用できることだ。このことはfloatプロパティーが本来フローコンテンツが回り込むように浮かせるものだったのにも拘らず、その汎用性から万能ツールのように扱われてしまったことと似ている。ウェブ開発者たちからもそのもっとすごいやつといった扱いになっていると言って良いだろう
HTTPSにした時に気を付けたこと - Weblog - Hail2u.net
何回かやる必要が出てきそうなので、どういう形でやったのかをアバウトに記録しておく。本当は何もせずできればいいのだけど、世の仕様はそんなにうまくできてはいない。 内部リンク 事前に徹底的に書き換えておくのが良い。内部リンクにはドメインも不要なので/で始まる絶対パスで全部書くように統一するのが楽だろう。 ただしrel=canonicalは色々なウェブサービスから(時々考えなしにプロトコル・スキームから始まっていると仮定されて)使われるため、http:から始める方が安全かもしれない。そもそもFacebook向けのOGPでog:urlを書いている場合もあり、この類もプロトコル・スキームから始める必要があり、どうせ書き換える必要は出てくる。諦めて機械的に書き換えができる仕組みを作っておくのも良い。 このウェブサイトの場合は、OGP他を消した上で全て絶対パスにしておくという手法を取ったが、おすすめしな
HTTPSへ
宣言通りHTTPSに移行した。まずはCloudflareの無料HTTPSを利用している。Cloudflareでは設定でHTTP Secure Transport Securityも有効にできるので、HTTPのままであろう旧URLからもスムーズに移行されるはずだ。RSSリーダー等で全部新着になったなどがあったら申し訳ないが諦めてほしい。 移行にはなおかなり不安が残る。しかしCORESERVER.JPが無料でHTTPSを有効にできるようになったので、いざという時の避難場所は確保できるだろうと考えている。他のいくつかのホスティング・サービスでも無料だったり、年1000円程度で提供されていることは確認したので、もしCORESERVER.JPがダメでもなんとかなるだろう。 このままCloudflareが無料で提供し続けてくれると楽でよいが、そう楽観視することも難しいと感じる。明らかに金のなる木であり
srcset属性を使ったSVGフォールバック・ハック
SVGをサポートする環境がほとんどになってきた。それでもなんとか8であったり、かんとか2.3であったりのことを考慮せざるをえないという状況はありうる。それにはonerror属性を使った対応が有力だが、srcset属性でSVGファイルを指定するだけというハックのことを知った。将来的に使えなくなるわけではないが、やりたいことと実装に食い違いが少なからずあるのでハックと言って良いだろう。 <img src="foo.png" srcset="foo.svg"> 表示したいSVGをsrcset属性で、フォールバックに使いたいPNGをsrc属性で指定するだけだ。これでsrcset属性をサポートしているブラウザーではSVGが、そうでないブラウザーではPNGが表示される。srcset属性のサポートに対して、より多くのブラウザーがSVGをサポートしていることから成立する。もちろん食い違いがあるのでSVGを
Internet Explorer 10や11でSVGがぼやけてリサイズされる(ことがある)
Windows 7向けのInternet Explorer 11が出たので、早速インストールした。おかしいところも特になく、F12ツールもずいぶん使いやすくなってるし最高かと思ったら、このウェブサイトのSVGのリサイズがちょっと変だった。11だけかと思ったら10もだった。少し前までのFirefoxみたいにCSSのbackground-imageプロパティー経由だとアレなのかとか色々調べてたみたけど、どうも違う。どうやらリサイズ後の縦横サイズが小数点以下を含むようなケースでぼやけるようだ。 Demo: SVG Resizing Bug on IE10から11 デモのように64.5pxのように小数点以下を含むサイズにリサイズすると、Internet Explorer 11(10も)では参考のスクリーンショットのようにぼやける。整数ピクセルでのリサイズやFirefox 25やChrome 30で
プレースホルダーのスタイルにおけるノーマリゼーション
テキスト入力コントロールにplaceholder属性を使って入力例を表示することができるようになってから、もうかなりの年月がたった。悪用されてもいるが、わかりやすいフォームには不可欠になりつつある程度には浸透したと言ってよいだろう。ただMozilla Developer Networkのグローバル・ナビゲーションに設置されている検索フォームのようにそのスタイリングに失敗しているケースはままある(Chrome 43だと入力済みかどうかまったく判断できない)。そういった失敗を極力減らすためには、Firefoxのようにopacityプロパティーを使ってノーマライズしてやるのが良いだろう。 ではFirefoxの挙動に合わせるようにノーマリゼーションする場合はどのようにCSSを書くことになるのだろうか。 Firefoxではユーザー・エージェントCSSでopacityの値に0.54を指定している(以前
Safariにおける日本語の文章に対する下線
(Mobile )Safari 7.1より下線がディセンダーに重ならずに引かれるようになった。主にリンクの下線で確認することができる。概ね問題なく期待通りにうまく機能しているものと考えていたが、日本語の文章ではそれなりの確率(再現条件はよくわからない)でおかしくなることを知った。例えば上記スクリーンショットでは、大きめのグリフを持つ「作」や「安」などで下線が途切れているように見える。 Safariでこの機能は、現状では一部実装に留まるものの、CSSのtext-decoration-skipプロパティーを使って実装されている。仕様で定義されているinkという値の実装というわけだ。つまり同じくこのプロパティーを利用することで、挙動を他のブラウザーと合わせることが可能になる。 a { -webkit-text-decoration-skip: none; } 下線がきれいに見えるかどうかは、ディ
Chrome 42におけるフォント設定とlang属性
Chrome 42でこのウェブサイトの日本語部分が変わってしまった(かもしれない)。内部的な標準フォント設定が変わったことにもよるが、それだけではない。設定で指定したSans SerifフォントがCSSのsans-serif汎用ファミリーに反映されなくもなった。lang属性がある要素のみで再現する。 Demo: lang="ja", font-family, and Chrome 42 例えばWindowsでは仮にChromeの設定(chrome://settings/fonts)からSans SerifフォントをＭＳ Ｐゴシックや游ゴシックなどに変更していた場合、lang="ja"を指定している最初のセクションのみChrome内部で設定されている日本語標準フォントであるメイリオになってしまう。OS Xでも同じ挙動になる。条件はlang属性というだけで、Googleの検索結果ページなどでも
クリティカルCSSの動的なインライン化
Inlining critical CSS for first-time visitsという、クリティカルCSSを初回訪問時のみインラインに展開して、その後はインライン化せず予めキャッシュさせておいたフルセットのCSSを使うというアイディアについての記事を読んだ。実装はともかく、アイディアとして成立していないんじゃないかと思う。 クリティカルCSSをインライン化することのメリットは既に多くのウェブサイトでも取り上げられており、もちろんネタ元のGoogle PageSpeedでも項が割かれている。ここでは特に触れないが、描画領域の大きさにかかわらず初期描画の高速化には大きなメリットがあるとは言えるだろう。上記リンク先の記事ではそれを動的に行うことで、2度目以降の訪問の時にはキャッシュ済みであるフルセットのCSSを使わせるようにし、効率的なキャッシュ運用と保守性を実現する実装について解説されて
EDJOの(デ)メリット
Every Declaration Just Once (以下EDJO)アプローチの最大のメリットはなんだろうかということについて考えていた。情報設計と重なるところがまるでないため、設計思想としては完全に成立しない。つまりCSSを設計することを放棄し、設計されたHTMLに対してスタイルを割り当てていく手法としてのみ存在しうる。このことがすなわちメリットなのではないだろうか。 CSSの限られた文法が情報設計に基づく複雑な構造の表現に適さないことは明白だ。OOCSSではHTMLとCSSを設計のもとに平等に扱っていたが、どうしてもCSSにおいては限界があり、複雑な命名規則やCSSプリプロセッサーの登場となったのではないかと思う。CSSプリプロセッサーの高機能化により実現可能になりつつあるが、それと同時に高度に抽象化された複雑さも氾濫しつつある。 EDJOにおいてはその書かれ方を見ればわかる通り、
画像の縦横サイズの追加
自前の画像を参照する時にwidthとheight属性を追加すると激しい腹痛におそわれる病を長く患っていたけど、どうやら完治したようなのでバッチ処理で追加してた。ついでにimg要素の各属性の記述順序なども書きかえたりして、楽しく時間を浪費した。大いなる無駄だが、他人には迷惑をかけないし、途中から段々トランスしてきた。 サイズを明示した画像がはみ出すことへの対策にはCSSでmax-widthプロパティーを使う。それだけだと縦横比が狂ってリサイズされるので、以下のようにheightプロパティーも併用するのが良い。 img { height: auto; max-width: 100%; } @supports (object-fit: scale-down) { img { height: auto; max-width: none; object-fit: scale-down; } } こう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
