セマンティック(意味論)を考慮したマークアップを記述することは、Web標準の使用に向けた重要な一歩です。セマンティックを考慮したマークアップとは、ドキュメント冒頭の最も重要な見出しに<h1>要素を用いるなど、各XHTML要素をそれぞれの本来の意図通りに用いる記述法のことです。
セマンティックを考慮したマークアップが完成したら、ドキュメントの構造とプレゼンテーションを分離し、CSSを利用してこれらの要素にスタイルを適用します。この際、マークアップとCSSの両方を検証し、これらが標準規格に準拠していることを確認するのも重要です。もちろん、他にも検討が必要な標準規格もありますが、この記事では、こられ2つを最も重要な標準規格として扱うことにします。
Fireworks CS4が登場するまで、Webサイトのレイアウトデザインは、各要素の意味合いをほとんど考慮することなく生成されていました。もちろん、あらかじめ視覚的に大小異なる見出しを作成することはあったかもしれませんが、実際に使用される要素はデザインが完成してから、XHTMLとCSSでの構成段階で決定されるケースがほとんどでした。
このワークフローは、1人のデザイナーがWebページのデザインと構築を担当する場面では十分なものの、XHTMLの構築が他のデザイナーやデベロッパーに委ねられるような場面では意図したドキュメント構造が必ずしもその通りに認識されるとは限らないため、結果として意味論的な配慮が欠如する恐れがあります。
この記事で紹介するアップデート版のCSS書き出し機能は、Fireworks CS4ドキュメント上でセマンティックを考慮したデザインを計画・実現するために2つの方法を提供します。これにより、一段と効率良くデザイン案を計画できるようになるだけでなく、第三者が容易にプロジェクトに参加できるようにもなります。
ここからは、その2つの方法である「テキストのタグ付け」および「HTMLコンポーネントシンボル」を解説するとともに、これらの長所・短所もあわせて紹介することにします。
Fireworksデザイナーの大半はテキストツールを利用して、作業中のデザイン上にテキストを配置しているはずです。だからこそ、意味合いを考慮した構造を定義する上で、標準的なテキストオブジェクトこそが絶好の機会になるのではないかと考えました。
そこで、今回はテキストオブジェクトにタグを付けられるようCSS書き出し機能を改良し、単に明快な命名基準に従うだけで、出力後のXHTMLに適切なタグが配置されるようにしています。
テキストオブジェクトから生成できる要素は、<a>、<blockquote>、<div>、<h1>、<h2>、<h3>、<h4>、<h5>、<h6>、<label>、<p>および<span>です。これらのタグ以外が指定されている場合、またはタグが一切指定されていない場合は、<p>が生成されます。
テキストオブジェクトで特定のタグを使用することは、当該オブジェクトの名前の冒頭にそのタグ名を付けることで指示できます。例:<h1>タイトル。
では実際に試してみましょう。
tagging.htmのソースを表示します(図1参照)。

図1. 3つのdivと1つの段落を含む、書き出し処理によって生成された有効なXHTMLドキュメント
ここまでではFireworksでテキストオブジェクトに対してタグ付けを行わなかったため、コンテンツは段落内に書き出されています。この段落にはlastNodeクラスが与えられ、Txt_Helloクラスのdivに囲まれていることが確認できます。
このドキュメントに関連付けられたCSSファイルを表示すると、lastNodeクラスはIDが「main」の要素内の段落に適用されることと、そのクラスのmargin-bottomが0にリセットされていることが確認できます。
また、別のdivに適用されるTxt_HelloクラスはFireworksのテキストオブジェクトの名前に基づくものでおり、このクラスによって所定の位置への配置が定義されるとともに、div内の段落にも適切なスタイルが適用されるようフォントとカラーのプロパティが定義されます。
これにより、ユーザはFireworks上ではもちろんのこと、外部エディタやCMSを利用しても、複数の段落を追加し、常に適切なスタイルを各段落に適用させることができます。ただし、テキストブロックの最後の段落には、必ずlastNodeクラスを適用する必要があることだけ注意するようにしてください。
では、次のサンプルを試してみましょう。
ドキュメントを再度書き出し、その結果をDreamweaverで確認します(図2参照)。

