さて、今回のリニューアルに際し、いろいろと実験的にやってみました。

画像に幅と高さを指定していない

去年の半ばから、画像（img 要素）に幅（width 属性）と高さ（height 属性）は必要でない気がしてきて、どこかで試してみたい気持ちがあったので、これを期に plucore.jp は画像に一切幅と高さを指定していません。なので Another HTML-lint gateway では軽微なエラーとして警告されますが、基本的には Valid なのでとりあえずは問題ないかと思ってます。

そもそもこの問題については imgにwidthとheightを指定しない理由と言う記事があり、これに関して少しだけ自分なりに反応してみました。

問題提起は上記記事の通り、IE では画像に幅と高さが指定されていると、画像が読み込まれない状態ではその領域が確保された状態で alt 属性値が表示されることになる。逆に指定されていないと alt 属性値の分だけ領域が確保されることになる。

ただし、これを優先させることによってレンダリングに負荷がかかるデメリットも存在する。これに関して思うところは、ケースバイケースで考えられると思います。
画像を多用するような Web サイトでは幅と高さは指定した方がよいとは思います。
逆に今回の plucore.jp のように、そこまで画像を使用していない場合は幅と高さを指定してもしなくてもよいと思います。

div 厨じゃないけど div を多用

無意味に、レイアウト用途で div 要素を使うのはよろしくない。だけどキチンと意味付けをして行けば、それはそれでよいと思っている。

右側カラム内を例にしてみます。

<div id="sidebar">
  <div class="advertisement webService">
    <h2><img src="/common/image/common/sidebar/webservice.png" alt="弊社運営Webサービス" /></h2>
    <ul>
      <li><a href="http://makit.jp/"><img src="/common/image/common/sidebar/makit_off.png" alt="商材を探せる。販路開拓ができる。商材情報サイト:Makit（メイキット）" /></a></li>
    </ul>
  </div>
  <div class="advertisement blog">
    <h2><img src="/common/image/common/sidebar/blog.png" alt="Blog" /></h2>
    <ul>
      <li><a href="http://log.plucore.jp/"><img src="/common/image/common/sidebar/plucorelog_off.png" alt="plucore.log" /></a></li>
      <li><a href="http://plucore.jp/column/"><img src="/common/image/common/sidebar/knowhow_off.png" alt="中小企業のためのWeb活用ノウハウ" /></a></li>
    </ul>
  </div>
  <div class="advertisement inquiry">
    <h2><img src="/common/image/common/sidebar/inquiry.png" alt="お問い合わせ" /></h2>
    <ul>
      <li><a href="https://plucore.jp/contact/us.fcgi"><img src="/common/image/common/sidebar/contact.png" alt="お電話でのお問い合わせは042-591-2421まで" /></a></li>
    </ul>
  </div>
</div>

div id="sidebar" 内にある div 要素にはスタイルは定義されていません。それなのに div 要素を定義した理由は以下の3つ。

1. 見出しとバナーがセットなので、div 要素の class 属性でそれが何かを定義
2. 将来性を考え、Web サイトの構成要素を抜き出すことが容易な形にしたかった
3. あまりよろしくないが、今後リニューアル時に何かしらのスタイルを定義する際に利用

複雑にならず、だけど拡張可能な形にするものとして div 要素に class 属性を与えてそれに名前を与えることで、今後”何かで”利用できると信じています。つまり予定が今のところないわけですが。
これの延長線上として microformats がありますが、今のところこれの対応は考えていません。面白い構想だと思いますが、結局ただの草の根的な活動だけで終わるのではないかと思ってしまいます。状況は追いかけてはいますが、個人的にも対応させることはないと思います。

2つ目は XPath で抜き出せるので、どうとでも応用が利きます。これもまた予定がないです。。。

div 要素をレイアウト目的で利用している人が多いですが、もっとセマンティックな方向で使ってみると何かが見えてくると思います。自分自身まだそこまで見えているわけでもないですし、理解もしていないですが、少しずつ勉強していくつもりです。

次回は実際の作業上のお話です。Dreamweaver のテンプレートや SSI をどう使い、効率的にできるかです。
意外と知られていない（？）Dreamweaver テンプレートのあんなことやこんなことを紹介したいと思います。

ちなみに上記のクイズの結果は個人ブログに掲載されているのでそちらを参照。
非推奨要素も答えに入っているのがちょっと卑怯だと思ったり思わなかったり。

XHTML 1.0 で定義されているフォーム関連要素一覧

まずは XHTML 1.0 で何が定義されているかを確認。ちなみに非推奨要素も含めます。

• form
• input
• textarea
• button
• select
• option
• optgroup
• label
• fieldset
• legend
• isindex（非推奨要素）

上記が XHTML 1.0 で定義されているフォーム関連要素の一覧です。
各要素のサンプルページを設けましたのでそちらをご確認ください。

• 各フォーム関連要素サンプル

思えばこれだけあります。主に使用する要素は form,input,textarea,select,option,label 各要素でしょうか。たまに fieldset,legend 要素を使うことがあります。
逆に使う機会がないのが button,optgroup 要素で、button 要素はともかく、optgroup 要素は仕事上だと使うのを躊躇います。個人的には積極的に使っていきたいのですが、世間ではただの option 要素のみで構成されているフォームが大半を占めているので、普段と若干違う挙動をする optgroup 要素はユーザに混乱を招くのではないかと思っているからです。
これが optgroup 要素が一般的になればいいんですけどね。この要素自体の存在を知らない制作者が多すぎるのが問題なんでしょうか。

