Undefined Database Configuration B地区ex｜お勉強：XHTML1.0→(X)HTML5移行メモ


exB - extreme B-AREA -

多くの常連が無駄死にで無かったことの証の為に・・・ 再び一陣の先頭を守る為に！ 正門よ！私は帰ってきた！！

about | bbs | Home

お勉強

ウェブ制作

コーディング

プログラミング

サーバ管理

大人の時間

ウェブ制作 - XHTML1.0→(X)HTML5移行メモ

最近のそれっぽいページにするにはXHTML1のままではもはや限界、と悟ったお話。

初稿：2013-01-22

これまでの経緯

妄信していたXHTMLとまるで逆な方向性ゆえ、個人的にネガティブなイメージしかなかったHTML5であるが、それはvideoエレメントのｇｄｇｄで決定的になった。このへんが決着するまではB地区でのHTML5導入はまずないかと。そんなわけで、俺のアンチHTML5は神崎大先生のHTML5はモジュール化しないの？に集約される。一部のゴリ押しとイメージ操作で持ち上げられたHTML5なんて大嫌いだ（Flashを拒否したiPhoneとiPadのためにオンブラウザでのマルチメディア実装手段として持ち上げた、というのもどーも気に入らん）。がもしIT業界に居続けたら、きっと「大嫌い」では済まされなかったのだろうな。

そんなわけで、B地区exとしてはXHTML5への移行のみ模索していた。ところがぎっちょん。

現状について

きっかけは、ツイートをページに埋め込むのに、見た目の問題で公式のコードを使おうかな、と思ったこと。ついでに構ってボタンツイートボタンもつけてみようかな、と。実装自体は簡単だったけど、やはりXHTML1.0では未定義な要素や属性が使われていて、W3Cのチェッカーで怒られたわけよ。

同じようなケースは今後ますます増えるだろうし、何しろ俺の本命だったXHTML2.0がW3C勧告に至ることなく糸冬 了 してしまった。策定の経緯は好きになれなかったHTML5だけどXML文書として扱うことも考慮されてたので、重い腰を上げる季節がやってきたのね。どうせXHTMLったって今までも別にセマンティックな使い方してこなかったんだからもういいだろ感はあるので、そろそろ移行してもいいお年頃になりましたとさ。

参考：2013年1月22日の屁理屈

そんなわけで、現状について軽く触れておく。

  • DTDはXHTML1.0 Strict、CSSは2.1。
  • コーディングはエディタ手打ち。
  • ヘッダ周りはTITLE属性除いてほぼすべて共通。
  • メニューまわりなど、メインのコンテンツ以外の部分はPHPでincludeしてる。
  • タイトルのサイト名などの共通部分は変数で埋め込んでるので気分で名前変えても安心（記事内に出てくるものは直打ち）。
  • せっかくなのでXHTMLは維持したい。
  • できれば屁理屈をなんとかしたい。

屁理屈をなんとかしたい、というのは、記事リンクがid属性に頼りっきりになってることもあるのだが、画像を全部/monologue/images/に放り込んでるので、すでに5000ファイル以上になってるのが最大の理由。

ファイル/ディレクトリ数の上限は、Windows系ではNTFSについては制限なし、FAT16/32で65,534となっている（8.3形式、Long File Nameの場合エイリアス毎にエントリーが必要となるのでもっと少なくなるらしい）。Linux（ext3）の場合32,768（トータルのファイル数はinodeにも依存）。MacOS（HFS+）は約21億。

B地区開始して5年半で5000ファイルであるからまだまだ余裕はあるのだが、いかんせん見通しが悪すぎる。せめて1年くらいで分割できるよう（上限に怯えずに更新できるよう、ともいう）何か考えねばなるまい。ただこれは過去記事に大きく影響する上、どうせなら月別ではなく日別も視野に入れたいので3日間ですぐできる話ではない。将来的な方向性としておく。

2013-09-09追記

inode云々以前にアダルトが規約違反だったので（マジで気づかなかった）引っ越さざるを得ないんだけど、調べたらぜんぜん平気だったくさい。

# df -h -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/simfs              3.8M    105K    3.7M    3% /
none                    256K     109    256K    1% /dev
#

