安全でアクセシブルなアイコン・フォント
Translation of: Bulletproof Accessible Icon Fonts by Filament Group アイコン・フォントを利用する場合、あらゆるユーザーに適切にアイコンを提供しようとすると、かなり気をつける必要があります。そのフォントが読み込まれなかった時にどうなりますか？@font-faceがまだサポートされていないブラウザーでは？ どうすれば安全に(bulletproofに)アイコン・フォントを利用できるかをこれから解説したいと思います。 効率的で機能的なウェブサイトを制作するという、この終わることのない探求において、ベクター形式のアイコンを提供する手段として、簡便であるフォントを利用することが何度も提案されてきました。対して私達は通常ベクター形式のアイコンとしてSVGをIan Featherがブログ書いたような理由から選んで(また、薦めて)おり、既に
CSSによる両端揃えの問題点とその解決へ向けて - Weblog - Hail2u.net
日本語の文章の場合、両端が揃っているとおさまりが良い。CSSではその両端揃えを行うためにtext-alignプロパティーにjustifyという値が用意されている。完全に日本語だけの段落ならほぼ100%、和欧混在の段落でも9割以上の段落で想定通り機能するが、まれに無残な結果になる。それは自動折り返しで長めの英単語が行頭に来る場合だ。 両端揃えは文字と文字の間を開けることで行われる。日本語だけの段落の場合、ほとんどどこでも改行することができる上、行送りの禁則処理が起こっても最大2文字分なので、行の長さが十分にあればその調整は認識されないだろう。問題は和欧混在の段落だ。 Demo: Justifying Problem この「contemporary」くらいの長さの単語だとまだマシな方で、あまり問題が起こることはない。しかし、このウェブサイトのようにcompareDocumentPosition
Webフォントの非同期読み込み - Weblog - Hail2u.net
Webフォントの読み込みは@importだと色々まずいので、主にlink要素を使って並列に読み込むわけだけど、これもまた貴重なHTTPリクエスト数を消費するとか、CSSのパース完了が少し遅れるなどあって、完璧な解というわけじゃない。それを非同期にWebフォント定義の含まれるCSSファイルを読み込むようにして、Webフォントのロードをページのレンダリングと並行して行わせるのはどうか、という試み。 非同期化することによりWebフォント定義の含まれるCSSファイルのリクエストとパースが、ページのレンダリングと並行して行われるようになる。head要素内でlink要素を直接書いた場合は、Webフォント定義の含まれるCSSのリクエストとパース後にページのレンダリングが始まることが多いので、体感速度(ページのレンダリングの開始までの所要時間)は向上する可能性が高い。 動的なlink要素の追加 いわゆるソ
ウェブ・フォントの読み込み - Weblog - Hail2u.net
ウェブ・フォントも完全に行き渡り、今はどう効率的に配信するかについて多くの時間を割くようになった。Google Fontsの低め安定路線を見限り、TypeKitやFonts.comへ鞍替えする人々も増えた。それと同時に自前でホスティングする人々も徐々にその数を増やしており、どれが最適解なのか一応の結論が出るにはもう少しかかるだろう。まず、ウェブ・フォントの読み込みにおいてどのようなアプローチがあり、どのようなメリット、そしてデメリットがあるのだろうか。 TypeKit等に頼るにしろ、自前でホスティングするにしろ、もちろん最終的にはウェブ・フォントをブラウザーに送りつける必要がある。読み込みとはまさにその部分の話だ。話がややこしくなるので、多様な実装を意識した安全な書き方などについては触れない。 普通に@font-face定義を利用 @font-face定義をただ普通に書く場合のメリットは、
モダンとクラシックをとりもつスタイル・ガイド
既にあるウェブサイトの実装を、今後を意識してモダンにしようとすると、どうしても既存のクラシックな何かしらの置き換えが必要になる。多くの人が作り始めているであろうスタイル・ガイドはそういった時に役に立つ。現状での保証された結果を提示してくれるからだ。 クラシックな何かしらの置き換えが必要になった場合、その目的をきちんと知る必要がある。そうでないと正しくモダンに置き換えることができない。すべてをフルスクラッチで書き直すといった場合でも、少なくともクラシックな何かしらによる結果を知る必要があるだろう。 スタイル・ガイドは良くも悪くも結果に過ぎないが、ちゃんとした結果であることは保証されている。それをきちんと作っておけばとあるコンポーネント(とでもいうようなもの)がどのような意図を持ったものかを具体的な実装を知ることなく理解できるはずだ。 ちゃんと作られたスタイル・ガイド、というとかなり大げさだが
Sass変数の(ダメそうな)案
時代はとっくにSass 3.4なのでローカル変数メインにしたいということが前提にある。そうすることで変数名にBEM等のしっかりとした命名規則を使わずに済み、自己言及的な変数名と数文字の変数名でおおむね完結することになる。パーシャル間で共有したい場合はしょうがないので!globalを使ってローカル変数をグローバルへエクスポートするようなあきらめを許容して誤魔化す。 まずある程度はグローバル変数として定義しておく必要がある。それらグローバル変数は自己言及的なもの(それこそ$color-black: #000;といったようなもの)で、実際にウェブサイトで使われる要素やクラスとは無関係に定義していく。 // _variables.scss $ratio: 1.7; $ratio-text: 1; $ratio-text-large: 1.5; $line-height-default: $rati
Style Guide - About - Hail2u.net
Sketch, markup, code, style, test, and then deploy. Weblog Documents Projects About Hail2u.netで使われているマークアップやスタイルの解説兼プレビューのページです。マークアップはHTMLのソースを、スタイルについては全ての変更履歴を含むGitリポジトリかこのページで参照されている非圧縮のCSSファイルを参照してください。このページに限ってはマークアップにおかしいところが多々ありますが、その多くはプレビューを作る上でのやむを得ない事情によるものです。 バージョニング フォーマットはSemantic Versioningを使っています。ただしAPIの変更などというものはあまりないので、以下のような条件でバージョン番号の増加を行っています: メジャー・バージョンは、レイアウトの大幅な置き換えやテーマカラー
Hail2u
Hail2uは、幅広い話題の記事や、おすすめのウェブページ、読んだ本などを公開している、ながしまきょう(hail2u)の個人ウェブサイトです。CSSや、HTML、ウェブ標準についての話題が多く、JavaScriptやサーバーサイドの話がそれに続きます。近年は特に話題を限定せずにいろいろ書いています。 最近の雑多な記録 3か月ごとの定期リリースでvim-css3-syntaxのv2.4.0を出した。 松岡美術館にモディリアーニなどの所蔵品が出てくる展覧会を見に行く。 マイナー番号が上がり、いろいろ変わったが、雰囲気は変わっていない。 GitHubにはブランチActivityという機能があり、そこでは強制プッシュなどで見えなくなったコミットのハッシュも見つかるようだ。 2023年の12月に行った展覧会の後期を見に、再びWHAT MUSEUMへ行く。 よくよく考えたつもりでESRのMagSafe
“マークアップ”するということ ～ HTML5勧告に寄せて ～
HTMLを適切な要素を使って書いていくことは実はそれほど難しくはない。しかし過剰に要素を使わずに、かつスタイリングすることも意識して、と適切に“マークアップ”するのはなかなかの修練を必要とする。いったい“マークアップ”するということはどういうことなのだろうか、そしてどのような思考の元に行えば良いのだろうか。 HTML5での変化 著作権表示のマークアップ small要素 footer要素とsmall要素 p要素とdiv要素 footer要素とp要素 スタイリングとの兼ね合い マークアップするということ HTML5での変化 コンテンツに則した素直な形でマークアップできること。 HTML5で変わることや変わったことは多くあるが、それらをおおまかに俯瞰するとこのような言葉に集約できる。そのために様々な要素や属性が追加され、既存の実装をなるべく壊さない形で要素の意味に変更が加えられた。これらの変化は
CSSライブラリーはそのままでどうぞ
Normalize.cssを始めとして、Twitter BootstrapやPureに至るまでCSSのライブラリーは数多くある。それらはそれなりに気をつけて作られているが、他のライブラリーと混ぜることはもとより、ページ制作者のCSSと混ぜることは想定されていない。単純にlink要素を使って先に読ませるか連結するだけで使わないと、開発者はもちろんそれらが使われているページのユーザーにも意図しない不具合が起きる可能性がある。 そのためNomralize.cssなどではわざわざ以下のように推奨されている。 It is recommended that you include the normalize.css file as untouched library code. 概ねライブラリーと呼ばれるものには手を付けるべきではないが、フロントエンド界隈では軽視されている傾向があるように思う。特にC
Google Fontsはいつまであるのか？
Will Google Fonts Ever Be Shut Down?という記事を読んだ。とてつもない数のウェブサイトで利用されているGoogle Fontsが果たしていつまで無料で自由に使えるままなのかを、今のGoogle Fontsの状態とその持つ意味から考察されてる。現状ではメリットがあるので提供しているけれども、それがコストに見合わなくなったらすぐやめるんじゃないかみたいな悲観的な観測で終わる。 Google Fontsからビジネス・モデルのようなものがよく見えてこないことと一部の限られたユーザーにのみ高く評価されていることが、ジャンルがまったく違うがGoogle Readerと重なるところがあるのは少しわかる。それを考えるとサービスの停止もありそうと考えてしまうのもわからないこともない。でも悲観的になるのはちょっとわからない。 それほどコストはかかっていないと思うし、とんでもな
main要素……
main要素については色んな人が色んな所で書いてるので、そのものがどういうものかとかは今さら書かない。main要素がもし複数出てきていいならアレとアレにdiv要素使わなくて良くなるなーという。アレとアレというのは、hAtomのentry-contentともうひとつはSchema.orgのArticle(BlogPosting)/articleBody。とか言いつつそこら辺は好みの問題っぽいのでちょっと別の話。 しょうがなくdiv要素を使うケースというのはそこそこあって、その最たるものがdiv.wrapper。これにrole="main"との対応が考慮されてmain要素の誕生につながったわけだけど、あらためてrole="main"のことを考えながらmain要素を使ってみると、div.wrapperは常にmain要素になりうるのかみたいな疑問が湧いた。 例えばウェブログのpermalinkのペ
JekyllみたいなのとWordPressみたいなのの組み合わせ
静的ウェブサイト生成ツール(面倒なので以下Jekyllみたいなの)と動的ウェブログ・システム(同じくWordPressみたいなの)のそれぞれの長所や短所はみなよく知っているようで、よりその人の状況にあったどちらかを選んだみたいな記事をよく見る。そういうの見る度にどうして両方使わないんだろうと思う。 静的なHTMLでのウェブサイトの運営は簡単で楽だしコストも掛からず、環境もあまり選ばない。けどMovable Typeでの破綻を引き合いに出すまでもなく、1000やそれ以上のHTMLを生成できる無理のないシステムはあるのかというと微妙な感じがする。で、規模に応じて動的なCMSと使い分ければ……となることが多いわけだけど、使い分けるのではなくJekyllみたいなのとWordPressみたいなのを組み合わせるのが良いのではないか。 テンプレート 分けちゃうとテンプレートの管理も分かれて面倒くさいとか
SassとBEM
SCSSファイルを整理し直している時、一気にBEMなクラスを使って書きなおしてやろうかとも考えていた。けど途中でSassならSCSSファイルの分割とその中での工夫によってBEMの構造を表現できそうと感じたので、今はそういう方向で試行錯誤している。実際BEMのウェブサイトでもファイルシステムを使ったBEMの表現方法という似た話が書かれているので荒唐無稽な考えではなさそう。 SCSSファイル名でblockを表現 その中でplaceholder selectorを使ってelementとmodifierを表現 外からはこのplaceholder selectorは使わない 既存のマークアップを利用したセレクターから@extendでBEM構造を関連付け HTMLファイルではBEMなクラスは振らない 必要な場合はシンプルなクラスを振る イメージはこのような感じ。HTMLでのマークアップの簡潔さは維持で
Sass: adjust-font-sizeミックスイン
ビューポートの幅に合わせてフォントサイズを変更するCSSを、コッぺッするのをやめSassのミックスインにした。あんまり見ない感じのミックスインになったのでメモがてらエントリーに。こうなるともうCSSじゃないどころかSCSSとしてもとても読みづらいものになってきていて、ダメなミックスインの例な気がしないでもない。 $safe-for-content: 4.5em; $safe-for-full: 66em; @mixin adjust-font-size($sizes) { @each $size in $sizes { $ratio: $size / 16px; $feature: min-width; $value: $safe-for-full * $ratio * $ratio; @if ($ratio < 1) { $feature: max-width; $value: $saf
Sassの!defaultフラグの使い方と使われ方
Sassを書く時には変数を多用することと思います。それら変数は自分で定義して自分で使うので、同じプロジェクト内で再定義する必要はあまりありません。しかし他人や自分の作ったSassファイルを流用する場合、その中で使われている変数の値を最適化する必要が出てきます。もしその変数がハード・コーディングされているだけだとしたらどうでしょうか？ その場合変数を直接書き換えることになるでしょう。こういったSassファイルの再利用における問題を解決するためにSassには!defaultというフラグが用意されています。 Less & Sass Advent Calendar 2011もついに18日目ですね。ゴールまであと少しです。 まずはSassリファレンスの!defaultを扱っている部分を読んでみましょう。参考にざっと以下に訳してみました。 変数の値を指定する時、!defaultというフラグを付けておく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