とは言え UA 側の実装がヘボすぎる点も考慮すべきかもしれません。IE・Firefox・Opera・Safari 共に全て同じ表示をされます。まだ MacIE の方が optgroup 要素の（完璧ではないにしろ）理想的な挙動であると個人的に思います。
下記にスクリーンショットを用意しましたので、確認してみると分かると思います。

• WinIE 6
• Firefox 2
• Opera 9
• Safari 2
• MacIE 5

ちなみに isindex 要素は IE 非対応のようで。
なお、isindex 要素は Transitional,Frameset のみで定義されています。Strict では使用出来ません。isindex 要素を使用せず、input 要素を利用しましょう。

Strict DTD の場合、fieldset 要素以外は form 要素の直接の子要素として配置することが出来ません。必ずブロック要素内にフォーム関連要素を含めるようにしましょう。
また、form 要素のネストはいかなる DTD であっても禁止されています。
label 要素は IE だと for 属性で部品と紐づけなければ一部の要素に対して期待した動作をしてくれないのが悲しい限りです。

とここまででとりあえずフォーム関連のまとめです。isindex 要素は使わないようにしましょう。（知られてもいないでしょうが）

Web サイトを制作する上で障害となるのが対象とするブラウザの線引きです。最近はだいたいどの Web サイトも

Windows

• Internet Explorer 6 以降
• Mozilla Firefox 1.5 以降
• Opera 8 以降

Mac OS

• Mozilla Firefox 1.5 以降
• Safari 2.0 以降
• Opera 8 以降

こんな感じだと思います。多少のバージョンの差異はあると思いますが。
そしてすでに Netscape は黒歴史と化している現状で、これに対応するにしても良くて Netscape 6 が妥当なところだと思います。それ以前の、特に Netscape Navigator 4.x は技術的にも対応するのが不可能です。（他のブラウザと同じレイアウトデザインにすると言う条件であればですが）

自分の中で対応ブラウザの線引きは実装の状況で判断してます。ですので、どんなに古いブラウザでも良くて Internet Explorer 5 か Netscape 6 が限界です。

ただし、全て同じ見た目にする必要性があるかと言ったら疑問でもあります。構造と表現の分離の観点から、1つの文書で複数の見た目を保持することは何らおかしなことではないですし。
そもそもスタイルシートの仕様では出力メディアに応じて振る舞いを変えることが可能となっています。それでもやはり様々な端末の実装が”なってない”のが現実です。
正直モバイルのフルブラウザがメディアタイプの screen 準拠になっているのがどうなのかと。handheld を最優先で、なければ screen を選択するのはアリだと思いますが、handheld さえも切り捨てられているのが納得いきません。

モバイルの話はともかく、技術的に画一的なレイアウトデザインを表現するのはナンセンスです。
究極的な話をすれば、我々のような制作者側が提供する見た目の振る舞いはあくまでお客様からの要望を踏まえたブランディングやユーザビリティを提供し、それ以上はユーザが独自にスタイルシートを用いて自身が望む可読性を確保すべきだと思います。
とは言え、それが様々な要因によって高いハードルであると思います。

未だユーザスタイルシートに関するサポートや、そもそもスタイルシート自体のサポートが弱いブラウザがあることによって、そのことの認知が低いですが、ユーザスタイルシートがあることをブラウザベンダだけでなく、制作者側でもアピールすべきだと思います。

ただやはり、ユーザスタイルシートも含めて、スタイルシートが取っ付きにくいのと、理解しづらいのが最大の難点ですが。

Webサイトを使って何ができるのか？

Webサイトは、「人を集める」「人に伝える」「人に行動してもらう」ということができます。
たとえば、「お客様に最新の商品情報を伝え、資料請求をしてもらう」とか「既存のお客様（もしくは見込み顧客）に情報を定期的に伝え、問い合わせをもらう」など、何かを伝えて行動を促すことが、Webサイトが得意としていることです。
「人を集める」ための手段としては、インターネット上の広告や検索エンジン、紙媒体広告との連動や営業活動との連動など、様々な手段があります。
Webサイトを活用していく上で、最初のハードルは「人を集めること」ですが、その手段は豊富であり、成功と失敗を見極めることも比較的容易です。それなりの努力をすれば、それなりの成果が得られることが、Webサイトにおける集客の魅力であると思います。

Webサイトにおける成果とは？

この連載では、「成果を出すWebサイト」について書いていきますが、そもそも成果とはなんでしょうか？
もちろん、それぞれの会社で目指す目的は異なっているので、その目的を達成することが「成果を出すこと」だと言えます。
ただ、そこで注意しなければならないことは、「どの程度の成果が出ているのかを測定できること」が重要だということです。
成果を測定することができなければ、Webサイトの制作費や広告費などの投資に対して、費用対効果を把握することができません。費用対効果を把握しながら、Webサイトを有効に活用していくためには、測定することが可能な成果を目標とすることが大切です。
具体的に言えば、問い合わせ数、資料請求数、申し込み数、アクセス数、などの数値で評価できる目標を立てることが重要です。

Webサイトにも数値目標を！

