double-team.orgでタグ「css」が付けられているもの

IE8 の β1 が出たので早速試してみた。(Mac OSX の Parallels で動いている Windows XPで検証)

  • content プロパティ未サポート(β1 でまだ実装されてないってのはどうよ?)
  • counter 系プロパティも同様
  • float,clear,position プロパティの解釈が変わった?(退化したと思われる)
  • data スキームサポート(ようやく!)
  • Acid3 にかけると「This website wants to run the following add-on: 'MSXML 3.0 SP9' from 'Microsoft Corporation'. If you trust the website and the add-on and want to allow it to run. click here...」と出てアドオンを入れろと言われる
  • Acid2 にかけたらスマイリーが出た(!)

float,clear,position プロパティ云々は弊社Web サイトを見て感じた。

以降追加して行く予定(時間があれば。。。)

  • なにげに Developer Tool が標準装備
  • content プロパティはサポートされていた
    • ただし after,before の疑似要素の書き方として、コロンが2つ続くのはダメっぽい
    • そもそも疑似要素の場合、コロン2つ記述するのって CSS3 で定義されてるんでしたっけ?
  • counter 系プロパティもサポートされてる

追記 2008年3月11日 16:00

疑似要素の表記でコロンが2つ続くのは確かに CSS3 からだけど、今のブラウザはこれに対応してるみたい。

やっぱり IE8 はこれにも対応するべきじゃないかしら。
いや別に必要じゃないって言えばそうだし、そもそも CSS3 のセレクタ はまだ Last call であるわけだから、勧告したら対応でもいいけどね。

社内向け文書を作成している時に試しに自動カウンタを使ってみたが、どうも Firefox と Safari では微妙に対応が不十分っぽい。

恐らく問題は文書構造にあると思われ。
テストページでは div 要素でセグメント化されたパターンとされてないパターンの2通りが載っているが、問題はセグメント化された方で、自動カウンタ上でルートとなる要素(ここでは h1 要素)が div で個々が分離されている場合、正常にカウンタが動作しない。

HTML と CSS のソースコードも載っているので、分かる人は教えてください。
そもそも書き方が違うとか、これが仕様とか、むしろ Opera が間違ってるとか、Firefox のバグやねーとか、カウンタなんか使わねーよとか、IE 早くカウンタ以前に content プロパティサポートしろとか、そんな感じのことをお願いします。

石川氏のブログで「html要素にheightプロパティ、body要素にmin-heightプロパティをパーセント値で指定すると、ウィンドウをリサイズしたときにbody要素の高さが変更されない」とのことで、いろいろ調べていたら Opera 9.23 だけの問題じゃないことに気付いた。

大元のバグ報告は CSS/DHTMLバグ辞典スレッド【第5版】の324では Opera のみが対象となっているが、手元にあるブラウザ全てで調べてみた。
対象ブラウザは以下の通り。

Windows
  • Mozilla Firefox 2.0.4
  • Microsoft Internet Explorer 7
  • Opera 7.02/7.52/8.01/9.01/9.10
MacOSX
  • Mozilla Firefox 2.0.4
  • Opera 7.52/8.01/9.23
  • Safari 2.0/2.04

WinIE6 と MacIE は min-height をサポートしていないのでそもそも対象外にしています。

結果は以下の通り。

Windows
  • Mozilla Firefox 2.0.4 発現せず
  • Microsoft Internet Explorer 7 発現せず
  • Opera 7.02/7.52/8.01/9.01/9.10 7.52 以降で発現
MacOSX
  • Mozilla Firefox 2.0.4 発現せず
  • Opera 7.52/8.01/9.23 発現
  • Safari 2.0/2.04 発現

Opera では 7.02 では現象は確認できず、7.52 以降で確認できた。恐らく Opera 7.02 までは min-height をサポートされていないと推測。
Safari では 2.0 で現象が確認できたので、恐らく 2.0-2.04 間の全てでこの現象は起こると予測。

ちなみに Camino 1.5 では確認できず、シイラ 2.2 では発現した。これはそれぞれ Gecko エンジンと KHTML(Apple WebKit)のエンジンが Firefox・Safari と同等であるからである(と思う)。

しかし現象が確認できないユーザもいるようだが、何かしらの条件があるのだろうか?

はてなブックマーク経由で見つけてきた。

自分の結果

HTML の結果
51
JustSayHi - A Free Dating Website
CSS の結果
65
Free Online Dating from JustSayHi

まあ CSS はプロパティによって使う・使わないが激しく分かれるので、まあこの辺が無難だろうと思います。印刷関連や音声関連が一切出てこなかった。

しかし HTML はちょっとなぁ。。非推奨要素まで入ってるから困る。b 要素とか s 要素とか偶然出てきたレベルだし。あとフレーム関連は一切知らない。
けどフォーム関連が全然思い出せなかったのは自己嫌悪。ダメだなぁ。

たぶんどこにでもあるネタだと思うけど、きっかけは”position プロパティの fixed 値を印刷時にはどーやって表示されるのか”が気になったので試してみたら”これでプレゼンテーションツールが作れるんじゃね?”ってことで作ってみた。

XHTML+CSS Slideshow Tool とは

純粋な XHTML と CSS の組み合わせで PDF 印刷することを前提に作られたプレゼンテーションツールです。
XHTML 文書の中身は S5 と似たような構造になっています(かなり単純化されてますが)。
なので JavaScript によるエフェクトは一切ありません。個人的にそんなのはいらないと思っているし。

