HTMLの質の追求は、モバイルがきっかけでブレイクする。
Web標準を考えるというエントリーで、フルCSSが受託案件で堂々と使えるようになったのは、SEOという言葉が出てきたから、という言葉を書いたら、はてブに微妙な反論があった。 しかし、それは現場では間違いではなかった。 2002～2003年頃は、ネスケ4を切るための理由がなかったのだ。 ネスケ4を切るということは、少なからずユーザーを失うというビジネスマターの決断になるので、制作者の論理、HTMLの論理などという瑣末（あえて言ってみる）なことで、ビジネスの機会損失になることは許されない。 もし捨てさせたければ、ビジネスニーズvsビジネスニーズの取捨選択の決断が必要。 そこにハマったのが、MovableType（blog）とSEOだった。blogは、なんだかんだとUTF-8であることが求められるし、SEO対策のためにテーブルレイアウトが悪者とされることとなった。 ずばり、この二つのキーワードが
-moz-column-*系プロパティが真価を発揮するとき - Hatena::agenda
しまったなんで気づかなかったんだろう。いやこの糞ぶろぐでリキッドマルチカラムをやるというのが無謀というかそりゃデメリットがあり過ぎるだろ何を今更っていうツッコミはやる前から重々承知していた。-moz-colomn系のマルチカラムは文章量によって適切な指定が異なるから、文章量の不定なHatena::agendaに適用させても縦スクロールを要求してしまう記事も出てくるんだ。そうではなくて、-moz-column系プロパティを、どうして今までGoogle検索結果にユーザースタイルシートとして使わなかったかってことだ。つまりコンテンツの物理的な量が概ね分かっていて、かつその量を閲覧者が調節できて、かつ一覧性が重要なものに対して、-moz-column-widthプロパティは適切なスタイル指定となる。 @-moz-document domain("www.google.com") { div#res
本物のリキッドレイアウト - 補足：Hatena::agenda
Hatena::agenda - 本物のリキッドレイアウトの続き。 リキッドなマルチカラムの実例 Hatena::agendaは実験場ではないけれども、CSS3 Columns - MDCで紹介されているmozilla独自拡張プロパティを使用してリキッドマルチカラムにしてみた。デメリットもかなりあってまだ改善の余地があり余っているものの、場合によっては低解像度から高解像度まで、シングルウィンドウから並行閲覧まで手広くカバーできる。 このプロパティを実装していないブラウザ向けに、一応スクリーンショットを用意してみた。 幅が小さいと1カラム（約50kb） ある程度広げると2カラム（約90kb） 充分広げると3カラム（約110kb） 念を押しておくが、-moz-で始まる独自拡張プロパティは、正しく使えば問題ない。これはCSS validatorを通らない。しかしCSS実装は、不明なプロパティは無
全てのブラウザで同じに見える必要はないし、それは不可能で間違ってる - 氾濫原
だって、ブラウザには、画像を表示できないブラウザとかがあるんだもんね。IE も Fx も Opera も、そういう意味では同じような違いで、Fx では先行実装を使って段組になってよみやすくなっていたり、IE ではのっぺりだったり、そういうのがあっていいはず。なのに、一個の表示に統一しないといけないみたいな、わけわかんないのに縛られたりする。別に違ってていいと思う。 あと Web と紙は違うから、違うアプローチの仕方 (可変レイアウト) をすべきなのに、紙と全く同じスタンスで作るから、問題になる。いろんな UA にむけてデザインするのがウェブデザインじゃないの？ 今のウェブデザイナーは殆どウェブデザイナーじゃないよね。そんなだから「ウェブデザイナー(笑)」みたいになるんだ。 しかし、ウェブデザイナーでもなんでもない自分がごたごたいうのもおかしいので、あれなんだけど、最近どうも甘く考え気味 (
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなアンテナ
jQueryの練習に、urn:isbn:なアンカーを解釋するのを作つてみた - 人生が二度あれば
