最近書かれた記事5件分を表示します。
更新状況をRSS 1.0形式でご覧になれます。
レンダリングエンジンとレイアウトエンジン、どちらがよく使われる語なのかふと気になって調べることにした。少し前に海外の記事でlayout engineと見た影響である。
Googleで調べたところ、日本語・英語ともにレンダリングエンジン(rendering engine)が優勢であった。しかしながら、レンダリングエンジンとは何もブラウザの描画機構のみを指す語ではないため、この結果は参考にしかならない。
次にWikipediaを頼ったところ、日本語と英語で差異が見られた。日本語ではレンダリングエンジン、英語ではlayout engineとして登録されている。Layout engine(Wikipedia)にはブラウザ関連のデータが含まれており、勝手に判断するのであれば、レイアウトエンジンと表記すればまず間違いないようだ。無論、両者の意味するところは同じであり、実際にはどちらで表記しようと問題はない。
本題から逸れるが、Comparison of layout engines (CSS)(Wikipedia)などはとても参考になる。
無料版の広告を完全に外したOpera 8.50がリリースされている。言葉は重なるが、Operaは完全無料化となった。
Opera 8.50 for Windows Changelogによると、広告廃止の他にセキュリティ関連の更新が含まれているようだ。日本語のサポートといった種々の情報はA blog? with Σαιτω(2005-09-20)が詳しい。
さらに、Opera 8.50 と広告廃止と Merlin(Note @ Temporary-Depot)によると、XSLTやCSS 3 selectorsの実装が予定されているという。XSLTについては、確か、「ブラウザの仕事ではない」といった理由で実装しないことが明言されていた。そのため、Merlinには期待がかかる。
body要素型の直下にはインライン要素を記述できないため、img要素は何らかのブロック要素に放り込んでやる必要がある。これにはdl要素型が適任かと考えたものの、dt要素とdd要素のどちらに含めるべきか迷っていた。
ここでdiv要素型(ブロック要素)の直下にimg要素を記述するという選択肢はない。フラグメント(id属性値による参照)などにおいて矛盾が生じるのは事実だが、div要素がなくてもその文書がHTMLとしてvalidなものとなつてゐるやうに記述しておくべきでせう。
という考え方に同意しているからだ。
dl要素型によるimg要素のマークアップはしばらく前から採り入れている。次のようなものだ。
<dl>
<dt><img alt="" /></dt>
<dd>補足説明</dd>
</dl>
img要素には何らかの補足説明が必要だろうと考え、dt要素として扱っていた。だが、定義型リストの表題たるdt要素に画像を置くのはどうだろうか。alt属性値による代替テクストはあるにせよ、あらゆる環境において必ずしも表示できないことを考慮すると、やはりdt要素としては不向きであるように思える。
考慮の末、img要素はdd要素に含めることとなった。
<dl>
<dt>表題</dt>
<dd><img alt="" /></dd>
</dl>
<p>補足説明</p>
補足説明は表題のものではないため、dd要素としてマークアップできない。こちらの欠点は、表題と代替テクストたるalt属性値をどう決めるかである。両者は似通ってしまうことが多く、なかなか難しい。
後者は冗長なマークアップであるように思えてきた。代替テクストをきちんと記述できれば、前者でも問題ないだろうか。
そもそも、本当にimg要素として画像を呼び出す必要があるのか、それをまず検討しなければならない。画像へのリンクだけで十分なものもあるため、もう一度検討してみたい。
2005-09-15 21:15追記
「話のさわりだけご紹介いたします。」とは聞き慣れた、あるいは見慣れた表現であろう。だが、このさわりには最初の部分といった意味はない。
もはやよく知られた話であろうが、意味は要点、あるいは聞きどころ、見どころとするのが本来である。しかしながら、誤用が定着してしまう例も数多くあると耳にした。これには檄を飛ばすがよく知られている。
誤用と本来の意味を知っていれば聞く分には問題ないだろうが、世代の離れた方と会話をする際には十分に注意したいものだ。意味の他には、「老骨に鞭打って……」といった他人に使ってはならない(自分が謙遜して使うのみ)言葉にも注意したい。
「ホームページ」に興味を持って早6年になろうか。長く問題であったクロスブラウザはPHPを用いることで解決し、現状では納得のいくマークアップができている。細かな工夫の余地はまだあれど、XHTML+PHPによるWebサイトの構築という観点では一段落したようだ。Webサイトの構造、あるいはXHTML、PHPについてこの機会に振り返ってみたい。
XHTMLにはいくつかの文書型が存在し、それぞれに特徴がある。
過渡期のXHTMLと解せば分かりやすい。非推奨ではあるが、font要素型などを用いることができる。
1.0 Transitionalに加え、フレームを使用できる。
厳格というよりはシンプルなXHTML。見栄えはCSSで制御するため、直接見栄えを指定するfont要素型などは使えない。
モジュール化されたXHTML。ユーザはDTDを任意に拡張することができる(extensible)ため、XHTML 1.0で非推奨だった要素型も使用可能ではある。application/xhtml+xmlとして認識させるべき。
XHTML 1.0は用途に応じて使い分ければよい。XHTMLの利点を活かすならapplication/xhtml+xmlとして認識させるべきだが、XHTML 1.0に限ってはtext/htmlとして認識させても構わないことになっている。
他方、XHTML 1.1は、XMLパーサ(構文解析を行うプログラム)に通すことを前提に規格化されたものであるため、application/xhtml+xmlとして認識させなければ意味をなさない。text/htmlとして認識させるべきではない。
だが、application/xhtml+xmlを正しく処理できないブラウザ(MSIE; ダウンロードのダイアログが出る)があるため、XHTML 1.0/1.1ともに、実際にはtext/htmlとせざるをえない。
この問題は、PHPを用いることである程度は解決できる。XHTML文書を出力する以前(XML宣言あるいはDOCTYPE宣言以前)に、以下の処理を加えてやればよい。
if (ereg("application/xhtml\+xml", $_SERVER['HTTP_ACCEPT'])) {
header("content-type: application/xhtml+xml; charset=UTF-8");
} else {
header ("content-type: text/html; charset=UTF-8");
}
HTTPリクエストヘッダのHTTP_ACCEPTフィールドにapplication/xhtml+xmlが含まれていればそれを返し、含まれていなければtext/htmlを返す。これでapplication/xhtml+xmlを認識できるブラウザ(厳密にはUser Agent)には、XHTML文書を本来の形で送信できる。
これを応用してXHTML 1.0/1.1の切り替えを行うことも可能ではあるが、私にはそうまでしてXHTML 1.1を用いる理由が見つからない。XHTML 1.0よりXHTML 1.1が優れているわけでもなし、無理に用いる必要などないだろう。
head要素の共有、クローラ(検索エンジンの巡回ロボット)に対してメールアドレスを出力しない、ブラウザを判別して補正スタイルシートを出力するなど、様々な使い方ができる。
XHTMLのみならずCSSファイルにまで組み込むことができるため、CSSファイルの中で補正スタイルシートの処理を行ってもよい。
<?php
// MSIEかどうか判別
$msie = 0;
$useragent = getenv("HTTP_USER_AGENT");
if (ereg("Mozilla/4.0 \(compatible; MSIE", $useragent)) {
$msie = 1;
}
// CSSファイルのContent-Typeを送信
header ("content-type: text/css; charset=UTF-8");
?>
@charset "UTF-8";
<?php
// MSIEなら補正スタイルシートを読み込む
if ($msie == 1) {
echo '@import "msie.css";'."\n";
}
?>
@charsetは先頭に位置する必要があるため、PHPのコードは分割しなければならない。この処理はhead要素内で行っても同じ結果になるが、XSLTを通す場合はCSSファイル中で処理してやるとよい。その方が効率的だと思う。
XHTML+PHPに限界を感じたわけではないが、いずれはXML+XSLT+PHPで構築したいと考えている。XSLTには以前から興味があり、先日、サーバでSablotron(XSLTプロセッサ)が利用できると分かったためだ。サーバサイドでXSLTを用いてXMLデータをXHTMLに変換できるのであれば、User AgentがXSLTプロセッサを積んでいなくとも問題はない。