使い方

  • title 要素にタイトルを記述し、これがヘッダのプレゼンする内容のタイトルとなる。
    サンプルでは”XHTML+CSS Slideshow Tool Ver 1.0”がそれに該当。
  • <div class="canvas"> がスライド1ページに相当するので、この中に内容を記述。
  • 見出しは h1 要素となっているので、そこにスライドごとに記述。
  • <div id="footer"> がスライドのフッタになるので、必要に応じて自身の名前や所属、コピーライトや連絡先を記述。
  • あとは PDF で印刷するだけ。

いろいろと思うこと

実はあんまし有効性がない。その辺の話はサンプルの中で書かれているけど、まあただ単に作ってみたかっただけ。
あとエフェクト演出がないとダメって人には向かない。だったら Keynote 使えって話だけど。

具体的な中身に関しては向こうのブログで書くつもりです(ネタ確保)。

追記 2007年8月23日 13:30

このツールの詳しい中身の説明を plucore.log で解説しています。こちらもご覧ください。

「Web 標準の日々」初日を終え、まったり中。レポートみたいなのははてなダイアリーの方にとりあえずその場の勢いで書いた。本当はセッション3の「富士通の実践、アクセシビリティ/ユーザビリティ。そしてファインダビリティ」も受講したんですが、資料配布なし、録音を認めていなかったので、エントリはしてません。記事としてはあるんですが、この辺表に出さない方がいいのかと思って。聞いておけばよかった。。

で、自身のエントリにレスを付けるのも変な話ですが、分かりやすいと思ってこうします。
float プロパティを使用する場合はその要素の幅の明示が必要」に対するコメントをいくつかいただいてますが、それにちょっち返答と言うか、自分の考え方を残しておきます。

  • 最近のモダンブラウザは概ねCSS 2.1の仕様に沿ってレンダリングされるから、最新ブラウザのみが対象であ れば必要ないかもしれないと思う今日この頃。e_luck
  • 2.1 なら shrink-to-fit するぜ? 2.1 では日本語で言う『明示的な幅〜』という部分も変更されていますね Kaminogoya

確かに CSS 2.1 では幅の明示は必要ないです。そして CSS 2.1 が草案(まだ最終草案の段階ですよね?)であるにもかかわらず、すでにブラウザ側が実装しているのも知っています。
でもこれは個人的な思いなんですが、現段階で「内容に合せて縮めた幅を算出する」と言う仕様があったとしても、実際に勧告してみないと分からないじゃないですか。ワーキンググループメンバーの主義主張でひっくり返る可能性だって無いわけではないですし。と言うかそっちの方は全然詳しくないし参加もしてないですし分かりませんが、未だ CSS 2.1 が10年くらいずっと今の状態であるわけなので、何が起こってもおかしくないと言うか。

と言うのが率直な感想で、いくら実装面で CSS 2.1 がほぼ準拠されているとは言え、限りなく公式に近いデファクトスタンダードだと思います。
それが良い悪いの話じゃなく、現段階の仕様には可能な限り準拠した方が将来に対するリスクは少ないんじゃないかな、と感じるんです。もっとも、この話は実装面にも依存するので、何とも言えませんが。この辺はあっちのブログで書いたように、会社的な考えにもなるんですが。
もちろん必ずしも仕様準拠ありきとまでは言いませんが、でもそれを踏まえた上で(今ならば)選択する余地はあると思うんです。幅を明示するかしないかとか。

でも思えば (X)HTML 文書は HTML なのか XHTML なのか、HTML なら 4.01 なのか 5 なのか、XHTML なら 1.0 なのか 1.1 なのかって選択できますけど、CSS は選択できないんですよね(HTML 5 はまだ選択肢として無いけど、例みたいな感じで)。まあこれは別に問題があるわけじゃないからいいのかな。パッと思いつくほど CSS のバージョン宣言しなければならない仕様差異があるわけじゃないし。CSS 3 だとまた話は違ってくるだろうけど。

なんかタイトルに「の」が連続してるけどいいや。

水平方向のナビゲーションの作り方」のはてなブックマーク見て、誰も float プロパティの使い方に疑問を抱いてないのを見て不安になった。

CSS 2 の仕様書内で float プロパティ(浮動体)は以下のように書かれています。

浮動ボックスは,明示的な幅をもたなければならない。明示的な幅は,置換要素の場合は,'width'特性, 又はその組込み幅によって割り当てられる。

ここである「width 特性」と「組込み幅」とはそれぞれ以下の意味となる。

width 特性とは
スタイルシートとの width プロパティを使用すること。
ちなみに「特性」は単に「プロパティ(Property)」を和訳した単語。
組込み幅とは
仕様書内では実寸法と表記されている。
実寸法 (Intrinsic dimensions)
環境によって決まるのではなく,要素自体によって定義される幅及び高さ。 CSS2では,すべての置換要素が, そして置換要素だけが, 実寸法で現われるとする。

組込み幅の定義をもっと具体的に表すと「img 要素・object 要素の width 属性もしくは画像やオブジェクト自体の幅、input 要素・select 要素の size 属性、textarea 要素の cols 属性」がこれに相当する。

なので、画像の回り込みに以下のような記述をすることは問題ない。

img {
    float: left;
    margin-right: 10px;
}

img 要素には幅があるので、スタイルシートで幅を与えることは(意図してその画像自身の幅と異なる大きさをしたいしたい場合以外であれば)無い。

ただし、幅を持たない要素は必ず width プロパティを使用する必要がある。
ここではリストを利用しているので、そのサンプルをそのまま使わせていただくが、通常であれば以下のように指定する。

HTML サンプルソース

<ul id="navigation">
  <li>編集</li>
  <li>削除</li>
  <li>追加</li>
</ul>

スタイルシートサンプルソース

#navigation {
  list-style: none;
}

