ウェブブラウザなんかに気を遣わなくてもいい理由 (agenda)
いつの間にか2009年になってしまった。 IE6に気を使わなくてもいい理由とか「そういう系」 の話を聞くと、なんで非営利個人サイトが自分の嫌いなウェブブラウザなんかに一々気を遣わなきゃならないんだとか思う。もちろん気を遣うのには色々理由があるだろう。だが「気を遣わなくてもいい理由」というのもあっていいんじゃないか。そう思ってだらだらと悪文を書いてみた。本当に悪文だからまとまりはないよ。 相手にしていられないほど膨大な種類の「ウェブブラウザ」 この文脈においてはウェブブラウザではなく、所謂レイアウトエンジンやHTMLパーサの種類を把握すべきだろう。たとえばSleipnirもfubも、同じMSHTML.dllを利用しているなら一つとしてカウントできる。 ウェブページのレイアウトエンジン レイアウトエンジン等の名称主なバージョン（2009年1月現在）応用しているプロダクト他
p要素の終了タグを省略する際の注意点 (agenda)
HTML4.01ではp要素の終了タグ「</p>」は省略することができるようになっている。数ある省略可能なタグの中で、最も気を付けなければならないのがこの「</p>」。 DTDの再確認 まずスキーマを見てみる。p要素の内容モデルを確認するのに必要なのは次の箇所： <!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body --> <!ELEMENT P - O (%inline;)* -- paragraph --> <!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;"> <!ENTITY % fontstyle "TT | I | B | BIG | SMALL"> <!ENTITY % phrase "EM | STR
横書きのマルチカラムと横スクロール (agenda)
横スクロールについては何カ月か前に考察した。その一部分を公開しておく。 横書きの文書の場合、十分に小さな量の縦スクロールによって新たな一行が表示される。誰もが「体で」知っていることだろう。この十分に小さな量の縦スクロールがユーザにきちんとフィードバックされる、つまりユーザはスクロールを細かく操作している感覚を持つことができる。 一方横書き文書のマルチカラムの新しいカラムボックスがインライン方向にどんどん追加されていく場合、それを横スクロールで表示しようとすると、十分に小さな量の横スクロールは、意味のあるフィードバックをユーザに返さない。つまり、「新しい行」ではなく、「各行の新しい一文字」が表示されることになる。したがってこの場合、ユーザにとって意味のある最小量の横スクロールは、カラムボックスの幅と同じである（正確にはカラムボックス＋カラムギャップ＋カラムボーダー幅）。次の画像は、以前横スク
Re: 僕があまりDocumentFragmentを使っていない理由 (agenda)
Latest topics > 僕があまりDocumentFragmentを使っていない理由 - outsider reflex ただ、どんな場合でも上位のDOMノードをゴソッと差し替えて高速化する方法を使うべき、とは言えません。 DocumentFragmentを用いて要素を切り貼りすると、著者スクリプト等が動作しなくなることは私もよく経験しているので、そのスクリプトを検証するまでもなく確かにその通りだと思う。そして文書ツリーを多数回変更するときはDocument Fragmentを経由する (agenda)は、確かにどんな場合でもと言っているように読める。 ここは素直に謝りたい。申し訳なかった。文書ツリーを多数回変更するときはDocument Fragmentを経由する (agenda)を読んで、文書ツリーを多数回変更するときは、どんな場合でもDocument Fragmentを使うべ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
