アクセシビリティ
デベロッパーリソース

目次

Fireworks CS4での標準規格に準拠したWebデザインの作成

セマンティックを考慮したデザイン

セマンティック(意味論)を考慮したマークアップを記述することは、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>タイトル

では実際に試してみましょう。

  1. Fireworks CS4が既に起動している場合は、一旦Fireworksを終了します。
  2. 記事冒頭の「はじめに」の節にリンクが用意されている付属ファイルをダウンロードし、このファイル内のREAD MEを参照しながらシステムにCSS Export ScriptとHTML Componentsをインストールします。
  3. Fireworks CS4を起動します。
  4. カンバスカラーを白に設定した500 x 500の新規ドキュメントを作成します。
  5. テキストツールを選択し、カンバス上の任意の位置をクリックしてから「Hello world」と入力します。
  6. フォントと書式の設定を「Arial、Bold、20px」に変更します。
  7. メニューからファイル/書き出しを選択し、書き出し対象を「CSSと画像」に設定してから、ドキュメントをtagging.htmとして書き出します。
  8. 書き出し先の位置にナビゲートし、tagging.htmとtagging.cssの両ファイルをDreamweaver CS4で開きます。
  9. tagging.htmをデザインビュー、ライブビュー、またはプライマリブラウザでプレビュー表示してみます。Fireworksドキュメントとほぼ同じ表示結果が得られるはずです。
  10. tagging.htmのソースを表示します(図1参照)。

    3つのdivと1つの段落を含む、書き出し処理によって生成された有効なXHTMLドキュメント

    図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クラスを適用する必要があることだけ注意するようにしてください。

では、次のサンプルを試してみましょう。

  1. Fireworksの作業画面に戻り、「Hello world」のテキストオブジェクトを編集します。
  2. カーソルをテキストの末尾に置き、Enterキーを2度押して空白行を1行挿入します。
  3. 次に、「A second paragraph?」と入力します。
  4. ドキュメントを再度書き出し、その結果をDreamweaverで確認します(図2参照)。

    段落ごとに1行のテキストが配置された2つの書き出された段落

    図2. 段落ごとに1行のテキストが配置された2つの書き出された段落

Fireworks CS4搭載のオリジナル版のCSS書き出し機能では、複数の段落が作成されることはなく、行間に改行(<br />)を用いて余白が挿入されます。また、Txt_Helloクラスも段落に適用されますが、divは作成されません。したがって、検証エラーを起こさずに新たなコンテンツを追加することはできません。

ここまでで、アップデート版のスクリプトが既に一段と標準準拠性に優れたページの作成に役立っていることがお分かりいただけることでしょう。

次に、タグ付けを試してみましょう。

  1. Fireworks CS4の作業画面に戻ります。
  2. 「Hello world」テキストオブジェクトを選択します。
  3. プロパティインスペクタまたはレイヤーパネル上で、このテキストオブジェクトの名前を「<h1>title」に変更します。
  4. ドキュメントを再度書き出し、その結果をDreamweaverで確認します(図3参照)。

    Fireworksでのタグ付けが反映された変更後のマークアップ

    図3. Fireworksでのタグ付けが反映された変更後のマークアップ

ご覧のように、ここでは読者が「Hello world」を<h1>に指定したことがFireworksによって尊重されています。しかも、今回は改行で行間に余白が挿入されているとともに(見出しの中に段落が配置されては矛盾が発生するため)、スタイルが適用できるよう<h1>h1_titleクラスが設定されています。また、<h1>要素内に配置できるのがインライン要素のみであることから、ここでは新たなdivが作成されることがありません。

既に触れたように、テキストオブジェクトにタグを付ければ、12種類のXHTML要素を生成することができます。

なお、この方法でアンカーの<a>を生成する場合は、これに対応するスタイルがすべてのアンカー要素にグローバルに適用されるという点に注意が必要です。また、:link:visited:hover:focus、または:activeの仮想クラスに異なるスタイルを指定することはできません。これらの仮想クラスのスタイル設定は、書き出されたCSSファイルを手作業で編集して調整する必要があります。

テキストオブジェクトの使用に関しては、他にも検討すべき3つの重要事項があります。

  • CSS書き出し機能はテキストをカンバス上の実際の位置ではなく、境界ボックスに基づいた位置に配置します。したがって、テキストを正確な位置に書き出すには、デザイン上でテキストボックスの配置やサイズ調整を厳密に行うことが重要になります。なお、この作業によりFireworks上のデザインには、わずかなズレが存在するかのように表示されることがあります。
  • 固定幅(area-text)の設定はスタイルシートに出力されますが、可変幅(point-text)は出力されません。このため、どの設定が適切であるかを適宜検討する必要があります。
  • 複数の書式が設定されたテキストに関しては、ベースとなるオリジナルの書式設定に関するスタイルのみが書き出されます。

