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（日時）"

link 要素をナビゲーションに利用することの注意点（改訂）

［2007-02-08 18:00: 内容を増訂しました。］

パンくずリストがベストとは限らない（WWW WATCH）で、link 要素を使ってページ間を関連づけるという方法が解説されています。本文でも指摘されているように、ブラウザの実装上の問題で、現実的にはナビゲーションとしては使えませんけど、セマンティックウェブという観点で見れば、むしろパンくずリストなどよりも、よほど重要な要素には違いないので、僕も興味深く拝見させていただきました。（「参考までに」で済ませてしまうのは、ちょっともったいないくらい。）

実装面について

機能として標準実装されている Opera に加え、Firefox 向けの可視化 Tips が FirefoxでOperaのようなlink要素を表示させる「Mozeraナビ=叢ナビ」 (インターネット帳面)と、link 要素を可視化してみる（double-team.org）で紹介されています。

ただ一点だけ気になったのは、「本来パンくずリストのようなナビゲーションは link 要素として記述するのがマークアップ的には自然だったりします」という一文です。（「ページ間の関係を示す」のには link 要素の方が良いという点はまったく同感ですが、パンくずリストの目的自体が、そもそも「ページ間の関係を示す」ことではなく、"サイト構造全体の中における現在位置の提示" にあるのではないでしょうか？）ブラウザの実装面から現実的な選択肢とはなりえないことを差し引いても、少なくとも現時点では、僕個人は、パンくずリストと link 要素は完全に切り離した方がいいように思います。おもな理由は以下の通り。

続きを読む "link 要素をナビゲーションに利用することの注意点（改訂）"

パンくずリストのマークアップ

ちょっと前に パンくずリスト（Topic Path）を作成する際に使えそうなサンプル8種（CSS HappyLife）というエントリーが盛況でしたが、今日はパンくずナビゲーションの論理構造面を補強する意味も込めて、(X)HTML マークアップの例を、サイト構造やサイトの目的に応じて、いくつか挙げてみました。CSS の話まで入れると長くなるので、今回は（も？）(X)HTML マークアップに話を絞ります。CSS については、特にセレクタまわりが結構 変わってしまいますが、ひとまず、HirasaWa さんのエントリーなどを参照してください。（気が向いたら、別エントリーを立てますけど、実際に書くかどうかは未定。）

続きを読む "パンくずリストのマークアップ"

配色管理用の CSS をモジュール化する

今日は再現性の高いスタイル（プロパティの集合）ごとに、CSS セレクタをグループ化して管理する事例として、ちょっと前から制作中のサイトで実践している、配色管理の方法を紹介してみようと思います。（とっくに似たようなことを実践されている方も、きっといらっしゃると思います。お気づきの点があれば、細かいことでもご教示・ご指摘いただけましたら幸いです。）

（なんだか、CSS が主題のエントリーって、随分、久しぶりのような気がする..。）

配色管理モジュールの作成方法

1. 色に関するスタイルをすべて、この配色管理モジュールに集約する。
2. 別出した color.css は、@import で上位 CSS ファイル（もしくは HTML ファイル）から読み込ませるようにする。
3. セレクタは、同一スタイルごとにグループ化する。（注意: CSS セレクタ、グループ化の落とし穴）
4. セレクタは、浅い階層の一般的なものを先に、深い階層の特殊なものを後に、一意なものを最後に記述する。（上書き予防）
5. 階層の深さがすぐに把握できるように、セレクタは冗長に表記する。
6. IE 6- 用のスタイルを別途定義しない場合は、子セレクタ・隣接セレクタ・属性セレクタなどは使わず、子孫セレクタで構造を記述する。

ブランディングのためのスタイルガイド、もしくは Color glossary などと考え方が若干似ていますが、要は色に関する設定だけをモジュール化して、独自の CSS ファイルに別出します。

• ［参考］Color glossary

続きを読む "配色管理用の CSS をモジュール化する"

コード共有のためのネーミングルール

最近、CSS の使いまわしなどを視野に入れ、一部で class名や id名の共有というテーマへの関心が徐々に高まりつつあるような印象です。microformats なんかも、その流れのひとつといえるでしょう。

• Naming conventions table（And all that Malarkey）
• もう、class名やid名で悩まないんだからっ！！（CSS HappyLife）
• (X)HTML の id/class における命名規則（purprin さん CSS Flight プレゼンスライド）

