ID使っても別に問題ない
CSSでID使うの良くない……どころか、ID使うのはゴミクズカスみたいな風潮で辛い。その根拠はいくつかあり、それらはCSSだけをただそのまま書く場合には納得出来ないこともないかなーと思うので余計に辛い。特にOOCSSのようなアプローチではIDは混ぜるな危険。だからといってIDを使わないのがベスト・プラクティスなわけじゃない。 CSS Lintの利用が広まり、これがID使うなって怒るのも原因の一端な気がする。Disallow IDs in selectorsではIDの問題点として以下のようなものを取り上げている。 However, IDs have a downside: they are completely unique and therefore cannot be reused. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
2018年のウェブフォントについて
少しの間Noto Sans Japaneseを利用していたが、すぐに止めた。やはりFOITが気になる。かといってFOUT強制も苦肉の策という印象しかない。……このような記事を書いていたら、先にうまくまとまったfont-displayデスクリプターについての記事が広まっていたので、そちらを読むのが良い。 他が高速・即時化しつつある現在、1MBくらいを超えるウェブフォントはどうにもならない。動的なサブセット化はわからなくもないが、労多くして……という印象だ。自前で作るのも難しいし、安心して任せられる速さの提供者は知らない。 回線の状況(種別ではなく)に応じてうまいこと切り替える仕組みを導入しなければならないだろう。そうなるとデバイスから「今、回線あんま速くないです……」といった動的な情報を得たいが、プライバシーにかかわるので難しい。残る可能性はfont-displayデスクリプターのみだ。 @
イアン結び
素早く結べ、ほどけづらいというイアン結びというちょうちょ結びのやり方を教えてもらった。スニーカーに限らず、革靴のロウ引きのひもでもこれで結べる。ゆるむということがほとんどなく、確かにほどけづらい。動画では説明が複雑で、難しく見えるが、やってみるとなんとなくできる。 普通のちょうちょ結びと違い、結び目に指をくぐらせる必要がないため、結び目が小さく決まる。その結果としてきつく結べ、ほどけづらいということのようだ。複雑な船乗り系の結び方のように結び方自体がほどけづらいというわけではない。 素早く結べるようになるまでにはかなりの修練が必要そうだ。今のところ普通のちょうちょ結びと同じくらい時間がかかっている。両手を同時に動かすのが難しく、これ以上素早く結べそうにない……。
CSS、レイアウト、現在、未来 - Weblog - Hail2u.net
floatプロパティーで柔軟なレイアウトを行うことは可能だが、それには熟練と標準化されていない知識が必要になる。Flexible Box Layoutは標準化されていないという問題は解決するが、限られた矩形を基準にレイアウトをすること由来の独特のおまじないという熟練は必要になる(heightプロパティーの工夫)。レイアウトには様々なパターンがあり、Flexboxが解決するのはその一部分でしかない。 問題はFlexboxの能力(とCSSにおける様々な単位の汎用性)が意外に高く、cross sizeが想定されているパターン以外にも流用できることだ。このことはfloatプロパティーが本来フローコンテンツが回り込むように浮かせるものだったのにも関わらず、その汎用性から万能ツールのように扱われてしまったことと似ている。ウェブ開発者たちからもそのもっとすごいやつといった扱いになっていると言って良いだろ
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が元々優れていたためあまり違いは感じないが、見やすさを失わずにヒゲ(セリフ
遅延読み込み用のぼやけた画像
Mediumでとある記事を高速にスクロールして読んでいたら、さりげなく画像を遅延読み込みしていることを知った。読み込み発火のタイミングがうまいのかあまり遅延読み込みの存在を感じさせないのもすごいと思ったが、プレースホルダー画像の実装方法が良さそうだった。単純に元の画像を幅30px程度まで小さくしてそれをブラウザーにリサイズさせることでぼやけた画像をプレースホルダーとして表示しているだけだが、十分に機能していそうで目から鱗だった。 画像の遅延読み込みはなかなか曲者で、読み込むタイミングやプレースホルダーとしている画像が悪いと大きくユーザーにストレスを与える。プレースホルダーでよく使われるローディング画像は読み込み中のインジケーターではあるが、同時に何か遅いことをやっていますというネガティブな印象も与えてしまう。ユーザーはローディング画像を見るとスクロールを止めなくてはならないのかと感じること
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を
1文字だけの改行の拒否
日本語の文章では任意の位置で改行できるため、レスポンシブ・ウェブ・デザインでは多くの場合、望まない位置での改行が起きる。例えば最後の1文字だけ次の行になってしまうと、読みやすさや理解度に致命的な影響を与える。例えば「？」だけ次の行に送られた場合、あるとないのでは大きく印象が変わるだろう。Twitterで@Takazudoと@oosugi20の会話を見て、やはりみな似たようなことは考えるものだと感じ、このあたりのことについて書いてみたくなった。 僕はjQueryで最後の五文字では改行が起きないようにいじったりしていた(うろ覚えで書いたもので、実際にはもっと複雑にやっていたと思う)。見出しがテキストのみの場合、最後の数文字の間に非改行ゼロ幅スペース(U+FEFF)を仕込むことで、その間で改行が起こらなくなるという仕組みだ。ここでは比較のためにクラスで判定するように書いてあるが、実際にはh1から
安全でアクセシブルなアイコン・フォント
Translation of: Bulletproof Accessible Icon Fonts by Filament Group アイコン・フォントを利用する場合、あらゆるユーザーに適切にアイコンを提供しようとすると、かなり気をつける必要があります。そのフォントが読み込まれなかった時にどうなりますか？@font-faceがまだサポートされていないブラウザーでは？ どうすれば安全に(bulletproofに)アイコン・フォントを利用できるかをこれから解説したいと思います。 効率的で機能的なウェブサイトを制作するという、この終わることのない探求において、ベクター形式のアイコンを提供する手段として、簡便であるフォントを利用することが何度も提案されてきました。対して私達は通常ベクター形式のアイコンとしてSVGをIan Featherがブログ書いたような理由から選んで(また、薦めて)おり、既に
OOCSSの欠点とEvery Declaration Just Onceのもたらすもの
昨日も少し書いたEvery Declaration Just Onceアプローチ(以下EDJOと略す)について、皆が目を瞑っているOOCSSの欠点、CSSが持つ特徴、HTMLとの兼ね合いという点からもう少し書いてみたい。これについては未だ誰ともちゃんと議論していない。機会があったらこの記事をベースにでも誰かと話してみたい。 上記Googleの文書は、主にパフォーマンスの観点で書かれている。どうしても長くなりがちな定義を分散して書くよりも、能動的に短くすることができるセレクターを分散して書いた方が、プロダクションにおいてリリースされるCSSファイルのサイズを小さくすることが可能だろうというものだ。同時にこの文書の筆者は自身のブログで、より自然にCSSを書くための手法(原文: 「The Natural Way of Writing CSS」)としてこのEDJOという手法について述べている。 僕
validate-html.js
W3CがホスティングしているNu Markup Checkerを使ってローカルのHTMLファイルをバリデーションにかけるNode.jsスクリプトを書き直していた。だいたい大丈夫そう。Gruntタスク……はやろうとすると遅すぎて死ぬのでやめよう。 Download: validate-html.js 利用にはrequestパッケージの別途インストールが必要。Browserifyを使って依存解決したスクリプトにしようとしたら、requestパッケージがまだBrowserifyに対応していなかった……。 ValidatorのAPIは本家と同じで、送信するHTTPヘッダとしてUser-Agentが必須なこと以外は特に注意は必要ない。 W3CでホスティングされているものはValidator.nuのものと少し違って、HTML5の仕様書に準拠したものになっている。わかりやすいところではhgroup要素が
ローカルのフォント
少し前にこのウェブサイトがNeue HelveticaまたはCalibriになるように変更した。ウェブ・フォントを普通に使う機会が増えたその反動で、自分のウェブサイトは使いたくなくなる、といったところであまり深い理由は無い。ローカルのフォントだと表示の速さが3倍回しくらいに感じる。初期ページ表示までに特に引っかかりがないようなウェブページだと、コンマ1秒もないウェイトですら影響は大きい。 ウェブ・フォントの表示における技術的な問題は、解決することは難しいことがわかってきた。仕様が不十分なこともあるが、実装が依存している技術に左右され、そこはどうにもしようがなさそうな領域だからだ。HTTPS + HTTP/2でかなり改善する可能性はあるが、ウェブ・フォント用の専用ストレージがブラウザーに実装されない限りは完全には解決できないはずだ。 一方ローカルのフォントにも解決できない問題は多い。そのひと
我慢の期間
MovableTypeとWordPressとJekyllとHugoや、Gruntとgulp、SassとLESSとStylus、果てはjQueryなどの話はスケールやパターンを変えて繰り返される。その話はあたかも特定の何かに依存することが良くないとか新しいこっちのがすごいぞというように結論づけられることが多くて、僕にはちょっと頷けないこともあったりする。大切なのは何を解決しようとしていたかを忘れないことだと思う。複雑化しそうな場合にそこから先へ踏み込まずに我慢する期間がいるとかかも。 GNU makeでいいじゃん的な結論はそれは確かにビルドという点ではそうなんだけど、Gruntが解決しようとしていたのはそこじゃない。npmという生態系の中で完結させやすいタスク実行環境を手軽に用意することができることで、それ以上でもそれ以下でもない。実行速度以外にも腐臭を放つAPIやプラグイン間で一貫性のない
max-widthを否定するクエリー
モバイル・ファーストが浸透して久しくなり、めっきりmin-widthクエリー以外を見かけることはなくなった。そんな中、not (max-width: 768px)という書き方を見かけて、なるほどなと思った。現状のブラウザーにおける実装(と安定した仕様)では768pxを含まずそれより大きいという表現がmin-widthでは書くことができないが、notキーワードとmax-widthを組み合わせることで実現できる。 Demo: Negation of max-width query 特定のデバイスや解像度を強く意識したクエリーの是非はとりあえず脇へ置いておいて、iPhone 5s以下やらiPad Airやら一般的なノートブックやらを意識してクエリーを書くことはままある。多くの場合はそれら特定のデバイスのサイズからを区切りにしてクエリーを書くわけだが、それらのサイズまでで書くとなると少し曖昧な記述
Sassのリスト
Sassではいわゆる「配列」のような複数のデータを格納するリストを作れる……というのだけど使ったことなかった。リファレンスでもさらっと流されてるし、リストを使う@eachの説明でもベタに並べてあるだけで、どうやって作ってどうやって使うのかイメージできなかった。変数の値を空白区切りにしたらリストな変数になるということはどう考えてもリファレンスからは読み取れないと思う。 基本 特に難しいこともなく空白(かカンマ)区切りで指定するとリストになる。 $lists: foo bar buz; .test { property: $lists; } リストな変数であってもそのまま参照した場合は普通の変数と同じようにそのまま(空白区切りのまま)出力される。 .test { property: foo bar buz } リストの特定のインデックスの値を参照するにはnth()関数を使う。 .test {
ウェブ・フォントの読み込み - Weblog - Hail2u.net
ウェブ・フォントも完全に行き渡り、今はどう効率的に配信するかについて多くの時間を割くようになった。Google Fontsの低め安定路線を見限り、TypeKitやFonts.comへ鞍替えする人々も増えた。それと同時に自前でホスティングする人々も徐々にその数を増やしており、どれが最適解なのか一応の結論が出るにはもう少しかかるだろう。まず、ウェブ・フォントの読み込みにおいてどのようなアプローチがあり、どのようなメリット、そしてデメリットがあるのだろうか。 TypeKit等に頼るにしろ、自前でホスティングするにしろ、もちろん最終的にはウェブ・フォントをブラウザーに送りつける必要がある。読み込みとはまさにその部分の話だ。話がややこしくなるので、多様な実装を意識した安全な書き方などについては触れない。 普通に@font-face定義を利用 @font-face定義をただ普通に書く場合のメリットは、
transformプロパティーを使ったセンタリングで○○がぼやける
幅や高さがわからない要素を上下左右にセンタリングするには長らくdisplay: table-cellを使ったものが主流だった。最近は、よりシンプルに実装できることからtransformプロパティーを使って50%戻すというような手法がメジャーになりつつある。しかしtransformプロパティーで動かすと常に何かがぼやけるリスクを伴う。 transformプロパティーによる上下左右のセンタリングは、CSS Tricksに書かれた記事を見るのが一番わかりやすいだろう。 .parent { position: relative; } .child { position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%); } transformプロパティーのtranslate()で%を使う場合、その要素の幅と高さが基準に
横にはみ出すナビゲーション
今回(2014年9月)のAppleのウェブサイトのリニューアルにはいくつもの興味深い点がある。ナビゲーションの二本線とバツ印が共にインラインのSVGなことなどもそうだし、多くのポーションがモダナイズされたにも関わらずPrototype.jsを継続利用したこともすごく気になる。その中でも一番気になったのは狭い画面向けの横にはみ出すナビゲーションだ。 これまでの通常は隠されている狭い画面向けのナビゲーションの多くは、次の3つに大別されていた。 ドロップダウン オーバーレイ ドロワー 極稀にアイコンのみのコンパクトに横へ並べたものもあったが、いずれの場合もナビゲーションの項目は縦に並んでいることがほとんどだ。一覧性に富み、アクセス性が高く、ユーザーの学習コストも低い。 これに対して横にはみ出すナビゲーションは、項目を画面外にはみ出すように横に並べ、スワイプでスクロールして探させるという形のものだ
@charsetを先頭へ
CSSの仕様では@charsetは先頭に置かれたものしか効果を発揮しない。最近は共にUTF-8でHTMLとCSSを書くだろうと思うので、あまり使われず、気にすることはもうあまりない。ただ何かしらの事情があって使う場合、カジュアルにファイルを連結してプロダクション用のCSSを作成すると、無意味な場所に@charsetが出てきて無駄が多くなる。 ちゃんと書かれていることを前提にすると、ブラウザーの処理の仕方と同じように先頭以外の@charsetを問答無用に削除しても良い。しかし、Normalize.cssのような最初に読ませる必要があるライブラリと@charsetが必要なCSSファイルを連結するケースではそれではダメになる。最初に見つけた@charsetを先頭へ移動させるというような形が一番マシだろう。 異なる@charsetが指定されたCSSファイルを連結する時におかしなことになるが、そのC
Sassの!defaultフラグの使い方と使われ方
Sassを書く時には変数を多用することと思います。それら変数は自分で定義して自分で使うので、同じプロジェクト内で再定義する必要はあまりありません。しかし他人や自分の作ったSassファイルを流用する場合、その中で使われている変数の値を最適化する必要が出てきます。もしその変数がハード・コーディングされているだけだとしたらどうでしょうか？ その場合変数を直接書き換えることになるでしょう。こういったSassファイルの再利用における問題を解決するためにSassには!defaultというフラグが用意されています。 Less & Sass Advent Calendar 2011もついに18日目ですね。ゴールまであと少しです。 まずはSassリファレンスの!defaultを扱っている部分を読んでみましょう。参考にざっと以下に訳してみました。 変数の値を指定する時、!defaultというフラグを付けておく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