どのような会社であっても売上目標や利益目標などの数値目標を立てて経営を行っています。営業活動においては、訪問件数や商談件数などの販売プロセスの中での目標と最終的な売上目標を数値目標として立てることが常識です。
それなのに、Webサイトには数値目標がない企業が意外に多いのではないでしょうか？
特にBtoB のビジネスをされている企業では、Webサイトに数値目標がない企業が多いと思います。これは、会社のWebサイトが直接的に売上につながるケースが少ない（最終的には営業マンが訪問して仕事を取るため）ということが原因のひとつだと思います。

たしかに、BtoB企業のコーポレートサイトが、直接的に売上につながることは少ないと思います。しかしながら、単にWebサイトを置いておくだけではなく、積極的に活用していく意識を持てば、普段の営業活動と連動させることで商談の糸口を作ったり、既存顧客との関係強化を図ったりすることは可能です。
そのような観点でWebサイトを活用するためには、アクセス数やユーザの訪問件数などの目標を立てることは、非常に有効であると考えます。
目標があって初めて、目標達成のための活動やサイトの内容を明確にすることができるからです。

「成果を出すWebサイト」を作り、運営していくための基本は、「数値目標を立て、費用対効果を把握しながら、目標達成のための適切な行動を行うこと」であると考えています。
次回からこのための方法論について書いていこうと思います。次回は、「妥当な数値目標の考え方」というテーマを書く予定です。また読んでいただければ幸いです。

とまあ早くも順応したわけですが、それでもたまに操作を間違ったりします。ちょっち本格的に覚えるためにもここに残しておきます。

表記の例

C-p：Ctrl+p

M-v：Alt+v

注：M キーを Alt と表記しましたが、これはメタキーなので Esc でも良いです。

これだけ覚えればだいたい問題ないと思ってます。と言うかこれ以外にほとんど使うことがない。。
ちなみに1文字でも何か書いたら自動保存される設定になっているので、上書き保存を意識することは全くありません。
（と言うよりこの辺の設定は全て taro さんのをそのまま引き継いだだけなので、どこをどうしたらそれが可能になるのかとか全然知らないと言うオチ。多分ググれば出ると思いますｗ）

と言うことで、id:ikasam_a さんから Plam の end アクションの処理が冗長になってるとのご指摘をいただき修正してみました。
（feedback ありがとうございました！）

ファイルをダウンロード

それから、他にもいくつか。

• メール送信時、TracFormat なリンクを取り除く部分が甘かったので修正した
• 改行を [[br]] とするフィルタを用意して、入力されたとおりに出力するようにした
• 本当は [[br]] を打ってもらえば良いんですが、そうするとメール送信時にそれを取り除く羽目になるなぁと思って、フィルタで解決するようにしました。
• MANIFEST ファイルがひどいことになっていて、0.03 〜 0.05 までの Plam の tar ボールが入ってしまってたので修正しました。
  0.06 をダウンロードした方、ゴミが混ざっててすいません。

やはり、My Ticket は CSV を引っ張ってきたいなぁと思うのですが、レポートの SQL によって項目の並びが変わってしまうのでどうしようか迷っているところです。
ブランチを切って社内特化でもいいかなぁ。

ちなみにプラコアでタスク管理に使っている Trac は下記のように手を加えてチケットの期限の項目を作っています。

trac.ini

[ticket-custom]
term = text
term.label = 期限
term.value = 2007/MM/DD

MyTicket の SQL

SELECT p.value AS __color__,
   (CASE status WHEN 'assigned' THEN 'Assigned' ELSE 'Owned' END) AS __group__,
   id AS ticket,
   c.value AS 期限, summary, component, version, milestone,
   t.type AS type, priority, time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t, enum p
    LEFT OUTER JOIN ticket_custom c ON (t.id = c.ticket AND c.name = 'term')
  WHERE t.status IN ('new', 'assigned', 'reopened') 
AND p.name = t.priority AND p.type = 'priority' AND owner = '$USER'
  ORDER BY (status = 'assigned') DESC, p.value, milestone, t.type, time

担当者別一覧

ついでに担当者別一覧という新規のレポートも作っているので公開します。デフォルトでアサイン済みの担当者別チケット一覧があるのですが、アサインしていない一覧もあればいいと思って作りました。

人数が少ない故にできることかもしれませんね。

SELECT p.value AS __color__,
   owner AS __group__,
   id AS ticket,
   c.value AS 期限,
   milestone,
   (CASE status WHEN 'assigned' THEN '* '||summary ELSE summary END) AS summary,
   component, t.type AS type, time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t,enum p
    LEFT OUTER JOIN ticket_custom c ON (t.id = c.ticket AND c.name = 'term')
  WHERE status IN ('new', 'assigned', 'reopened')
AND p.name=t.priority AND p.type='priority'
  ORDER BY owner, p.value, (status = 'assigned') DESC, c.value, milestone, t.type, time

XHTML+CSS Slideshow Tool とは

• XHTML+CSS Slideshow Tool Ver 1.0 サンプル ファイル
• PDF 印刷したサンプル

純粋な XHTML と CSS の組み合わせで PDF 印刷することを前提に作られたプレゼンテーションツールです。
XHTML 文書の中身は S5 と似たような構造になっています（かなり単純化されてますが）。
なので JavaScript によるエフェクトは一切ありません。個人的にそんなのはいらないと思っているし。

とまあそのままコピペですが、目的はあくまで PDF 印刷です。ブラウザ上で見ることも出来ないことはないですが、JavaScirpt を使ってどうこうしなければ、それこそ S5 のようなツールのようにしなければ少し難しいです。ページ送りとか。

