HTML の見出しをめぐる議論

先週は数日にわたって頭痛がひどくて、意識的に電脳から距離を取るようにしていたんですが、この周辺の話題については、色々な意見が出ていて楽しく拝見してました。

ただ、ひとつ気になったのは、思った以上に多くの方々が、現有の...ないし自分の周辺で目にするモデルの枠内だけで仕様書の内容を捉えてしまっているところ。

続きを読む "HTML の見出しをめぐる議論"

Re: XHTML+CSS (r)evolution, 3rdの内容は信ずるに値するか?

Kuruma さんが、先日の XHTML+CSS (r)evolution, 3nd に対する、とっても良いレポートと論評をアップしていて、参加者された方には是非とも一読をオススメしたいのですが、いくつか気づいた点がでてきたので蛇足気味ではありますが、一応、書き留めておきます。

続きを読む "Re: XHTML+CSS (r)evolution, 3rdの内容は信ずるに値するか?"

論理構造を文脈に読み換えながら class 名を考える

最近、一部で話題に上がっている POSH にも、"Use good semantic-class-names" という実践項目がありますが、今日はその class 名のつけ方について、最近、思い至ったことから。

POSH encapsulates the best practices of using semantic HTML to author web pages. Semantic HTML is the subset of HTML 4.01 (or XHTML 1.0) elements and attributes that are semantic rather than presentational.

posh - Microformatsより

基本的にはより論理構造を意識した class名をつけることが、今日のお話の目的なんですが、semantic-class-names のリンク先にない新味は、論理構造を文脈に読み換えながら class 名を考えるという点。（ただし、普段から意識的に文書全体の構造に照らして class名をつけている方には、それほど新味はないかも。）

例によって、あくまで試案であり、選択肢です。（というか、そもそも僕自身が試行錯誤の最中。）是非や取捨は各自でご判断ください。

関連リソース

• Naming conventions table（And all that Malarkey）
• Web Authoring Statistics: Classes（Google Code）
• コード共有のためのネーミングルール（我的春秋）

続きを読む "論理構造を文脈に読み換えながら class 名を考える"

定義リストの違和感（続）

前回の続きです。

念のため DTD を見直してたら（チェックしたのは HTML 4.01 Strict の DTD）、なんか激しく不安をかき立てられるような記述が..。

続きを読む "定義リストの違和感（続）"

定義リストの違和感

実は前々から定義リストの記述モデルって、どうにも気持ち悪いなと感じてます。

他所さまであまり突っ込んでいるのを見かけないので、僕の知識不足か誤解から来ているのかな..と、ずっと口にするのを避けてたんですが、HTML WG が発足して、HTML のモデルに関する議論が（少なくとも欧米では）盛んになってきていることもあるので、恥をかくのを覚悟で、書き留めておきます。

何かご存知の方は、是非、ご教示を。

続きを読む "定義リストの違和感"

hr要素は改名して、インライン要素とするのが活路かも

なんだか br要素の話が賑やかなようなので便乗。(^ ^;)

• ここで改行ったら改行（カナかな団首領の自転車置き場）
• br 要素（カナかな団首領の自転車置き場）
• 私はbr要素が好きじゃない（der Gegenwart）
• br要素は好きじゃない（sky line blog）
• br 要素問題は CSS2.1 で解決か!?

どちらかというと現行規格ではなく、次世代規格の話になるので、少なくとも批判とかじゃありません。平たくいえば「br, hr 要素を論理セパレータとして見なすとこんな感じかな？」「その特性を活かすなら、仕様をこう変えた方がいい気がする」的な話です。

ちょっと小難しそうな感じがする方は、前置きはスルーして、ユースケースとサンプルコードだけ眺めてもらって、まったく支障ありません。っていうか、次世代規格の話だし、需要自体もそんなにたくさんあるようなネタでもないし、いっそ、全部まるごとスルーしてもいいかも。(笑)

構造本位か見栄え本位かは文脈や用法次第

まず <br/>, <hr/>, <seperator/>要素が構造か見栄えかの問題ですが、結論だけいってしまえば、僕はこれは文脈や用法次第だと思います。どちらにもなりうる、と。たとえば、「第3章の4段落目」と「56ページの16行目」は、それぞれ対象が文章にあるのか、書籍媒体にあるのかの違いがあるだけで、両方とも構造を示してますよね。もちろん、ホワイトスペースの調整のための見栄え本位な改行だってありえるでしょうし。