#navigation li {
  width: 2em;
  float: left;
  background: transparent url(arrow.gif) no-repeat scroll left center;
  padding-left: 12px;
  margin-right: 15px;
}

もっとも、リストにある文字数によって幅を変える場合はかなり面倒なことをしないと行けないので、やはり display: inline; を使用するのが簡単と言えば簡単ですが。

全然関係ないですが、サンプルのソース上では「追加」になっているのに表示結果の画像では「新規追加」になっているのは直した方がいいと思います。

追記 2007年7月17日 11:04

CSS 2.1 では、と言う話を受けて別途エントリしました。そちらもご確認ください

と思いつつもう1ヶ月が経ってしまったが、昨日から本格的に取り掛かり、何とか今日中にはできるかなぁ~。ってな感じで進めてた。

やはり無理でした。HTML はもう出来上がってるんですが、ここから Movable Type のテンプレートに起こさなければならないのでいろいろと面倒です。
一応時間を見ながらテンプレートを入れ替えていきます。作業中は何かと不都合が生じるかもしれませんが、とりあえずここ最近の PV 数の遷移を見る限りは問題ないかと(何

テンプレート書き直しと言っても、実際にはデザインが変わるんです。
今回はいろいろと挑戦してみました。

  • div 要素完全廃止(ちょっとこれはやってみたかった)
  • 画像なし(エントリ内にある写真はともかく、それ以外の装飾用の画像は完全撤廃)
  • Firefox・Opera・Safari 対象(IE だといろいろ不都合が生じる箇所がありますが、多分問題ないと思う)
  • header,footer が ID 属性ではなく class 属性(これはただの気まぐれ。実験的に採用してみただけです)
  • wu さんの「デフォルトスタイルの差異を無くすCSS」を使ってみた(ほとんどこれに頼りっきり。仕事でも使ってます)
  • きくちゃんの「99%CSSで作るプルダウンメニュー」を使ってみた(同じく仕事でも使っています。ありがたやー)

ってな感じです。デザイン自体は何も考えてない、その場でやっつけです。
作ってて思ったんですけど、やってることって例の「画像の使用を極力控えて(長いので略)大会」と同じなのでは? と感じたけど、それはそれ。これはこれ。機会があれば大会の方にもチャレンジしてみます。

追記 2007年5月22日 17:48

やはり IE はメニュー部分がダメっぽい。IE7 も。
この辺直せれば直します。直せなければ放置か別の代替手段を考える。

あと、トップページとエントリページでそれぞれエントリタイトルの見出しレベルが違う(トップページだと h2 要素で エントリページだと h1 要素)んですが、追記や変更の見出しレベルは何にしたらいいんですかね?
この辺は動的に変えられるわけではないじゃないですか。そもそもエントリ内に見出しを書くこと自体が無理なんですが。

トップページの構造(簡潔に)

  • double-team.org(h1)
    • エントリタイトル(h2)
      • エントリ内の見出し(h3)

エントリページの構造

  • double-team.org(p)
  • エントリタイトル(h1)
    • エントリ内の見出し(h2)

エントリ内の見出しは p 要素で記述するべきですかね? でもそれだと見出しじゃないですもんねぇ。
追記や変更を見出しで記述すべきかどうかはともかく、エントリ内に見出しが記述できないのは問題なのかと思ってる。
(ちなみに h2 要素で記述するのはちと違う気がする。トップページだとエントリタイトルと並列になるし。)

昨日のアルコールが胃の中に残った状態で仕事場へ。若干気持ち悪い。近くのコンビニでマンゴージュースを買って洗浄。甘い。
日課である RSS を消化してたら今日が CSS Naked Day だったことを思い出す。これに自分もやるべきかどうするか多少迷ったが、良い機会なので乗ってみた。自戒も込めて。

で、今日1日スタイルシートを適用しないプレーンな XHTML 文書を晒すわけだけど、これを実行に移すにあたって考えられた手段が2つ。

  • スタイルシートを呼び出している link 要素を削除もしくはコメント内にしてしまう
  • スタイルシートを空のファイルにしてしまう

どっちかだろうなぁ。どっちがラクかなぁ。なんて思ったけど、XHTML 文書に手を加えるのはアレな感じだったので後者を選択した(何

このブログは相当な手抜きで構築したからあまり中身を見たくないのだが、また今後もこーゆーことが起こり得ると思うと再構築の意欲が出てくる。時間がかかるからかなり余裕がある時じゃないと実行に移れないのが難点。
なんせまだコメント部分とかトラックバック部分とかかなり適当だし、コメントの確認画面なんてそもそもテンプレート作ってないし、検索結果画面も恐ろしい。それ以前に全ページ h1 要素がブログ名の「double-team.org」なんだけど、まあ全体的に結構ヤバイ。

でもだからこそ今日のイベントにチャレンジしてみた。スタイルシートがあると分からないことが、今日みたいなひょんな出来事によって暴かれてしまう。ネタ提供。自己犠牲。でも自分は M じゃない(何

追記 2007年4月5日 12:32

関係ないっちゃ関係ないけど、見れば分かる通りこのブログでは hr 要素を使ってるよ!

ここ数日、いろんなブログで id,class 属性の議論が話題になってる
個人的な結論から言ってしまえば、デファクトスタンダードに則ってやればいい。
この一言で終わるんですが、ダメですかね?

id="header" はデファクトスタンダードの典型

この議論でよく例に出されている id="header" ですけど、これこそデファクトスタンダードの典型なんじゃないかと思うわけです(良い悪いかはともかく)。
言ってしまえば「ロゴとかナビゲーションとか検索窓があるこのブロックをヘッダとして id 属性を付与して意味を与えればいんじゃない?」と言う風習、習慣、慣わし、デファクトスタンダードなのかと思う。
で、今は「それはおかしいんじゃないの?」と疑問が投げかけられてる。でも個人的にはヘッダはヘッダであって、唯一無二の固有性を持つ存在であるわけだから、それは id 属性であっても問題ないのでは? と感じる。

と言うわけで、ヘッダやフッタ、他にあるとすればナビゲーションとかは

  • id="header"
  • id="footer"
  • id="navigation"

と言うどこでもよく目にするこれはアリかと(多少の命名規則の違いは今は問わない)。
まあ別にこれらを class 属性に変えたところで実作業上、特に問題はないんですけどね。
ただ組織的にやる場合は各々のローカルルールがある程度存在すると思うので、その辺はそれを優先するにしても、そのローカルルールが存在しない組織ないし個人はデファクトスタンダードに則るのが無難だし、少なくとも作業上の間違いはない。

なんて思ってるんですが、他にもいろいろ言いたいことがあるけどそれはまたいつか話す機会があれば。

変更 2007年3月22日 21:05

リンク先修正

今日はとても面白い1日だった。いや別に仕事とかプライベートとかじゃなく、ガリガリ CSS 書いてて楽しかった。
なんとなく「できるかなー」と思ってグリグリ2時間くらい費やした甲斐があった。でもあとで調べたらいい感じの記事があって、「こっち参照でいいんじゃない?」とも思ったが、せっかくなので残しておく。

と言うわけでまたここからで申し訳ないんですが、パンくずリストがベストとは限らない | WWW WATCH を見て「link 要素を可視化させちゃえば(ちょっとだけ)解決できるんじゃない?」と思ってやってみた。

XHTML の記述を例えばこんな感じに。

<link rel="start" href="index.html" title="最初のページへ" />
<link rel="next" href="next/index.html" title="次のページへ" />
<link rel="prev" href="prev/index.html" title="前のページへ" />

で、CSS はこう。

head {
display: block;
}

link {
display: block;
width: 100%;
}

link::after {
content: attr(title);
}

最小で書くとたったこれだけで可視化は可能。一番重要なのは head 要素を可視化するのが必要。ここでは display プロパティの値を block にしているが、inline でも問題ないあくまで表示するだけならば値を inline でも良いですが、link 要素の display プロパティの値が block になっているのと、ルートの html 直下にインライン要素が配置されるのは不自然なので、head 要素はブロック要素として扱うのが良いです。
ちなみに link 要素に疑似要素の ::after が付随しているので当然のことながら IE だと無理です。IE 対応しようと思ったら JavaScript でアレコレやらないと多分無理だと思います。

ただこれだとちょっと味気ないので、ちょっとだけ装飾してみる。

head {
display: block;
padding: 5px 5px 10px;
border-bottom: solid 1px #ccc;
}

link {
display: inline;
font-size: 80%;
color: black;
padding: 3px 5px;
border: double 3px #ccc;
border-color: #ccc #666 #666 #ccc;
}

link:hover
{
border-color: #666 #ccc #ccc #666;
}

link[rel="start"]::after {
content: "ホーム";
}

link[rel="next"]::after {
content: "次へ";
}

link[rel="prev"]::after {
content: "前へ";
}

title 属性をそのまま使わず、単語で分かりやすく表記してボタンっぽいデザインにするとそれらしく見える。

ただこれらの方法ではいくつか問題点がある。

  • Opera だとリンクなしで表示される
  • tab キーで選択できない
  • head 要素内にあるのを無理矢理可視化させたので、ページ内のコンテンツと組み合わせるのが難しい
    • position プロパティを使ってアレコレやればできるけど、またブラウザの問題(CSS の解釈とかなんとか)が出てくる

Opera の問題ですが、否定疑似クラスを使うっぽいと思ってるけどあまり理解してないので今回は見送りです。本当に否定疑似クラスなのかさえ定かでない。。。
tab キーによる選択が出来ないのは致命的です。こればっかりは Firefox の実装の問題なのでお手上げ。
position: fixed; でブラウザの上部または下部に固定してしまうってやり方はアリだと思いますが、また IE が邪魔するわけですよ。
結局のところ、使える場面があるのか無いのかはっきりしないです。やろうと思えば出来るけどクロスブラウザじゃないよ、って感じでしょうか。

余談ですが、リンクタイプの rel 属性の値 netx と prev は ブログのテンプレート内に入れて今回のようなナビゲーションとして使うと便利かもしれません。Movable Type のテンプレートタグを使って

<MTEntryNext><link rel="next" href="<$MTEntryPermalink$>" title="<$MTEntryTitle remove_html="1"$>" /></MTEntryNext>
<MTEntryPrevious><link rel="prev" href="<$MTEntryPermalink$>" title="<$MTEntryTitle remove_html="1"$>" /></MTEntryPrevious>

なんて書くといいかもしれません。(たぶんデフォルトのテンプレートにこれが記述されていると思います。さっぱりそんなの忘れ去ったので確認できませんが。)

さらに余談ですが、大元の記事であるパンくずリスト(Topic Path)のマークアップに関して、番号(順序)付きリストでマークアップするのがベターなのかと思います。あと番号なし(箇条書き)リストではちょっと意味が違うかなぁ、とも思うけど、入れ子にしていくのもアリだと思う。ただ、段落でマークアップするのを否定するわけじゃないし、それはそれで解釈として正しいはず。
仕様の方に話が飛ぶのもアレだけど、手元にある素材(要素)で料理(マークアップ)するのに、必要状況下でその素材(要素)が無い、もしくは当てはまらないとなったら何かしらで代替を用意するしかない。けどだからと言ってパンくずリストのための要素を用意(仕様策定)するのは本末転倒。だから今あるものでやるしかないのです。正解があるわけじゃないかもしれないけど(日本語がおかしい)、自分が正解だと思えるやり方でいいと思います。だから自分は番号付きリストでやる。それだけです。

追記 2007年2月9日 23:00

記述ミス修正

追記 2007年2月14日 10:51

head 要素の取り扱いについて加筆修正

通常、(X)HTML + CSS で構築されたサイトはモバイル環境(i モードや Ez web とか)でも CSS を切り離された状態で閲覧されるのは周知の事実。一部 CSS 対応してるけど、本当にちょっとだけだし、実装もインラインの style 属性とか head 内に style 要素を記述する方法などがあるが、結局のところ外部 CSS には全く対応しておらず、ちょっとどころかかなりゲンナリする。
ただ、もし CSS に対応すると言うことになることになったら、キャリア側は CSS メディアタイプを screen ではなく handheld として実装して欲しい。フルブラウザがメディアタイプ screen 準拠していることによって、こうした状況が発生しているのは事実だし、スマートではない。

ただ、PC で閲覧する Web サイトとモバイルで閲覧する Web サイトは同じにすべきなのかどうかとされる議論もある。運営する側からすればコスト的にも同一にした方が良いのは当然だし、本来であればそうあるべき。しかしモバイル端末がそれに至っていないのは、クローズドなモバイルサイトが往々にして確立され、それが”正”だと思われているユーザ側が脱却できない点にもある。
そうしたクローズドな世界とオープンな世界のギャップを埋めるのは難しいし、もし可能になるとしてももっと先になると思う。

で、じゃあ技術的に何とか埋める方法は無いかと模索してみたが、あくまで見た目上の話だけをすればある程度は互換性を持たせることができるとは思う。ただし Valid でなければスマートでもない。あくまで互換性重視と言う意味合いで語るのであれば、完全な物理マークアップしかない。

この結論に至った経緯として、一番の課題は「(X)HTML + CSS ではモバイル端末で色・レイアウトが表現できない」ことである。ユーザ側からすると、見栄えはもっとも印象に残り、そのサイトの良し悪しの判断材料としても用いられるのは見て取れる。もちろんユーザビリティの点も重要だ。個人的に必須だと思うのは EZ-GREEに見るケータイサービス構築の重要なポイントにあるショートカット機能。つまり accesskey 属性。コンテンツの遷移を0 ~ 9と # * キーで制御するのは必須だと思う。ページの上部等へのアンカーリンクも同様。

ちょっとユーザビリティに関して偏ってしまったので話を戻すと、モバイルサイトでは未だに marquee 要素が平然と存在する。我々からすると想像を絶するような世界なのがこの要素だけで分かると思う。それだけ見栄えが重要視されている。そんな中でいかにして PC とモバイルを共存させるかを考えると、実装上の問題から物理マークアップするしかないのは致し方ないと思う。物理マークアップするにはいくつか条件が必要になる。

  1. 文書型定義は HTML4.01 Trantisional(XHTML では非推奨要素は使用できない)
  2. 文字の色、大きさは font 要素を使用
  3. 行揃えは align 属性を使用
  4. テーブルレイアウトではなく、通常の CSS レイアウト
  5. PC で閲覧する場合は CSS で font 要素等のスタイルを消す
  6. 文書構造は通常のマークアップ

簡単まとめるとこのようになる。もちろんこれが正とは思わないし、スマートだとは思わない。ただ、現状を省みるとそうせざるを得ない場面があるのは確か。
半ば強制的にモバイルと兼用させると言う考え方も問題なのかもしれないが、あくまで一例としての話なので。

ちなみに最大の問題点は画像サイズとファイルサイズだが、解決方法は無いに等しいし、あるとしればそれこそ XML 文書で作成して XSLT で UserAgent ごとに変えるとか何とかごにょごにょもあるけど、結局コストがかかると言う問題に行き当たるから意味が無い。
あと CSS でスタイルを消すと言うのは

<p align="center"><font color="#ff0000" size="+1">ほげほげ</font></p>

<p><font color="#00ff00" size="-1">ほげほげ</font></p>

この HTML に対して

font[colo]
{
color: black;
}

font[size]
{
font-size: 100%;
}

と CSS で消せばよいのだが、問題は IE では意味が無いと言うこと。なのでもっと簡略的に書いてしまえば

font
{
color: black;
font-size: 100%;
}

としてしまえばよい。

最後にもう一度言っておきますが、これは間違いであることを承知で書いています。モバイル側が互換性を無視して独自拡張を続けていくことに対して、こちら側が歩み寄った場合の話なので、運用面やコスト面重視で考えるとこうするのがベストでもベターでもないけど、解釈としてはアリなんじゃないかと思うわけです。実践するかしないかは任せますが、Perl や PHP で UserAgent 振り分けて動的にページを生成させるとか、そんなことするくらいならこっちの方がまだマシ、と言うのが自分の考えです。

関連リンク

仕事の合間のエントリなので、思ったままのことを手短に書きます。

  • そもそも CSS でデザインするためには (X)HTML が分からなければ意味がない。
    • div 要素が必要以上に発生したり、直接テキストが入るのはいかがなものか(せめて p 要素で括って欲しい)
    • 同じような現象として空 div や br 要素を使って float プロパティによる回り込み解除をするとか。
    • 上記2つは物理マークアップと大差ない
  • W3C 信者や strict 厨になれとは言わないが、妥協すると言う風潮が広がることは後世にとってもよろしくない。
    • だけど W3C や WaSP の努力は認めるべき。
  • 「CSS でレイアウトすればリデザインが簡単」と言えるあなたを私は信じられない。
    • 今のデザインで固まってしまった (X)HTML 文書を改修せずに、デザイナから上がってきたデザインをその通りに表現できますか?
      • (X)HTML 文書の構造が決まっているのに、それを無視したデザインを上げてくるデザイナを信用できますか?
      • デザイナはマークアップを知らなければ良いと思っていますか?
        • そしてデザイナは (X)HTML を知ろうとしましたか?
          • そのデザイナから上がってきたデザインを可能な限り再現しようと努力しましたか?
    • 本気で (X)HTML 文書を改修せずにリデザインをするためには css Zen Garden のようにしなければ高い柔軟性はない。
  • (X)HTML 文書が妥当であるからこそ CSS レイアウトが可能であって、そうでなければただの見た目 CSS。
  • 「テーブルを使ってはならない」と思ってるあなたこそテーブルを使ってくださいお願いします。
  • 「(X)HTML < CSS」ではない。
    • 「CSS で表現しなければならない」 と疑心暗鬼にかかってるのは問題。
    • ブラウザの表示がおかしいのは、あなたが9割原因であることに気づいてください。
      • 残りの1割は文法上、妥当・非妥当に関わらずほとんど回避できます。
        • それでも回避できない場合は JavaScript やテーブルなどを使ってください。

最近やたら CSS 関連のエントリを見かけるのですが、内容としてどうかと思うのが立て続けにあったので。

関係ないですけど、「(X)HTML + CSS は万能薬ではない」ってどっかで見た気がするんですが、オリジナルがあったら申し訳ないです。中の人とか。

WWW WATCH にて XHTML、CSS を学ぶ時の 6つの間違いがエントリされてるのをはてなブックマーク経由で見たんですが、概ね(と言うか完全に)同意できます。まあ最後のはオチとしては面白いんですが、そんな人が「XHTML とはー CSS とはー」と声高に叫ぶとは思えませんがね。本当にそんな人に教わったもしくは教わっている人は不幸すぎます。この業界で 1,2 を争うほどの。
ちょっと個人的にいろいろ言ってみる。あくまで「オレはこう」みたいな。うぜー。

個人的な意見ですが、「Dreamweaver」 を買うお金があるなら、最初はそのお金で 「Fireworks」 を買った方がいいんじゃないかなと思います。いや、別に Fireworks じゃなくてもいいんですけどね。Web サイト制作を始めるにあたって最初に購入するべきソフトとしては、きちんとした画像編集ソフトの方をオススメしますよということです。

最初はテキストエディタで手打ちしろと。そのかわりテキストエディタはきちんとしたソフトを用意しましょう。(個人的には Win なら 「秀丸エディタ」 がオススメですが)

「最初からオーサリングツールを使わずにテキストエディタを使え」と言うのはちょっとハードル高いけど、多分これしか対処法と言うか、勉強法は無いのかなとは個人的にも思う。Dreamweaver もそうだけど、良くも悪くもオーサリングツールはレンダリングエンジンを乗せてるから、その「見た目」を”正”とする傾向は初心者にはある。(経験談)
あくまで HTML 文書を記述するだけならテキストエディタでよいし、それがビジュアライズとして機能する必要性はないので。

あと個人的にオススメしたいテキストエディタは Windows 標準装備のメモ帳。ez-HTML でもいいですけどね。

でも仕様書は英語だし、、という人にオススメの書籍を挙げるとすれば、XHTML 関連では神崎正英氏の 「ユニバーサルHTML/XHTML」、益子貴寛氏の 「Web 標準の教科書」、CSS 関連では 「セオリー・オブ・スタイルシート」 あたりがよろしいかと。

それでも W3C の仕様書は必ず目を通しておくべきものですよ。

あー、「Web 標準の教科書」はかなりハードルが高いなぁ。それ以外の書籍は読んだことないですが・・・。確かに「Web 標準の教科書」は良い。(X)HTML と CSS の仕様書をそのまま書籍化したって感じが実にいい。しかもそれなりに解説もされてるので、あと数年は使える本だと思う。
ただ、如何せん難しすぎる。別に益子氏が悪いとかじゃなくて、各仕様が複雑すぎて理解できないと思う。それこそ HTML に関して何も前知識が無い人からしたら。(テーブルレイアウトだけしかできないマークアップエンジニアも同類です)ただまあ、これ以上ないってくらいの重要資料(すでに書籍扱いではない)なので、HTML と言う文書構造が多少なりとも分かったら読むべき本だと思う。

そして自分のオススメは「詳解 HTML & XHTML & CSS 辞典」です。(X)HTML の各要素や CSS のプロパティ別に対応ブラウザが掲載されているのと、DTD での要素定義が一覧で見られるのは重要。
あとこれは Web に関わる人全てに言えるけど、「ブラウザのしくみ」は読んでおくべきだと思う。Web の全てが載ってる(たぶん)ので、デザイナやマークアップエンジニア、プログラマなどの技術者もそうだし、ディレクタやマネジメントなどの管理職(と言ってしまっていいのか分からんけど)も知っておくことは多い。

これ、意外に理解していない人がいるのですが、XHTML がすべての基本です。CSS は XHTML で文書構造を定義されたものに対してスタイル (見た目) を定義するもので、どちらが主で、どちらが従かは明白です。

自分がこれに当たります。昔の話ですが。HTML はそこそこ知ってて、そこから CSS レイアウトに入ってしまったので、ちょっと遠回りしてしまった感はある。だから 2 年もかかったんですけどね。それがだいたい 6 年前。
でも当時からしてみたら、今は CSS に関するノウハウはすごい多いし、この環境で「CSS 勉強するの難しい」とか言ってるのは正直甘いと思う。関連書籍もたくさんあるし、ぐぐれば腐るほど出てくるし、それでレベルアップできないのはただ単に避けてるだけとしか思えない。なんだかなぁ。

とまあ、好き勝手書きましたが、最後にちょっとだけ。
こうした XHTML+CSS に関するエントリを見て「よし、自分もやってみよう」と思うのは大いに歓迎です。ただ 1 つだけ誤解して欲しくないのは、全てを CSS で表現しようと思わないことです。
確かに CSS で全ての表現を可能にします。だからと言って、無理に文書構造を当て、CSS で装飾するのはよろしくないと思います。
具体的には

  • table 要素を使ってはいけない
    • (似たような意味で)代替として定義リストを使用する
  • クリッカブルマップを敬遠する
  • 無闇に画像置換をする
    • 同様に img 要素を敬遠する
  • 必ず XHTML 文書でマークアップしなければならない

と言った誤解はして欲しくないです。そしてこれは (X)HTML+CSS を勉強する過程で恐らく必ずと言っていいほど起こる問題です。CSS で表現すべきところと (X)HTML 文書で実現すべきところの区分けは曖昧ではありますが、全部を全部 CSS 任せと言うのはどうなのかな、と思うので。(mixiCSS テクニックのコミュニティを見てるとそう思わざるを得ないので)

z-index のあれこれ

|

仕事で z-index プロパティを使う機会があったんですが、なんだか上手くいかなかった。いろいろ試行錯誤してようやく思い通りの動きをしてくれたので、ここに z-index プロパティの仕様を含めたまとめを書いてみる。

まずは z-index プロパティの仕様から。引用するのが面倒なので仕様書をそのまま見てください。

簡単に仕様をまとめると、

  • position プロパティで [fixed] [absolute] [relative] のいずれかの値を持つ要素(つまり [static] 以外の値)にのみ適用される
  • z-index プロパティの [auto] はボックスの重なり順が親要素と同じになる
  • [整数] は値が大きいほど値が小さいボックスよりも前面になり、小さいほど大きい値よりも背面に配置される
  • [整数] はマイナスの値も指定できる

以上のようになる。
これを踏まえたうえで以下のサンプルを作成してみる。

HTML ソース

<div id="zindex2">
z-index の値が 2<br />
要素の順番は 1
</div>

<div id="zindex1">
z-index の値が 1<br />
要素の順番は 2
</div>

<div id="zindex0">
z-index の値が 0<br />
要素の順番は 3
</div>

CSS ソース

div#zindex0 {
position: absolute;
top: 50px;
left: 180px;
z-index: 0;
width: 200px;
height: 200px;
background: yellow;
}

div#zindex1 {
position: absolute;
top: 80px;
left: 210px;
z-index: 1;
width: 200px;
height: 200px;
background: pink;
}

div#zindex2 {
position: absolute;
top: 110px;
left: 240px;
z-index: 2;
width: 200px;
height: 200px;
background: lime;
}