XHTML+CSS Slideshow Tool の XHTML 文書の中身

別に XHTML でなければならないわけではないです。HTML 4.01 でも構いませんが、将来的の構想（そこまで壮大な話じゃないけど）では HTML より XHTML の方がよいので XHTML にしました。
将来的な構想を考えれば XHTML よりも XML の方がよいですし、むしろそっちの方が現段階でも XSLT との組み合わせでやれば出来てしまう。だけどそれじゃちょっちどころかかなり敷居が高くなってしまうので XHTML を選択したと言う背景もあったりなかったり。
（でも XML+XSLT の方が汎用性が高いからこっちの方がよかったり。XML+XSLT パターンのスライドショーツールも作ってみようかしらｗ）

それはともかく、このプレゼンテーションツールの基盤である XHTML 文書の中身ですが、以下のような構造文書になっています。

• html
  • head
    • title
  • body
    • div id="contents"
      • div class="canvas"
        • h1
        • 本文
    • div id="footer"

必要な要素はこれで事足ります。
div class="canvas"（以下キャンパス）がスライド1ページに該当するので、ページを分けたい場合はキャンパスを増やしていってください。

head 要素に profile 属性が指定されていますが、これは link 要素に rel="made" のリンクタイプを記述しているためです。XHTML（だけじゃなく HTML 4.01 でもそうなんですが）では定義されていない値なので、プロファイルを指定してこの値を定義してあげなければならないためです。
この辺の詳しい話は神崎氏の「名前のウェブとXHTML文書のプロファイル」を参考にしてください。

ちなみにスタイルシートは2つ読み込んでいます。

• slide.css
• review.css

slide.css

対象メディアは印刷・スクリーン
これがメイン。対象メディアにスクリーンを入れたのは多少なりともスタイルシートによるレイアウトを楽にするため。PDF 印刷を目的にしているので、スタイルシートを書く度に印刷プレビューを行うのは相当なまでのストレスになるので、ある程度ブラウザ上で見て、たまに印刷プレビューをして問題ないか確認するフローがベターだと思ったのでこうしました。

review.css

対象メディアはスクリーン
ブラウザ上で見るためだけのスタイルシート。本来ならば不要だけど、少しはこっちも気を配った方がいいと思ったので一応定義しました。スタイルシートファイルもあります。たいしたこと書いてないですが。

スタイルシートの仕組み

あまり中身を見せたくないって言うかリファクタリングなんてしてないんでかなり酷いことになってます。とは言え、今回はここが本題と言うかメインなので、やらないわけにいかないんですが。。

YUI Fonts CSS の利用

必須じゃないけどあると便利。なライブラリ。利用できるものは全て利用するｗ

スライドのヘッダを実現するには

自分の作ったスライドショーツールではプレゼンテーションのテーマ（タイトル）をヘッダに示していますが、人によってはスライドの見出しをヘッダに持ってくる人もいると思います。で、個人的に自分は前者なので今の設計では後者の手段は実現しづらいかもしれません。
これは文書構造の問題です。スライド1ページに対して見出しは h1 要素なので、プレゼンテーションのテーマをそれより上位の見出しは存在しないのためです。もっとも、title 要素を上位として位置づけたのが今回のツールですが。少しこの辺は考えてみるつもりです。

それはともかく、このヘッダは title 要素を可視化させてヘッダとして利用してみました。

head,
title {
    display: block;
}

title {
    position: fixed;
    top: 0;
    right: 0;
    width: 100%;
    padding: 1em 2em 1em 0;
    background: #ccc;
    text-align: right;
    font-size: 122%;
    font-weight: bold;
}

まず head 要素と title 要素を可視化させるために display プロパティを使用します。head 要素以下のメタデータ等はただ単に見えないようになっているだけで、実際にはこうしてスタイルシートで可視化させることが可能です。この詳しい話は「link 要素を可視化してみる」を参考にしてください。

title 要素をヘッダとして利用するには全スライドに対して上方部分に固定させる必要があるため、position: fixed; を利用します。ちなみに position プロパティの fixed 値は Windows Internet Explorer 6 では未対応のため、この時点で対象ブラウザから外れます。

フッタを下方部分に固定させる

フッタもメタデータから出してもよかったのですが、これはこれで少し面倒だったので通常の要素で構成しました。

div#footer {
    position: fixed;
    bottom: 0;
    left: 0;
    width: 100%;
    padding: 0.5em 1em;
    background: #ccc;
    line-height: 1;
    font-size: 14px;
    font-family: Arial,Helvetica,sans-serif;
    font-style: normal;
    font-weight: normal;
}

    div#footer p {
        font-size: 100%;
    }

実はここで問題が発生しました。文字サイズがスライドの1ページと2ページ以降で変化するのです。上記では文字サイズを px 単位で指定していますが、当初は YUI の通りパーセント単位で指定していました。そうすると文字サイズが変化してしまったので絶対指定の px 単位にしました。まあ IE は対象ブラウザから外れているので問題ないかとｗ

キャンパスを定義する

ここはそれほど難しく考える必要はなく、要はヘッダとフッタに被らなければいいだけなので、以下のように定義しました。

div.canvas {
    page-break-after: always;
    position: relative;
    top: 5em;
    left: 0;
    padding: 2em 4em;
}

