マルチカラムって何さでCSS段組って結局擬似的なアレなのでさっさと本物のマルチカラムが実現出来るようになってほしい
とありますが、仕様書を読むまでもなく、これはヤバイと思うわけで。印刷用途以外では、本物のマルチカラム
は実現できない方がいい。……ということは、NN4 向けに multicol 要素を用いて段組された文書を見たことがある人ならよくわかっているはずのことなんですが、もうそれを知っている人も少ないということなんでしょう。
あと、一応、心ある人は仕様書も読んでおくといいと思います。まだ草案ですけれども。（というか、もう5年以上も審議しているんですね。そんなに議論すべき問題があるのかな。よくわからないんですが）
「エディトリアル～」に私が寄せたコメントを引用します。
かつて、HTML 文書で段組が実現したことが1度だけあるわけです。それが NN4 独自拡張の multicol 要素です。で、そのときに「本物の段組ってのはダメだな」とみんな思った。だから、独自拡張を積極的に取り入れた HTML4.0Transitional においても、multicol 要素は無視されたんです。
本物の段組というのは、ようするに新聞のようなレイアウトを実現するんですけれども、サイズ不定のコンピュータの画面で真似すると非常に読みにくくなるんです。当然でしょう。左カラムの一番下までスクロールして読んでいって、その続きは右カラムの一番上なんですよ。ひとつの文書を読むために、何回も上下にスクロールしないといけないのです。「段組みたいなもの」はまあ、有用ですけれども、「本物の段組」はダメなんですね。
CSS3 が勧告されても、基本的に印刷用スタイルシート以外では使うべきでないと思います。
たしかに、私の考えを突き詰めていけばそこにたどり着きます。ただ、私は文字サイズ固定も別の観点から許容しますし、マルチカラムデザインも同じ理由で許容します。
紙の組版に慣れた方がよく口にされる「1行字数を制限したい」という希望は、既に CSS2 において max-width プロパティとして取り入れられています。W3C は、幅制限もやっていいといっているのです。CSS によるデザインの場合、問題があれば閲覧者の側に対処法があるから、これが許されているのですね。
現状のいろいろなwebページを見る限り、本当に求められているのはマルチカラムでなく、JAVAのSwingにあるレイアウトマネージャのような機能じゃないかな、なんて思います。
レイアウトマネージャには、コントロールや文字のサイズ、領域の大きさが固定だという前提があります。そのため個人製作のソフトウェアの多くは、Windows のユーザ補助機能などによりシステムの標準文字サイズを大きくした場合に、全く使えなくなってしまいます。あるいは、標準の文字サイズを無視して、小さな文字のままなんですね。
HPB の「どこでも配置モード」の操作感がまさしくレイアウトマネージャのそれなんですけれども、HPB の見事な大失敗によって、多くの人が重要なことを悟ったんじゃないでしょうか。画面サイズと文字サイズが不定の Web デザインにおいて、全てを希望通りにするのは不可能だ、と。ある環境に最適化されたデザインは、必ず他の環境で問題を引き起こすのです。
JAVA のレイアウトマネージャを HPB の「どこでも配置モード」に例えたのは間違いだったので、訂正します。どこでも配置モードと同じやり方をしているのは VB の Windows フォームデザイナ（あるいは Web フォームコントロールの配置）でした。
ざっと読んだ感じでは、テーブルレイアウトに似た発想のようですね。FlowLayout はけっこう違いますけれども、GridLayout と BorderLayout は非常に近い（というか GridLayout など、そのまんまという感じ）。
画面サイズの変更への追従という点でも、文字サイズ耐性という面でも、テーブルレイアウトは優れているんです。ではなぜ批判されるのかというと、結果としての見た目のために、ソースにおける情報の登場順序が不自然な操作を余儀なくされるからです。それがなぜ問題かというと、一部のテキストブラウザや音声系ブラウザでは原理的にテーブルを解釈することが不可能なので、情報がソースの順に提示されるからです。
レイアウト・マネージャー２という解説を読むと、レイアウトマネージャの GridLayout では行と列を個別に指定できるようですね。これなら、テーブルレイアウトの利点だけを享受できそうです。（ちなみに BorderLayout の東西南北の指定も、 情報の登場順に依存しないようです）