想定できる結果です。z-index プロパティの値が大きくなるほど前面に配置される。仕様通りの結果です。
では次にこうしたらどうなるだろうか。

HTML ソース

<div id="zindex2">
z-index の値が 2<br />
要素の順番は 1

<div id="zindex1">
z-index の値が 1<br />
要素の順番は 2

<div id="zindex0">
z-index の値が 0<br />
要素の順番は 3

</div>

</div>

</div>

つまり各要素を入れ子にしてしまう場合。そうすると先ほどとは表示結果が違うことが分かる。これは単純な話で、position プロパティが [absolute] の時、基点がサンプル 1 とサンプル 2 では違うからだ。

position CSS辞典 - position - 要素の配置方式を指定する

absolute
包含ブロック(祖先要素のうち、もっとも近い祖先の要素にあたるブロック要素の内容領域)の各辺を基準に配置され、"top, bottom, left, right" の各プロパティで指定する絶対的な位置指定となる(祖先要素に位置指定されている要素がなければ、初期包含ブロックを基準とする)。

"absolute" の説明を補足しておくと、たとえば、一番最初の包含ブロックである初期包含ブロックは、html要素の各辺が基準になるので、スクロール分も含めてページ全体が基準になります。つまり、topプロパティ・leftプロパティはページの左上が原点に、bottomプロパティ・rightプロパティはページの右下が原点となります。html要素に対して、widthプロパティ, heightプロパティを指定することで、初期包含ブロックの横幅・高さを指定することもできます。