ヘッダとフッタに被らなければいいとは言え、キャンパス内容があまりにも長くなる（A4 用紙の高さを超えるくらい）とさすがにどうにもならないですが。overflow プロパティ使ったところで PDF 印刷時には意味をなさないので。ですのでこの辺は長くならないよう気をつけてください。文字サイズや行間、マージンや余白を調節するなりして対処してくださいとして言えません。。

ここで page-break-after プロパティを利用していますが、これは印刷時にこの要素以降で改ページされるためのものです。ちなみに要素以前に改ページを行いたい場合は page-break-before: always; となります。
値が always ですが、page-break-after,page-break-before プロパティでは以下の値が定義されています。

auto

改ページについて制御しない。初期値です。

always

必ず改ページを行う。

avoid

改ページを禁止する。

left,right

次のページが左右のページになるように強制的に改ページさせる。

今までスタイルシートはブラウザ上の見た目を制御するだけと言う認識が先行してましたが、印刷や音声ブラウザに対してもそれ専用のプロパティが存在するので是非とも利用してください。

印刷時にのみ適用されるスタイル

今回は PDF 印刷を目的としているので、印刷に特化した形になりますので必要に応じて最低限の対応はしておきたいところです。

@media print {

    div.canvas.cover h1
        margin: 2em 0;
        font-size: 3.5em;
    }

    div.canvas.cover p.Author {
        width: 12em;
        margin-left: auto;
    }

    div.canvas a {
        color: blue;
    }

    div.canvas a::after {
        content: "（"attr(href)"）";
     }

}

印刷時に適した形で見出しや段落のマージン等を設定します。なお class 属性値の cover は表紙の意味を示しています。表紙くらいはちょっとだけ飾らないと様になりませんからｗ

ハイパーリンクは PDF ファイルや紙媒体に限らず印刷されるとそのリンク先が分からないので、URL を文字列として表示させてあげる必要があります。
上記では a 要素の直後に URL の文字列を括弧で括って表示させるようにしています。ちなみに相対パスで記述すると意味が分からなくなるので、できれば絶対パスで記述して欲しいところです。

ここで @media 用いて印刷に適したスタイルを定義していますが、@media を利用するには通常のセレクタを利用するように { } で囲う必要があります。意外と忘れがちになりますが、@media の他にも @page,@font-face があります。

最後に

個人ブログの方でも書きましたが、正直言って実用性はそれほど高くはないです。ただ単に作ってみたかっただけなので。でも考え方次第で PDF 印刷と言う縛りがあるにしろ、XHTML 文書とスタイルシートでこうしたものも作れると言うことを表に出せただけでもよかったかと。
スタイルシートで何でも出来るとは言っても、文書構造があって初めて成り立つので、スタイルシート（見た目）先行で考えるのはよろしくないです。今回のスライドショーツールの XHTML 文書が完全に正しいかははっきり言って微妙ですが、でも今考えられる限りではこれがベストだと思ってます。

ちなみにスライドごとにデザインを変えられたり出来るので、面白いことは出来そうです。（ヘッダとフッタはさすがに無理ですが）

ページ内で画像を使用する際の操作が簡単になりました

Movable Type 4では、多くのお客様にとってわかりにくいと言われていた「画像を使用する時の操作」が大幅に改善されました。画像の選択が容易になったほか、編集画面で画像の配置を確認できるようになりました。
Movable Type 4 での編集画面イメージ

従来より、弊社では「継続的にコンテンツを増やし、サイトを成長させていくことの重要性」をお客様にご提案しています。Movable Type 4は、継続的にサイトを成長させていくためのプラットフォームとして、非常に有効なツールであると考えております。

制作費用は、30万円から承ります

Movable Type 4を使用したWebサイトの構築は、30万円から承ります（ライセンス費用5万円は別途必要）。
ご興味のある方は、ぜひプラコアの問い合わせフォームからご連絡ください。

既存のお客様には、アップグレードのご案内をお送りします

過去に弊社で、Movable Type 3 を使用してサイトを制作させていただいたお客様には、順次アップグレード作業についてのご案内をお送りしてまいります。どんなに遅くても8月中にはお送りいたしますので、ご期待ください。

Makit のスタイルシートのファイル分割を元に解説します。

HTML 文書から読み込まれるスタイルシートのファイル構成

• import.css
  1. default.css
  2. elements.css
  3. layout.css
  4. header.css
  5. footer.css
  6. sidecontents.css
  7. table.css
  8. contents.css
  9. style.css
  10. top.css
  11. clearfix.css
  12. niftyCorners.css

ファイルは大きく分けて3つの役割で構成されています。

1. 要素の再定義
2. 大枠のレイアウト定義
3. 部分装飾の定義
4. その他

それぞれの役割をスタイルシートのファイルに当てはめると以下のようになります。

要素の再定義

• default.css
• elements.css

レイアウトの定義

• layout.css
• header.css
• footer
• sidecontents.css

部分装飾の定義

• table.css
• contents.css
• style.css
• top.css

その他

• clearfix.css
• niftyCorners.css

import.css から呼び出されるスタイルシートの順番は重要で、マクロな定義からミクロな定義へと段階的に狭めていくのがセオリーです。
これは @import 宣言を使用した場合、考え方として呼び出すファイルの @import 宣言に呼び出されるファイルが展開されると認識すると分かりやすいかもしれません。
ソースコードで示すと分かりやすと思います。

例：import.css のソースコード

@charset "utf-8";

@import "hoge.css";
@import "foo.css";

例：import.css から呼び出される hoge.css のソースコード

@charset "utf-8";

p {
    color: yellow;
}

