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要素は改名して、インライン要素とするのが活路かも"

Firefox メインでも、ひそかに Opera 好きのユーザー

lomo さんのエントリーで、

コメント・トラックバック・ソーシャルブックマークのコメント・Twitter…なんでもいいのでOperaに対するご意見を聞けたらなって考えています。

Operaのよいところってどこですか?（caramel*vanilla）より

という話が出ていたので、僕もひとつ。ちなみに僕は Mac | Win2K + Firefox 2(5) : Win2K + IE 6(2) : Mac + Safari (1) : Mac | 携帯 + Opera (2) の割合で使い分けてる、わりと節操のないユーザーです。(^ ^;)

続きを読む "Firefox メインでも、ひそかに Opera 好きのユーザー"

「一歩先のWeb標準」連載開始

デジタルスケープさんの WithD にて今月から連載を持たせていただくことになりました。（ネタもそうですが、文章が堅くて、編集の方にご迷惑をお掛けしたと思いますが。(- -;;ゞ ）

• マークアップのmust, should, may - 一歩先のWeb標準 ♯1（WithD）

奇しくも「勘違い甚だしいstrict HTMLの解説」（sky line blog）なんてエントリーが出た直後で、なんだかタイムリーになってしまいましたけど（文章の核になる部分は 1か月以上前から用意してたものなので、単なる偶然なんですが）、書かれている内容は、このブログ内の過去のエントリーとも関連してます。

要するに僕の場合、must ではなく、may の話が多いので、「しなければならない」みたいな文脈で受け取らないでくださいねって、ことわり書きみたいなもんです。たとえば僕の (X)HTML の話なんて、マークアップがライトウェイトかヘビーウェイトかの違いでしかないわけで、別に body 内が h1〜h6 と p だけで構成されてたって、全く問題ないんですよね。

ついでにいえば、HTML か XHTML かだって同様。あくまで僕個人は、そんなに大した問題じゃないと思ってます。だって、再利用したり再構築したりするとしても、おそらくそれを行うのは検索サービスだったり、ソーシャルメディアだったり、CMS だったりで文書作成者以外の第三者のことが大半なわけですし、いうなれば自由意志でつける、見えない付加価値みたいなもんです。（なんだか料理の隠し味みたいですけど。）

それでも、あえて付加価値をつけたり、未来の Web が少しでも便利なるように、"自分自身ができること" を模索してみたい...という方に向けた連載です。（このブログも基本的には同じ路線ですが。）たとえ万人向けの内容でなくとも、ごく少数の方でもお気に召していただけることがあれば、それだけでとってもうれしいです。

CSS Nite Shuffle レポート

日刊徒然音声雑記などでお馴染みの境祐司さんのご招待で CSS Nite Shuffle に行ってきました。（境さん、ありがとうございました！）

境さんとは、知識共有や暗黙知まわりでお話することができましたが、このあたりはまたいずれ（必ず）。

天気は冬に逆戻りしたかのような冷たい雨。会場は、渋谷のラブホテル街の中にある、ライブハウスということで、なんだか妖しくも不思議な気分でした。(笑)

続きを読む "CSS Nite Shuffle レポート"

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 文書フォーマットの現実的な落としどころ。

随想: CGM時代のWebの「使い方」「作り方」

もう一昨日の話になっちゃいますけど、久々、イベントに足を運んでみました。

• 第1回 「Web研」: CGM時代のWebの「使い方」「作り方」（withD）

一応、「公開ポッドキャスト」と銘打っているので、おそらく内容については、そのうち長谷川恭久さんの Inflame Casting と境祐司さんの 日刊徒然音声雑記で公開されるものと思いますので、内容レポートは割愛させてもらって、個人的に気になった要素と思ったことを、備忘録がてら書き散らしておきます。感想や意見というより、講演者の方々の話の中でビビっときたキーワードから考えさせられたことを勝手気ままに書き散らした随想って感じなので、フィードバックにもならなければ、読者の方々のお役にも立たないかもしれません。

続きを読む "随想: CGM時代のWebの「使い方」「作り方」"