わたしが信じた、そして来ることはなかった未来
XHTML 2.0という規格がありました。W3Cによって策定されワーキングドラフト (草案) まで公開されていた規格です。わたしはこの規格に多大なる期待と希望、そして未来を感じていました。ですかこの規格はウェブブラウザを開発している各団体や企業からは半ば無視され、仕様通りの実装はされたアプリケーションがまったく存在しませんでした。そうしてそれらの団体や企業によって新たに立ち上げられた団体であるWHATWGにより策定され、実装もある程度なされていたHTML 5はのちにW3Cの規格として採用され、そちらを優先するということでXHTML 2.0は2009年に廃案となってしまいました。
セクショニング要素という概念が存在せずdiv要素で代替しなければならず、またヘッドライン要素もh1要素からh6要素までとしばりがあった従来のHTMLやそれにXMLの概念を付随させ後方互換を維持しつつ拡張させたXHTMLでは拡張性や移植性に不安がありました。そうしたものから発展させ、過去のものを遺産であると切り捨て新たにつくられたものがXHTML 2.0である、というのがわたしの認識です。今にしておもえばそうしたかんがえが敬遠されなかなか実装するウェブブラウザが増えなかったのではないかとおもうのですが、XHTML文書ないしはHTML文書を作成し、そしてウェブブラウザはつかうだけのわたしには、ただただ未来のあるべき言語であるとしかおもえていませんでした。
新たに生みだされたHTML 5ではXHTML 2.0にあったsection要素も仕様に入れられ、そしてその要素の下に置けるヘッドライン要素はh1要素だけにしばることが可能になりました。h1要素と「1」とあるもののそのヘッドラインのレベルはsection要素の入れ子具合によって決められるようになり、XHTML 2.0のsection要素とh要素の関係とほとんどいっしょになりました。次に示すようなXHTML 2.0の仕様と現状のHTML 5の仕様に関する不満はありますが、妥協案としては とても優秀な言語であるとおもっています。
セクショニング要素がsection要素だけではなくarticle要素、aside要素、nav要素と複数種類 設けられていて煩雑
blockcode要素やl要素がなく、またp要素がul要素などのブロックレベル要素を子として持てない
要素が増えたというのに名前空間が今までのXHTMLと同じ http://www.w3.org/1999/xhtml のまま
信じていた未来がなくなり現実を見ながら生きることになった今、わたしにできることは実装されていない仕様に関して期待することは止めようということだけです。WebSocketやIndexedDBもそろそろ仕様も実装も固まってきた頃合いであろうとおもうので、今ようやく手を出そうという気持になっております。
XML文書に色づけをほどこすXSLTスタイルシートを書きました
任意のXML文書に色づけをほどこした上でHTML文書に変換させるXSLTスタイルシート を書きました。XML文書ならなんでも良いので自分自身に色をつけさせることも可能です。
Markdownの記法をおぼえずに済むたった一つの方法
MarkdownやReSTだとかの記法をおぼえるのに時間を割くよりは、すでにおぼえているであろうHTMLで文書を書いた方が時間の浪費を抑えられます。そうしましょう。どのプログラミング言語でもHTMLのパースをおこなえるライブラリーは用意されているでしょうし、その方がはるかに都合がよろしいかとおもいます。
type属性にfileがはいったinput要素のウェブブラウザ上での表示を細工する
Google Chromeでしか動作していませんでした。Operaでは非表示 (display: none) になっているinput要素をlabel要素から開くことができず、またFirefoxではそもそもtype属性の値がfileとなっているinput要素をlabel要素から開くことができませんでした。Operaの場合はネガティブマージン等をつかい見えないようにすることでなんとか対処できますが、Firefoxの場合は根本的に別の手段を取らなければどうにもなりません。
type属性の値がfileになっているinput要素の表示はウェブブラウザごとによってことなります。またCSSで装飾することもほかのinput要素とはちがい自由さに欠けます。なのでウェブページの表示とあわせるためには、input要素自体はinput[type="file"] { display: none }として非表示にしておき、ほかの手段をもって当該要素を開けるようにして、そちらで表示を制御すれば良いでしょう。
HTML <form>
<p><input type="file" id="upload-files" required><label for="upload-files">SELECT FILES</label></p>
</form>
CSS fieldset { border: none }
#upload-files { display: none }
label { color: blue; text-decoration: underline }
#upload-files:valid + label { color: red }
#upload-files:valid + label::after {
content: ' (ok)';
font-size: .8em;
}
demo
「重い」ということ以上のAdobe Flashの問題点
Adobe Flashを否定する言説の中で最も多く見られるものは「重い」というものです。たしかにそれは非力な環境しか用意できないかたにはつらいものでしょう。ですが「重さ」という点であればJavaScriptも書きかたによってはAdobe Flashと同様に重くなってしまいますし、重く表示されるAdobe Flashと同等のことをJavaScriptだけでさせようとおもえば、むしろAdobe Flashよりも重くなってしまうのではないでしょうか。Adobe Flashにはそれ以上に問題とすべきものがあるとわたしはおもっています。それは「代替手段が用意しづらい」ということです。
JavaScriptであれば、もし何かの都合でJavaScriptが実行されなかったとしても表示されるのは素のHTMLであり情報を得るのになんら不足はありません。ですがAdobe Flashはちがいます。代替手段を用意することは不可能ではありませんが、一からまったく別のものを用意しなければなりません。その手間を煩ってか多くのかたは適切な代替手段を供せず、Adobe Flashを動作させられる環境の入手方法を示すのみです。事情がありそうした環境をあえて無効にしている、もしくは無効にせざるを得ない環境のことをまったく考慮しているとはおもえません。JavaScriptを使用していつつもJavaScriptが無効な環境にたいして適切な代替手段が用意していないウェブページも多くあります。ですがそれらのウェブページでも対応しようとおもえばAdobe Flashに依存しきってしまっているウェブページよりは、代替手段を用意するのが簡単です。
もちろん先にも申しました通りAdobe Flashでも代替手段を用意することは可能です。ウェブページをおつくりになるかたはそうしたこともしっかりとかんがえて作成するよう心がけてもらいたいとわたしはおもっています。