では上記の重要事項について少し詳しく見ることにしましょう。ここでは4つの<span>と2つの<a>タグでタグ付けが行われた、6つのpoint-textオブジェクトから構成されるWebサイトの「パンくずリスト」を例に挙げることにします。次の図にあるように、書き出し後の間隔が均一になるよう、Fireworksで境界ボックスを6ピクセル間隔で配置していたとしても、Fireworks上のこれらのテキスト間隔は9ピクセルで表示されることがある点に注意が必要です(図4参照)。

Fireworksおよびブラウザで表示される6つのpoint-textオブジェクトの比較

図4. Fireworksおよびブラウザで表示される6つのpoint-textオブジェクトの比較

今回の強化版CSS書き出し機能は、文字間の間隔(letter-spacing)、行間(line-height)、テキストの横揃え(text-alignment)、フォントの太さ(font-weight)およびフォントスタイル(font-style)の各オプションをサポートするとともに、段落の前後にある余白を、それぞれの段落に関連付けられた、単位「em」のmargin-bottom値に変換します。

HTMLコンポーネントシンボルの使用

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のコンポーネントには、以下の編集可能プロパティが含まれています。

  • Text(テキスト)
  • Color(カラー)
  • Font (Family)(フォントファミリ)– 様々な標準の選択肢あり
  • (Font) Size(フォントサイズ)
  • (Font) Style(フォントスタイル)
  • (Font) Weight(フォントの太さ)
  • Line height(行間)

テキストオブジェクトに見出しのタグ付けを行う方法と比較して、このリストに特に制限があるように感じられないかもしれませんが、この2つには明らかな違いがあります。

  • シンボルには任意の幅を設定できないため、必ずテキストコンテンツのサイズが適用される
  • シンボルには複数の行にわたるテキストを配置できない
  • シンボルの行間設定値の変更はFireworksには反映されない
  • シンボルのプロパティは一度につき1つしか変更できない

さらに、残念ながら共有ライブラリパネルにはCS3の短所が引き継がれており、CS4のシンボルプロパティパネルにも、次に挙げる煩わしい既知のバグがいくつか存在します。

  • ショートカットキーを利用してフィールドのコンテンツをコピー&ペーストすることができず、その代わりにシンボル自体がコピー&ペーストされてしまいます。コピー&ペースト機能には、対象フィールドを右クリックすることでアクセスできます。
  • パネル内の表示が正しく更新されないことがあります。内容を編集した直後でも、古いプロパティが表示されたままになることがあります。

シンボルの使用には、再利用が可能であること、手軽に入れ替えが可能であること、そして一度の編集で複数の対象を更新できること、といったメリットの他にも、使用するフォント(ファミリ)の選択肢をユーザのコンピュータ上で最も一般的なものに限定できるというメリットがあります。ただし、ここでテキストオブジェクトを弁護するのであれば、テキストオブジェクトを使用する場合、標準的なフォント以外が用いられる際に、必要な警告が発せられるということが注目に値します。

どのフォントがWebで問題なく使えるかが不確かな場合は、Code Styleサイトの最も一般的なWindows・Mac・Linux向けフォントの調査結果*を参照することをお勧めします。

既にお気づきの通り、筆者は見出し用のHTMLコンポーネントの使用を推奨していません。それ以外のリンクシンボルおよびフォーム要素のシンボル群は、読者のワークフローにおいて重宝するはずです。

リンクシンボルの使用

リンクシンボルには、以下の編集可能プロパティが含まれています。

  • Text(テキスト)
  • Font (Family)(フォントファミリ)– 様々な標準の選択肢あり
  • (Font) Size(フォントサイズ)
  • Href
  • Link color(リンクカラー)
  • Link (font) weight(リンクフォントの太さ)
  • Link (text) decoration(リンクテキストの修飾)

他にも、:visited:hover:activeの仮想クラス共通で、カラー、太さおよび修飾に関するプロパティを編集することも可能です。

リンクシンボルにも前出の見出しシンボルと同じ問題がありますが、ここではそれほどの問題にはなりません。

