1文字だけの改行の拒否
日本語の文章では任意の位置で改行できるため、レスポンシブ・ウェブ・デザインでは多くの場合、望まない位置での改行が起きる。例えば最後の1文字だけ次の行になってしまうと、読みやすさや理解度に致命的な影響を与える。例えば「？」だけ次の行に送られた場合、あるとないのでは大きく印象が変わるだろう。Twitterで@Takazudoと@oosugi20の会話を見て、やはりみな似たようなことは考えるものだと感じ、このあたりのことについて書いてみたくなった。 僕はjQueryで最後の五文字では改行が起きないようにいじったりしていた(うろ覚えで書いたもので、実際にはもっと複雑にやっていたと思う)。見出しがテキストのみの場合、最後の数文字の間に非改行ゼロ幅スペース(U+FEFF)を仕込むことで、その間で改行が起こらなくなるという仕組みだ。ここでは比較のためにクラスで判定するように書いてあるが、実際にはh1から
node-inlining
HTMLからlink要素で参照しているCSSの内容をstyle属性に全部展開するNode.jsパッケージ、node-inliningを書いていた。HTMLとCSSを別々に普通に書き、このパッケージに含まれるCLIプログラムでコンパイルすると、HTMLメールとしてうまく機能するHTMLができあがるということになる。GitHubで推奨されている外部リソースに依存しない静的なエラー・ページを作成するためにも使えるかもしれない。 CLIプログラムはごく簡単に使うことができる。 $ npm install -g inlining $ inlining input.html >output.html これでoutput.htmlにインライン化されたHTMLファイルが吐かれる。処理例はREADMEの簡単な例やtestディレクトリーを見てくれればわかるはずだ。 Node.jsパッケージとしての利用は少しや
プレースホルダーのスタイルにおけるノーマリゼーション
テキスト入力コントロールに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
よろしくESLint
重い腰を上げてESLintを使い始めた。そろそろv1.0.0になるらしい。これは良いなと思ったところを簡単にまとめておく。ついでに引っかかって対処にちょっと悩んだところも。既にすごく好感触なので、このまま素直に乗り換えられると良いな。 package.jsonに設定が書ける 外部設定ファイルとしては.eslinrcの他にもpackage.jsonに混ぜ込むこともできる。フィールド名はeslintConfigで、それ以下は同じ。 { "eslintConfig": { "env": { "node": true } } } 通常のnpmパッケージでは別にした方が良さそうだが、依存解決にnpmを使うだけとかコマンド作るためだけのようなプライベートなケースでは特に気にせず混ぜてしまって良さそう。 no-multi-spaces 複数の連続した空白が検出できる。 var a = 1; これで警告出
CSSできれいな斜め線
CSSで斜めに線を引くようなことをするには多少なりとも工夫が必要だった。つまりCSSで作る吹き出し(もう5年前の記事だ)のようにborderプロパティーを使って頑張るしかなかったわけだ。今はlinear-gradient()があるので直観的に作ることができるようになった。しかしきれいに引くとなるとまだ工夫が必要そうだ。 Demo: CSS Diagonal Line borderプロパティーを使ったもの、linear-gradient()を背景で使ったもの、Data URI化したSVGを背景に使ったもの、以上の計3つのデモを作った。 .lg { background-image: linear-gradient( to right bottom, transparent 50%, #f0f 50% ); background-repeat: no-repeat; background-si
OOCSSの欠点とEvery Declaration Just Onceのもたらすもの
昨日も少し書いたEvery Declaration Just Onceアプローチ(以下EDJOと略す)について、皆が目を瞑っているOOCSSの欠点、CSSが持つ特徴、HTMLとの兼ね合いという点からもう少し書いてみたい。これについては未だ誰ともちゃんと議論していない。機会があったらこの記事をベースにでも誰かと話してみたい。 上記Googleの文書は、主にパフォーマンスの観点で書かれている。どうしても長くなりがちな定義を分散して書くよりも、能動的に短くすることができるセレクターを分散して書いた方が、プロダクションにおいてリリースされるCSSファイルのサイズを小さくすることが可能だろうというものだ。同時にこの文書の筆者は自身のブログで、より自然にCSSを書くための手法(原文: 「The Natural Way of Writing CSS」)としてこのEDJOという手法について述べている。 僕
ウェブ・フォントの読み込み - Weblog - Hail2u.net
ウェブ・フォントも完全に行き渡り、今はどう効率的に配信するかについて多くの時間を割くようになった。Google Fontsの低め安定路線を見限り、TypeKitやFonts.comへ鞍替えする人々も増えた。それと同時に自前でホスティングする人々も徐々にその数を増やしており、どれが最適解なのか一応の結論が出るにはもう少しかかるだろう。まず、ウェブ・フォントの読み込みにおいてどのようなアプローチがあり、どのようなメリット、そしてデメリットがあるのだろうか。 TypeKit等に頼るにしろ、自前でホスティングするにしろ、もちろん最終的にはウェブ・フォントをブラウザーに送りつける必要がある。読み込みとはまさにその部分の話だ。話がややこしくなるので、多様な実装を意識した安全な書き方などについては触れない。 普通に@font-face定義を利用 @font-face定義をただ普通に書く場合のメリットは、
“マークアップ”するということ ～ HTML5勧告に寄せて ～
HTMLを適切な要素を使って書いていくことは実はそれほど難しくはない。しかし過剰に要素を使わずに、かつスタイリングすることも意識して、と適切に“マークアップ”するのはなかなかの修練を必要とする。いったい“マークアップ”するということはどういうことなのだろうか、そしてどのような思考の元に行えば良いのだろうか。 HTML5での変化 著作権表示のマークアップ small要素 footer要素とsmall要素 p要素とdiv要素 footer要素とp要素 スタイリングとの兼ね合い マークアップするということ HTML5での変化 コンテンツに則した素直な形でマークアップできること。 HTML5で変わることや変わったことは多くあるが、それらをおおまかに俯瞰するとこのような言葉に集約できる。そのために様々な要素や属性が追加され、既存の実装をなるべく壊さない形で要素の意味に変更が加えられた。これらの変化は
スクロールバーの幅
スクロールバーの幅を知りたいことはままある。CSSで拾えれば最高なのだけど……というところで、calc(100vw - 100%)で拾えることがわかった。ただこれで拾えるかどうかはその要素の親に依存するので、いつでもどこでも使えるわけではない。せめてJavaScriptでは扱えるようにしてみたい。 Demo: Get Scrollbar Width with JavaScript ボタンをクリックするとスクロールバーの幅がダイアログで表示される。オーバーレイのスクロールバーの場合は0pxになり、そうでない場合はスクロールバーの幅が返る。body要素の幅が100%であることが条件になるが、まず大丈夫だろう。 仕組みは単純なものでwidthプロパティーをcalc(100vw - 100%)にした要素をbody要素の子に突っ込んで、計算済みスタイルを拾うというだけだ。overflowプロパティー
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
違和感
違和感は明確に自分が意識していない感覚に物事が触れた時に感じられるものだ。ただし自分が違和感を感じたことを大々的に「変だ！ 気持ち悪い！」などと感情的に表現してしまうとおかしな人になってしまう。そこで論理的に批判したくなるわけだが、大体において理論武装には穴や見落としがあるので、これまたおかしな人になってしまう。かといって違和感を感じたという事実を封印してしまうと、ストレスでおかしな人になってしまう。 違和感を感じるための感覚は自分の今までの経験に基づいて構成されたものなので、その否定は自分の存在意義を一部崩してしまう。しかし、そういった自分の存在意義を維持するため、延いては自身を守るために理論武装すると、説得したい相手を押さえつけるだけの結果に終わってしまう。 違和感を感じたことを大切にしつつ、かといってそれに自分だけが納得のいくような理由付けを行わないようにすると良さそうだ。つまり違和
透過PNGをSVGを利用して軽くするテクニック
透過PNGは現状では唯一に近いフルカラーの透過画像を作成する手段だが、ファイル・サイズが大きくなりがちだ。対してJPGはファイル・サイズという点で大きく優るが、透過することは出来ない。このあちらを立てればこちらが立たずの問題をSVGのマスク機能を使って透過だけを受け持つPNGとJPGを組み合わせることで両立させるテクニックを知った。 透過させた画像をまず普通に作る。それから透過してないJPG画像と、透過を反転させてマスクに使うPNG画像を生成する。それらをHTMLでSVGのmask要素をインラインに書くことで組み合わせる。ベースとなるJPG画像が一般的にファイル・サイズに優れ、マスクに使うPNGは空白が多いこと、SVGの記述はごく短いもの、というわけで最終的に低ファイル・サイズが実現できる。 SVGのセキュリティ上の制限により、HTMLにインラインで記述するケースでしか使えないのでCSSの
1/5くらい欠けた円を回す
新しいApple Storeアプリで使われてるローディング・アイコンをCSSで模したもの。たまにこういうものを作ると、自分が新たなCSSテクニックを学ぶことに貪欲でないことを再認識させられる。 Demo: Apple Store App Loading Icon .loading { border: 1px solid #797673; border-radius: 51%; position: relative; width: 2rem; height: 2rem; background-color: #fff; animation-duration: 1s linear infinite spin; } .loading::before { display: block; position: absolute; width: 50%; height: 50%; content: "";
コンソールに内側の余白を
clibというプロジェクトがあって、それ自体にはほとんど興味が無いんだけど、そこに載っているコンソール画面のスクリーンショットがきれいだった。白い画面というのが珍しいこともあるけど、左に余白をもたせてあるのがすごく良さそうに見えた。真似して内側に1文字分くらい余白をもたせてみたけど、かなり快適。 だいたいのターミナル・エミュレーターには内側に余白をもたせる設定がある気がする。僕は残念なことにConEmuに落ち着いてしまったので、Settings→Main→Size & Pos→AlignmentでPad sizeを設定して余白をもたせた。上下と左右を別々に設定したいところだけどそれは無理だったので、1文字分で妥協した。Ckw-modなんかでもinternalBorderで内側の枠線を設定することで余白をもたせられる。
CSSグラデーションによるリンクの下線
CSSグラデーションを使った太くならないリンクの下線は、Mediumの詳細な記事やterkel.jpのその解説とも言える記事を見てそのうちやってみようと思っていた。フォントサイズが大きい時に下線が2pxや場合によっては4pxくらいで引かれるようになるのは見た目に結構な負荷を与えるので、常に1pxで引きたいといった希望を持ってる人は多いはずだ。 このウェブサイトでは以下の要件を満たすような感じで実装した。 常に1pxで下線を引く 文字サイズに依存しない なるべくシンプルな実装 a { background-image: linear-gradient( transparent 0, transparent 50%, rgb(91, 172, 208) 50% ); background-position: 0 1.1em; background-repeat: repeat-x; backg
コンテンツとUIパーツの比率
コンテンツとUIパーツ(chrome)の比率についての記事を読んだ。単純にコンテンツを最大限確保するのではなく、画面サイズに応じて適切な大きさでUIパーツを提供することによって、コンテンツとUIパーツの比率への影響を最小限に抑えるべきだという風に読んだ。U-Siteでの日本語訳に期待したい。 Chrome (ブラウザーの方)やFirefoxのハンバーガー・ボタンやWindows 8のチャーム(廃止されるらしい)のような極小化したUIパーツは、発見性や再現性、そしてインタラクション・コストが高いということのようだ。ハンバーガー・ボタンの文脈でよく語られるあの三本線が何を意味しているかユーザーがわかるのかどうかという話のもっと前の段階で問題があるということだろう。 主にデスクトップ・アプリケーションでの話だけれども、逆にモバイル・アプリケーションでUIパーツを大きくしすぎないことにももちろん繋
ターミナル画面のマークアップ
Markdown (やその派生)のpre要素になる記法では、問答無用にその中はcode要素でマークアップされる。多くの場合はコードの断片なのでそれでいいんだけど、そうじゃないことももちろんある。例えばCLIプログラムでの操作手順を記載する時のターミナルの画面のコピー。 プログラムによる出力はsamp要素で、キーボードによる入力はkbd要素になるので、以下のようにマークアップするのがベストに近い。 <pre><samp>$ <kbd>node --help</kbd> Usage: node [options] [ -e script | script.js ] [arguments] node debug script.js [arguments] Options: ... NODE_DISABLE_COLORS Set to 1 to disable colors in the REPL
Sassでの色管理
Sassでは色を変数として定義でき、また様々な関数でそれを操作することが可能になっている。そのため色を論理的に管理することが可能になっているが、これといった手法が確立されているわけではない。このウェブサイトでは少しややこしい形で管理するようにしている。どういう目的でこういう複雑な構造になっているのかを簡単に書いておきたい。 基本色の定義 基本色、つまりテーマカラーであったり、本文の背景色や文字色といった見た目のイメージを決定する色は、色コードを直接指定して定義する必要がある。これはほぼ間違いなくみんな同じように書いているだろう。 $color-dark: rgb(60, 51, 48); $color-light: rgb(252, 249, 240); $color-accent: rgb(17, 136, 187); これらは背景色であったり文字色、そしてリンクの文字色として使っている
アクティブなナビゲーション項目とmark要素
アクティブなナビゲーション項目、つまり現在のページへのナビゲーション項目はclass属性を使ってactiveなどと付けられることが多い。特に間違ってはいないんだけど、いまいちピンとこない。というかしっくりこない。大体は流されてそうしているけど、このウェブサイトではmark要素を使ってる。 HTML5仕様ではmark要素は以下のようになってる。 The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context. mark要素が含まれる要素のコンテキストとは別のコンテキストでの関係性をハイライト等で表したい時に使うと解釈してる(同じコンテキストならemやstrong、そしてb
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