inode消費はわずか3％。カゴヤのVPSの仮想化はOpenVZなんだけど、恐らくホストOSのファイルシステムはext4、ディレクトリあたりのサブディレクトリのエントリー上限は64,000個だから余裕のよっちゃんだったようだ。でもFTPなんかでディレクトリ参照すると、ファイルリストだけで1MB近いのはやっぱ困るｗ 次の環境ではそのへんも気をつけてサイト設計したい（ミッションクリティカルな運用はしないので、別にOpenVZでもいいよ。

それはさておき、極力Strictなコーディングを心がけているので、仕様の違いさえしっかり理解できれば他のDTDへの移行はそれほど難しくないとみている。ぶっちゃけ変更箇所をルート以下にGREPで一発置換かければ済むんじゃないかと。

XHTML1.0とHTML5のコーディング上の違い

恐らく使用できる要素や属性はHTML5のほうが広いと思われる。“タグが使えなくなるかどうか”はあまり神経質にならなくてもいいんじゃないかと（用途・機能の変更はあるだろうが）。具体的には、DOCTYPE宣言やHEADの子要素の違いをきっちり把握すればスンナリ移行できるのでは。HTML5 のW3C日本語訳を読むのはちょっと後にして、ひとまず概要だけでも知っておこうとググってみた。

参考：ゼロからはじめるHTML5でのサイト制作

うーむ。Lint的にはおｋが出ても、文書の構造化という大前提を考えるとまんま移行というのはよろしくなさそうだな。移行段階をいくつかに分けるしかないかもしれん。

  1. DTDやHEAD要素の子要素など、基本的な文法の差異
  2. HTML5における構造化に影響する要素の把握
  3. HTML5におけるその他の要素の把握
  4. 既存ファイルのうち機能変更のある要素や属性の把握
  5. 既存ファイルの修正箇所の把握

1だけなら3日で確実に収まるが、3は後日でいいとして2と4も含めるとなるとちょっと微妙か？これにCSS3との差異も入ってくるんだよな。あとひょっとしたら、鯖側でMIME-Typeあたりいぢらないといけないかもね。さらに5についてはXHTML化しようとすると、仕様だけでは片付かない問題をはらんでいる。

XHTML5での実装上の問題

実際には仕様の差異だけでなくいくつか壁があるようだ。

  • XHTMLは外部DTDを参照しないので、基本の5つ（&<、&>、&&、&"、&'）以外の追加の実体参照を指定できない。
  • XML宣言の省略はできない。これを解釈できないブラウザが存在する。
  • XHTML5ではContent-Typeにtext/htmlが使えない。application/xhtml+xmlまたはapplication/xml。これを解釈できないブラウザが存在する。
  • XHTML5文書の拡張子は.xhtml or .xht。これを解釈できないブラウザが存在する。

追加の実体参照ほとんど使ってないのでここはさしたる影響はないと思うんだけど、残りは俺のコーディングの問題じゃないからなあ。特にContent-TypeはXHTML5とHTML5の決定的な違いがそこである以上、text/htmlはどうあっても使えないようだ。またソース先頭でブラウザ分岐が必要になるんかね。

結局IEのせいかよっ！！！！！

なんにせよ、ここで挫折してしまうとB地区exがexでなくなってしまうわけ。あれ、それだけ？

第一段階：DOCTYPE宣言とHEAD要素まわりの変更

まずはXML宣言、DOCTYPE宣言、HEAD要素のMETA関連だけに絞ってXHTML5化してみたのだが･･･。まず予想以上にいろんなところで'を多用していた。顔文字がやたら多いｗ 単純に「'」を置換するわけにもいかないし、整形式でこんなに躓くとは思いもよらず。他にもパースエラー連発で正直どうにもならない。眠くなってきたこともあって、ひとまずXHTML5への移行は見送ることにした。もっと集中力あるときじゃないと無理だわ。

そんなわけで、HTML5で妥協。まずはDOCTYPE宣言とHEAD要素まわりの変更でどこまでいけるのか試してみることにした。これが現行コード。