では、リンクシンボルに慣れ親しむために、実際にこのシンボルを使ってみましょう。

  1. 新規ドキュメントを作成します。
  2. 共有ライブラリを開きます。
  3. HTMLフォルダを展開し、その中になる「リンク」をカンバス上にドラッグ&ドロップします。
  4. シンボルプロパティパネルを開きます。
  5. 任意の数のプロパティを適宜変更します。
  6. このドキュメントをsymbol.htmとして書き出します。書き出し対象は「CSSと画像」に設定します。
  7. 書き出されたファイルを見つけ、主に使用するブラウザでプレビューしてみます。

書き出されたリンクがFireworksで表示されていたものとまったく同一であることが確認できます。:link:visited:hoverおよび:activeの各仮想クラスのカラー、修飾、太さといったプロパティも、すべて維持されていることが確認できます。

Dreamweaverで関連CSSファイルを開くと、図5に示すような、すべての関連ルールが作成されていることが確認できます。アンカー向けのCSSルールがどの順序で生成されるかは、すべてのステートに常に正しい書式が適用されるようにする上で非常に重要です。アンカーのID「#リンク」は、Fireworksのオブジェクト名に基づいて生成されています。

リンクHTMLコンポーネントを書き出すことによって生成されたCSSルールの例

図5. リンクHTMLコンポーネントを書き出すことによって生成されたCSSルールの例

List Itemシンボルの使用

より的確な意味合いのマークアップをFireworksから出力できるようにすることへの支援を求められた際、筆者は、順不同リストを作成できるようにすることを最優先課題として取り上げました。だからこそ、強化版に収録されている新しいシンボルのList Itemには細心の注意が払われています。

シンボルの名前がList Itemにはなっているものの、たいていの場合、このシンボルはリンクを作成するために使用します。この解説では、矛盾しているかのような印象を与えかねないので、もう少し詳しく説明することにします。Webサイトには必ず何らかの形のナビゲーションが存在します。ナビゲーションの構成を意味論的な観点から考えた場合、これらはあくまで一連のリンクのリストに過ぎません。つまり、List Itemはリンクを作成するためにピッタリのシンボルと言えます。

List Itemシンボルには、以下の編集可能プロパティが含まれています。

  • Text(テキスト)
  • Color(カラー)
  • Font(フォントファミリ)
  • Size(フォントサイズ)
  • Weight(フォントの太さ)
  • Node type(ノードタイプ)– normal、first、lastまたはbothで指定
  • Is link?(リンクであるかどうか)– trueまたはfalseで指定
  • 標準のリンクシンボルに用意されているすべてのプロパティ

このシンボルでは「Node type」プロパティと「Is link?」プロパティが最も重要になります。「Node type」では各リスト項目がマークアップ上で何を表すのかを指定し、「Is link?」では当該シンボルによるアンカー出力の有無を指定します。アンカーを出力すれば、リンクシンボルを使用する場面同様に、適切なスタイルの適用が可能になります。

「Node type」プロパティの設定とその効果を以下に示します。

  • Normal – 書き出し時に生成されるマークアップ:<li>Text</li>
  • First – 書き出し時に生成されるマークアップ:<ul><li>Text</li>
  • Last – 書き出し時に生成されるマークアップ:<li>Text</li></ul>
  • Both – 書き出し時に生成されるマークアップ:<ul><li>Text</li></ul>

様々なList Itemシンボルを組み合わせ、そして、これらのNode typeを正しく設定することで、子リスト項目さえも含む、完全な順不同リストを書き出すことができます。

次に、具体例を用いながら解説することにします。

  1. 新規ドキュメントを作成します。
  2. 共有ライブラリを開きます。
  3. HTML Enhancedフォルダを展開し、その中になる「List Item」をカンバスの左側にドラッグ&ドロップします。
  4. シンボルプロパティパネルを開きます。
  5. Textプロパティの値を「Link 1」に変更します。
  6. メニューから編集/クローンを選択し、このシンボルのクローンを作成します。
  7. 複製されたシンボルを右に50px移動させます。
  8. 移動したシンボルのTextプロパティの値を「Link 2」に変更します。
  9. このシンボルをクローンし、以前同様に移動してから、Textプロパティの値を「Link 3」に変更します。
  10. もう一度、シンボルのクローンと同様の移動操作を行います。
  11. このシンボルのTextプロパティの値を「List item」に変更します。
  12. このシンボルの「Node type」の値を「last」に設定します。
  13. 「Is link?」の値には「false」を設定します。
  14. Link 1シンボルを選択し、「Node type」の値を「first」に設定します。
  15. このドキュメントをul.htmとして書き出します。書き出し対象は「CSSと画像」に設定します。
  16. ul.htmをDreamweaverで開き、そのソースコードをコードビューで確認してみます(図6参照)。

    FireworksのList Itemシンボルによって生成されたマークアップ

    図6. FireworksのList Itemシンボルによって生成されたマークアップ

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

