CSS3 モジュール： マルチカラムレイアウト仕様書邦訳
CSS3 モジュール： マルチカラムレイアウト 2007-06-06 W3C 草案 原文 http://www.w3.org/TR/2007/WD-css3-multicol-20070606 原文の編集者 Håkon Wium Lie, Opera Software, howcome@opera.com 訳注 Jintrick.netによる意訳です。正確な情報と異なる可能性に留意してください。 Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply. 概要 このモジュールは、CSSにおけるマルチカラムレイアウトを説明する。これはCSS3ボックスモデルモジュールに基づいており、要素の内容を複数行にする機能を追加
ウェブブラウザなんかに気を遣わなくてもいい理由 (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
Re: 僕があまりDocumentFragmentを使っていない理由 (agenda)
Latest topics > 僕があまりDocumentFragmentを使っていない理由 - outsider reflex ただ、どんな場合でも上位のDOMノードをゴソッと差し替えて高速化する方法を使うべき、とは言えません。 DocumentFragmentを用いて要素を切り貼りすると、著者スクリプト等が動作しなくなることは私もよく経験しているので、そのスクリプトを検証するまでもなく確かにその通りだと思う。そして文書ツリーを多数回変更するときはDocument Fragmentを経由する (agenda)は、確かにどんな場合でもと言っているように読める。 ここは素直に謝りたい。申し訳なかった。文書ツリーを多数回変更するときはDocument Fragmentを経由する (agenda)を読んで、文書ツリーを多数回変更するときは、どんな場合でもDocument Fragmentを使うべ
文書ツリーを多数回変更するときはDocument Fragmentを経由する (agenda)
「文書ツリーを多数回変更するときは、直接行なわずにDocument Fragmentを経由してくれ」という話。 一度DOMの実装を書いてみるなり、書こうとしてみるなりすれば分かる。DOM文書ツリーの変更、特にHTML文書におけるそれがどれだけの要素に影響を与えるかが。Document Fragmentの何が良いかといえば、例えば「View」から切り離されていることが挙げられると思う。DOM実装に依存するし想像でしかないけれども、文書ツリーに直接何らかのノードを加えたり削除したりすると、表示スタイルの計算にリソースを多少なり消費するが、Document Fragment中のノード群を操作する限りスタイルは関係ない。操作が完了した後に実際の文書ツリーに一回だけ変更を加えるなら、スタイルの計算も一回ですむ。文字列連結を何度も繰り返すか、それとも文字列の配列を一回だけjoinするかの違いを連想して
Google検索結果をリキッドマルチカラムで一望し、次の検索結果を先行読み込みして高速に表示し、かつ履歴で戻れるGreasemonkeyスクリプト (agenda)
Google検索結果をリキッドマルチカラムで一望し、次の検索結果を先行読み込みして高速に表示し、かつ履歴で戻れるGreasemonkeyスクリプト 注：Googleの仕様変更に伴い、このスクリプトは形骸化している。修正版はMulticol Google Search (agenda)で公開している。 Googleをマルチカラム環境に最適化する (agenda)は、10分かそこらで書いた適当なスクリプトだったのでいつか書き直そうと考えていたが、暇を見つけて終わらせたので公開しておく。今回Stylishやユーザースタイルシートは使わず、Greasemonkeyのみで動作するようにした。googlesearchutility.user.js。 スクリーンショット 留意点など 訳あってwww.google.comでしか履歴は動作しない。www.google.co.jpでも基本的に動作はするが、そこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