<?xml version="1.0" encoding="UTF-8"?> 1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">　2
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">　3
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />　4
<meta http-equiv="content-style-type" content="text/css" /> 　5
<meta http-equiv="content-script-type" content="text/javascript" />　6
<meta name="description" content="天安門" />
<meta name="keywords" content="天安門" />
<meta name="Author" content="ギガ男爵" />
<meta name="Distribution" content="Global" />　7
<meta name="Rating" content="adult" />
<meta name="viewport" content="width=800" />
<link rel="stylesheet" type="text/css" href="/css/common.css" media="screen" />
<link rev="made" href="mailto:baron@b-area.org" />　8
<link rel="CONTENTS" href="/home.html" />
<script src="/js/tweet_button.js" type="text/javascript"></script>
<title>ギガB地区ex - 2013年1月な屁理屈</title>
</head>

修正が必要なのは強調の箇所。このうち1、5、6、7、8は不要もしくは未定義なので削除。W3Cチェッカーで怒られたから間違いない。2、3、4を次のように変更した。

ちなみにkeywordsとかの天安門は中国除け（こうしておくと当局ご自慢の金盾により勝手にブロックしてくれる、という噂）。

<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8" />
<meta name="description" content="天安門" />
<meta name="keywords" content="天安門" />
<meta name="Author" content="ギガ男爵" />
<meta name="Rating" content="adult" />
<meta name="generator" content="EmEditor10">
<meta name="viewport" content="width=800" />
<link rel="stylesheet" type="text/css" href="/css/common.css" media="screen" />
<link rel="CONTENTS" href="/home.html" />
<script src="/js/tweet_button.js" type="text/javascript"></script>
<title>ギガB地区ex - 2013年1月な屁理屈</title>
</head>

その結果がこちら。

XHTML5化された2013年1月の屁理屈 / W3C Markup Validatorの結果

一見問題ないように思えるな。W3Cチェッカー通すと9件のwarningが出てるけど、すべて「BLOCKQUOTE要素のCITE属性はまだブラウザ未対応だよ」なので特に問題はなさそう。んまあMETA要素がこれだけでいいのかわからんけど、暫定移行としてはひとまずおｋとしよう。次のステップに移る。

第二段階：HTML5における構造化に影響する要素の把握

※書き始めてるけどちゃんと理解するのには時間かかりそうなので何度も書き直すと思う。

まず要素の分類をみると、こんな感じらしい。

  • メタデータ・コンテンツ（Metadata content）
  • フロー・コンテンツ（Flow content）
  • セクショニング・コンテンツ（Sectioning content）
  • ヘッディング・コンテンツ（Heading content）
  • フレージング・コンテンツ（Phrasing content）
  • エンベッディッド・コンテンツ（Embedded content）
  • インタラクティブ・コンテンツ（Interactive content）

このほかセクショニング・ルート、なんてのもあったりでめんどくさそう。書いては消し、になるんだろうなあ。ちょっとHTML5を嘗めすぎていたようだ。暫定移行どころか本格的に取り組まないと、結局二度手間になる気がしてきた。

↓もとりあえず適当に俺様分類中。きっとすぐ変わる。

論理レイアウト要素

これまではDIV要素にIDやCLASS属性とCSSで対処していたレイアウトに影響するもの、と解釈してみる。

header
ヘッダ。みもふたもない。入れ子不可。この要素はセクショニング・コンテンツではないうえ、セクションをまたがるマークアップも考えられるので、使いどころには注意が必要。
footer
フッタ。みもふたもない。この要素はセクショニング・コンテンツではない。一般的には子要素にaddress要素を持つことになると思う。同一ドキュメントで何度も使えるが入れ子は不可。
article
独立した記事。入れ子にもできる。h1などの見出しセットで使うのが基本というか推奨されているようだ。ちゃんと構造化されていれば見出しレベルに従って入れ子になるんだと思う。スタイルの区分けのために使うべきではなく、それは従来どおりdiv要素で行うこと。
nav
ナビゲーション。みもふたもない。
section
セクション。みもふたもない。articleやasideなどの他のセクションに分類できないもの。h1などの見出しセットで使うのが基本というか推奨されているようだ。スタイルの区分けのために使うべきではなく、それは従来どおりdiv要素で行うこと。

注意が必要なのは、あくまでも論理レイアウトのための要素であること。たとえばfooter要素は<div id="footer">などを単純に置き換えるものではなく付近の記事内容に対するフッタ情報なのである。それゆえドキュメントによっては複数回footer要素が出現することもあり得る（物理レイアウトであれば1度しか使うべきでない）。

Page Top