リスト項目を縦に整列した場合に出力される項目間の無効なクリア<div>タグ

図7. リスト項目を縦に整列した場合に出力される項目間の無効なクリア<div>タグ

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

縦型のナビゲーションを実現するための正しいコード

図8. 縦型のナビゲーションを実現するための正しいコード

このような場面で期待通りの結果を得るためには、書き出し処理が完了してから「仕切り」的な要素を<li>タグ内に手作業で移動し、必要に応じてスタイルを幾分調整する必要があります。

フォーム要素のシンボルの使用

今回の強化されたバージョンでは、<form>要素が最も徹底的に見直されています。これまでもWindows用とMac用のフォーム要素は装備されていましたが、特にMac用のものは、その有用性に疑問が残るものでした。

今回の強化ではWindows、Mac両方の要素群がアップデートされており、一段と多くのプロパティが編集可能になるとともに、適切かつ有効なマークアップおよびスタイルが書き出されるようになっています。また、強化版にはHTMLのTextArea要素も収録されています。

フォーム要素に用意されている編集可能プロパティは以下の通りです。

  • TextまたはLabel(テキストまたはラベル)
  • Color(カラー)
  • Font (Family)(フォントファミリ)– 様々な標準の選択肢あり
  • (Font) Size(フォントサイズ)
  • (Font) Style(フォントスタイル)
  • (Font) Weight(フォントの太さ)
  • Type(タイプ)– ボタンおよびテキストフィールドに対してのみ様々な選択肢あり
  • State(ステート)– TextArea以外のすべての要素に対して様々な選択肢を提供

ボタンシンボルのTypeプロパティでは、Submit、Reset、Buttonのいずれかのボタンタイプの書き出し・表示を指定することができます。テキストフィールドのシンボルは、標準テキストまたはパスワード入力のいずれかを選択して書き出せます。

Stateプロパティの内容はシンボルによって異なるものの、一般的には当該要素上にポインタが配置された状態のOver、当該要素が選択された状態のSelected、および当該要素が無効化された状態のdisabledを表すことができます(無効化された要素は無効化されて書き出されます)。

フォーム要素を含むドキュメントを書き出す際には、有効かつ標準規格準拠のマークアップが得られるよう、以下の事柄に注意する必要があります。

  1. HTMLフォーム要素シンボルが用いられたドキュメントの書き出し時には、すべての要素が1つの<form>要素内に配置されます。.NET環境の開発ではこの動作が一般的であり、たいていの場合、この動作が問題になることはありませんが、同じドキュメントに検索フォームとメッセージ投稿用のフォームが存在するケースなど、明らかに用途の異なる複数のフォームが1つのドキュメント内に存在するような場面では、フォームの構成を手作業で修正する必要があります。
  2. <fieldset>および<legend>要素が書き出されることは一切ありません。Fireworks上では一連の<form>要素を論理的に定義することができないため、これらの要素は、書き出し後に手作業で追加し、必要であればスタイルを外すことで不可視の状態に保つことができます。

    この余分な手順を踏む必要性について、疑問に思われているかもしれません。これは、すべてのユーザがInternet ExplorerやFirefoxなどの標準的なデスクトップブラウザを使用しているとは限らないからです。つまり、マークアップは可能な限り意味論的に正確に、そしてアクセシブルにする必要があるということです。
  3. ラジオボタンとチェックボックスのみ、それに関連する<label>要素を書き出します。デザイン上で他のフォーム要素向けに可視的な<label>が必要な場合は、このテキストオブジェクトに<lable>タグを付けるようにします。ただし、このケースでもフォームのコントロールIDの値が含まれた「for」属性を追加することで、当該ラベルを所定のフォームコントロールに関連付ける必要があります。

    可視的な<label>タグが不要な場合は、一旦これらのタグをデザイン上から削除し、書き出し処理が完了してからこれらをマークアップコードに追加することができます。この際、CSSを利用して不可視にし直すことを忘れないようにしてください。

フォーム要素の使用に関しては、他にも次の2つの注意点があります。

  • Fireworks上のサイズ指定に関係なく、TextAreaシンボル以外のフォーム要素が高さの値を出力することは一切ありません。高さを指定するとブラウザ間で予期せぬ様々な結果が生じます。テキスト入力用などのスペースで高さを拡張したい場合は、代替策としてパディングを使用するようにします。これにより、テキストの縦方向の整列が保たれます。
  • ブラウザによってはフォーム要素のデフォルトパディング値が異なるため、書き出された要素の幅がオリジナルデザインのそれとは同じにならないことがあります。