図2. 段落ごとに1行のテキストが配置された2つの書き出された段落
Fireworks CS4搭載のオリジナル版のCSS書き出し機能では、複数の段落が作成されることはなく、行間に改行(<br />)を用いて余白が挿入されます。また、Txt_Helloクラスも段落に適用されますが、divは作成されません。したがって、検証エラーを起こさずに新たなコンテンツを追加することはできません。
ここまでで、アップデート版のスクリプトが既に一段と標準準拠性に優れたページの作成に役立っていることがお分かりいただけることでしょう。
次に、タグ付けを試してみましょう。
ドキュメントを再度書き出し、その結果をDreamweaverで確認します(図3参照)。

図3. Fireworksでのタグ付けが反映された変更後のマークアップ
ご覧のように、ここでは読者が「Hello world」を<h1>に指定したことがFireworksによって尊重されています。しかも、今回は改行で行間に余白が挿入されているとともに(見出しの中に段落が配置されては矛盾が発生するため)、スタイルが適用できるよう<h1>にh1_titleクラスが設定されています。また、<h1>要素内に配置できるのがインライン要素のみであることから、ここでは新たなdivが作成されることがありません。
既に触れたように、テキストオブジェクトにタグを付ければ、12種類のXHTML要素を生成することができます。
なお、この方法でアンカーの<a>を生成する場合は、これに対応するスタイルがすべてのアンカー要素にグローバルに適用されるという点に注意が必要です。また、:link、:visited、:hover、:focus、または:activeの仮想クラスに異なるスタイルを指定することはできません。これらの仮想クラスのスタイル設定は、書き出されたCSSファイルを手作業で編集して調整する必要があります。
テキストオブジェクトの使用に関しては、他にも検討すべき3つの重要事項があります。
では上記の重要事項について少し詳しく見ることにしましょう。ここでは4つの<span>と2つの<a>タグでタグ付けが行われた、6つのpoint-textオブジェクトから構成されるWebサイトの「パンくずリスト」を例に挙げることにします。次の図にあるように、書き出し後の間隔が均一になるよう、Fireworksで境界ボックスを6ピクセル間隔で配置していたとしても、Fireworks上のこれらのテキスト間隔は9ピクセルで表示されることがある点に注意が必要です(図4参照)。