例：import.css から呼び出される foo.css のソースコード

@charset "utf-8";

p {
    color: red;
}

認識として、import.css では以下のように起こっている。

@charset "utf-8";

p {
    color: yellow;
}

p {
    color: red;
}

@import 宣言がされた順にスタイルシートは読まれていくので、マクロの定義を先に持っていき、ミクロの定義を後ろに順に宣言していきます。

各スタイルシートの解説

default.css

要素の再定義を行っているファイル。これは wu さんの「デフォルトスタイルの差異を無くすCSS」を拝借して、さらに自分でいろいろ変えてます。

elements.css

default.css はブラウザ間の差異を可能な限り吸収したスタイルシートですが、elements.css はその Web サイトに似合った要素の定義を行います。なので Web サイトごとにこの中身は違います。

layout.css

大枠のレイアウトを定義したスタイルシートです。Makit では3カラムになっているので、その記述がされています

header.css

ヘッダ部分のレイアウトを定義したスタイルシートです。本来であれば layout.css に記述するところですが、細分化してヘッダ・フッタそれぞれでファイルを分割しました。
これは Makit の HTML テンプレートを Template-Toolkit を利用していることにも関係しています。

footer.css

フッタ部分のレイアウトを定義したスタイルシートです。

sidecontents.css

左右のブロックを定義したスタイルシートです。ここは分割していません。理由はごにょごにょ（何

table.css

テーブル要素を使ったレイアウトの定義です。フォームなどのテーブルを使用する箇所が多いため、後述する contents.css 内に記述するよりテーブルは別ファイルで定義しました。ただの横着ですｗ

contents.css

コンテンツ内のレイアウトを定義したスタイルシートです。主にログイン画面や商材の一覧、詳細画面が定義されています。

style.css

コンテンツ内の装飾を定義したスタイルシートです。かなり細かいものはここに全て放り込んでます。

top.css

トップページのみで使用するスタイルシートです。トップページは他のページとデザインが異なるので、一括でこのファイルのみで完結させています。（大枠のレイアウトは別ですが）

clearfix.css

ClearFix のみを記述したスタイルシートです。同じ定義をいたるところに分散させるより、一カ所にまとめてしまった方が分かりやすいと思い、こうしました。ただし複数のファイルに跨いで定義されていることになるので、あまりオススメはしませんが。。。

niftyCorners.css

Nifty Corners Cube で配布されている角丸を実現する JavaScript ライブラリのスタイルシートです。詳しくは Nifty Corners Cube にて。

スタイルシートは分割定義していくもの。1ファイルに全てを詰め込むのではなく、目的や用途に応じてファイルを分割し、管理・運営をスムーズに進めていくための考え方です。
まだ自分の中でしっくりくる管理方法を見つけていませんが、当面は上記のような形になると思います。

id:amachang 氏の「マークアップエンジニアはどこへ向かうべきか」を見て、昨日いつも通り八王子のお店で飲みながら考えてました。

自分はマークアップエンジニアです。(X)HTML と CSS しか書けません。JavaScript や Perl、PHP 他に DB 関連や Apache のインストールさえもやったことがありません（Apache のインストールは8年くらい前に1回だけやりましたが、あっさり挫折したり。。）。
じゃあ危機感を覚えてないかと言われたら「NO」です。危機感とはちょっと違いますが、やりたいことがあって、そのために JavaScript なり Perl なり XSLT なりを勉強していきたいと思っています。そう思いつつもう1年（どころじゃないですが）経ってしまい、結局動けずにいる←結論。

そう言った行動できていない現状には危機感を覚えていると言っても良いかもしれません。
正直、クライアントサイド（HTML もそうですが、JavaScript とか）よりもサーバサイドが今覚えるべきことだと思っています（技術的な分野以外だとプロジェクトマネジメント方面もそうですが、人がいない今だと優先順位はちょい低いと思っている）。

XML をアレコレパースしてうにょーん（何）とかやりたかったり、そもそも自分でいろんな API も作ってみたいなぁとか思うわけです。そのためにはサーバサイドの何かを覚えていくしかないかな、と。taro さんお願いします。

でも1つだけ言いたいのは、(X)HTML と CSS”しか出来ない”とか”しか書けない”人が淘汰されるかと言ったらそうじゃないと思う。会社に1人でも何かしらの能力が高ければそれに似合った仕事が割り当てられるし、他の人のヘルプにも入れるし、時間的制約がある中で物量をこなせる人とか、いるわけじゃないですか。組織の中でやっている人は分かると思いますが。
もちろんそれに甘んじるかどうかは本人次第だと思いますが、ニーズと言う意味で言えばマクロでもミクロでもあると思う。そこまでに到達できる人が少ないだけで、HTML の仕様さえも知らないエンジニアはいっぱいいるし、どう考えてもスタイルシートで再現しずらいデザインをあげるデザイナもいるし、HTML なんて知らずに見た目だけのテーブルレイアウトをする Web デザイナもいる。

おざなりになりがちな HTML を武器にすることは必要不可欠な要素だと思う。Web 全体で仕様通りの HTML を書ける人が半数を超えたらニーズとして失うかもしれない。そこに固執するならば。
だけどその先が JavaScript だったり Perl だったりの他言語なのかと言ったら必ずしもそこだけじゃない。マーケティングかもしれないしプロマネかもしれないしコンサルティングかもしれないし他の何かかもしれない。