上記の通り、id="zindex2" は最上位の基準となる先祖要素が無いため、初期包含ブロック(html 要素)を基準に配置されている。
id="zindex1" は id="zindex2" に包含されているため、id="zindex2" を基準として配置し、同様に id="zindex0" は id="zindex1" を基準に配置されている。

しかし問題はここではない。id="zindex1" と id="zindex0" が重なり合っている点が重要である。
通常であれば id="zindex0" の上に id="zindex1" が重なるはずだが、実際は逆に id="zindex1" の上に id="zindex0" が重なっている。

要素を入れ子にしたら z-index プロパティの挙動がおかしくなったと考えられる。しかしこれは恐らく仕様通りの結果のはずです。
z-index プロパティの仕様は以下のようになっています。

'z-index'
値:  auto | <integer> | inherit
初期値:   auto
適用対象:   位置決め要素
継承:   しない
パーセント値:   N/A
メディア:  視覚メディア

仕様では z-index プロパティは継承されません。ですので、子孫要素が新たな z-index プロパティを指定しても、それが親要素を継承していないため、例え値が 0 であったとしても親要素の背面に配置されることはないのです。
つまりここでは、id="zindex1" の値が 10 であったとしても、子要素の id="zindex0" からすると値は id="zindex1" は 0 に見えるのです。