図4. Fireworksおよびブラウザで表示される6つのpoint-textオブジェクトの比較
今回の強化版CSS書き出し機能は、文字間の間隔(letter-spacing)、行間(line-height)、テキストの横揃え(text-alignment)、フォントの太さ(font-weight)およびフォントスタイル(font-style)の各オプションをサポートするとともに、段落の前後にある余白を、それぞれの段落に関連付けられた、単位「em」のmargin-bottom値に変換します。
Fireworks CS3から導入されたリッチシンボルは、Webサイトのデザイン時、インターフェイスのプロトタイプ作成時、または他のグラフィックデザインの構成時に利用・再利用できる、編集可能なデザイン・インターフェイスコンポーネントです。Fireworks CS4では、これらのシンボルの書き出し時に、必要なXHTMLマークアップおよびCSSが生成されるよう、この機能が強化されています。
Fireworksチームが当初目指したのは、CSS書き出し機能が用いられる際、HTMLコンポーネントを利用してすべての要素のマークアップを生成することでした。しかし、今回タグ付けというテクニックが導入されたことにより、HTMLコンポーネントの使用は効率面でも劣ることから、HTMLコンポーネントの必要性は下がると考えられます。だからといって読者のワークフローにおいて、HTMLコンポーネントが無用になるという分けではありません。その証拠に、筆者は新たなHTMLコンポーネントシンボルを作り直し、これらを今回の強化版CSS書き出し機能の一環として提供しています。
メモ:既存のHTMLコンポーネントを既に使用している場合は、当該ドキュメントのライブラリを更新して新たなコンポーネントを含めない限り、デザインの書き出し時にエラーが発生する恐れがあります。
HTMLコンポーネントシンボルは、共有ライブラリパネル(メニューからウィンドウ/共有ライブラリを選択)のHTMLフォルダに配置されています。シンボルとして用意されているのは、リンク、見出し_1、見出し_2、見出し_3、見出し_4、見出し_5、見出し_6、テキストフィールド、テキストエリア、コンボボックス、チェックボックス、ラジオボタンおよびボタンです。
フォーム要素にはすべて、Windows VistaとMac OS ×両方のデフォルトテーマが適用されたものが用意されています。また、他のOSテーマも手軽に作成できます。これについて詳しくは、Aaron Beall執筆の別途記事「Fireworksでのリッチシンボルの使用」およびSarthak Singhal執筆の別途記事「Fireworks CS3でのリッチシンボルの拡張*」を参照してください。
CS3のリッチシンボルと同じように、HTMLコンポーネントのプロパティは当該シンボルがカンバスで選択された状態で、シンボルプロパティパネルを利用して変更できます。
見出し_1から見出し_6のコンポーネントには、以下の編集可能プロパティが含まれています。
テキストオブジェクトに見出しのタグ付けを行う方法と比較して、このリストに特に制限があるように感じられないかもしれませんが、この2つには明らかな違いがあります。
さらに、残念ながら共有ライブラリパネルにはCS3の短所が引き継がれており、CS4のシンボルプロパティパネルにも、次に挙げる煩わしい既知のバグがいくつか存在します。
シンボルの使用には、再利用が可能であること、手軽に入れ替えが可能であること、そして一度の編集で複数の対象を更新できること、といったメリットの他にも、使用するフォント(ファミリ)の選択肢をユーザのコンピュータ上で最も一般的なものに限定できるというメリットがあります。ただし、ここでテキストオブジェクトを弁護するのであれば、テキストオブジェクトを使用する場合、標準的なフォント以外が用いられる際に、必要な警告が発せられるということが注目に値します。
どのフォントがWebで問題なく使えるかが不確かな場合は、Code Styleサイトの最も一般的なWindows・Mac・Linux向けフォントの調査結果*を参照することをお勧めします。
既にお気づきの通り、筆者は見出し用のHTMLコンポーネントの使用を推奨していません。それ以外のリンクシンボルおよびフォーム要素のシンボル群は、読者のワークフローにおいて重宝するはずです。
リンクシンボルには、以下の編集可能プロパティが含まれています。
他にも、:visited、:hover、:activeの仮想クラス共通で、カラー、太さおよび修飾に関するプロパティを編集することも可能です。
リンクシンボルにも前出の見出しシンボルと同じ問題がありますが、ここではそれほどの問題にはなりません。
では、リンクシンボルに慣れ親しむために、実際にこのシンボルを使ってみましょう。
書き出されたリンクがFireworksで表示されていたものとまったく同一であることが確認できます。:link、:visited、:hoverおよび:activeの各仮想クラスのカラー、修飾、太さといったプロパティも、すべて維持されていることが確認できます。
Dreamweaverで関連CSSファイルを開くと、図5に示すような、すべての関連ルールが作成されていることが確認できます。アンカー向けのCSSルールがどの順序で生成されるかは、すべてのステートに常に正しい書式が適用されるようにする上で非常に重要です。アンカーのID「#リンク」は、Fireworksのオブジェクト名に基づいて生成されています。

図5. リンクHTMLコンポーネントを書き出すことによって生成されたCSSルールの例
より的確な意味合いのマークアップをFireworksから出力できるようにすることへの支援を求められた際、筆者は、順不同リストを作成できるようにすることを最優先課題として取り上げました。だからこそ、強化版に収録されている新しいシンボルのList Itemには細心の注意が払われています。
シンボルの名前がList Itemにはなっているものの、たいていの場合、このシンボルはリンクを作成するために使用します。この解説では、矛盾しているかのような印象を与えかねないので、もう少し詳しく説明することにします。Webサイトには必ず何らかの形のナビゲーションが存在します。ナビゲーションの構成を意味論的な観点から考えた場合、これらはあくまで一連のリンクのリストに過ぎません。つまり、List Itemはリンクを作成するためにピッタリのシンボルと言えます。
List Itemシンボルには、以下の編集可能プロパティが含まれています。
このシンボルでは「Node type」プロパティと「Is link?」プロパティが最も重要になります。「Node type」では各リスト項目がマークアップ上で何を表すのかを指定し、「Is link?」では当該シンボルによるアンカー出力の有無を指定します。アンカーを出力すれば、リンクシンボルを使用する場面同様に、適切なスタイルの適用が可能になります。
「Node type」プロパティの設定とその効果を以下に示します。
<li>Text</li><ul><li>Text</li><li>Text</li></ul><ul><li>Text</li></ul>様々なList Itemシンボルを組み合わせ、そして、これらのNode typeを正しく設定することで、子リスト項目さえも含む、完全な順不同リストを書き出すことができます。
次に、具体例を用いながら解説することにします。
List item」に変更します。last」に設定します。false」を設定します。first」に設定します。ul.htmをDreamweaverで開き、そのソースコードをコードビューで確認してみます(図6参照)。