と言うわけで、「CSSer ステップアップカンファレンス」やりませんか？に賛同させてもらいます。具体的にどのような内容を行うつもりなのかお伺いしたいところです。

タイムマネジメントは、個人として意識することも重要ですが、一緒に仕事をするチームとして意識することでより高い成果が望めるのではないかと思います。
ということで、プラコアのタイムマネジメントをちょっとご紹介します。

まずはタスクを洗い出す

時間を有効に使うためには、「やるべきこと」と「やりたいこと」を洗い出して、それを「いつやるのか」を決めることが大切です。

プラコアでは、Tracにできるだけ細かくチケットを発行することでタスクの洗い出しをやっています。Tracの中で、優先順位や期限を把握できるようになっています。
自分と他のメンバーのタスクが把握できて便利です。

タスクをどこまで分解するかは、仕事の内容や人それぞれの好みにもよるのですが、個人的にはできるだけ細かく分解した方が良いと思います。1つ1つのタスクが細かい方が短時間で解決できるので、仕事にリズムが生まれると思うのです。

時間に区切りをつけてゴールを設定する

効率よくタスクを消化するためには、「いつやるか」が重要だと思います。1日をいくつかのブロックに分解して、そこにタスクを配置していきます。

私の場合は1日を「午前」「午後3時まで」「午後6時まで」「夜」という4分割にしています。それぞれのブロックで、「このタスクを解決する」ということを決めています。1日に4回ゴールがあることで、ゴール間際の追い込みが何回もできて効率アップにつながると思っています。特に期限間際にならないと仕事が進まないタイプ（わりと、みんなそうですよね）の人におすすめです！

さらに、1日の中のブロックには、それぞれ役割を持たせます。たとえば、以下のような感じです。

• 午前は頭を使う仕事やハードな仕事
• 午後3時までは、気分良くできる仕事
• 午後6時までは単純作業
• 夜はゆったりと考える仕事

いつもちょうど良いタスクがあるわけではないので、必ずしも思い通りにはなりませんが、1日の中でリズムをつくることが大事だと思います。
また、自分の中で最もパフォーマンスが上がる時間帯を見つけておけば、その時間帯に難易度の高いタスクを配置することで全体の効率を高められます。

チーム内の決まりを作る

タイムマネジメントは、結局のところ「計画を立てて、自分がそのとおりにできるように工夫すること」だと思います。
そのように考えると、1人だけでそれを意識してもうまく行かない場合が出てきます。他のメンバーからの依頼事項やチームとしての段取りがあるからです。

そこで、プラコアでは次のようなルールを決めています。

• 帰宅前に次の日の午前中のタスクを宣言して必ず実行する（いまは次の1日のタスクを報告しています。そのためのツールがPlamです。）
• 午前中は雑談や相談はしない
• 午前中は1人でタスクを完結できるように段取りする
• お昼の時間にタスクの進捗を相互チェックする（あーこれはできてないや）

「まずは、午前中だけはきちんとマネジメントできるようにしよう」という発想です。実際にできているかどうかの相互チェックが最近甘くなっているので、気を引き締めないといけませんが、ルールを決める前よりは仕事がやりやすくなったと思います。

うまく表現できていないと思うのですが、タイムマネジメントのポイントは、「いかに波に乗るか」だと思います。
チームとして「波に乗れる」マネジメントができたらいいですね。

はてなスター設置しました

ブログ記事の横にはてなスターを押すボタンが付いていると思います。
はてな ID をお持ちの方は是非ポチポチ押してあげてください。

Plam 0.06 リリースします

Plam-0.06.tar.gz

以下の変更を加えました。

• パスワード変更できるようにしました
• メールアドレスを変更できるようにしました
• チケットの URL へリンクするようにしました
• メール送信時に TracFormat なリンクを除去するようにしました

チケットへのリンクがちょっと力業なので、この変更は微妙かもしれません。
My Ticket は RSS ではなくて CSV とか引っ張ってくるようにした方が良いかな。

何かご意見などあればよろしくお願いします。
ソースコード読んでおかしいところがあるとか、Catalyst の使い方でおかしいところがある等のツッコミは大歓迎です。

• Firebug Japanese
• Google Browser Sync
• Html Validator
• Tab Mix Plus
• Japanize
• Save Link in Folder
• Wrap Bookmarks Toolbar
• Stylish
• IE Tab
• Opera View
• tabgroups
• MR Teck Link Wrapper

Firebug Japanese

ページ内の DOM・HTML・CSS・JavaScript を解析してその場で一時的に書き換えたりデバッグしたりと、かなり便利ですよね。使っている人多し。

Google Browser Sync

ブックマーク・履歴・Cookie・セッションその他いろいろの情報を Google Browser Sync の入った他の Firefox と並列化できる最強の拡張機能。Firefox を新規でインストールした時は本当に頼りになる。
ただし初回起動時はかなり重い。

Html Validator

そのページの HTML 文書をその場で Validator にかけて文法チェックしてくれる拡張機能。最近ようやく日本語化してくれた。

Tab Mix Plus

定番。タブの拡張ではこれを超えるものは無い。タブのフォーカス設定があるのが最大の理由。あとタブ上でマウスホイールでタブの切り替え。重要。

Japanize

英語の Web サイトを日本語化してくれる拡張機能。有名どころの Web サイトならばほとんどに対応してます。英語読めない人にオススメ。自分みたいな。

Save Link in Folder