（そういえば、大学で編集の雑用をしていた時分、テキストファイルや Word 文書の行末に、ご丁寧にも毎行、改行を入れてくれる人が後を絶たなかったのを思い出しました。(^ ^;) ）

<br/>, <hr/>, <seperator/>要素の特性

ちなみに、これらの要素だからこそできる、構造化や意味づけの用法として、どんなものがあるかなんですが、鍵となるのは、おそらく空要素タグという性質になるかと思います。

ならば、空要素タグの性質とは何か？

真っ先に思い浮かぶのは、それは構造を持てない（＝子孫や内容を持てない）という性質。この性質は一般に空要素タグの短所や限界として捉えられることが多いんですけど、実は裏を返せば、ツリー構造（もしくは入れ子構造）を成していなければならないという、SGML or XML系マークアップ言語の制約に影響される部分が少なくなることも意味しています。

この辺に絡むこととして、表題のようなことを前々から考えてたので、ちょっとまとめてみました。動機が上掲の議論とは別のところからきているので、はたして参考に値するかどうかはわかりませんけど。

続きを読む "hr要素は改名して、インライン要素とするのが活路かも"

Re: 正しくHTMLを書こうと心がけている人に5つの質問

Rusica さん＠der Gegenwart の正しくHTMLを書こうと心がけている人に5つの質問に何となく反応してみました。

1. HTML文書を制作する際に使用しているプログラムをお答えください。（Webプログラムも含む）
2. 採用しているDTDとその理由をお答えください。
3. 何故正しくHTMLを書いているのですか？
4. W3CとWHATWG、どちらに期待してますか？
5. あなたにとってHTMLとは何ですか？

正しくHTMLを書こうと心がけている人に5つの質問より

1. テキストエディタ追記: （状況に応じて、割と節操なく変えてます。Windows: EmEditor, Crescent Eve | MacOS X: skEdit, JEditX, Smultron, Carbon Emacs+PSGML, mi | IDE: Aptana, Oxygen）, Web Developer（Firefox 拡張）, Total Validator（Firefox 拡張）, Firebug（Firefox 拡張）, 追記: Copy URL+（Firefox 拡張）
2. 普段は XHTML 1.0 Strict。ただし、状況に応じて XHTML 1.1 や XHTML 1.0 Transitional, HTML 4.01 Transitional を選択することもあります。追記: 前方後方どちらの規格にも対応しやすい Strict を軸に、使用要素や更新作業者が誰になるかといった種々の条件によって、最適なものを選択。
3. 第一にメンテナンス性と分業効率のため。第二に機械処理のしやすさ（されやすさ）のため。
4. どちらも。というか、相乗効果を期待してます。追記: 特に要素にするか属性にするかをめぐる議論（time 要素と datetime 属性 etc.）とか。
5. Web 文書フォーマットの現実的な落としどころ。

なぜ XHTML で 5W1H のマークアップなのか？

ちょっと思い立って、5W1H の XHTML マークアップの手段について、少しずつ整理してみることにしました。理由や意義については、また別エントリーを立てるとして...

我的春秋: 5W1H のマークアップ 1: When（日時）より

というわけで、理由と意義、あと注意点などについて、ちょっと書き留めておこうと思います。

続きを読む "なぜ XHTML で 5W1H のマークアップなのか？"

When? を軸にした Webアプリケーションモデル

モデルタイプ別の比較

比較項目	カレンダー型	年表型
事例	Google Calendar	SIMILE Timeline @Nifty Timeline
特性	ポイントは曜日。 より日常生活に密着した用途（日程管理など）に適している。（→ 日常生活のリズムが曜日という概念と密接に関係しているから？） 過去よりも未来の予定を扱うのに向いている。	ポイントは長いレンジを俯瞰する時の利便性。 未来よりも過去のデータを時間にマッピングしていくのに向いている。

続きを読む "When? を軸にした Webアプリケーションモデル"

5W1H のマークアップ 1: When（日時）

ちょっと思い立って、5W1H の XHTML マークアップの手段について、少しずつ整理してみることにしました。

理由や意義については、また別エントリーを立てるとして、とりあえず今日のところは、When?（いつ？）...つまり、日時のマークアップ手段から。

続きを読む "5W1H のマークアップ 1: When（日時）"