図6. FireworksのList Itemシンボルによって生成されたマークアップ
CSS書き出し処理では、オブジェクトの列や行の位置が解読され、ドキュメントの構成が推測されます。なお、この際用いられるフロートクリアの仕組みが原因で、縦型の順不同リストの作成を試みると、無効なマークアップが作成されることになります(図7参照)。

図7. リスト項目を縦に整列した場合に出力される項目間の無効なクリア<div>タグ
縦型のナビゲーションを作成する場合は、単にこれらのフロートクリアdivを削除してから、各<li>タグ内にclearFloatクラスを割り当てます(図8参照)。また、長方形、線、テキストなどのオブジェクトを使用してFireworks上のリスト項目を視覚的に分散している場合は、縦型、横型どちらのリストに対しても、無効なマークアップが生成されます。

図8. 縦型のナビゲーションを実現するための正しいコード
このような場面で期待通りの結果を得るためには、書き出し処理が完了してから「仕切り」的な要素を<li>タグ内に手作業で移動し、必要に応じてスタイルを幾分調整する必要があります。
今回の強化されたバージョンでは、<form>要素が最も徹底的に見直されています。これまでもWindows用とMac用のフォーム要素は装備されていましたが、特にMac用のものは、その有用性に疑問が残るものでした。
今回の強化ではWindows、Mac両方の要素群がアップデートされており、一段と多くのプロパティが編集可能になるとともに、適切かつ有効なマークアップおよびスタイルが書き出されるようになっています。また、強化版にはHTMLのTextArea要素も収録されています。
フォーム要素に用意されている編集可能プロパティは以下の通りです。
ボタンシンボルのTypeプロパティでは、Submit、Reset、Buttonのいずれかのボタンタイプの書き出し・表示を指定することができます。テキストフィールドのシンボルは、標準テキストまたはパスワード入力のいずれかを選択して書き出せます。
Stateプロパティの内容はシンボルによって異なるものの、一般的には当該要素上にポインタが配置された状態のOver、当該要素が選択された状態のSelected、および当該要素が無効化された状態のdisabledを表すことができます(無効化された要素は無効化されて書き出されます)。
フォーム要素を含むドキュメントを書き出す際には、有効かつ標準規格準拠のマークアップが得られるよう、以下の事柄に注意する必要があります。
<form>要素内に配置されます。.NET環境の開発ではこの動作が一般的であり、たいていの場合、この動作が問題になることはありませんが、同じドキュメントに検索フォームとメッセージ投稿用のフォームが存在するケースなど、明らかに用途の異なる複数のフォームが1つのドキュメント内に存在するような場面では、フォームの構成を手作業で修正する必要があります。<fieldset>および<legend>要素が書き出されることは一切ありません。Fireworks上では一連の<form>要素を論理的に定義することができないため、これらの要素は、書き出し後に手作業で追加し、必要であればスタイルを外すことで不可視の状態に保つことができます。<label>要素を書き出します。デザイン上で他のフォーム要素向けに可視的な<label>が必要な場合は、このテキストオブジェクトに<lable>タグを付けるようにします。ただし、このケースでもフォームのコントロールIDの値が含まれた「for」属性を追加することで、当該ラベルを所定のフォームコントロールに関連付ける必要があります。 <label>タグが不要な場合は、一旦これらのタグをデザイン上から削除し、書き出し処理が完了してからこれらをマークアップコードに追加することができます。この際、CSSを利用して不可視にし直すことを忘れないようにしてください。フォーム要素の使用に関しては、他にも次の2つの注意点があります。