ようにしておいけば良かった...なんて、よく後悔してます。定着しちゃうと、変えづらいですよね。成らず」ともいいますし、いずれ、ちゃんと内容に則した名前とドメイン名をつけなおすつもりです。br要素の話が賑やかなようなので便乗。解決か!?どちらかというと現行規格ではなく、次世代規格の話になるので、少なくとも批判とかじゃありません。要素を論理セパレータとして見なすとこんな感じかな?」「その特性を活かすなら、仕様をこう変えた方がいい気がする」的な話です。小難しそうな感じがする方は、前置きはスルーして、ユースケースとサンプルコードだけ眺めてもらって、まったく支障ありません。いうか、次世代規格の話だし、需要自体もそんなにたくさんあるようなネタでもないし、いっそ、全部まるごとスルーしてもいいかも。<seperator/>要素が構造か見栄えかの問題ですが、結論だけいってしまえば、僕はこれは文脈や用法次第だと思います。どちらにもなりうる、と。「第3章の4段落目」と「56ページの16行目」は、それぞれ対象が文章にあるのか、書籍媒体にあるのかの違いがあるだけで、両方とも構造を示してますよね。ホワイトスペースの調整のための見栄え本位な改行だってありえるでしょうし。文書の行末に、ご丁寧にも毎行、改行を入れてくれる人が後を絶たなかったのを思い出しました。<seperator/>要素の特性ちなみに、これらの要素だからこそできる、構造化や意味づけの用法として、どんなものがあるかなんですが、鍵となるのは、おそらく空要素タグという性質になるかと思います。空要素タグの性質とは何か?真っ先に思い浮かぶのは、それは構造を持てない(=子孫や内容を持てない)という性質。XML系マークアップ言語の制約に影響される部分が少なくなることも意味しています。この辺に絡むこととして、表題のようなことを前々から考えてたので、ちょっとまとめてみました。動機が上掲の議論とは別のところからきているので、はたして参考に値するかどうかはわかりませんけど。さんのエントリーで、コメント・トラックバック・ソーシャルブックマークのコメント・Twitter...なんでもいいのでOperaに対するご意見を聞けたらなって考えています。いう話が出ていたので、僕もひとつ。割合で使い分けてる、わりと節操のないユーザーです。今月から連載を持たせていただくことになりました。(ネタもそうですが、文章が堅くて、編集の方にご迷惑をお掛けしたと思いますが。1か月以上前から用意してたものなので、単なる偶然なんですが)、書かれている内容は、このブログ内の過去のエントリーとも関連してます。話が多いので、「しなければならない」みたいな文脈で受け取らないでくださいねって、ことわり書きみたいなもんです。構成されてたって、全く問題ないんですよね。僕個人は、そんなに大した問題じゃないと思ってます。文書作成者以外の第三者のことが大半なわけですし、いうなれば自由意志でつける、見えない付加価値みたいなもんです。(なんだか料理の隠し味みたいですけど。模索してみたい...という方に向けた連載です。(このブログも基本的には同じ路線ですが。)たとえ万人向けの内容でなくとも、ごく少数の方でもお気に召していただけることがあれば、それだけでとってもうれしいです。(境さん、ありがとうございました!)境さんとは、知識共有や暗黙知まわりでお話することができましたが、このあたりはまたいずれ(必ず)。天気は冬に逆戻りしたかのような冷たい雨。会場は、渋谷のラブホテル街の中にある、ライブハウスということで、なんだか妖しくも不思議な気分でした。何となく反応してみました。HTML文書を制作する際に使用しているプログラムをお答えください。(Webプログラムも含む)採用しているDTDとその理由をお答えください。(状況に応じて、割と節操なく変えてます。選択することもあります。軸に、使用要素や更新作業者が誰になるかといった種々の条件によって、最適なものを選択。第一にメンテナンス性と分業効率のため。第二に機械処理のしやすさ(されやすさ)のため。いうか、相乗効果を期待してます。文書フォーマットの現実的な落としどころ。CGM時代のWebの「使い方」「作り。