ファイルを保存するディレクトリをあらかじめ登録しておいて、ダウンロード時に選択できる拡張機能。頻繁にファイルをダウンロードする人向け。

Wrap Bookmarks Toolbar

ブックマークツールバーを多段表示してくれる拡張機能。ブックマークレットを多用する人向け？　でもブックマークにキーワード設定してロケーションバーで呼び出す方が簡単だったりする。。。

Stylish

ユーザスタイルシートの作成を支援してくれる拡張機能。ドメインごとに作れるのでわざわざテキストエディタを開かずにその場で書けるのが楽です。

IE Tab

Firefox のタブ内で、開いているページを Internet Explorer で開く拡張機能。わざわざ IE を起動しなくてよいので便利。
IE View よりこっちの方が個人的に好み。

Opera View

開いているページを Opera で開く拡張機能。ちなみに IE Tab と違って Opera が起動します。たぶんただ単にページの URL を Opera に渡してるだけっぽいw

tabgroups

タブをグループ化してくれる拡張機能。タブを多く開く人向け。ちょっち重いのが難点。

MR Teck Link Wrapper

長い URL を折り返してくれる拡張機能。開発時には使用しない方が良いです。あくまでブラウジング時に利用する感じで。

かなりマイナーな拡張機能も混じってますが、大抵は有名どころかと。
これらが無いと Firefox は使いづらいですよね。

さて、
何かの企画を立てるとき、お客様（や社内）にプレゼンをするとき、ちょっとしたデータを示すことができるとグッと説得力が増してきます。
企画を立てる仕事をしている人は、きっとデータ集めで苦労した経験があると思います。企画を立てることが仕事ではなくても、自分の考えているアイデアを裏付けるデータが欲しいと思う人は多いと思います。

私も「たった100人でもいいからアンケートができたらいいのに」「自分が聞きたいことに皆が答えてくれたらいいのに」と思ったことは数知れずですが、なかなか簡単にアンケートはできません。
リサーチ会社はたくさんあるのでお金を掛ければ、それなりに情報を集めることができますが、そんなに気楽に使える値段ではありません。

ちょっとしたアンケートをしたい（しかも無料で）というときに使えそうなサイトがないだろうか？
そんなに都合のいいものが･･･

あるんです！！（下手な通販番組みたいでごめんなさい。）

アンケート100人に聞きました！というサイトです。このサイトでは、無料で簡単にアンケートを作成できます。いまでもかなりの量のアンケートが登録されているようです。
試しに1つアンケートを作成させてもらいました。「取引先の住所や電話番号を調べるときに何を使って調べますか？」というアンケートです。
我ながらあんまり面白くないアンケートにしてしまったので、残念ながらあまり回答は集まりませんでした。（2週間で10件だけ･･･）
私のアンケートは、いまいちでしたが、皆が興味を持つようなテーマであれば、1週間以内で数10件の回答があるものもあります。数10件でも参考データにはなると思いますので、使い方によっては、役に立つのではないかと思います。

同じようなサイトで、無料アンケートサイト [ ASQ ]というのもあります。

ちなみに、私の作ったアンケートの結果は、下記のような感じでした。

もっと件数が集まれば、アンケート結果からウンチクを垂れてみようとおもったのですが、残念でした･･･。
「Webって、既存のお客さんもけっこう見てるものなんだよね」と言いたかっただけなのですがね。

1. ログイン
2. Trac の My Ticket をリストアップして表示
3. 選んで次へボタン
4. 選んだ項目が入ったフォームを出力
5. 登録してるユーザ全員にメール送信。内容を DB へ保存。

せっかくなので公開しようと思います。
（どうせならリポジトリを公開したいところですが、ちょっと準備不足なため、とりあえず tar.gz に固めておいておきます。）

Plam-0.03.tar.gz
Plam-0.04.tar.gz
（バグを発見したため version 0.04 を公開します）

Catalyst + TT + DBIx::Class で作ってます。
バックエンドには MySQL を使ってます。展開したディレクトリの中には CREATE TABLE する SQL をまとめたファイル db/plam.sql を入れてあります。
lib/Plam/Model/DBIC.pm に DB への接続に関する設定が書いてあるので適宜調整してください。（元々書いてあるパスワードはでたらめです。）

後は scripts/plam_server.pl するなりして起動してください。

起動したサーバにアクセスするとログイン画面が出ます。
初めは administrator と言う管理者権限のユーザだけ登録されています。
パスワード mypass と入れればログインできます。

パスワードを変更する機能は未実装なので、変更したい場合は DB を直接いじってください。以下のワンライナーで SHA1 ハッシュ化されたパスワードができます。

perl -MDigest::SHA1=sha1_hex -le "print sha1_hex('mypass')"

個々のユーザのプロフィールで Trac の URL、ユーザ名、パスワードを入れるとそのユーザでログインしたときに自動で Trac のチケットを取ってきてリストアップしてくれます。
（弊社で使っている Plam に登録している Trac も弊社内で管理している物です。もし Plam を使ってみようと思ってくださった方は、Plam 内に別なアプリケーションのユーザ名とパスワードを預かることになる点に注意してください。）

メールは Plam に登録しているユーザ全員に配送されます。
メール送信後には DB 上にもデータを貯めるようにしていてその一覧もできるようになってます。
Text::Trac で Trac 記法が使えます。

今後やりたいこと

• パスワード変更
• メールアドレス変更
• チケットにリンク張りたい
• マイルストーン名も出したい