行動記録

WebDAVシステム構築ガイド released

あるスキーマに準拠するということ ( Re: 遠足に持っていくもの )

HTML 文書の作成とは、ある文書の文書構造をタグを用いて明示化していくことです。 その際には、特定のスキーマに従ってマークアップしていくこととなります。 で、そのスキーマではマークアップできない文書構造というものも勿論存在します。 顕著な例では、HTML 4.01 のスキーマを用いたときのリストを含む段落です。 これは、そのような文書構造をマークアップすることは HTML 4.01 のスキーマでは力不足であるためマークアップできないということを意味します。

そこで、朝顔日記の遠足に持っていくものより引用。

インチキくさいですか？ :p)

HTML4 等のスキーマでは当たり前のマークアップですよね。 object 要素を使ってリストを……などというのが流行っているようですが、 代替コンテンツを表示させたときにどのような構造になるのかぐらいは考えた方がいい。 スキーマに valid ならば良いという考えは美しくないとは思わないのだろうか。

HTML のための id と class

Web::Blogoscope の XHTMLの最適化手法内の id/classを少なくするから引用。

id/classはdiv/span要素と組み合わせてスタイル適用のためのトリガーとして使う（スクリプトの参照先などにも利用するが、ここではひとまず置いておく）。id/classも少ないに越したことはない。

これは特に、効率的なCSS設計と関係する。id/classセレクタではなく子孫セレクタが利用できないか考えるのが、CSSの効率化に不可欠だからだ。なぜならid/classづけはCSSだけで完結する作業ではなく、XHTMLでid/class属性を追加・修正するという手間が発生するからである。

作業効率を考えると、CSSだけで作業が完結する子孫セレクタを利用したほうがよい。何よりXHTMLがクリーンになるというメリットもある。

なんか凄く違和感があるなぁ。 XHTML の話をしているのに CSS の効率化の話がでてくるし。 そもそも、文書構造を考える時点でスタイルシートなんかに囚われていることがおかしいのではないだろうか。 文書構造を示す上で必要であるならば id も class も積極的に指定していくべきだ。 これは、XML の設計目標の一つである「Terseness in XML markup is of minimal importance.」にも合致した考え方でもあるだろう。 そうやって、文書構造を明示した上で、スタイルシートやスクリプトのために必要であるならば、別途 id や class を振ってやればいい。

form の為の CSS を考えてみる

現実逃避(謎)ついでに form の CSS を考えてみる。 お題(謎)は、mixi の CSS テクニックとかいうコミュニティ。

label 要素で括って、label 要素を block レベルとしてレンダリングさせてみた。 問題点は次のようなところか。

submit ボタンがないのは盲点だったなぁ。 お題(謎)に入ってなかったのを見落としてた。 まあ、右揃えでもいい気もするが。

いろんなパターンを考えてみると面白いかも知れない。よくわからんが。

Re: あなたの知らないかもしれないCSS: 5. こだわりのh1

textocean のエントリ あなたの知らないかもしれないCSS のこだわりのh1 から引用。

サイトのタイトルにちょっとこだわったフォントを使いたい。でもそれぞれのPCにフォントがインストールされていなければそれは可能になりません。そこでテキストの代わりに画像をってのは、結構常套手段となっています。（最近ではFlashで読み込んで表示するものもあります）

<h1><img src="widget-image.gif" alt="Buy widgets" /></h1>

もちろんこれでも問題ないのですが、Googleなどのサーチエンジンなどからは当然拾ってもらえません。

何故「当然拾ってもらえません」と言えるのでしょうか? 敢えて「当然」という表現を使うならば、仕様を考えれば、むしろ、そこから取得することが当然だと思うのですが。

元ネタだか翻訳されるものだかはわからないのですが、Ten CSS tricks you may not know では次のようになってますね。

This is OK but there's strong evidence to suggest that search engines don't assign as much importance to alt text as they do real text (because so many webmasters use the alt text to cram in keywords).

これを以って「当然」と断ずるのはなんか違うんじゃないでしょうか。 まあ、悪意のあるユーザが多いから検索エンジン側としては対処せざるを得ないという背景はあるのかも知れませんが、 その理由を書かずに「当然」と断ずるだけでは、img 要素の alt 属性の意味への誤解を誘発してしまうと懸念します。

「表」は表ですよね。当り前ですが。

MinuteDesign のそのテーブル、本当に必要?より引用。

典型的な 2 列の表 を作ってみました (データ出典)。上下とも同じ表です。ただし、上は table + tr + th + td、下は dl + dt + dd で記述し、それぞれスタイルを付けてあります。CSS を外したり、ソースを表示して確認してください。この程度のデータなら、何もテーブルを使わなくたって、定義リスト を使ってシンプルに書いてしまうことができます。簡単でしょ?

単に CSS を適用してみたときの見映え見ためが同等になっているだけで、前者は表で後者は定義リストでしかないと思うんだが。

もちろんこの方法ですべてのテーブルを書き換えることはできませんが、中身のデータによっては、これで意味も通じるし、よりアクセシブルになります。どうぞお試しあれ。

意味が通じるか否かはコンテンツに依存するのでなんともいえないところですが、 「よりアクセシブルになります」ってのは意味がわかりません。 表であるべきものを定義リストで表現することによってアクセシビリティが低下することはあっても、向上することはないと思うのですが。 なんだか、「 table はアクセシブルではない」という変な理解をしているように思ってしまいます。

table をレイアウトに用いることへの W3C の見解

Black Box(何処)で HTML Techniques for WCAG 2.0 W3C Working Draft 09 December 2003 の 8 Tables for layout の邦訳が公開された。 それをきっかけにちょっと読んでみると引き続きレイアウト目的の table は引き続き許容されているということか。まあ、この方針に従っていればあまり問題はないはずではあるけど。というか、なんか今更のコメントですか、御意(謎)。

なお、哀さん(誰)は次のように言っているが、元の哀さん(誰)の翻訳にツッコミを入れただけなので半分というよりは一部だと思った。

この翻訳の半分はいわいさんでできています。入浴中にまで頭を捻っていただいて（謎）。ご協力多謝です。

まあ、入浴中云々の話は事実ではある。 尤も、いらないところ訳したなぁ、と思ったのと、それと同程度におもしろいところを訳したなぁ、と思っただけだけど。

IWAI, Masaharu iwai@alib.jp

Copyright © 2003 IWAI, Masaharu All Rights Reserved.

powered by blosxom