普通のHTMLの書き方
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
スクロールバーの幅
スクロールバーの幅を知りたいことはままある。CSSで拾えれば最高なのだけど……というところで、calc(100vw - 100%)で拾えることがわかった。ただこれで拾えるかどうかはその要素の親に依存するので、いつでもどこでも使えるわけではない。せめてJavaScriptでは扱えるようにしてみたい。 Demo: Get Scrollbar Width with JavaScript ボタンをクリックするとスクロールバーの幅がダイアログで表示される。オーバーレイのスクロールバーの場合は0pxになり、そうでない場合はスクロールバーの幅が返る。body要素の幅が100%であることが条件になるが、まず大丈夫だろう。 仕組みは単純なものでwidthプロパティーをcalc(100vw - 100%)にした要素をbody要素の子に突っ込んで、計算済みスタイルを拾うというだけだ。overflowプロパティー
srcset属性を使ったSVGフォールバック・ハック
SVGをサポートする環境がほとんどになってきた。それでもなんとか8であったり、かんとか2.3であったりのことを考慮せざるをえないという状況はありうる。それにはonerror属性を使った対応が有力だが、srcset属性でSVGファイルを指定するだけというハックのことを知った。将来的に使えなくなるわけではないが、やりたいことと実装に食い違いが少なからずあるのでハックと言って良いだろう。 <img src="foo.png" srcset="foo.svg"> 表示したいSVGをsrcset属性で、フォールバックに使いたいPNGをsrc属性で指定するだけだ。これでsrcset属性をサポートしているブラウザーではSVGが、そうでないブラウザーではPNGが表示される。srcset属性のサポートに対して、より多くのブラウザーがSVGをサポートしていることから成立する。もちろん食い違いがあるのでSVGを
横にはみ出すナビゲーション
今回(2014年9月)のAppleのウェブサイトのリニューアルにはいくつもの興味深い点がある。ナビゲーションの二本線とバツ印が共にインラインのSVGなことなどもそうだし、多くのポーションがモダナイズされたにも関わらずPrototype.jsを継続利用したこともすごく気になる。その中でも一番気になったのは狭い画面向けの横にはみ出すナビゲーションだ。 これまでの通常は隠されている狭い画面向けのナビゲーションの多くは、次の3つに大別されていた。 ドロップダウン オーバーレイ ドロワー 極稀にアイコンのみのコンパクトに横へ並べたものもあったが、いずれの場合もナビゲーションの項目は縦に並んでいることがほとんどだ。一覧性に富み、アクセス性が高く、ユーザーの学習コストも低い。 これに対して横にはみ出すナビゲーションは、項目を画面外にはみ出すように横に並べ、スワイプでスクロールして探させるという形のものだ
クリティカル・パスのCSSなるシロモノ
クリティカル・パスのCSSをインライン化して、描画の開始を早めるテクニックが広まり始めている。数字上は確かに効果的だが、ソーシャル・ボタンの非同期化によるスクロールのつっかかりと似たような問題を孕んでいるのではないかという思いが強い。 世の中にはスクロールをまったくしない人とすぐにする人がいる。しない人はまったくしないので、クリティカル・パスのCSSのインライン化は意味があるような無いようなところだ。効果的になるはずのスクロールする人は、ページが表示され次第とりあえずスクロールするという行動を取ることが多いように思う。その時、非同期で読み込まれたCSSが間に合っていないとかなりひどいことになるだろう。 こういったページ閲覧中のちょっとしたパフォーマンスの低下を避けるためにも、CSSは一気に読ませた方が良いと考えている。非同期化されたJavaScriptによりコンテンツの追加や削除が頻繁に行
kyonagashima.com
Brad Frostが自分の名前のドメインを確保するのにぼったくられたという記事を読んで、良い機会なのでkyonagashima.comを確保した。面倒だったので735円だしといつも通りValue Domainで取得した。 世間のドメイン取得代行業者への評価は地に落ちているような印象だが、僕は実際に辛いトラブルにあったことがなく、大体は根気強いメールのやりとりのみで解決できてきたので、あまり悪く評価してはいない。でも検索クエリーを横取りして先に奪ってしまうといったことはやってそうだなという程度には信用していない。 実際にそういった状況に遭遇したとしたら、金の問題よりもイライラで沸騰しそうだ。買って後悔することはまずないので、買っておくかという程度の気持ちで確保した。そのはずなのに既に後悔していたりもし、ままならない。とりあえずのところは不要であるのに、ネガティブな理由で動いてしまったからだ
“マークアップ”するということ ～ HTML5勧告に寄せて ～
HTMLを適切な要素を使って書いていくことは実はそれほど難しくはない。しかし過剰に要素を使わずに、かつスタイリングすることも意識して、と適切に“マークアップ”するのはなかなかの修練を必要とする。いったい“マークアップ”するということはどういうことなのだろうか、そしてどのような思考の元に行えば良いのだろうか。 HTML5での変化 著作権表示のマークアップ small要素 footer要素とsmall要素 p要素とdiv要素 footer要素とp要素 スタイリングとの兼ね合い マークアップするということ HTML5での変化 コンテンツに則した素直な形でマークアップできること。 HTML5で変わることや変わったことは多くあるが、それらをおおまかに俯瞰するとこのような言葉に集約できる。そのために様々な要素や属性が追加され、既存の実装をなるべく壊さない形で要素の意味に変更が加えられた。これらの変化は
Google Fonts版のSource Sans Pro
Google Fonts版のSource Sans Proはオリジナルと微妙に違うところがある。多くはほとんど気づかないようなものだが、稀に顕著に現れることもあり困る。僕が今まで気づいた中で最も顕著なものはExtra Lightを使った時に38px以上にすると、文字のストロークがExtra Lightに見えない程度に太くなってしまうという問題だ。 Demo: Source Sans Pro 手元のWindowsではほとんどすべてのブラウザーで再現した。ClearType有効・無効や古いOSだとまた変わるかもしれない。iPhone 5sのMobile Safari 8では再現しないが、これも世代によって変わるかもしれない。太くなるだけでなく汚くなってしまうので、なかなか厳しい。 これに気づいたのは結構前で、Google Fontsのフォントがイマイチ信用できないというきっかけになった。再現性
Google Fontsはいつまであるのか？
Will Google Fonts Ever Be Shut Down?という記事を読んだ。とてつもない数のウェブサイトで利用されているGoogle Fontsが果たしていつまで無料で自由に使えるままなのかを、今のGoogle Fontsの状態とその持つ意味から考察されてる。現状ではメリットがあるので提供しているけれども、それがコストに見合わなくなったらすぐやめるんじゃないかみたいな悲観的な観測で終わる。 Google Fontsからビジネス・モデルのようなものがよく見えてこないことと一部の限られたユーザーにのみ高く評価されていることが、ジャンルがまったく違うがGoogle Readerと重なるところがあるのは少しわかる。それを考えるとサービスの停止もありそうと考えてしまうのもわからないこともない。でも悲観的になるのはちょっとわからない。 それほどコストはかかっていないと思うし、とんでもな
ウェブ・タイポグラフィーのベスト・プラクティス
Translation of: The All-Inclusive Guide to Web Typography Best Practices インターネットを見渡してみると、如何にタイポグラフィーがウェブ・デザインにおいて絶対的な支配力を持っているかに気付くことでしょう。とにかくウェブ・デザインの95%はタイポグラフィーだというわけです。このようなことを考える時は、様々なことを考慮しなくてはいけません。インターネットとはコンテンツであり、コンテンツとは文字そして文章です。すなわちタイポグラフィーを意味するわけです。 懸命なウェブ・デザイナーなら誰しもこのことは知っており、注意深くまた慎重に時間を費やし、作成中のウェブサイトでタイポグラフィーがきちんとなるようにしていることでしょう。その中では読者に機能的で魅力的であるようなタイポグラフィーを提供するため、ウェブサイトの情報アーキテクチャ
Sitelinks Search Box
ページ下部に検索フォームを復活させて、GoogleのSitelinks Search Boxに対応させたつもり。本当は検索ページを別に作ってそっちに寄せようかと思ったけど面倒になってきたので、とりあえずGoogleカスタム検索を復活させてMicrodataを仕込んだ。 Sitelinks Search Boxの注意点はウェブサイトのホームページにのみ仕込むこととUTF-8でしか機能しないことくらい。例を見る限りはサードパーティの検索システムを利用するのも問題ないように見える。仕込んだからといって使ってくれるわけではないらしい。 最終的に以下のようなマークアップになった。 <html itemscope itemtype="http://schema.org/WebSite"> <body> <aside role="search"> <form action="http://www.goo
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の変更などというものはあまりないので、以下のような条件でバージョン番号の増加を行っています: メジャー・バージョンは、レイアウトの大幅な置き換えやテーマカラー
CSSのローディング・アイコンのコスト
今までは主にアニメーションGIFで作られていたローディング・アイコンをCSSアニメーションで作るみたいなのが流行っている。面白いとは思うし、ちゃんと作ればスケーラブルなので便利そうでもある。けれどもローディング・アイコンを表示するための空要素が必要になり、かつ後にそれを消さなくてはならない。CSSだけだと面倒くさそうだ。 どういうローディング・アイコンかはこの際問題ではないので、とりあえずmain要素以下に何かしら(仮にサムネイルとする)をロードするまでローディング・アイコンを表示することを考えてみる。普通はJavaScriptでローディング・アイコンの追加→サムネイルのビルド→ローディング・アイコンの削除→サムネイルの追加とやるわけだけど、ローディング・アイコンの追加と削除でDOM操作を伴うのはコストがある気がする。 <main id="result"> <div class="spin
Drawic v2.4.0
DrawicにPinboardのアイコンを加えるついでに忘れていたInkscapeのアイコンを追加した。Dribbbleはついで。チェックマークはユニコードで代用効きそうだけど、シャープが保証されてそうなやつない気がするので作っておいた。 SVGはメキメキと露出が増えてきた。今利用しようとすると、問題になるのはやはりCSSスプライトに相当する手段。CSSにData URIで埋め込んで「Text Sprite」などとプレゼンで言ってる人もいるけど、ちょっと微妙な感じ。機能的にはそうだとは言えるんだけど、言うまでもないデメリットがあるわけなので気軽に代わりに使えるわけではないから。このプレゼン自体はData URIする時にはURLエンコード使おうとか、他は大体頷きながら興味深く読めた。
CSS3のtransformを使ったフォントの変形
CSS3のtransformプロパティでscale()(または-ms-filterでMatrix())を使うと、ブロックの拡大と縮小ができる。これを利用するとVerdanaをCondensedなフォントっぽく細くしたり、ワープロ時代の倍角文字や縦倍角文字を実現することが簡単にできる。コンテンツ本文に使うのは無理があるが、見出しなどには良さそう。特に@font-faceで気軽に変更できない(してもあまり効果的ではない)日本語の見出しには面白い試みなんじゃないかと思ったが、一番綺麗にしたいIE8で残念なので微妙。 Verdana Narrow? Demo: Verdana Narrow 単純に細くしたいブロックでtransform: scaleX(num);を使えば良い。 .narrow { -webkit-transform: scaleX(0.8); -moz-transform: sca
アクティブなナビゲーション項目と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
right: 100%か負のマージンか
これまでCSSにはレイアウト方法があまりなかった。これからはFlexible Box LayoutやMulti-column Layout、Grid Layoutを始め、positionプロパティーに使える値の拡充などもあり柔軟に行えるようになるだろうが、それはけっして既存のレイアウト方法が不必要になるということではない。選択肢が増えると受け止めるべきだ。例えばright: 100%や負のマージンを使って親要素の外側左にレイアウトする手法はそのまま使い続けることになるだろう。 ほとんど同じレイアウトを実現するright: 100%と負のマージンの使い分けを通して、レイアウト方法の選択をどう行うべきかという基本的な思想を解説することにより、今後増えてくるレイアウトの選択肢にどう相対すべきかがわかるのではないかと思う。そしてそれはCSSプロパティーの意図された使い方を理解するということでもある
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
引用元の表記
blockquote要素における引用元の表記をどうマークアップするかでWHATWGとW3Cの仕様で違いが出たので、俄然盛り上がってきた。昨日公開されたHTML5 Doctorの記事を始め、様々な人が見解を書いている。概ねシンプルなW3C版が優勢な気がする。どう決着するかには関心があるものの、現状どうするべきかについてはよくわからなくなってしまったので、それぞれどういうコードになるのかとその思想の違いをメモだけしておく。 WHATWG版では以下のようにfigure要素を使い、figcaption要素で引用元の表記をマークアップする。このウェブサイトではこっちを採用中。 <figure> <blockquote> <p>引用(いんよう、英語：citation, quotation)とは、広義には、他人の著作を自己の作品のなかで紹介する行為、先人の芸術作品やその要素を自己の作品に取り入れること。
ディテール
Webページにおける細かいパーツを正しく実装することがユーザー経験の向上につながるということについて書かれたUI: Getting the Details Rightを読んだ。WordPressの結構な人気テーマでもタブがあたかもパンくずリストのように表示されていたりするし、頭ではわかってても実践にまでは至らないことも多そう。 Getting the Details Rightではいくつかの有名なパターンを例に、こう実装するとユーザーが混乱しにくいという説明をしている。例えばスライドショーでは切り替えの矢印以外にも「いくつくらい画像が用意されていて、今何番目を表示しているのか」を示すドットを使ったインジケーターが重要であるとしている。また、画像や画面の切り替えにも簡単なアニメーションを導入することによって、ユーザーに「どう切り替わったのかをアニメーションで示すことによって戻る方法を示唆でき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