なので、対応策としては id="zindex0" の値をマイナス値にしてしまえば解決します。

div#zindex0 {
position: absolute;
top: 50px;
left: 180px;
z-index: -1;
width: 200px;
height: 200px;
background: yellow;
}

しかし何故か IE6 と Opera9 ではダメなんですが・・・仕事でやった時は上手くいったんですけどね。ちょっと事情が違うみたいなので、今度また再検証してみます。

以下独り言(何
なんとなく position プロパティが怪しい感じ。仕事でやった時は[absolute] と [relative] の組み合わせだったから、なんかその辺が絡んでるのかも。
と思って試してみたが、やっぱ違うっぽい。そもそもの考え方が違うのかなぁ。ほぼ同じような構成で再度検証してみるしかないかも。

このブログも当然のように CSS で完全レイアウトされてるわけですが、やはり問題は外部 CSS ファイルの管理方法。管理もそうだけど、そもそもの設計方法が重要ってお話。

早水悠登氏のエントリを見て、「あー、気持ちは分かるなぁ。これって設計上の問題でも発生するんだよなぁ」とうにょうにょ思ってたんですが、じゃあ実際にどーすりゃいいのよ、ってなるとこれがまた難しい。

とりあえずこの double-team.org の CSS を例に出してみます。
まずは外部 CSS ファイルの構成から。

  • import.css(以下の CSS ファイルを読み込むための CSS ファイル)
    • elements.css(各要素を再定義&リセット用 CSS ファイル)
    • layout.css(大枠のレイアウトを定義した CSS ファイル)
    • header.css(ヘッダ部分の CSS ファイル)
    • footer.css(フッタ部分の CSS ファイル)
    • navigation.css(ナビゲーション部分の CSS ファイル)
    • contents.css(MT とは関連のないコンテンツ用の CSS ファイル)
    • entry.css(エントリ内に対する CSS ファイル)
    • entry_menu.css(エントリの日付、タイトル、タグ等の装飾用 CSS ファイル)
    • search.css( input 型とタグ型検索用 CSS ファイル)
    • sidebar.css(右側にあるボックス用 CSS ファイル)

他にも Windows 版 IE6 用の CSS ファイルがあったりしますが、そこは割愛。とりあえずこんな感じです。
こう見ると分かると思いますが、モジュールのような考え方でヘッダはこれ、エントリはこれと言った感じで、全てファイルを分けています。この考え方は昔からありましたが、最近のライフハック的な流れから定着してきました。7月にあったWeb標準の日長谷川 恭久さんロクナナの中村 享介さんと河内 正紀さんが各セッションでこれについてお話をされてました。(各セッションの内容は 「Web標準の日」のサイトにて公開されています。

関係ないですが、CSS の記述順はかなり適当です。 hail2u.net さんや 2xup.org さんのように、何かしらの規則性がある書き方は今のところなってないです。なんとなく外枠( display プロパティやボックスモデル関連)を先に記述するようには努めていますが、フォントやテキストまで下がると結構曖昧だったりします。

話を戻します。こうやってレイアウトの構造によって CSS ファイルを分けているわけですが、完全にスマートで綺麗と思われる内容には仕上がりません。(自分の場合はですが ← 言い訳)
それはなぜか。これだけ CSS ファイルを分散化しても、各 CSS ファイルにおいて共通項が存在してしまうことです。

よく分からないですね。もっと具体例を出します。
例えば各エントリのタイトル部分(本エントリでは「CSS の管理ってどうしたらいい?(主に設計に関して)」がこれに該当)は XHTML 上では h2 要素でマークアップされています。これのスタイルが記述されている CSS ファイルは entry_menu.css です。
今度は About ページの部分を見てみます。ここのタイトルは h3 要素でマークアップされています。ですが、文字サイズや色は同じです。ですがこのページはエントリされたものではありません。ただの静的 HTML 文書です。なので、この部分のスタイルは contents.css ファイルに記述されます。

しかしこれだと同一内容のスタイルが entry_menu.css と contents.css に記述されることになります。これでは意味がありません。例えばこのブログをリデザインをしようとした時、 h2 要素のスタイルを変更したとしても h3 要素のスタイルが変わらなくなってしまいます。これは非常にありえることです。サイトを設計した私でさえ見落とす可能性があるでしょう。

もちろんこうした共通部分はセレクタの複数指定で回避できます。しかしどちらか一方の CSS ファイルに記述しなければならないのですが、それがどちらに書くかが問題です。
これを解消するために別の CSS ファイル(例えば heading.css )を作成してそこに記述するのもアリですが、そうすると今度はそれに応じて他の部分も分割・統合しなければならなくなり、 CSS ファイルが肥大化していきます。もちろん細分化していけば保守管理が楽になると言う人もいるでしょうが、一般的に言えば 10 も 20 も CSS ファイルが作られていくと保守管理に支障をきたすはずです。

組織的に運営していく過程では、これはもう何かしらのガイドラインを設けれなければならないです。個人であれば自分の主義主張を通すので良いかと思いますが、やはり製作者として何かしら一般共通認識がなければならないと思います。
どうしたら正しいのかは今のところ私にも分かりません。ですが、ある一定の基準を設けなければただのカオスでしかないので、自身で独り善がりにならない程度のポリシーを持つべきなのかと思います(抽象的ですが)。

ブックマークを漁って気まぐれで Interactive CSS Box Model Demo を見ようとしたら404を返されて「うあーこれってもう過去の遺産としても存在を認めてくれないんですがー」と叫んだ。

ボックスモデルを図解した良い資料だったんだけどなぁ。

Internet Archive で探したらあったことはあったけど、重要なボックスモデルを再現した Flash まで取得してるわけじゃないから意味ナス。