CSSとJavaScriptのインライン化
CSSやJavaScriptをインライン化してみている。速い。ラスター画像もBase64で埋め込めみたくなる。しかしインライン化はやはり気持ちが悪く、落ち着かない。この気持ち悪さはウェブサイトと言う単位に意味が薄くなってしまうことにあるのではないか。 ウェブサイトは全体で一冊の本になっているようなイメージが漠然とある。フレーム全盛期を体験していることが大きい。このイメージではそれぞれのウェブページはその本のページにあたり、それぞれから参照されるCSSやJavaScriptファイルはそのページ群を留める接着剤やひもにあたる。それらをインライン化してしまうと、本のページそれぞれを切り離し、ペラペラな紙にしてしまっているような印象を持ってしまう。 実際にはそれぞれのウェブページは半ば独立したもので、ユーザーからも様々なウェブサービスからもそう扱われるようになって久しい。直帰率が限りなく100%に
“マークアップ”するということ ～ HTML5勧告に寄せて ～
HTMLを適切な要素を使って書いていくことは実はそれほど難しくはない。しかし過剰に要素を使わずに、かつスタイリングすることも意識して、と適切に“マークアップ”するのはなかなかの修練を必要とする。いったい“マークアップ”するということはどういうことなのだろうか、そしてどのような思考の元に行えば良いのだろうか。 HTML5での変化 著作権表示のマークアップ small要素 footer要素とsmall要素 p要素とdiv要素 footer要素とp要素 スタイリングとの兼ね合い マークアップするということ HTML5での変化 コンテンツに則した素直な形でマークアップできること。 HTML5で変わることや変わったことは多くあるが、それらをおおまかに俯瞰するとこのような言葉に集約できる。そのために様々な要素や属性が追加され、既存の実装をなるべく壊さない形で要素の意味に変更が加えられた。これらの変化は
:target擬似クラスとHistory API
:target擬似クラスではフラグメント識別子と一致する要素に対してスタイルを当てることができる。これを利用するとCSSだけでインタラクティブにデザインを変更することが可能になる。一方History APIではページの遷移なくフラグメント識別子を含め、アクセス中のURLを書き換えることができる。では:target擬似クラスで有効になっているスタイルは、History APIでフラグメント識別子を変更した場合に動的に切り替わってくれるだろうか。 Demo: :target and history.replaceState() デモ・ページではEnable #test:targetをクリックするとURLに#testというフラグメント識別子が追加される。#test:targetセレクターを通して、文字色を緑にするようにしてあるので、クリック後文章が緑になることだろう。Disable #test:
ゆるやかな出会い
内容に曖昧なところの少ない公式文書や仕様書、あるいはWikipediaの項目などのみをリンクで参照する形でウェブログの記事が書かれることが多くなった。孫引きや孫々引きのような記事は減り、全体的な記事の質は比べ物にならないくらい上がった。その一方でゆるやかな繋がりは死に、それに伴うゆるやかな出会いは消滅した。 このあたりのことはもう取り返しがつかないであろうし、今こそTrackBackのような何かが……などといっても混乱させるだけだろう。そういう世界になったというだけの話だ。 今の世界では記事は記事で独立した存在であり、その前後の記事はおろか書いた人のことにまで思い及ぶことはほぼない。あったとしてもそれは否定的な動機によるものだろう。そういった独立した記事達はもはやウェブログのような形態には収まることは無意味で、効率良く横断的に情報のみを得られるようなStack OverflowやQiita
クラス名の命名規定
pixivのCSSで使われるクラス名ルールという命名規則の記事を読んでいた。初見では大規模だとBEMの衝突が絶対に起きない書き方の方が優れているように思えた。しかし衝突するであろうことに警報を出すという形にゆるくすることで、開発者たちに自由を与えるというような目的でこうなっているようだ。ちょっと興味深い。 規模が大きくなると制約を厳しくして安定性を重視する一辺倒だったが、こういう自由さをうまく提供しようという考え方をすることはあまりなかった。具体的にも、変更されることがあまりない、またはわかっている人だけが行うひとまとまりのルートにのみ特殊な命名(_で始める)というのはバランスが良さそうに思える。 コードだけを見てみるとうまくいっているというのは少し驚く。_で始まるところはあまり触らない人と_で始まるところを触る人、と人的リソースが能力や職掌に応じてうまく振り分けられているのかなと想像して
余白を割合で分割
余白を特定の比率で分割したいなとちょっと考えていた。つまりmargin-leftとmargin-rightプロパティーの計算済みの値が3:2とかの比率で自動調節されるように、ということ。そのようなことをTwitterでちょっと書いたら、@o_tiがcalc()を使う方法を考えてくれた。 Demo: Split margins 1 to 3 最初のデモの幅は320px、二つ目のデモの幅は480pxになっている。margin-leftプロパティーでcalc()を使い、100%から要素の幅を引いた残りを4で割っている。margin-rightプロパティーはautoで自動調節すれば良い。 .test { margin-right: auto; margin-left: calc((100% -320px) / 4); width: 320px; } Inspect margin-left: cal
git cleanを使ったGitHub Pagesの管理フロー
submodule (やsubtree)を使ったGitHub Pagesの管理フローは良いのだけど、もっと適当な感じでやりたいなと色々試している。要件としては生成に使ってる仕組みやログは非公開にしたいので、rebaseからpush -fのような変更を取り込んで更新する仕組みは使えない、というくらい。最新の実験ではclean -fでステージされてないファイルを削除できることを利用してやってみている。 まずはビルド。masterブランチでビルドしてindex.htmlなどをバンバンそこに吐いていくような雑なケース。 $ npm run build $ git add --all $ git commit --all --message="Rebuild" これでGitHub Pagesに必要なファイルが生成され、masterブランチにコミットされた状態になった。 $ git checkout
git subtreeの練習
Gitのサブモジュールでは面倒そうな、頻繁に更新される別のリポジトリを取り込む方法としてサブツリーマージを行うラッパーであるgit subtreeコマンドを使う練習を始めた。どちらかというと「参照する」要素の強いサブモジュールに対して、サブツリーは「切り分ける」や「取り込む」という感じなんじゃないかと理解している。全般的に間違ってそうで怖い。 「切り分ける」、つまりリポジトリのサブディレクトリを別のリポジトリにしたい場合は、単純なケースだと親にあたる方で.gitignoreや.git/info/excludeを使ってサブディレクトリを除外してやれば良い。でもこの場合、両方のリポジトリで関連した変更がある時にそれぞれのリポジトリでコミットしてやらないとならないので面倒くさい。 「取り込む」場合はサブモジュールが基本なわけだけど、他で作業して戻ってきてたりする必要があるし、サブモジュールの更新
入力フォームのラベルをフワッと浮かせるパターンの別解
Float Label Patternはかっこよくて、単にラベルをプレースホルダーにするよりはマシなので使いたくなる。しかしラベルとプレースホルダーは別に提供してやりたい。機能も違うものなので、その方がきっと良いはずだ。そこで別解として、ラベルが斜めに動くものを考えた。もちろんCSSのみで実装している。 Demo: Alternative Float Label Pattern 入力フォームにフォーカスすると、左にあるラベルが斜め右上に少し移動すると同時に入力フォームが左へ拡大する。これによりFloat Label Patternと同じような結果になるが、デフォルトの状態ではラベルとプレースホルダーを両立させることができる。 ラベルを入力フォームのフォーカスと連携させるには、隣接兄弟セレクターを使うくらいしか方法はなさそうなので、マークアップは入力フォーム→ラベルの順にする必要がある。また
書く時
ウェブログが再評価されていることの表れか、書くことについて書かれた記事を読む機会が増えた。そのひとつの「ブログの記事書くときに気をつけていること」を読んで、僕もいくつかあるなーとか考えていた。「消さない」以外だと大きいところで3つのルールがある。 タイトルで内容を推測させない 一番気をつけているのはタイトルだ。内容がパッと見でわかるキャッチーなタイトルにしたい気もするのだけど、そうするとどうしても先入観を与えるのでミスリードを誘発する。近年はどうしてもソーシャルブックマークやニュースアプリ経由での流入が中心となるので、先入観を与えてしまうとがっかり感で終わるユーザーも多くなる。この記事も「ブログ記事に不要な3つの“ない”」といったタイトルに出来そうだけど、しない。 ただどのようなことについて書いてあるのはそれなりにわかりやすい必要があるので、それだけは最初の段落を併用して書く。最初の段落は
書いてるよ
毎日ガシガシ文章を書いている。大抵はエディタに向かって書いてるわけだけど、たまに思い出したように余ってるルーズリーフの紙に書いてみたりもしてる。技術寄りの文章を紙に手書きで書くと、なんかすごく恥ずかしい感じで後頭部がカーッと熱くなってくる。逆にエディタで日常の感想的なことを書いてると、指がブルブル震えてくる。 紙に書かれた技術的な話題とかあまり役に立たないのになんで書いてるんだろう、というようなことなのかなと思っていたんだけど、どうも違うみたいだ。パソコンで技術的な話を書く時は、並行してブラウザーで関連する話題を検索したり、リンクとして参照するページを開いたり、様々な形でその話について調べながら書く(書いてしまう)。パソコンを閉じて紙に向かって書いてると、自分の記憶のみを頼りに書く必要があるので、その技術的な話のちゃんと理解していない部分がどんどん浮き彫りになってくる。ので恥ずかしくなって
autocomplete=offと人の主体性
少し前に「autocomplete=offするのやめて、ブラウザーのパスワード管理を使わせて欲しい」という記事を読んだ。autocomplete=offはブラウザー内蔵のパスワード管理機能を壊すことが多いので、結果として覚えやすいとか使い回しのパスワードにしたくなってしまうみたいな悪循環を引き起こすんじゃないかなどという様に読めた。僕はもう長いことブラウザーの管理機能使ってないので、autocomplete=offそのものについてはどっちでも良いやという感じではあるけど、それでもちょっと考えるところはある。 この問題はtarget=_blankやuserscalable=noする問題とかと同じで、ブラウザーが内蔵している機能を破壊して良いのかということになる。ユーザーに選択肢を与えるべきだという観点では、もちろん破壊してはならない。戻す方法がないので、ユーザーの行動を開発者の都合によって制
minimist - Weblog - Hail2u.net
Node.jsでCLIツールを作る時に使えるコマンドライン・オプションのパーサーとしてminimistをよく使うようになった。なかなかの好感触。同様のものとしてoptimistやその後継のyargsが有名で、しっかりと作るならそっちの方がよく出来ているけど、数個のオプションの切り替えと余りの抽出くらいならminimistの方が楽。 インストールしたら以下のようにパースしたいコマンドライン・オプションの配列を渡すと、良きに計らってくれたオブジェクトが返ってくるので、それを使うことになる。 #!/usr/bin/env node 'use strict'; var minimist = require('minimist'); var argv = minimist(process.argv.alice(2), { string: ['output'], boolean: [ 'sourcem
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
ベンダー拡張プリフィックスはウェブ制作者たちのためにある
ブラウザー開発者はベンダー拡張プリフィックスをなくす方向に動いているような気がする。短いリリース・サイクルの中で、仕様の要件を満たしているのなら外すといった地味な確認作業から開放されたいのかもしれない。そういう理由はわからなくもないが、ウェブ制作者も面倒くさくなくなるのでそれで良い、と考えていそうなことにはまったく賛成出来ない。 CSSグラデーションの実装と仕様の紆余曲折は、ウェブ制作者にベンダー拡張プリフィックスに対する不信感を植え付け、いい加減に付加する口実を与えてしまった。独自に実装、仕様が追随、対立、仕様の変化、対応、どの段階においてもベンダー拡張プリフィックスはさほど効果は上げなかった。結果、書くのがただただ面倒なだけということに。 変化についていくことを諦めたウェブ制作者たちは単純なコピペかそれを機械的に行うツールに頼ることになり、それが常態化した。今はここ。そんなに頭や気を使
プル・クオート
英語で書くとPull Quote、Calloutなどとも呼ばれる抜粋見出しのこと。雑誌のインタビュー記事などでよく見る、インタビュー内容の一部が抜き出されて見出しのように配置されているやつ。blockquote要素でマークアップするのかと思ってたら、aside要素の方が適切らしい。引用ではなく抜粋で、かつコンテンツに同じ内容が既にあるので、なくなっても特に問題がないからか。 この記事はクリエイティブ・コモンズ 表示-継承 3.0 非移植で提供される。 aside要素で括るだけで、あとはp要素のみで良いようだ。figureやblockquote、q要素を更に利用してもよいように思えるけど、冗長すぎるか。出典的なものはfooter要素を使えば良さそうだけど、大抵の場合は明確なので必要なさそう。多人数相手のインタビューみたいなので、誰の発言なのかを示したい時などには使うと良いのかも。以下のマーク
Chrome 31での@font-face定義
Chrome 31で@font-face定義でunicode-rangeプロパティーを使った時の挙動が変わった。今までは@font-face定義を使ってローカルにあるフォントの一部をunicode-rangeプロパティーで差し替える場合、差し替えるグリフ以外はローカルのフォントが維持されていたんだけど、一部差し替えるだけだと他のグリフが全部失われるようになった。この挙動はInternet Explorer 11と同じで、仕様通りになった。 指定したフォント・ファミリーの名前と同じ名前のフォント・ファミリーがユーザーの環境に存在している場合、そのスタイルシートが使われている文書では(ユーザーの環境に存在している)フォントは事実上使われないことになります。これによりウェブ制作者は、ユーザーの環境にあるフォント・ファミリーの名前との衝突を気にすることなく、自由にフォント・ファミリー名を選択するこ
シンプルで簡単なだけでは十分ではない
ある機能を追加しようとした時、いくつかある手法から選択する条件として、シンプルであることや簡単であることをが重要視されることは多い。けど、それと同じくらい今だけでなくこれからの機能との兼ね合いも考慮するべきで、シンプルで簡単という作業上のメリットのみで選択してしまうのは良くない。フロントエンドの人なのでclearfixを例にして書く。 マークアップの追加によるものを論外とすると、clearfixの実装としては主に以下の4つが挙げられると思う。 オリジナルのcontent: "."を使ったもの マージンの相殺を考慮したもの Micro clearfix overflow: hiddenを指定するだけのもの シンプルであることや簡単であることのみを考えるのなら、間違いなくoverflow: hiddenを指定するだけのものを選択することになると思う。 なんといっても1行で済むことと、擬似要素が
JekyllみたいなのとWordPressみたいなのの組み合わせ
静的ウェブサイト生成ツール(面倒なので以下Jekyllみたいなの)と動的ウェブログ・システム(同じくWordPressみたいなの)のそれぞれの長所や短所はみなよく知っているようで、よりその人の状況にあったどちらかを選んだみたいな記事をよく見る。そういうの見る度にどうして両方使わないんだろうと思う。 静的なHTMLでのウェブサイトの運営は簡単で楽だしコストも掛からず、環境もあまり選ばない。けどMovable Typeでの破綻を引き合いに出すまでもなく、1000やそれ以上のHTMLを生成できる無理のないシステムはあるのかというと微妙な感じがする。で、規模に応じて動的なCMSと使い分ければ……となることが多いわけだけど、使い分けるのではなくJekyllみたいなのとWordPressみたいなのを組み合わせるのが良いのではないか。 テンプレート 分けちゃうとテンプレートの管理も分かれて面倒くさいとか
Webフォントのホスティング
Webフォントのホスティングのみを提供するようなサービス、つまりWebフォント専用のカスタムCDNを探していた。しかし、Webフォントがメジャーになったとはいえ、そこまでニッチなサービスはあんまりないようだ。代表的なものだとTypeFront。が、かなり制限厳しい。試してすらいないけど、$15/月は払わないとまともに機能しそうもないような仕様だった。 Webフォント専用にこだわらずに、GitHub PagesやDropboxを利用するという手もありそうだけど、Internet Explorer 9以降やFirefox 3.5以降におけるCORSによる制限に対応できない。また、パフォーマンスに難点があったり、Content-Typeでトラブりそうとかも。 Google Drive Google Driveだとどうかなーとテストしてみたら、Access-Control-Origin: *となっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