名前の共有はコードの共有のための（複数人で同一コードを編集・転用する）重要なファクターのひとつですし、非常にいい傾向だとは思うんですけど、実際につけられている名前を見てみると、シブい顔をせざるを得ない事例が結構あるようです。

続きを読む "コード共有のためのネーミングルール"

(X)HTML, XML のコメント記述位置

コメントの記述位置について以下のようなエントリーを目にしましたが、目から鱗です。というか、未熟にも今まで気づきませんでした。(- -;;ゞ

コメントは、対象となる要素の中に記述すべし

デザイナさんにより書き方はいろいろあるかもしれないが、

<!-- hoge start -->
<div id="hoge">
  // 中身
</div>
<!-- hoge end -->

こうじゃなくて、

こうしてほしい。

<div id="hoge">
   // 中身
<!-- /hoge -->
</div>

divの中に終了を示すコメント入れなくてどーする！（構造を考えてみれば分かることですよね？）

HTMLのコメントの書き方 - capsctrldays (2007-01-19)より引用:

コレ、論理構造の妥当性の面もそうですが、内部構造を、XSLT やら DOM やらで操作する時に、決定的な違いが出てきますよね。

続きを読む "(X)HTML, XML のコメント記述位置"

WebKit が CSS 3 box-shadow に対応

WebKit のナイトリービルドが box-shadow プロパティ（-webkit-box-shadow）に対応してます。これはうれしい実装情報ですね。ほかのブラウザでも、こうやって角丸やドロップシャドウに、だんだん画像を使わなくても良いようになってくると良いのですが。

WebKit とは？

• WebKit とは

要するに Safari のベースになっている Cocoa ベースのブラウザコンポーネントです。

サンプル

WebKit CSS 3 box-shadow Example

WebKit での CSS 3 box-shadow プロパティは、-webkit-box-shadow: [右方向の影の長さ] [下方向の影の長さ] [ぼかし半径] [色]; で指定します。たとえば -webkit-box-shadow: 2px 2px 2px #666; のような具合です。

W3C のドラフトでは、カンマ区切りで複数の光源によるドロップシャドウ効果も想定しているようですが、WebKit では、今のところそこまでは対応していないようです。ただ -webkit-border-radius と組み合わせれば、ボックスに角丸＋ドロップシャドウ効果を同時につけることができます。

WebKit での表示状態

続きを読む "WebKit が CSS 3 box-shadow に対応"

CMS の見出しレベルに悩む

（追記: タイトルをより内容に合うように変更しました。本文も若干修正しましたが、内容に関わる変更はありません。）

最近、CSS よりも、関心が XHTML に傾きがちな管理人です。(^ ^;) 今日は、目下、裏でせっせと制作中の MovableType サイトのコーディングからのネタです。

このココログもそうですけど、ブログツールを含む何らかの CMS を使っていると、「幾つめの見出しレベルからスタートしたらいいんだ？」、「別のサービスから引っ越したら、見出しレベルが１つズレちゃった」、「文書構造をカスタマイズしたので、これまでの見出し要素のレベルを調整しないといけないよな..」。そんなことで困った経験とか、過去にありませんか？

続きを読む "CMS の見出しレベルに悩む"

タグクラウドのマークアップ

最近 巡回しているサイトで、ちょっと面白いエントリーがあったので、紹介がてら、自分でも考えてみようかと。

Marking Up a Tag Cloud （24 Ways）

del.icio.us, Flickr, Technorati の (X)HTML ソースを比較しながら、タグクラウドの適切なマークアップについて考察しているエントリーです。といっても、著者の Mark Norman Francis は、これらにいきなりダメ出しをしています。いわく、「問題は、みんな間違っていることだ」（The problem is, everyone's doing it wrong.）と。

続きを読む "タグクラウドのマークアップ"

abbr は本来 機械のための要素 —マークアップは誰（何）のためのものか？

さきの２つのエントリーと関連して。

1. 略語に振り回される今日この頃
2. abbr の title 値を CSS でポップアップ

abbr を使わずに直書きするのが最善？

ANOTHER PIECES（id:xcezx さん）の「abbr 要素 その2」というエントリーで、次のようなご指摘をいただきました。（id:xcezx さん、ありがとうございます。個人的にこういう前向きな批判や議論は大歓迎です！）

「CSSを処理しないテキストブラウザや音声読み上げブラウザでは、やはり略語のフルスペルは表示されないよね。」というのがユーザビリティ的な観点から、満点をあげられない理由。

ユーザビリティを考えるなら、小賢しいテクニックなど使わずに、"XHTML (eXtensible HyperText Markup Language)" とかした方がよっぽどいい気がする。

結論からいえば、この指摘は大変ごもっともで、括弧でくくってベタ打ちテキストを直書きするのが、一般的には最善の策といえます。（一応、「略語に振り回される今日この頃」の方で選択肢として挙げたつもりではあるんですけど..。(^ ^;) ）

abbr要素 + title属性よりも直書きの方がアクセシビリティ的に良い理由には、id:xcezx さんが指摘されているテキストブラウザ上で表示されないことに加え、 IE 6- が abbr 要素に非対応なこともあります。

ただ、もしこれに「音声ブラウザ」（スクリーンリーダー）での「ユーザビリティ」を加えるとなると、話は少し変わってきます。

続きを読む "abbr は本来 機械のための要素 —マークアップは誰（何）のためのものか？"

abbr の title 値を CSS でポップアップ

非対応ブラウザ: 4.x

折角、caramel*vanila の lomo さんが、前のエントリー（略語に振り回される今日この頃）にフォローアップして下さったこともあるので、僕の方でもちょっとだけ＋αをつけてみます。

略語に対してつける <abbr> 要素には、その原語なり原表記なりを title 属性の値に記述するのが普通です。モダンブラウザのデフォルト設定なら、<abbr> で括られた個所にマウスを乗せると、title 属性の値がツールチップの形で表示されます。

でも、ツールチップでは文字が小さくて見にくいですし、またマウスを乗せない限りは、何の略語であるのかが、結局わからないままです。そこで、その title 属性値（つまり原語）を CSS だけを使ってWebページ上に表示してみましょう。

続きを読む "abbr の title 値を CSS でポップアップ"

Web 標準志向 XHTML / CSS リファレンスのための５つの改善要素

今日は、ちょっと逃避で、大分前の書きかけ（未公開）エントリーを引っ張り出してきてみました。ちょっとここ数日、落ち着かなくて..。

最近、つくづくよく思うのは、"Web 標準コーダーのための XHTML / CSS リファレンス" みたいな感じの、携帯に便利でコンパクトなリファレンスブックが欲しいなということです。今でもたくさんの HTML / CSS リファレンスは出版されているわけですが、イマイチしっくり来るモノがないというのが実感です。ぶっちゃけ、既製品には、ユーザビリティ的に色々と顔をしかめたくなる点が多くて..。従来品との相違点でいえば、大体、次の５つのポイントに集約できるかと思います。

1. 非推奨要素・属性・属性値は排除したい
2. 読み方、原語を明記してほしい
3. 規格と実装は区別して！
4. 非対応ブラウザ側を表示する
5. 非対応ブラウザ対策の提示

続きを読む "Web 標準志向 XHTML / CSS リファレンスのための５つの改善要素"

SyntaxHighlighter: ソース表示用ライブラリ

対応ブラウザ: 6+ 1.0+ 8.5+ 2.0+ 3.4+

(X)HTML や CSS などのソースコードの表示に、Mochikit にもバンドルされている、SyntaxHighlighter を試用してみました。設置も利用も比較的 お手軽で、MT や WordPress といった CMS を利用している方の選択肢になるかも。（参考: MochiKit: 軽量 JavaScript ライブラリ）

入手先

dp.SyntaxHighlighter

SyntaxHighlighter の特徴

長所

1. ソースコードを文法にしたがって色分けできるので、とても見やすい
2. 行数が表示されるので、話題にしているコードの場所を示しやすい
3. ソースコードをそのままコピペできる
4. ベタ打ちのソースコードを <textarea class="code"> で括るだけなのでラク
5. HTML/XML タグのエスケープが原則必要ない
6. JavaScript を切っていても、ソースコード自体はアクセシブル

短所

1. Perl, Lisp に対応していない
2. 必要なページごとに指定された内容の script タグを、HTML 文書の末尾に毎度毎度 挿入しなくてはならないのが、若干 煩瑣（仕方ないといえば、仕方ないけど。）
3. 言語ごとに js ファイルが分かれていて、その都度、必要なものだけ関連づける必要がある
   （かといって、最初からすべての js ファイルを、すべてのページ末に貼り付けるのは、あまりに芸がない）

（もちろん上記の短所は、JavaScript を使いこなせる方なら、ある程度はハックして解決できるでしょうけど..。）

続きを読む "SyntaxHighlighter: ソース表示用ライブラリ"

CSS 3 は Konqueror がアツイ！

（2006-10-18 追記あり。）

CSS 3 の最新情報を扱った CSS3.info が、各種モダンブラウザにおける、CSS 1〜3 セレクタ対応状況のテスト結果を報告しています。テストケースは全部で 578 にも及び、IE 6, IE 7, Firefox 1.0, Firefox 1.5, Opera 8.5, Opera 9, Safari 2.0, Safari ナイトリーテスト版（r16925）, Konqueror 3.5 が対象。JavaScript で動作する testsuiteは、Lucky bag::blog でも取り上げられていた、先日 公開されたものが利用されています。（ただし :hover, :active, :focus, :selection といったダイナミック擬似クラスはテストの対象外。）

主要な最新ブラウザが軒並み 350±7/578 の範囲内で対応しているのに対し、IE 7 が 330 と出遅れているのがわかりますが、それより驚くべきは（ 6項目の小さなバグを残すものの）Konqueror 3.5 が 570/578 ものテストをクリアし、すべてのセレクタに対応していることです。（Konqueror は K-Desktop Environment（KDE）が conqueror = 征服者 に掛けてつけた名前で、"コンカラー" と読みます。）

続きを読む "CSS 3 は Konqueror がアツイ！"

CSS Nite LP, Disk 1 レポート（その３）

イベントからもう５日も経って、旬も過ぎているのにも関わらず、いまだダラダラと一方的に勝手な意見を並べ立ててますが、CSS Nite LP, Disk 1のレポートも、これで本当にラストです。(^_^;;)

1. CSS Nite LP, Disk 1 レポート（その１）
2. CSS Nite LP, Disk 1 レポート（その２）

続きを読む "CSS Nite LP, Disk 1 レポート（その３）"

CSS Nite LP, Disk 1 レポート（その２）

遅くなってすみません。CSS Nite LP, Disk 1 のレポート、続編です。

後半はアクシデントで順番が入れ替わった境祐司さん、Opera CSO の Charles McCathieNevile さん、そして矢野りんさんのお三方。ただ、境さんのプレゼンのレポートも長くなっちゃったので、これもちょっと分けます。それにしても、前半のお三方も含め、実際、本当に豪華なメンバーですよね。(^ ^;)

1. CSS Nite LP, Disk 1 レポート（その１）
2. CSS Nite LP, Disk 1 レポート（その３）

続きを読む "CSS Nite LP, Disk 1 レポート（その２）"

CSS Nite LP, Disk 1 レポート（その１）

CSS Nite LP Disk 1 に行ってきました。

Web 関係でこのテのイベントに出席するのは初めてですが、さすがに花形業界だけあって、参加者も多くて、皆さん関心が高いですね。（ただ、個人的な印象としては、参加者の皆さん、質疑応答の時とか、少々大人しすぎるような気も..。(^ ^;)）少し遅れての入場になってしまったんですが、トップバッターの境さんがトラブルで遅れて来られるとのことで、入場したときには Mozilla Japan の瀧田さんがプレゼンをされてました。以下、発表順に僕の個人的な感想を残しておきます。

1. CSS Nite LP, Disk 1 レポート（その２）
2. CSS Nite LP, Disk 1 レポート（その３）

続きを読む "CSS Nite LP, Disk 1 レポート（その１）"

HTML エディタとしての Carbon Emacs

Dreamweaver などがまだ Intel Mac に対応していないこともあって、目下、色々なエディタを試用しながら、自分に合ったモノを探しています。ポイントは以下の通り。

1. Intel Mac + Tiger でも動作すること
2. UTF-8 の読み書きに対応
3. GREP（正規表現検索や置換）ができること
4. シンプルな UI
5. 軽量・軽快なこと
6. 要素・属性・属性値・コメントなどの色分け機能
7. 要素名・属性名・属性値などのコンプリーション（補完）機能
8. 閉じタグのコンプリーション（補完）機能
9. DTD, RelaxNG, XML Schema などからのパーシングができること
10. もしくは文法チェック（validation）がエディタ内でできること

最後の２点は欲を言えば..といったレベルの希望なんですけど、それでもいくつか候補は上がってます。そのうちの一つが今回 取り上げる Carbon Emacs（+ PSGML）です。

続きを読む "HTML エディタとしての Carbon Emacs"