style属性にgrid-areaプロパティー
grid-template-areaプロパティーで、識別子を使って特化型のグリッドを作ることが増えた。こういう場合、各グリッド項目に対して、grid-areaプロパティーで名前を付けていくことになる。この名前付けを、CSSファイルではなく、HTMLファイルに書いてしまった方がいいのではないだろうか。 例えば以下のようなリストがあり、そのレイアウトにグリッドを使うとする。グローバル・ヘッダーのナビゲーションを想定している。例なのでa要素は省略した。 <ul class="nav"> <li class="news">News</li> <li class="feature">Feature</li> <li class="column">Column</li> <li class="store">Store</li> <li class="search">Search</li> </ul>
clamp()関数を使った基本フォント・サイズの決定
calc()やclamp()関数など、CSSの計算式では、100vwなどから%をうまく作れない。そのため、%の基本フォント・サイズを描画領域に応じて決定することは難しいと考えていた。しかし、%を作れなくても、100%にピクセルを加える形でもいいことがわかった。そこで、最小で100%、最大で125%、その間は描画領域のサイズに応じてなめらかに上昇するという形の実装を、clamp()関数を使って行った。 このウェブサイトでは既に導入されているので、上記変化を確認することができる。ユーザーがどのようなフォント・サイズ設定をしていても、なめらかに変化し、うまく動いているようだ。また、ズームしても問題なく動き、フォント・サイズの変更とズームを組み合わせてもちゃんと動く。「なんでもmin()、max()、clamp()関数でやってみよう！」というのは、今だけは正しい姿勢かもしれない。 実装 html
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で
Yu Gothic UIの仮採用 - ウェブログ - Hail2u.net
Yu Gothic UIというフォントがある。ＭＳ Ｐゴシックに対するMS UI Gothic的なものの、游ゴシックに対するものだ。あまり大っぴらには使われていないが、Segoe UIとフォントリンクされているので、日本語のWindows 10では日常的に目にしているはずだ。これをフォント指定に追加してみている。 Windows 10でUIに使われることからか、Windows 10発売当初からも(雑に)改善されたようで、あの問題は起こらない。メイリオに比べるとやはり狭く、長文には向かないと考えられるが、游ゴシックと比べるとちょっと狭いくらいなのでギリギリ許容範囲なのではないかとも感じる。またmacOSには存在しない(と思う)ので使いやすいという利点もある。ウェイトもレギュラー(400)以外に200、300、600、700相当があり、使いでがある。 system-ui generic fam
lang属性の効果範囲 - Hail2u
ウェブサイトの言語セレクトメニューを作る時、英語で一覧させることも多いが、それと同じくらいそれぞれの言語名でそれぞれの言語を表示することもある。母国語で表示されていれば絶対にわかるだろうし、見つけやすいだろうという理屈だ。そのこと自体にはいくつか欠点が考えられるわけだが、HTMLとしてはlang属性を使えばうまくマークアップできるだろう。同時にtitle属性を使って英語でフォローすると完璧……だが、そこそこ面倒くさいことになる。 それぞれの言語名でそれぞれの言語を表示した言語選択メニューは択一しづらい(またはスキャンしづらい)という問題がある。特にアルファベット＋αの言語名は混同しやすいし、ソート順が不明確になりやすく、順にたどって見つけなければならない。どこら辺にありそうかアタリをつけることができないわけだ。 ルート要素のlang属性でen-USが指定されているとする。 <span la
ウェブ・フォントの読み込み - Weblog - Hail2u.net
ウェブ・フォントも完全に行き渡り、今はどう効率的に配信するかについて多くの時間を割くようになった。Google Fontsの低め安定路線を見限り、TypeKitやFonts.comへ鞍替えする人々も増えた。それと同時に自前でホスティングする人々も徐々にその数を増やしており、どれが最適解なのか一応の結論が出るにはもう少しかかるだろう。まず、ウェブ・フォントの読み込みにおいてどのようなアプローチがあり、どのようなメリット、そしてデメリットがあるのだろうか。 TypeKit等に頼るにしろ、自前でホスティングするにしろ、もちろん最終的にはウェブ・フォントをブラウザーに送りつける必要がある。読み込みとはまさにその部分の話だ。話がややこしくなるので、多様な実装を意識した安全な書き方などについては触れない。 普通に@font-face定義を利用 @font-face定義をただ普通に書く場合のメリットは、
YUI 3: CSS Resetの問題
ブラウザごとのデフォルト・スタイルシートの違いを吸収するためのスタイルシートをメンテするのが面倒になったので、YUI 3のCSS Resetを使うことにした。が、このサイトではちょっとした問題が起こった。少し前にTwitterでつぶやいたりしたhtml要素にbackground-colorやbackground-imageを指定した場合、body要素の背景が描画エリアいっぱいにならなくなるというCSSの仕様絡みの問題。 この仕様によってbody要素に指定していたヘッダの背景画像がずれてしまった(ずれるサンプル)。ずれる理由は上記仕様によりbody要素の上下でmarginの相殺が起こり、marginの相殺が起こった部分は透明(親であるhtml要素)が透けて見える)ようになり、背景画像の開始点はそれに続くbody要素のコンテント・エリアになるから。 html { color: #000; ba
システム・フォントのショートカット - Weblog - Hail2u.net
システム・フォントのリフレッシュが各OSで進んでいる。かといって無指定の場合はそれらシステム・フォントが利用されるというわけでもない。あまり長いfont-familyプロパティーを書くのは好きではないので、@font-faceで抽象化したい。それを試すついでに、srcデスクリプターで-apple-systemキーワードが利用できるかどうかの確認もした。 Demo: The “System” Font Shortcut ざっと確認する限りはうまく反映されているようだ。こういうものを書いているとsystem汎用フォントファミリーなどなくてもどうにかなると思うが、同時にこういう形でしかどうにかできないからこそ必要なのかもしれないとも思う。少なくともSan Franciscoによってフォント指定の概念が覆されてしまい、リニアーなスタックでは表現することができなくなったので、必要な方向になっていくの
画像配置の自動化とその本当の目標
ウェブページにおいて図であったり飾りであったりする画像の配置はCSSを通して行う。多くの場合はクラスとしてパターン化した配置のひとつを要素に割り当てることで行うわけだが、これを自動化したい。具体的に言えば、画像の縦横サイズやアスペクト比、キャプションの有無に基づいて最適な配置を自動で行い、手作業で要素にクラス名を振らなくて済むようにしたい。 紙媒体の場合は物理的な制限があるので、文章が収まるようにレイアウトを決め、それに合うように画像を作成し配置するという形が多い。ウェブページでも同じように行われてきたが、物理的な制限は違う形のもののため、レイアウトは別の形で自由に行えるのではないだろうか。 また画像そのものにはその最適解が別にあるはずだ。写っているものの最も良い状態を求めて作成し、配置はその画像で伝えたいことが存分に伝わるように、かつ本文のバランスを崩すことなく配置できると良い。そういっ
max-widthを否定するクエリー
モバイル・ファーストが浸透して久しくなり、めっきりmin-widthクエリー以外を見かけることはなくなった。そんな中、not (max-width: 768px)という書き方を見かけて、なるほどなと思った。現状のブラウザーにおける実装(と安定した仕様)では768pxを含まずそれより大きいという表現がmin-widthでは書くことができないが、notキーワードとmax-widthを組み合わせることで実現できる。 Demo: Negation of max-width query 特定のデバイスや解像度を強く意識したクエリーの是非はとりあえず脇へ置いておいて、iPhone 5s以下やらiPad Airやら一般的なノートブックやらを意識してクエリーを書くことはままある。多くの場合はそれら特定のデバイスのサイズからを区切りにしてクエリーを書くわけだが、それらのサイズまでで書くとなると少し曖昧な記述
OOCSSの欠点とEvery Declaration Just Onceのもたらすもの
昨日も少し書いたEvery Declaration Just Onceアプローチ(以下EDJOと略す)について、皆が目を瞑っているOOCSSの欠点、CSSが持つ特徴、HTMLとの兼ね合いという点からもう少し書いてみたい。これについては未だ誰ともちゃんと議論していない。機会があったらこの記事をベースにでも誰かと話してみたい。 上記Googleの文書は、主にパフォーマンスの観点で書かれている。どうしても長くなりがちな定義を分散して書くよりも、能動的に短くすることができるセレクターを分散して書いた方が、プロダクションにおいてリリースされるCSSファイルのサイズを小さくすることが可能だろうというものだ。同時にこの文書の筆者は自身のブログで、より自然にCSSを書くための手法(原文: 「The Natural Way of Writing CSS」)としてこのEDJOという手法について述べている。 僕
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
下方向にもCSS Transitionでスムーズにスクロール
少し前のCSS Transitionを使ったスムーズにスクロールしてトップに戻る機能という記事では、CSS Transitionを使ってスムーズにスクロールさせるためにbody要素のmargin-topプロパティーを負の値を設定した。これはとにかく上方向へのスクロールにしか使うことは出来ない。下方向にスムーズにスクロールさせるためにはまた別のアプローチが必要になるようだ。 何かしらのCSSプロパティーを使い、body要素を上方向にずらすということになる。つまりtransformプロパティーでtranslate()やtranslate3d()を使いY方向のマイナスへ動かすのが向いているようだ。あとはtransitionプロパティーを組み合わせるだけでスムーズにスクロール(しているように見せる)ことができる。 Demo: Scroll Down Smoothly with CSS Transi
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の検索結果ページなどでも
indexのマークアップとpermalinkのマークアップ
何らかのツールでテンプレートを元にページを生成する昨今、あまりページごとに大きくアウトラインの構造(変な表現だ)が変わることはない。枠を作って流し込む、枠を作って流し込む、というわけだ。ウェブではコンテンツは主に文章であるので、流動性はそれなりに高く、流しこむこと自体は多くの場合は問題にならないが、もうちょっと考えても良い所ではある。 典型的なウェブログのindexのページは以下のような構造になっていることだろう。 header main article article article footer これから自身以外のarticle要素を取り除いたものがpermalinkのページ構造になる。 header main article footer この時点でmain要素でグルーピングする意味はほとんどなくなる。合わせてpermalinkでは文書のプライマリ・コンテンツはこのarticle要素
スクロールバー
昔はOSネイティブを尊重したスクロールバーにしろ派だった。今は描画領域がらみで色々考えたくないので、オーバーレイで独自描画されちゃえばいいのに派になってる。WindowsだとInternet Explorer 11以降(10以降かも)の自動非表示スクロールバー的なのが妥当な落とし所なのかな。かっこいいと思ってはいないんだけど。 ウェブ制作者としては、もちろんこの辺りの扱いが仕様通りに実装されてればどっちでも良いわけだけど、ちゃんとされそうな気配がまるでない。また仕様自体でもMedia Queriesのwidthやheightではスクロールバーを含むで、CSS Values and Units Module Level 3のvw系では含まない(スクロールバーの有無に影響を受ける)だったりして、大変覚えづらい。 それぞれがそうなっている理由や実装がマチマチな理由もなんとなく推測できる。でも、こ
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の変更などというものはあまりないので、以下のような条件でバージョン番号の増加を行っています: メジャー・バージョンは、レイアウトの大幅な置き換えやテーマカラー
MinifyしてからConcat
配布されているライブラリーを最小ツールに通すと、ライセンスあたりの扱いで面倒なことになる。またCSSの場合は壊れる可能性を否定できないことは意識しなければならない。ということで重い腰を上げて、最小化してから連結するような工夫をソース・マップを維持することを前提にこのウェブサイトで実験し始めた。 JavaScriptファイルのビルドをGruntでやるとして、最小化についてはソース・マップのサポートは問題ないので、いつも通りgrunt-contrib-copyとgrunt-contrib-uglifyを使うことにする。最後に連結する時にソース・マップを維持できるのかというのが最大の問題だったが、7月にソース・マップのサポートがgrunt-contrib-copyへ入っていたため、結果的にはこれを使うだけで良かった。 タスクの手順的には以下のようになる。 一時ディレクトリーを掃除 一時ディレクト
タスク・ランナーをnpm run-scriptでラップ
npm で依存もタスクも一元化するという記事を興味深く読んだ。僕もしばらく前、具体的にはnpm v2出た時からGruntをnpm run-scriptでラップして使っている。概ね良好に機能すると感じている。懸念であった引数で特定の処理を行わせたいようなケースもnpm v2で引数を解釈できるようになったので解決した。 npm run-script経由にすることによる大きなデメリットとしては、そんなに速くもないnpm経由で常にタスクを実行することによる速度の低下が挙げられる。 この速度の低下は、Gruntやgulpの主要な目的であるビルドにおいてはそれほど問題にならない。ビルドにかかる時間に比べると、相対的にその低下の割合は低いものだと考えられるからだ。しかしタスクはそういったものにとどまらず例えばHTML(やMarkdown)のプレビューであったり、Sassのオンデマンド・コンパイルといった
Sassでの色管理
Sassでは色を変数として定義でき、また様々な関数でそれを操作することが可能になっている。そのため色を論理的に管理することが可能になっているが、これといった手法が確立されているわけではない。このウェブサイトでは少しややこしい形で管理するようにしている。どういう目的でこういう複雑な構造になっているのかを簡単に書いておきたい。 基本色の定義 基本色、つまりテーマカラーであったり、本文の背景色や文字色といった見た目のイメージを決定する色は、色コードを直接指定して定義する必要がある。これはほぼ間違いなくみんな同じように書いているだろう。 $color-dark: rgb(60, 51, 48); $color-light: rgb(252, 249, 240); $color-accent: rgb(17, 136, 187); これらは背景色であったり文字色、そしてリンクの文字色として使っている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
