HTMLは開発者たちのために
昔からよく「HTMLの正しさ」というような表現を見る。少し前はHTMLの構造的な完全さや文法的な正確さなどにウェブページの表示やCSS、そしてJavaScriptが依存していたので、そういった点を強く意識する必要があった。Firefoxが親切に教えてくださっていたXMLパースエラーのことを思い出すとわかりやすい。僕も良くそれに類する表現を使っていた。 今はブラウザーとウェブ標準技術が共に進化したので、そういった形式的な正しさはさほど重要ではない。かろうじてハイパーリンクだけがまともな壊れたHTMLでもなんとか修復して解釈してくれる。命名規則ベースのCSSならばHTMLがどうあれうまくスタイルが当たってくれるだろう。足りない機能はDOMツリーの状況をほとんど無視できるShadow DOMでどうにでもできるというわけだ。 HTMLにCSSとJavaScriptを生やしてウェブページが出来ていた
ブックマークのおっかけ
ソーシャル・ブックマークはまだそれなりに機能するが、いまだに追いかけるのが難しい。その中ではてなブックマークのお気に入り機能は出色の出来栄えと言えそうだが、やはりブラウザーであのページを見るのは辛い。かといってRSSリーダーで読むのもなかなか難しいと感じる。HBFavは良いものだが、やはりデスクトップでどうにかしたい。 ストック型では色々試した末にはてなブックマークのお気に入りRSSからIFTTTのEmail Digestに貯めて毎日深夜に送っておくという形でしばらく落ち着いた。RSSリーダーでお気に入りフィード読むのは本当に苦行だったが、相当マシな気もする。特に気が向かなかったら読まずにとっておくこと(未読でプレッシャーかかったりしない)も、捨てることもできる。僕は送る時間を夜中の3時にして余裕のある朝にチェックできるようにしているが、みながウェブページを見てブックマークし終わる午後3時
我慢の期間
MovableTypeとWordPressとJekyllとHugoや、Gruntとgulp、SassとLESSとStylus、果てはjQueryなどの話はスケールやパターンを変えて繰り返される。その話はあたかも特定の何かに依存することが良くないとか新しいこっちのがすごいぞというように結論づけられることが多くて、僕にはちょっと頷けないこともあったりする。大切なのは何を解決しようとしていたかを忘れないことだと思う。複雑化しそうな場合にそこから先へ踏み込まずに我慢する期間がいるとかかも。 GNU makeでいいじゃん的な結論はそれは確かにビルドという点ではそうなんだけど、Gruntが解決しようとしていたのはそこじゃない。npmという生態系の中で完結させやすいタスク実行環境を手軽に用意することができることで、それ以上でもそれ以下でもない。実行速度以外にも腐臭を放つAPIやプラグイン間で一貫性のない
rel=subresourceを併用したCSSの遅延読み込み
クリティカルなんとかの関係やウェブ・フォントにおいて、CSSの遅延読み込みを行う気運は高まっている。様々なアイディアがあって、普通にCSSの内容を読み込んでhead要素に追加するものや、link要素を動的に追加するもの、予めlink要素をrel=stylesheetなしで書いておいて後で追加するものなどがその主なものだ。最後の手法ではrel=subresourceを追加して書いておくと、一部ブラウザーでダウンロードが速く始まるんじゃないかというアイディアを持った。 サポートが広いのでprefetchかなと思ったけど、書いたそのページ内で使うリソースの先読みに使うものではないような印象で、すぐさま使う場合はsubresourceの方が適切なようだ。Chromeがそういうイメージで実装してるという話で、ウェブ標準では特に細かく規定はないようではある。 <html> <head> <style>
スクロールバーの幅
スクロールバーの幅を知りたいことはままある。CSSで拾えれば最高なのだけど……というところで、calc(100vw - 100%)で拾えることがわかった。ただこれで拾えるかどうかはその要素の親に依存するので、いつでもどこでも使えるわけではない。せめてJavaScriptでは扱えるようにしてみたい。 Demo: Get Scrollbar Width with JavaScript ボタンをクリックするとスクロールバーの幅がダイアログで表示される。オーバーレイのスクロールバーの場合は0pxになり、そうでない場合はスクロールバーの幅が返る。body要素の幅が100%であることが条件になるが、まず大丈夫だろう。 仕組みは単純なものでwidthプロパティーをcalc(100vw - 100%)にした要素をbody要素の子に突っ込んで、計算済みスタイルを拾うというだけだ。overflowプロパティー
横にはみ出すナビゲーション
今回(2014年9月)のAppleのウェブサイトのリニューアルにはいくつもの興味深い点がある。ナビゲーションの二本線とバツ印が共にインラインのSVGなことなどもそうだし、多くのポーションがモダナイズされたにも関わらずPrototype.jsを継続利用したこともすごく気になる。その中でも一番気になったのは狭い画面向けの横にはみ出すナビゲーションだ。 これまでの通常は隠されている狭い画面向けのナビゲーションの多くは、次の3つに大別されていた。 ドロップダウン オーバーレイ ドロワー 極稀にアイコンのみのコンパクトに横へ並べたものもあったが、いずれの場合もナビゲーションの項目は縦に並んでいることがほとんどだ。一覧性に富み、アクセス性が高く、ユーザーの学習コストも低い。 これに対して横にはみ出すナビゲーションは、項目を画面外にはみ出すように横に並べ、スワイプでスクロールして探させるという形のものだ
スクロールバー
昔はOSネイティブを尊重したスクロールバーにしろ派だった。今は描画領域がらみで色々考えたくないので、オーバーレイで独自描画されちゃえばいいのに派になってる。WindowsだとInternet Explorer 11以降(10以降かも)の自動非表示スクロールバー的なのが妥当な落とし所なのかな。かっこいいと思ってはいないんだけど。 ウェブ制作者としては、もちろんこの辺りの扱いが仕様通りに実装されてればどっちでも良いわけだけど、ちゃんとされそうな気配がまるでない。また仕様自体でもMedia Queriesのwidthやheightではスクロールバーを含むで、CSS Values and Units Module Level 3のvw系では含まない(スクロールバーの有無に影響を受ける)だったりして、大変覚えづらい。 それぞれがそうなっている理由や実装がマチマチな理由もなんとなく推測できる。でも、こ
Chrome 35でオンマウス時に画像がずれる
久々にソーシャル・ネットワークのアイコン的なものを作ろうとしていた所、オンマウスで画像のコンテナのサイズが微妙に変わり、画像の位置が微妙にずれるという現象に遭遇した。どうやら%単位でpaddingプロパティーを指定すると起こるようだ。Chrome 35のバグっぽい。 Demo: Image Displacement on Hover 親がfloatプロパティーを使っていたり、display: inline-bockだったりして、子の画像の大きさによりサイズが変化する場合にのみこのバグは再現できる。ずれの量はタイミングと画像のサイズによって変化する。 何がずれているのかを明らかにするためにoutlineプロパティーを指定してみたところ、親の幅がおかしなことになっているようだ。親の幅と画像の幅が相互に関係し合うような形になっているため、%単位でpaddingプロパティーを指定するとサイズが決ま
SVGのリサイズにおける端
SVGはフレキシブルにリサイズされるけど、実装依存なので細かい部分では想定通りいかないことがある。例えばそのエッジ。キャンバスとちょうど同じ大きさのrect要素をリサイズすると、実装とサイズによっては端がぼやける。SVG側でどうにかできるので、なんとかしてやると良い。 端のぼやけはChrome 34で起こりやすく、Firefox 29ではあまり起こらない。Internet Explorer 11ではpx単位でのリサイズなら起こらないかも。SVGのリサイズは実装側のパフォーマンス重視かアウトプット重視かで大きく変わってくるので、端のぼやけが起こらないようになることは期待できない。 <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns="http://www.w3.org/2000/svg" version="1.1
Chrome 33でユーザー・スタイルシートが削除 - Weblog - Hail2u.net
色々仕込んでたのが全部消えてびっくりしたけど、どうやらChrome 33からユーザー・スタイルシートの機能が削除され使えなくなったようだ。Stylish使うか、ユーザー・スクリプトで強引に仕込むしかない。フォントの書き換えなんかはユーザー・スタイルシートでやりたい……。 ユーザー・スタイルシートを必要とする人が少ないのはわかるんだけど、ドキュメントに直接ではない形でCSSを注入する仕組みはあった方が望ましい気がする。ユーザーによる変更が、ページ制作者に認識できる、しやすい(style要素を数えるだけ)、やろうと思えば削除できるというのはアレな感じする。 Firefoxに舞い戻りたくなるけど、アレなのでWindowsのSafariをもう一回出して欲しい。あ、Opera使えば良いのか。
つまらないGruntタスク
Gruntfile.jsをサッと開く手段としてeditという簡単なタスクを勢いで書いたんだけど、無意味でつまらないGruntタスクだった。Gruntには様々なタスクがあり、自分でもNode.jsを駆使して自由に書けるので、色々やりたくなる。けれどもグッとこらえて、ワークフローにおける定型作業の自動化に絞った方が、ワークフローと開発環境、そしてGruntfile.jsに優しい。 grunt-contrib-watchを使ったSassの自動コンパイルやLiveReloadのタスクは確かに便利なんだけど、開発から公開までのワークフローの段階として必須というわけじゃない。これらはタスクというよりも環境なので、別に自分好みの環境を作った方が集中できるし、好みでない環境を押し付けずに(そして押し付けられずに)済む。 また、Gruntでなんでもやることに慣れてしまうと、設定されてるしそれで良いかみたいな
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
CSSでフォント・ファミリーのショートカットを作る
最近のブラウザーではlocal()を使ってフォント・ファミリーのショートカット(的なもの)を作ることができる。CSS Fontsモジュール仕様のsrcプロパティーの項にも思いっきり書いてあるんだけど、今まではそんなに必要なかったのであまり使われていない。5ウェイト展開なヒラギノ角ゴのiOS 7へのバンドルと、3ウェイト展開の游ファミリのWindowsへのバンドルにより必要性が少し増えた気がする。 特に游(ゴシック|明朝)はWindows 8.1とOS X 10.9でファミリ名が違う上、少し古いFirefoxでのアレとか、OS Xには細字がないとかもあるので、色々考慮するとfont-familyプロパティーではややこしいフォント指定を行う必要が出てくる。そうやって出来た長いリストのfont-familyは読みづらく、デバッグのしづらさにつながる。local()を使ってフォント名を作り直してや
ベンダー拡張プリフィックスはウェブ制作者たちのためにある
ブラウザー開発者はベンダー拡張プリフィックスをなくす方向に動いているような気がする。短いリリース・サイクルの中で、仕様の要件を満たしているのなら外すといった地味な確認作業から開放されたいのかもしれない。そういう理由はわからなくもないが、ウェブ制作者も面倒くさくなくなるのでそれで良い、と考えていそうなことにはまったく賛成出来ない。 CSSグラデーションの実装と仕様の紆余曲折は、ウェブ制作者にベンダー拡張プリフィックスに対する不信感を植え付け、いい加減に付加する口実を与えてしまった。独自に実装、仕様が追随、対立、仕様の変化、対応、どの段階においてもベンダー拡張プリフィックスはさほど効果は上げなかった。結果、書くのがただただ面倒なだけということに。 変化についていくことを諦めたウェブ制作者たちは単純なコピペかそれを機械的に行うツールに頼ることになり、それが常態化した。今はここ。そんなに頭や気を使
プレースホルダーがラベルで、コントラストが低く、余白がない入力フォーム
プレースホルダーをラベルにしたフォームや、コントラストが低いフォーム、余白がなかったりするフォームはそれぞれよく見る。特にプレースホルダーをラベル代わりにするのは、すっきりするので多用されている印象。使いたい気持ちはわからなくもない。けどこの3つが組み合わされると、なかなかひどい感じになるという実例をGoogleで見てしまった。 Internet Explorer 10ではこのような感じになる。ページの読み込み直後にメールアドレスを入力するフォームにフォーカスが当たり、プレースホルダーの文字列がその時点で消える。この状態だと、すぐ下のパスワードというプレースホルダーが、あたかもその上の入力ボックスらしきものに対するラベルのように見えないだろうか？ 実際に「パスワードを入れたのにログイン出来ない！」などと言う人はいた。 ラベルのように見えてしまう大きな原因は、その低コントラストでフラットな入
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: *となっ
適切に改行を行う
ブラウザーはviewportによって折り返しを自動で行なってくれるわけだけど、場合によっては適切ではない位置で行われてしまうのをコントロールしたいという話。見出しをセンタリングしているようなケースで幅によっては一文字だけ次の行になってかっこ悪い！ みたいなのを解消したいということであったり、逆にびろ～んと間延びしないようによさそうな位置で改行を入れたいということであったり。一年くらい前にResponsive Line Breaksと呼ばれるようになった。 具体的なものはResponsive Line Breaksにあるデモやこのウェブログの日付表示の部分とかがそれ。ここではviewportの幅が広い時に良い位置で改行が入るようになっている。 article footer br { display: none; } @media (min-width: 60em) { article foo
Feedlyに引越してはいけない(今は)
Feedlyはなかなか素晴らしいフィード・リーダーだと思う。カード・レイアウトでざっと流し読みしつつ気になったのがスッと取り出せるまたはタブで開けるというスタイルは好き。最近はここが勝負とばかりにGoogle Reader互換APIを提供したり精力的で良い。それでも引っ越してはいけない。購読しているRSSのリストをOPMLでエクスポートできるようになるまでは。 OPMLでのエクスポートをサポートしないということは、二度とそこから引っ越せないということとほぼ同じ意味を持つ。人によっては購読数は50くらいかもしれないけど、それでもその50を別のフィード・リーダーに移すことを考えたらぞっとする。そのうち対応されるとは思うし、プライオリティーは高そうなのでそれまで待った方が良い。 それまでは……フィード・リーダーを読まない日々というのも良いのでは？ 追記 OPMLでのエクスポートがサポートされたの
HTMLにおけるimg要素のalt属性
HTML Standardの4.8.1.1 Requirements for providing text to act as an alternative for imagesをざっと把握できるように日本語で箇条書きにしただけのものです。最終的には原文をしっかりと読むべきでしょう。 基本 必ず定義されるべきである その値は空であってはならない その画像に代わりになる最適な文字列である ページ上の全ての画像をそのalt属性の値で置き換えてもページの意味合いが変わってはならない 画像のキャプションや題名、銘とみなされるような補助的な説明を意味するものであってはならない 前後で解説されている情報の繰り返しであってはならない 画像以外に何も含まれていないリンクやボタンで使われる場合 リンクやボタンの目的を明確に伝える文字列を指定する わかりやすく説明するために文章ではなく画像のチャートやグラフを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Image Displacement on Hover