hamashun.com

CSS Nite Vol.12に行ってきました。
今回はVOX、WordPress、Fireworks 8と、盛りだくさんの内容でした。
以下長文です。 まとめ能力の欠如が見られます。

Daily Link

PowersetはGoogleに迫るか？

確かに、検索する時は単語だけを並べますよね。

Google、「Code Search」をお披露目

JavascriptやPHPが多く出てきますけど、CSSもヒットするようです。
少し触ってみます。

Google Code Search

・・・・・・どうやら使いこなすには、正規表現が必須なご様子。

CPSC：ソニーのバッテリーリコール、現時点ではノートPC用のみ

PSPは大丈夫みたいです？

Mac IE 5をお使いの方ごめんなさい

さすがMS。 見事な投げっぱなしジャーマンですね。

USBハムスターホイール

ほ、欲しい・・・・・・！

Note

今日は、web creators conferenceにお呼ばれしてきました。
今回はSEOが議題だったのですけど、いやー為になりました。
アクセス解析などSEO的な事は、実践を通さないと中々学べない部分だと思うので、学校だと勉強しづらいんですよね。
そういう意味で、貴重なお話が聞けたと思います。

何人かの方と名刺交換をさせて頂いたんですけど、家に帰ってから残数を確認した所、残り3枚になっていました。 危ない危ない。
今月末の、卒業制作巨大プレゼンに向けて、最終兵器名刺を作成せねば。
さてどんなデザインにした物か・・・・・・。

ちなみに、某学校の友人とバッタリ出くわしたのは驚きでした。
余りの驚きに、かなり挙動不審に陥っておりました。 あっはっは。

• CSS Nite LP, Disk 1に行ってきました（1）
• CSS Nite LP, Disk 1に行ってきました（2）
• CSS Nite LP, Disk 1に行ってきました（3）

行ってきましたCSS Nite LP, Disk 1！
これは毎月開催されているイベント、CSS niteの有料版なのですけど、実は前回のジャンケン大会で招待枠を頂いたので、無料で参加してきました！
いやーラッキーでした。

会場は千駄ヶ谷駅前の津田ホールです。
付近にコンビニがあったので、からあげをお腹に放りこんでから会場に向かいました。
少し余裕を持って行った事もあって、座席は最前列をゲットです。 最近目が悪くなってきたので、できるだけ前だと嬉しいんですよね。

講演は全部で5つあって、その誰もがWeb業界の著名人です。
5つをまとめて1つのエントリで書くと超長文になってしまうので、2回か3回に分けて書こうと思います。

• CSS Nite LP, Disk 1に行ってきました（1）
• CSS Nite LP, Disk 1に行ってきました（2）
• CSS Nite LP, Disk 1に行ってきました（3）

昨日の続きです。
会場では青山ブックセンターが出店してて、講演される方の著書などを置いていました。
パラパラっと見てみたのですけど、やっぱり買う時は本腰を入れてチェックしたいので、特に買い物はありませんでした。

他にも、FirefoxやOperaの人がブースを出していました。
ニンテンドーDSのOperaは触ってみたかったのですけど、時間が無くて断念。 残念。

• CSS Nite LP, Disk 1に行ってきました（その1）
• CSS Nite LP, Disk 1に行ってきました（その2）
• CSS Nite LP, Disk 1に行ってきました（その3）

3日間もかけたレポートも、いよいよ最後です。
って言うか引き伸ばしすぎです。 ごめんなさい。

時間が結構押していたので、休憩時間は当初の予定から大幅に短縮されて約15分でした。
お腹が空くと眩暈がする体質の僕は、全力疾走で近場のコンビニへ行って、肉まんを胃に詰め込みました。
そして戻ったら、サービスで用意されたタリーズコーヒーが完売していました。 ショック。

準備に忙しくて、前日でのお知らせになってしまいました。
デジタルハリウッド クリエイターズオーディションに出場します。
これは、クラスの中から選抜された卒業制作の作品を、たくさんの人の前で晒しつつプレゼンをする、という物です。
Web業界では人材不足が叫ばれている（らしい）ので、これ幸いと企業の方が大勢いらっしゃるのです。

会場はデジタルハリウッド東京本校になります。
前日でのご案内となってしまいましたけれど、お時間の都合が付く方は、是非いらしてください。
もし、会場でお会いしましたら、どうぞよろしくお願いします。

先週金曜日、27日に行われたクリエイターズオーディションは無事終了しました。
お越し頂いた方にはお礼申し上げます。

僕個人としては、練習の時よりも上手くいって一安心です。
序盤のツカミとしてウケを狙ったポイントで、良い感じに笑いが起こったので緊張がほぐれたのかもしれません。
ちょっとネタに走りすぎたかな、とも思ったのですけど、企業の皆様から頂いた評価シートでも、概ね好評だったようで嬉しい限りです。

明日からは、各企業さんからの詳しいお話や面接等で忙しくなると思います。
これまでとは違った楽しさにワクワクしています。

行ってきましたXHTML+CSS (r)evolution, 2ndに！
最近はCSS niteにも行けてなかったので、久しぶりのイベント参加です。

XHTML+CSS (r)evolutionの講演は、名著Web標準の教科書を執筆された益子さんです。
Web標準の教科書（以下コロコロコミック）や雑誌Web creatorsの連載には、いつもかなりお世話になっているだけに期待も大です。

今回のお題はCSS3のカタチとナカミ。
CSS3の情報で日本語の物はまだまだ少ないので、これはかなり嬉しいです。

今回でひとまずの区切りとなるCSS Nite。 数えればなんと18回目でした。
月イチ無料開催はこれで終わりになり、今後は様々な形態での開催となっていくようです。

今回の内容は第一部が来賓の方3人による、割と告知的な内容。 第二部が主催の鷹野さん（株式会社スイッチ）による「Internet Explorer 7対策」という物でした。
イベントレポートと自分の為の覚書の、両方の意味を込めて記事を書いておきます。

第一部

WebSig24/7、ネクサス　アドバンスセミナー、W2Cから、3人のゲストが、次々にイベントの告知や団体の説明をされました。
CSS Niteは割と実装側の立場のイベントですけど、そうではなくてディレクション側のイベントもあったりで、そちらの方も興味を惹かれました。

第二部

さて、第二部は鷹野さんの「Internet Explorer 7対策」です。
まだまだシェア的にはIE6が多いんですけど、今後はIE7が主流になっていくのは明らか（プリインストールされるから）。 つまり、今はまだIE7対応するかを考えるという段階ですけど、すぐに対応が必須になるという事でした。

第二部では更に、マイクロソフトの人が駆けつけてくれて、鷹野さんや会場からの質問に答えて頂けるなど貴重な情報を聞く事ができました。
（ほぼ？）オフィシャルな情報という事で、本当に貴重でした。 以下にメモできた限りを書いてみます。

• VistaとXPのIE7は、レンダリングは同じ。 セキュリティ的には違う
• スタンダードスタンドアローン版IEは、MS的にはノータッチ。 知りませーん、というスタンス（通行人さん誤字のご指摘ありがとうございます）
• IE6からIE7への自動アップデートの日取りは、現在未定
• 条件付コメント（Conditional Comments）は、あくまで最終手段。 推奨している訳ではない
• IE7のズーム機能は、CSSぽい何かをほげほげして実現しているらしい。 次Ver,では更に進化したズームになるかも
• メイリオの日本語は、やっぱり斜体にならない
• フォントがデフォルトでＭＳ　Ｐゴシックなのは、現在のサイトと表示が違ってくる可能性がある為

こんな感じです。 VistaとXPの違いとか、MSの中の人から直接聞けるとやはり安心感が違います。
ズーム機能の「ほげほげ」の辺りは、企業秘密的内容なのか少し言葉を濁されていたのが余計に気になりました。 逆に調べてみたくなってきますねｗ

IE7で変わる事

• XML宣言が使いやすくなる
• a要素以外にも:hover擬似クラスが使える
• pngのアルファチャンネルやmin-プロパティシリーズ、属性セレクタなど、色んなテクニックが使えるようになる
• !importantを正しく理解する
• BOXの勝手拡張が修正

こうして並べてみると、その他のブラウザにかなり近づいてきた気がしますね。
「BOXの勝手拡張」というのは、IE6なんかで内容の量に応じてサイズが勝手に変わるバグの事で、分かりやすい言い方だなと思いました。

clearfixってどうなん？

BOXの勝手拡張が修正された事によって、IE7にはいわゆるclearfixなどで対応する必要が出てきました。
このclearfixについては色んな意見があるようですが、鷹野さん的には「運用の方が大事なのでは」という感じなようです。
これについては僕もちょっと気になっている部分なので、今度別エントリで書いてみたいと思っています。

2007年のfont-family

僕も先日Vista後のメイリオ及びfont-familyについてという記事を書いたのですけど、やはりこれは皆さん気になる部分みたいです。
鷹野さんが提案するfont-familyは以下の物です（見やすいように改行しています）。

font-family:
 "メイリオ",
 "Meiryo",
 "ヒラギノ角ゴ Pro W3",
 "Hiragino Kaku Gothic Pro",
 "ＭＳＰゴシック",
 "Osaka",
 sans-serif;

font-familyの指定内容についてはさておき（色々と好みが入ってくる問題なので）、印象に残ったのはsans-serifは半角の￥マークがバックスラッシュになるという事。 そ、そうだったのか。
他にもMacで見るVerdanaは微妙に太く見えるなど、細かいけれど気になる部分の豆知識が嬉しい感じでした。

プレゼント貰っちゃいました！

恒例のジャンケン大会では、Dreamweaver プロフェッショナル・スタイルを頂きました！
熟読の上、星5つでamazonレビューを書きたいと思いますｗ

そしてさらに、終了後にプレゼントを受け取る際に、更なる嬉しい出来事が･･････！
でも長くなってきたので、次回に続きます。

っという訳で前回のエントリの続きです。
今回は、わりと単純なレポート&雑記的内容です。 いわゆるただの日記ですごめんなさいごめんなさい。

お礼とか言ってみた

ジャンケン大会で勝ち取った本を頂いた時に、どうやらOperaの人達が来ている事が分かりました。 盗み聞きもとい聞こえてしまった他の人の会話で。

ここであれです。 キュピルリーン！ って頭の中に閃きが走りました。 ニュータイプのごとく。
Operaの人→Kurumaさんは最近Operaで働いているらしい→いるかも！ という事で行動力MAXで話しかけてみました。

Shun：あ、すいません。 Operaの方と伺ったんですが･･････。

Operaの人：あ、はい、そうです。

Shun：失礼ですが、Kuruman.orgの方とかいｔ

Kurumaさん：あ、私です。

ご本人ｷﾀー！ という事で、スターハックの件で色々と教えて頂いた事のお礼を言ってみました。
ちょい緊張してた上にエレベータを待たせていたので、ちゃんとお礼になっていたか微妙ですけれど。

懇親会に出てみた

その後は懇親会に参加させて頂きました。
これまでも終了後の懇親会は開かれていたんですけど、実は初参加です。 ザギンで飲みだなんて、贅沢なシチュエーションじゃないですか！

懇親会では多数の方と名刺交換をさせていただきました。
デジパのリョウケンさんからはコメントもいただいたりで、いやもうこんなペーペーにありがとうございます！
持っていった20枚の名刺は、あっという間に配り終えてしまいました。

懇親会ではミニプレゼンみたいなのがありました。
スピーカーの方達の個性がかなり強く出ていて、参考になるなあと思いました。
[bA] Business Architects Inc.の人のスピーチでは、指差しでスライドを指していたので、通称「あの棒」を差し出してみたり（身内ネタすみません）。
他にもWeb界隈でよく名前をお見かけする方と話ができたり、鷹野さんにも色んな方を紹介して貰ったりと、充実しすぎな時間でした。

CSS Nite 卒業式

そして宴もたけなわ気もそぞろ（by蟹の貴公子様）になった頃、サプライズイベントのCSS Nite 卒業式が行われました。
花束やらメッセージカードやらがプレゼントされた後に、鷹野さんの愛娘マリンちゃんからのビデオレターが！ 会場もなごみまくりんぐでした。

終了後、一部の方は3次会に行かれたようですが、さすがに終電が怖かったので、僕は素直に帰る事にしました。
いやー、最高の夜でした。

オマケ：
5月12日に東京・神田で、コーディングに特化したCSS Niteが開催されます。
有料版ですが、コーダーにとっては参加必須なイベントになりそうです。

CSS HappyLifeさんで、コーディング大会みたいなのやりたいなぁ～というエントリが公開されてから、物凄い勢いで反響が集まっています。
自分の実力を試せるのはもちろん、他の人のコーディングを見られるのも凄く勉強になりそうですよね。

これから仕事が忙しくなりそうな予感がしますけど、「なあに、かえって耐性が付く」という心意気で是非参加したいでっす。

CSS HappyLifeさんで、ちょっと前から告知されていたコーディングコンテスト。 ついに正式に開催が告知されました！
これはもうコーダーのみならず、全Webクリエイターが注目ですね！

ちなみにこのコンテスト、CSS Niteのコーダー特集とも言うべきCSS Nite LP, Vol.3 "Coder's High"との連動企画という事で、審査員の方々も超豪華なメンバーとなっています。
そう、告知ページをクルクルーッと下に降りていくと超豪華な審査員の名前が･･････。 名前が･･････。
（わかりやすいように画像で引用します）

　　　(　ﾟдﾟ)
　＿(__つ/￣￣￣/＿
　　　＼/　　　　 /
　　　　￣￣￣￣

　　　( ﾟдﾟ )ミ
　＿(__つ/￣￣￣/＿
　　　＼/　　　　 /
　　　　￣￣￣￣

えーゴホン。 余りの衝撃に思わずAAを探してきてしまいました。
という訳で、僭越ながら（全くだ！）ワタクシ浜 俊太朗、コーディングコンテストの審査役を務めさせて頂く事になりました！

事のきっかけはCSS Nite Vol.18での事。
その日のプレゼントでドリーの本を貰った僕は、一言お礼を言おうと主催の鷹野さんに話しかけたんです。

（中略）

それから色々あって、こんな大役を頂く事になりました。
自分なりの目線でもって、みなさんの作品を拝見させて頂こうと思います。 よろしくお願いします。

以下はオマケ。

CSS Nite shuffleに行ってきました！
このイベントは、CSSという名前が付いているにも関わらず、CSSだけでなくデザインだとかディレクション的な事もやっちゃおう！ といった目的があるそうです。　shuffleだけに。

エコなデザイナーになろう

長谷川泰久さんのこの講演は、CSS Nite in 大阪の時から聞いてみたいと思っていたので、個人的にラッキーでした。
地球環境問題とWeb制作の問題を、からめて話すという進め方が新鮮でした。

アウトプットするという事を特に強調されていたと思うんですけど、僕もそう思います。
やっぱり人間、本を読んだだけじゃあ中々身につきませんよね。

ちなみに、「すごい病院」で検索すると、本当にすごかったです。

Apollo、インストールから向かうビジョンまで

Apolloに関しては、これまでは何となく分かったような分からないような感じだったのですけど、この講演で大分理解する事ができました。
Apolloを一言で表すなら、Flashプレーヤーのおばけなんだそうです。 HTMLやPDFもできるFlash、みたいな。

ブラウザを使わずにWebと関わると言えばiTunesが代表だと思うんですけど、あれってOSごとに違う作りらしいんですよね（ソフトウェアに詳しくないんでアレですけど）。
でも、ApolloならFlashやHTML、JavaScriptで開発ができるので、結果的にクロスOSが簡単に実現できるというのも利点だとか。
うーん、なんだかちょっと、楽しそうです。

そもそもWPFとは？ WPFで何ができるのか？

すみません。 今日までWPFって知りませんでした。
何やらApolloとライバル関係になりそうですけど、こちらは3Dに強いんだとか。 なんだかプレステとセガサターンを彷彿とさせますｗ

僕個人としては、WPFよりはApolloの方がとっつきやすいかな、と思いました。 3Dは敷居が高いような感じが。

リッチコンテンツ制作に求められるセンスとスキル

驚いたのは、A BATHING APEがこれまでWebサイトを持っていなかったという事。 そうだったのかー。
このサイトが、普段Webに関わっている立場からするとかなり驚きなつくりで、トップページにはexeをDLするボタンがあるのみ。 それを実行する事で、コンテンツが見られるという仕組み。

Webの常識ではかなり型破りで危険な作りですけど、BAPEのファン層を考えると、その心配は余りないような気もします。
多分、雑誌で見たり友達からの口コミで利用する人が多いんじゃないかなあ。

感想みたいの

shuffleは、最初にサプライズコンテンツとして弦楽コンサートがあったり、途中でお客さん同士のコミニュケーションを取りやすくするしかけがあったりと、普段のCSS Niteとはちょっと違った雰囲気でした。 そもそも会場もクラブですしｗ
次回開催も楽しみです。

CSS Nite LP, Disc 3 -Coder's High-の連動企画、コーディングコンテストが開催中です。
応募すると-Coder's High-の参加費が2.000円引きになる特典付き！ 締め切りは今週末22日（日）の24時ジャスト！
しかも今から参加すれば、普段の業務のようにコーダーに仕事が回ってきた時点で納期が直前という、よりリアルな状況で参加できます！ もちろん良い意味で。

「えー、でもPSDデータしか公開されてないしー。 私Fireworks使いなのよねー」というあなたも大丈夫。
hxxk.jpの真琴さんが、PNGデータを作成してくれました！
2007-04-08T17:06:26+09:00 でページ内検索するとわかりやすいです。

審査基準

さて。
色々とあって僕も審査役として参加させて頂いているんですが、ここで僕なりの審査基準を書いておきたいと思います。

審査基準を満たす

とりあえず基本という事で。 審査基準に関しては平澤さんの告知ページを参照してください。

お客様の事を考えている

デザインを見ると、どう見ても企業サイトな訳です。 なので、お客様の目的を叶えるために作られたサイトが良いと思います。
その辺りで提案力が重要になってくると思います。

CSSハックの使い方

CSSハックは使われているのか。 使われているならどのハックを使っているのか。
使っていないなら、不自然なHTMLになっていないのか、という点を見たいと思います。

こんな感じでしょうか。
ちなみに賞品にある、各審査員ごとのプラスアルファは、「コーディングがしやすくなるグッズ」にしようかなあとか思っています。
皆様のご参加をお待ちしています！

CSS Nite LP3が終了しました！
例によって、ちょっとしたレポートを書きます。 自分用まとめの意味合いが強いので、行ってない人は解りにくいかもです。

いきなりおまけ

つーか長えよ！ って言う人用に、短縮版を追記部分に用意しました。

会場の様子

ズドーンと大きいホールに、机と椅子が整然と並んでいる感じでした。 建物の印象も近代的でオサレな感じです。
一つの長机に椅子は二つなので、かなりゆったりと過ごす事ができました。

益子さんのセッション「ザ・コーディングの美学」

3つの観点、「真・善・美」に沿って、コーディングの美学を語られました。
「真」は仕様通りかどうか。「善」は、例えばプログラマーも使いやすいソースなど、良心的な事。 そして「美」はインデントの入れ方やコメント、改行位置などとの事でした。

この中で僕が注目したのは、「美」の部分でした。
「美」に関しては、個々人の意識の差が出やすいと思います。 そういった部分で益子さんのご意見を聞けるのは貴重かなーと。

これまでにも、CSSの値やセレクタが長くなってしまった場合に改行する、というのはよく見かける手法でしたが、HTML側のタグを改行してしまう、という考え方は斬新でした。 これを実行するには、改行して良い箇所とそうでない箇所を熟知していなければならないので、「真」の知識も必要とします。
CSSの値も、font-familyプロパティやbackgroundプロパティなど、値が長くなりがちなものは改行するのも益子さん流の特徴みたいです。

最後にあったのが、NerdとGeekの話。
端的に言えばNerdは使えないオタクでGeekは使えるオタク。 みんなでGeekを目指そうよ！ という感じ。
その為には「真・善・美」を意識して、自分の仕事に誇りとプロ意識を持つ必要がある、みたいな。

ちょっと話は外れるんですけど、Perlハッカーって言うと「Perlの凄い人」って意味合いですけど、「CSSハッカー」って言うと、どうしても「CSSハック」が意識に出ちゃう気がします。
「CSSの凄い人」って、何て呼べばいいんですかねー。

小久保さんのセッション「フィロソフィー・オブ・コーディング」

フィロソフィーです。 哲学です。 なんだか難解そうなタイトルですけど、とても勉強になりました。

Web製作者の価値は、Web業界の価値に左右されるというのが、重要なポイントでした。
簡単に言うと、「サッカー日本代表とセパタクロー日本代表だと、どっちが稼ぎが多いか」みたいな感じでしょうか？
例え同じ日本代表であっても、サッカー業界の方が大きいので、稼ぎも多いはず。 多分。（セパタクラーの皆さんごめんなさい）

で、業界の価値はどのように決まるのかという事を考えると、それは製作物一つ一つのデキ。 つまり製作者一人一人のがんばりだという事です。
転じて、コード（HTMLだけでなく、全てのコード）が悪いとWeb業界の質が悪くなるという事に。

Web標準の正体についても言及されていました。
Web標準の目的とは、良いコードを作る事、ただそれだけ。 それ以上でもそれ以下でも無いとの事。
「これはWeb標準に含まれる」「いやそれは含まれない」という議論はナンセンス。 という意見も。

では、なぜ、正しいコードを書かなければならないのでしょうか？ 考えてみよう。という形で終わりになりました。
ちょっと前に、XHTMLを選択する理由という話題がありましたけど、これの回答にもなりそうです。

鷹野さんのセッション「Dreamwaverのコーディング機能再点検」

僕は基本的にエディターを使うヒトなので、ドリーは使わないんです（会社のPCにはインストールすらされていない）。
でも、コードヒントのカスタムとかは参考になりました。 今度自分のエディタでもやってみよう。

神森さんのセッション「Liveコーディング（A）」

ほぼ全工程において、ドリーのデザインビューを使用して進めていました。
これは「どの操作をしたらどういった結果になるか」を熟知しているからこそ、できる事ですよね。 でなければコードとかグチャグチャになるでしょうし。
例によって僕はドリーを殆ど使わないので、逆に新鮮な視点で見る事ができました。

ヤスヒサさんのセッション「Microformatsで上質コーディング」

来ました長谷川恭久さん。 ヤスヒサさんのプレゼンはテンポがよくて、グイグイ引き込まれます。 そしてお題はMicroformats。 期待せざるを得ません。

プレゼンは、「Microformatsとは何ぞや？」という所からはじまります。
「マッシュアップ」が最近は普通に聞く単語になっています。 異なるWebサイトからデータを持ってきて合体させちゃったりするアレですね。
それにはAPIを使う訳ですけど、ちょっと敷居が高かったりします。

その点Microformatsは超簡単です。 現在あるタグに属性を追加するだけで利用できます。
APIのような「製作者による大掛かりなコンテンツのマッシュアップ」はできませんけど、「各ユーザ（閲覧者）による細かいデータの抽出」をが行う事ができます。
この辺りの詳しい話は、ヤスヒサさんのサイトで資料が公開されているので、そちらを参考にされた方が、より理解が深まります。

余談ですけど、打ち上げの時に「nowaにはMicroformatsを実装しないの？」というお話を頂きました。
実は今回のプレゼンでかなり面白そうだと思ったので、もう少し調べてみたいと思います（あくまで現段階では個人的な意見であり、今後実装されるかどうかは全くもって別問題です）。

太田さんのセッション「プロはこう使う！Another HTML-lint 徹底活用」

みんながお世話になっている（かも）のAnother HTML-lintのお話です。

点数を気にする余りに逆にアクセシビリティが下がってしまう、という件は、バリデータやlintを使い始めた頃にはありがちですよね。
結構、多くの人が通ってきた道かもしれません。
点数はあくまで目安にして、そもそもの目的を見失わないようにしたいですね。

河内さんのセッション「Liveコーディング（B）」

今度はドリーのコードビューを駆使する、河内さんのLiveコーディングです。
急遽、bAのお二人に挟まれてコーディングをする事になりました。 な、なんてプレッシャーな・・・！

特に勉強になったのは、ナビゲーションなどから全体のサイト規模を想像して作業を進めるという部分。
確かに、全部のデザインが上がってからコーディングがスタートする事ってあんまり無いですよね。 後になってあたふたしない為にも、これは意識したいです。

あとは、背景画像をスライスする時に小さくスライスしすぎると、IEではCPUに負荷がかかるというのは初耳でした。
これは早速、社内に広めたいところです。

コーディングコンテスト表彰・講評

本当は3分くらい時間がもらえる予定で、喋る事を考えていたんですけど、時間が押していたのでカットされましたｗ
賞に選ばれた作品については、平澤さんの記事、浜賞☆コーディングコンテストVol.1｜CSS HappyLifeで講評が掲載されています。

僕のBlogでは、惜しくも賞には選ばれなかったけれど「ここが良い！」と思った作品については、今後講評を載せていきたいと思います。

おまけ2

その他打ち上げの時の事などは、nowaに書く予定です（雑記です）。

7月15日、16日は、みんなでアキバへレッツゴウ！
という訳で、Web標準に関連したイベントです。

開催要項を見ると、物凄い数のセッションがあります。 同時進行もあるので、全部に出る事は不可能です。
しかもセッションは登録制な模様。 つまり、受けたい授業を決めないといけないんですね。 選択制の授業みたいで、何だかわくわくしてきますｗ
ちなみに、参加者には後日、音声データのダウンロードがあるようなので安心です。

チケットの販売は6月1日からです。
6月中旬頃にはセッションの登録が開始されるようなので、人数漏れしないように、公式ページのRSSを登録して、小まめにチェックしておくと良いのではないでしょうか。

多分、またついったー方面でも何かあるんじゃないですかねー。 と無責任な期待をしてみたり。

既にあちらこちらで報告が上がってますけど、ついったー発の眼鏡オフに行ってきました。
このオフはcremaさんのつぶやきが発端で、何故か「眼鏡or伊達眼鏡orサングラスorマッキー眼鏡 な人達でオフをやろう！」という流れに。

「オフ会やろうか？」という段階から1週間経たずに開催されるという、超スピーディーな展開でした。
twitterっていう場的に、それくらい軽いノリの方が「らしい」ような気もしたり？

集合場所は眼鏡屋

集合場所は渋谷マークシティの眼鏡屋ZOFF。 安い割りにオサレなフレームを扱っている店です。
Shunさんは露天で売ってるような1000円くらいの伊達眼鏡しか持っていなかったので、ここで新調しました。 猫をイメージソースにしたフレームだとか。
色はもちろん赤。 色々と3倍です。

あと、UK君に訳あってのわTシャツを持っていきました。
実物の写真は彼のBlogでどぞー。

会場はベルギービールの店

会場は、道玄坂パク森の隣にあるベルギービールの店、Hemel（ヘイメル）でした。
ここがかなり当たり。 大当たりです。 渋谷とは思えないレベルの高さですよ。
料理の味はもちろん、接客もマニュアルに囚われない系で大満足でした。 今度個人的に行こうっと。

2次会はダーツ

2次会はダーツでした。
Shunさんダーツとか人生で初だったんですけど、その割にはかなり楽しめました。 狙いの付け方が全然分からなくて、勘だけで投げてましたけれど。
それにしてもUK君の空気の読めなさは異常。 もうちょっとこう、なんだ、ほら。 年上を立てるという事をだね。

その他

• twitterオフ用の名刺を用意している人多し
• frickrの写真を名刺にしてくれるやつは格好良い（海外のサービスらしい）
• ベルギービールの種類の多さは異常
• kengoさんからSkype Me!のステッカーを貰った（ありがとうございます！）
• 時価の魚は釣る所から
• Katsuoとんのダーツの命中精度も異常。 若さか？ 若さなのかっ？

まとめ

ついったー関連のオフは初参加だったんですけど、かなり軽いノリで集まれていいですね。
今後も面白そうなオフがあったら参加したいです。
そしてcremaさん、かなり突貫で大変な幹事役お疲れ様でした！ 楽しかったです。

おまけ

ﾌﾞｰﾝがビールの販売を始めたようです。

開催まで1週間ちょいとなったWeb標準の日々ですが、いよいよセッション登録が開始されました。
追記：ここで登録URLを掲載していましたが、事情により削除しました。 アドレスはＷｅｂ標準の日々からのメールを参照してください。

それと、会場周辺の簡単な地図も公開されているので、土地勘の無い人は事前にチェックしておくと当日になって慌てなくて済みます。

関係ないですけど、最近はアキバの周りに飲食店増えましたよね。 打ち上げの店には困らなそう。

超長いんでショートカットメニュー作りました。
あと、JavaScriptの素人が書いてます。 あちこち間違ってたらごめんなさい。

• マークアッパー・デザイナー向けJavaScript入門
• マークアップエンジニア・HTMLコーダー向け、Yahoo UI Library活用術
• Google Gears入門
• JSの使いどころ
• liveプレゼン
• 猿でもわかる GreaseMonkey
• Firebugの話
• 総括

Twitter関連でお世話になっているukstudioが、初心者向けJavaScript勉強会を主催してくれたので、モリモリ勉強してきました！
会場は株式会社ノッキングオン様に提供して頂きました。 ありがとうございます！
僕は行ってなかったんですけど、モバイル勉強会の時もお世話になったそうです。

マークアッパー・デザイナー向けJavaScript入門

資料公開（補足も必見）

トップバッターのUKは、JavaScriptの基本をざっくりと語ってくれました。
入門書に書いてあるような内容が中心でしたけど、疑問に思った事をすぐに聞けるという環境は良かったです。
赤い髪の人の適切なツッコ・・・補足もありましたし！

基本的な事

• CDATAの内容は、XML的には<や&を参照しなくて良い（この辺、今度じっくり調べたい）
• 「_」は、海外ではアンダースコアと呼ぶ
• リテラルとは、文字列とか、trueとか、nullとか、直接値を書く事
• 普通の配列は、数字で管理する
• 連想配列は、文字列で管理する
• 普通の配列も連想配列も、やってる事は同じ。 ただ、複雑な所では、違う事も出てくる。
• %は、「割った余り」という演算子
• >=と<=は、以上以下という演算子
• &&は、演算子同士を比べたりして、両方ともtrueならtrueを返す
• ||はどちらかでOK

ローカル変数とグローバル変数

変数を定義する時にvarを付けたりと付けなかったりなのは、ちゃんと意味があったらしい。
関数のなかでvarを付けて定義すると、その変数はその関数内でのみ使える変数（ローカル変数）になる。
関数の中でvarを付けずに定義すると、それは関数の外でも使える変数（グローバル変数）になる。

var a = 1;

function hoge () {
  a = 2;
}

functionの中のaはグローバル変数なので、最初のaに代入された1は上書きされる。

var a = 1;

function(){
 var a = 2;
}

functionの中のaはローカル変数なので、最初のaに代入された1はそのまま。

オブジェクト志向

ごめん、よくわからなかった！
後半の_tad_さんの説明がフォローしてくれているので、そちらをどぞー。

DOMについて

ノードとは、HTMLで言うところの要素みたいな感じ。

<a href="index.html">Top</a>

この場合、<a>が要素ノード、href="index.html"が属性ノード（属性と値の両方を含めるぽい？）、Topがテキストノードとなる。
もちろん、属性ノードは属性の数によって増える。

IE様は改行（br要素ではなく、単なる改行）もノードとしてしまうらしく、ノードの数がブラウザによって違う、という事態になるとか。
まったくもうこれだからＩ（ｒｙ

まとめ

• 基本的な事を喋ってくれた
• UKはいじられ愛されキャラ
• 準備とかお疲れ様！

マークアップエンジニア・HTMLコーダー向け、Yahoo UI Library活用術

資料公開

YUIを語って貰うならこの人しかいないッ！ 紫色の何かをたずさえ来てくれた―――!!! （いや今日は無かったけど）
という訳で、HolyGrailさんが初心者向けに解説をしてくれました。
ちなみに、プレゼン終了直後に資料を公開されていました。 早すぎですｗ

YUIを使うメリット

• ブラウザウィンドウの表示領域（ツールバーとかを除いた、純粋な領域サイズ）の取得
• class名でelementを取得できる
• 座標の取得
• 他にもいっぱい
• これらをクロスブラウザでやってくれる！
• しかも、自分が書くのは超シンプルなコード

多分、他のライブラリにも共通する事だと思うんですけど、ライブラリを用意さえすれば、後はそれを使うタイミングなどを指定するだけで良いみたい。
マークアップエンジニア向けに説明すると、CSSファイルのコンポーネント化の感覚に近い物があるかも？（それの是非はここではともかく）

あと、今回の資料のCSS部分は、Holyさんの後輩のマークアップエンジニアさんが担当されたそうです。
後輩さんとは、本当ならこの前お会いできるはずだったんですけど、事情により流れてしまいました。
近い内にお会いしたいと思いまくりです。

まとめ

• YUIは、色んな便利をクロスブラウザで実現してくれる
• とにかくまずはさわってみよう！
• 英語が読めない人はYahoo UI Library リファレンスを見るといいかも

Google Gears入門

makotokagaさんは、少し前から話題になっている、Google Gearsに関する事を喋ってくれました。
・・・んですけど、すみません！ ぶっちゃけ僕には難しすぎました！
理解できた事と言えば

• AdobeのAIRはアプリケーションぽさがあるけど、Gearsはあくまでブラウザベース
• オンラインでデータをキャッシュして、オフラインで見られる
• データはSQLiteで管理される
• SQLiteという、現在普及している技術を使う事によって、みんながいきなり使いこなせる

という事くらいでした。 ううーん、すみません精進します。

JSの使いどころ

moさんのプレゼンは凄かったです。
何が凄いって、終わった後のマークアッパー・デザイナー達の目の輝きとでもいいますか。
いったい何が彼らをそうさせたのでしょうか。

moさんのプレゼンはJSの使いどころという事で、「JavaScriptの使い道はWebだけじゃないんだよ」という事を語ってくれました。

ブックマークレット

SBMやtumblrでおなじみのブックマークレット。 これはJavaScriptで作る事ができる。
どうやら割と簡単に作れそうな感じ。

Firefox拡張機能

Firefoxの拡張機能を作るには、XUL(ズール)という、XMLベースの言語とJavaScriptを使う。
簡単に言うと、DOMをJavaScriptで操作するように、XULをJavaScriptで操作するんだとか。
これも手を出してみたい・・・！

Flash

ActionScriptからJavaScriptを、またその逆を呼び出す事ができる。

RIA

リッチなインターフェイスのアプリケーションを作れる！（すみませんここ聞き漏らしました）

DreamweaverやPhotoshopの拡張機能

これが凄かった！ 特にPhotoshopの拡張機能が紹介された瞬間に、マークアッパーとデザイナーは今までの苦労が走馬灯のように流れた事間違いなし。

moさんが今回紹介してくれた拡張機能は、『psdファイルからhtml要素やhead部分など最低限の構成と、素のテキストを吐き出してくれる』という物。
つまり、psdファイルからテキストをコピペする必要が無くなる訳で。
いやもう本当に、プレゼンが終わってから、一斉にみんなが同じ質問をしたのには笑いましたｗ（公開はしてくれるんですか？みたいな）

デスクトップアプリ

JavaScriptで作ったTwitterクライアントを紹介。
多分、見た目部分はCSSなんかを使っているのかな。 その辺り、なんだかAIRとも共通する便利さがあるのかも。

まとめ

• JavaScriptはWebだけの技術じゃない
• まずはブックマークレットから始めてみるといいかも
• Photoshopの拡張機能が超スゴイ

なんだか、Adobe製品のスクリプトには、まだまだ面白く便利にできる余地がある気がします。
エンジニアさん達が余り使わない分野だから（？）余計に未開拓なのかも。

liveプレゼン

_tad_さんがやってくれたのは、ほぼ真っ白なメモ帳を用意して、ライブに書き込んでいくというliveプレゼン！
いやあこの発想は無かったですわ。
内容は、プログラミングの基礎の基礎、みたいな感じでした。

キーワードは「めどい」。
なにせ「めんどい」とタイプするのすら「めどい」くらい！

構造化

• 順番にやる
• 条件を見る
• 繰り返す

プログラムっていうのは、基本的にこんな事を書いていく。 例えば次のコードなら、

if(uk == "20") {
 while(n <= 20) {
 document.write("hogehoge");
 n++;
 }
}

もし、ukと文字列20が等しければ（条件を見る）、
nが20になるまで文字列hogehogeを出力する（繰り返す）
となる。 順番にやるっていうのは、上から順に降りてくる事（・・だったはず）。

オブジェクト指向

実はめどくない。
考え方としては、「ナイフは野菜に使うと便利だけど、人に使うのはNG。 じゃあナイフは人に使えないようにしよう」という物。
JavaScriptで考えると、「機能によって、使える場所を制限しておこう」という感じ？

つまり、覚える事は少なくて済む（制限によって区切られた物ごとに覚えれば良い？）

ライブラリ

ライブラリとは、図書館のような物。
司書（エンジニア）さんはその本の種類（そのライブラリは何なのか）を知っておけばよくて、本の内容（コードの内容）までを全て熟知しておく必要は無い（知っておくに越した事はないだろうけど）。

また、既に世界各所で使われているので、不具合がおきづらい。
バグがあっても、報告をすれば直してくれる（事が期待できる）。

また、ライブラリのコードは生きた見本である。
まずは実際に使ってみて、動きなどを体験してからコードを読むと、理解が深まる。

CSSのcommon.cssは、ローカル性が強い。
対してJavaScriptのcommon.jsは、グローバル性が強い。 との事。
これは使いまわしがしやすいか否か、という意味。
（まあ、CSSはHTMLによって変わってくるので、結局は文書次第になってしまうと思います）

まとめ

• liveプレゼンメソッドすげー
• 例え話が解りやすい！
• やっぱり大事なのは使ってみる事

猿でもわかる GreaseMonkey

資料公開

赤い髪の人、Yoshioriさんのプレゼンは、グリモンに関する事です。
多分GreaseMonkeyだから「猿でもわかる」なんだと思うんですけど、誰もツッコめませんでした。

Yoshioriさんのプレゼンは、また強烈でした。
スターウォーズのライトセイバーをポインター代わりに進行をするんですけど、ご本人のキャラもあいまって、爆笑しながらも理解しやすい内容になりました。

グリモン、最初の部分の書き方

// ==UserScript==
// @name          hamashunGreaseMonkey20070714
// @namespace     http://www.hamashun.com
// @include       http://auth.livedoor.com/*
// @version       1.0
// ==/UserScript==

• @nameは、可能な限りユニークな物にしておく良い。 これがかぶると、動作もかぶってしまう恐れがある
• @namespaceがあるので、もし万が一@nameがかぶっても、一応は安心？ とりあえず自分のドメインとかにしておくと良い
• @includeは、適用するサイトの事。*はワイルドカード
• バージョンを書いておく

冒頭に書くのは大体こんな感じで、あとはJavaScriptで書いていくだけのよう。

細かい点いろいろ

• グリモン専用の関数が用意されている
• eval()で、外部スクリプトを読み込む事ができる・・・が、セキュリティ的に余りお勧めできない
• LDRは、グリモンを組み込みやすいように工夫されている（そうなのか！）
• セキュリティ的に危うい物も作れてしまうので、注意が必要
• とはいえ、作ったらバンバン公開しよう！ 優しい先輩達が優しくDisって教えてくれるよ！

JavaScriptクイズ

a = 5 + "3";
b = 5 * "3";

それぞれ、変数にはどんな値が代入されるのか？

答えはaが53で、bが15。
aは普通にそのまんまなので割愛。
5 * "3"は、数値と文字列は掛け算できないので、いい感じに判断して数値同士として扱ってくれる。

var a = 10/3;

ではこれは、どんな値がaに代入されるのか？

答えは3.3333333333333335
他の言語では小数点以下は扱わない事が殆どらしい。
JavaScriptは整数型を持っていないので、このようになるんだとか。
ちなみに、3.3333333333333335に3を掛け算すると、空気を読んで10としてくれる。

var a = new array;

a[1.5] = "foo";

alert[1.5];

小数点を解するという事は、配列に小数点以下の数値を指定する事もできる。

alert(2 & 3 == 1);

（この辺りからかなり難しくなってきて、メモったコードも怪しくなってきます）
この結果出力される値は？

答えは「0」
&演算子と==演算子だと==演算子の方が優先されるので、まず 3 == 1 でfalseが返る。
falseは0として扱われるので、 2 & 0 という事になる。
&演算子はビット演算子と言って、ビット（0と1）の世界として比較する。
その結果により、0が出力される。
なお、出力された0はビットの世界の0（つまりfalse）ではなく、 3 == 1 の結果の0である。

他にもいくつかの問題があったんですけど、メモがうまく取れていなかったり、再現ができなかったりで断念しました。
きっと他の誰かが書いてくれるはず・・・！

まとめ

• JavaScriptはツンデレ
• はて☆スタの32分の1がYoshioriさんによるもの
• JavaScript楽しい！

Firebugの話

sendさんのプレゼンは、Firebugについてでした。
コンソールのをちゃんと消さないとだめだよ！ って内容でした。
時間がかなり押せ押せだったので、ぜひ、今度また聞いてみたいと思いました。

総括

ものっそい楽しかったです。 質問しまくってしまいました。
最近、自分の中でJavaScriptとかDOMへの関心が高まってきているのもあって、タイミングも良かったです。

ユーザーCSSを作っていて感じたんですけど、何かを作るのって凄く楽しいです。
まずは何か、超簡単なグリモンかブックマークレットに挑戦してみたいです。

元々、この勉強会はUKが「社内勉強会でJavaScriptについて喋る事になった～」的な事をつぶやいたのがきっかけでした。
「じゃあTwitterでもやろうぜ！」と誰かが言い出して、あれよあれよと言う間に30人もの参加者が集まっていました。
会場探しやら色々な準備やらで大変だったと思うけれど、おかげでとても勉強になりました。 ありがとうUK！ お疲れ様！

あ、次回も楽しみにしてるから！

• Staff（セッション受付）
• Staff（道案内）
• Staff（セッション受付）
• Staff（セッション受付）
• Staff（販促物配布）

＼(^o^)／

本当は神崎さんのセッションだけは見られるはずだったんですけど、スタッフの人数的な問題でダメでした。
でも神崎さんの名刺を貰えたり、mozillaの人と仲良くなれたり、真琴さんと会えたりしたから超ハッピーだもん。

ショートカットメニュー

• このレポートの概要
• まず知っておくべき事
• ルビの話
• MIMEの話
• 複合文書の話
• XHTML2の話
• SVGの話
• 複合文書での名前空間
• 複合文書でのCSS
• アドレスバーに属性をコピペする？
• スキーマの話
• DTDの編集
• スキーマトロン（の補足）
• その他（質疑応答含む）
• オマケ

このレポートの概要

途中からだったので、全ては聞けませんでしたけど難しい内容でした。
現時点では、一般の製作者というよりはマニア向け 。

内容は、W3Cで活動されていた石川さんが、自身が策定に関わった仕様などについて語ってくれるというもの。
将来的にXHTMLは複数のマークアップ言語を一緒に使える（SVGやMathMLとか）という話を中心に、スキーマとかW3C裏話なんかも。

石川さんは「仕様」について深く関わってきた人なので、その辺りを意識しながら読むといいかもです。
最後のオマケには、懇親会でのちょい話もあります。

あと、僕にとって多分に未知の領域なので、間違っている部分もあるかと思います。
誤りを発見されましたら、ご指摘頂けますと嬉しいです。

まず知っておくべき事（ざっくりと）

SVG

絵を描く為のマークアップ言語。 手打ちだと才能の無駄使いクラス

MathML

数式の為のマークアップ言語。 ブラウザだけでなく、数学的なアプリケーションでも使える

XML複合文書（以下複合文書）

複数のXML言語を一緒に使う文書（XHTML+SVG+MathML など）

スキーマ

XML文書のルール。 DTDをスキーマ言語の例として挙げると解りやすい。 検索するとDB系の情報がヒットしやすいので、「XML スキーマ」とすると良い

名前空間（の指定）

XHTMLのa要素とSVGのa要素、普通に書いたらどっちのa要素か解らない→「この中はXHTMLの空間だよ」と示してあげる

ルビの話

部屋に入ったと同時に終わったので、他の人のまとめに期待。

MIMEの話

『XHTMLならXMLとして扱って欲しい』と言っていた。
なお、メモ用紙とかを用意しながら聞いてたので、一部完全ではないかも。

• 仕様書は、text/html版とapplication/xhtml+xml（application/xmlだったかも？ スライド公開待ち）版の両方がある
• application～の方は、（ソースを開いて見ると）タグの書き方もよりXMLぽく書いている
• その辺りの空気を読んで欲しい（XHTMLはXMLベースである）
• XHTMLにtext/htmlを使うぐらいなら、いっそHTML4.01にしてしまえ（これは、本気では言ってないけど本音かも、と感じました）

複合文書の話

複合文書には、2種類の方法がある。
一つは、現在の感覚と近い方法で、object要素などで外部リソースを参照するという物。

もう一つは同じXHTMLファイル内に埋め込む事で実現する方法。
これは説明するより例の方がわかりやすいので、XML 複合文書の可能性と課題に載っているXHTML と MathML と SVG の混在例を見るとよい。
ソースを見ると、XHTMLの中に

<math xmlns="http://www.w3.org/1998/Math/MathML"> ～ </math>

<svg:svg xmlns:svg="http://www.w3.org/2000/svg"
  width="8cm" height="8cm" viewBox="0 0 100 100"> ～ </svg:svg>

こんな感じの記述がある。 xmlns属性で名前空間を指定する事で、その中に異なる文書を記述している。
前述の方法よりこちらが理想。

ちなみに、この例のDTDを見てみると、超長くて眩暈がする（15.000行を超える！ ちなみにXHTML1.0 Transitional は1.200行）。
これはXHTMLとSVGとMathMLのそれぞれの組み合わせを書いているから。
3通りだけでもコレなのに、（他の言語もあわせると？）全部で23通りの組み合わせがある。
『本気でやりたいなら、俺の屍を超えて行け！』との事。

XHTML2の話

よく「XHTML2はあれが足りない。これが足りない」という声が上がるが、XHTML2は複合文書の土台になるようにしてある。 言うなればプレーン・ピザ。
なので、単体で見てアレコレ考えるのは違う。 また、HTML5と単純に比較するのも、石川さん個人の考えでは「違う」

SVGの話

• SVGは、仕様自体が最近できた為、洗練されている（モダンな仕様）
• SVGはケータイブラウザで普及が進んでいる
• それはベクター画像だから、機種によって画面サイズが異なっても、きれいに全画面表示できるから
• ネットフロントや、Operaモバイル9で現在対応済み
• PCブラウザでも、モダンブラウザでは結構対応している

複合文書での名前空間

例えば、XHTMLでのa要素とSVGでのa要素を、複合文書にただ書いただけでは、どちらがどちらかが解らない。
なので、名前空間を指定してやる必要がある。
『名前空間』は、複合文書では必須である。

ちなみに、名前空間を指定しても、DOMとしては持っている。
（複合文書は複数の文書を集めたのではなく、一つの文書内に複数の文書がある、という意味？）

複合文書でのCSS

@namespaceで名前空間を指定する必要がある。

アドレスバーに属性をコピペする？

XHTMLから属性のみを抜き出して、アドレスバーにペーストする。
OperaではStyleが適用されたりする（これがスクリーンから遠くてよく見えませんでした。 他の方のまとめに期待）。

スキーマの話

• 色んなスキーマがある（スライド公開待ち）
• スキーマは基本的に、一部分だけ書く、というのはできない。 一度書き出すと全部書かないといけない。 故に、仕様を書くにはいいが、普通の製作者には向かない
• ただし、Schematron（スキーマトロン）は、スキーマを補足する用途に使える
• 製作者が使うなら、通常のDTDなどにスキーマトロンを加える、「いい所取り」がおすすめ

DTDの編集

DTDの拡張は考えない方がよい（マニアの領域）。
編集で使いやすくする程度に。

例えば、DTDを読んで入力補完をしてくれるエディタで、onclick属性なんかが出てくるのがウザイ場合。
スキーマを読み書きできるエディタを使って、該当の箇所を上書きなりで修正する（多分、一時的に行う事だと思います）。

スキーマトロン（の補足）

• やりたい事だけ書く
• 他のスキーマは、メッセージ（コメントの事？）が英字のみだが、スキーマトロンは日本語が使える
• アサート：ポジ
• リポート：ネガ（この二つはよく解らなかった。この辺り不確かですみません）

その他（質疑応答含む）

• 複合文書の検証をコマンドラインで行うには、NVDLスクリプトを使う
• 石川さんオススメのエディタはoXygen/（オーキシェン）。 シェアウェアでJAVAベース
• HTML Slidyはスキーマトロンを使っている？ （ソースを見たけどよく解りませんでした）
• XHTML2とHTML5は、お互いを尊重した方がいい（争ってばかりいると、いつまでたっても進まない）
• Ian Hicksonは個人としてHTML5に関わっている。 HTML5イコールGoogleの総意、という訳ではない。 でも、ちょっとは何かあるかも？（Googleのみぞ知る？）。
• 標準に関わる者は、何か業を背負っているような（同じ人達が同じ業界をグルグル転職してる）

オマケ

Web標準の日々終了後の懇親会で、石川さんとiwaimさん達と膝突合せトークをする機会に恵まれました。
何でも現在、石川さんは後任を探しているんだとか（もちろん、いきなり全部を引き継ぐという訳じゃなくて、最初はお手伝いみたいのから）。

石川さんが危惧しているのは、後任が日本人以外になってしまって、日本人とW3Cとの結びつきが益々薄くなってしまう事だそうです。 我こそはと思う方は、石川さんに熱意を伝えてみてはいかがでしょうか。
あ、ただ、世界中から総叩きにあっても大丈夫なくらいの精神力が必要だそうです。

ショートカットメニュー

1. 表現は視覚だけじゃない
2. 色んなUA（の一例）
3. 音声ブラウザとスクリーンリーダーの違い
4. スクリーンリーダについて
5. 音声ブラウザやスクリーンリーダーのシェア
6. 読み上げについて
7. JAWSの読み上げ方
8. CSSの話
9. 質疑応答
10. 点字ブラウザについて
11. 感想

表現は視覚だけじゃない

構造と表現が分けられている事が、Web標準の基礎。
と言うと「視覚表現と構造の分離」と思いがちだが、その考え方は聴覚表現や触覚表現でも必要。

例えば、強調を表現するにはCSSで文字色を赤にしたり太字にしたりするが、それだけでは聴覚的や触覚的には強調されていない。（相当する表現は声を大きくするとか、音程を変えるとか、解説を付けるとか？ 現段階の機能で可能かどうかは別で）。

色んなUA（の一例）

視覚系ブラウザ

IE、Firefox、Opera、Safari

モバイルブラウザ

端末ごとのブラウザ

フルブラウザ

PDAブラウザ

テキストブラウザ

Lynx

サーチエンジン

Google

音声ブラウザ

ホームページリーダー

Firefox+FireVox

音声ブラウザとスクリーンリーダーの違い

音声ブラウザは「ブラウザ」。 スクリーンリーダーはPCの操作など全般を支援する。
つまり、スクリーンリーダーはブラウザソフトでは無い。

スクリーンリーダについて

最強の呼び声高いスクリーンリーダーはJAWS（ジョーズ）。
ただし価格が高い。

前述の通り、スクリーンリーダーはIEなどのブラウザを通してアクセスする。 よってUAはそのブラウザとなる。
その為にアクセス解析ではシェアが分からず、クライアントに視覚障害者への対応を勧める事に苦労する（具体的な説得材料が一つ減ってしまう）。

アクセシブルでないサイト（ショッピングサイトなど）を使った際には、辻さんはその旨をサイト側に伝える事があるとか。
（これはShunの意見ですが）それが辻さんに限る事だとは思えないし、フォームのアクセシビリティは特に重要なのでは。

スクリーンリーダーという事は通常のPC操作も支援している訳で、例えばテキストを打つ場合も読み上げてくれる（キーを叩く度、変換する度に読み上げる）。
例としてスピーカーの辻さんの「辻」という字を変換すると、「辻斬りの 辻」と読み上げていた。

音声ブラウザやスクリーンリーダーのシェア

音声ブラウザではホームページリーダーが。 スクリーンリーダーではPc-TalkerとXPトーカ－が多い。
JAWSは性能はいいけれど、値段もあってかまだまだ一般には普及していない。
（ここでモデレーターの植木さんから補足があって、 「インフォアクシアではPc-Talkerとホームページリーダーの2つをチェック対象としている」との事）

読み上げについて

ホームページリーダーでは、見出しやリンク部分を女性の声で読み上げる事で、通常のテキスト（男性）との区別を付きやすくしていた。
支援ソフトの種類によっては、女性の声のままで音程を上げる事で区別を付けてる物もある。

「、」や「。」は、「てん」「まる」と読み上げられていた。
例として上の行だと、「てん やまる はてん てんまると読み上げられていましたまる」となる（「」はどうだったかな・・メモ忘れか、登場しなかったか。 こちらの件はJAWSの読み上げ方にて追記済み）。

前述のJAWSでは、h1要素やh2要素を「見出し1」「見出し2」と読み上げてくれる。
また、リンク部分も「リンク トップ」「リンク ブログ」などと、「リンク：ほげほげ」という形式で読み上げてくれる。 他のスクリーンリーダーではそこまではやってくれないらしく、この辺りが最強たる所以？

JAWSの読み上げ方

支援技術が実際にどのように読み上げるのかを、JAWSで体験する事ができました。
必死にメモを取りましたが、展開が速かったので曖昧な部分が多くあります。 正しくは音声とスライドの公開を待ってください。

、

「てん」

。

「まる」

？

「疑問符」

・

「ナカテン」

「」

「かっこ」「かっことじ」

【】

「すみつきかっこ」

h1要素 h2要素

「見出し 1」「見出し 2」

p要素

特に何も無く、通常のテキストとして読み上げる

リンク部分

「リンク：ほげほげ」

ul要素、ol要素

1項目を読み上げた後に「3の1」など、全体数と現在数を伝えてくれる

blockquote

「ブロッククォート～ブロッククォート終了」

strong要素 em要素

特に何も無く、通常のテキストとして読み上げる（「強い強調」と「強調」だったかも）

del要素

特に何も無く、通常のテキストとして読み上げる

ここで分かる事は、（strong要素や？）del要素を通常のテキストとして読み上げてしまう支援ソフトがある、という事。
つまり、音声系の環境もサポートするならば、他の手段でそれを伝える事を考える必要がある（もちろん正しいHTMLである事を前提に）。

CSSの話

画像置換にdisplay: none; を使用するとスクリーンリーダーで内容を得られなくなるように、視覚表現の為の指定がアクセシビリティを下げてしまう事がある。

また現在の音声ブラウザは、link要素のmedia属性に対応しているとは言いがたく、media="screen,print" などと指定しても読み込んでしまう。

質疑応答

CSSが適用されると隠される、ナビゲーションスキップメニューの是非

• ミツエーリンクス的にはNG
• ただ、聴覚ブラウザ専用ではなく、他の用途でも使えるなら（文書として必要なら）良いのでは
• 音声ブラウザにはhn要素のみを次々に読み上げる機能があるので、しっかりとしたマークアップをする事も大事（スクリーンリーダーでは未実装も多いが）
• WCAG的には、欲しい（植木さんの補足）
• この辺りは日々進歩している

一般の（製作者でない、という意味）視覚障害者はどのくらいWebを使っている？（主観で）

• ハードルが高いのは確か
• 支援ソフトも、今後はオープンソースが増えて値段も下がったりするかも

Googleの検索ページを読み上げたらどうなる？

• 検索結果のサイト名が見出しでマークアップされているので、そこだけを次々に読み上げる事ができる
• 少しインデントされている部分（関連リンク？）も同じく見出しでマークアップされている

Flashや動画コンテンツは？

• コンテンツ側が代替情報を用意する事が重要
• Flashのアクセシビリティはどんどん上がっていっている
• 動画に関しては、「ここを開くと動画が再生される」と分かっていればOK。 いきなり再生されるとびっくりする。
• いきなり再生されると、動画の音声と読み上げの音声がかぶってしまう
• 辻さんはMdN Interactiveのコラムでも、その辺りの事を書いているとの事

点字ブラウザについて

セッション終了後に、点字ブラウザの動作を見せてもらえる事になりました。
本当なら写真を撮ったりしたかったんですが、次のセッションの都合上無理でした。 なので文字だけで説明。

• 点字ブラウザは、画面でなく、モノ（もしかしたら、モノ＋ソフトの両方かも）
• 動的に点字が生成される
• 画面にあわせて、点字部分のパーツがニョキニョキ動く感じ
• 点字のパーツは、鉄系の素材で頑丈な感じ
• 値段は超高いっぽい

感想

実際に読み上げソフトを常用している人の話を聞けるっていうのは、ものっそい貴重な体験でした。
お恥ずかしながら、スクリーンリーダーと音声ブラウザの違いもこのセッションで知りました。
そういえば、聴覚スタイルシートの話は出ませんでした（質問するのも忘れた・・）。 まあ、media属性の対応もまだ十分で無いのなら、殆どサポートされて無いのかもしれません。

今回のセッションと直接の関係は無いんですけど、前に2ch系のBBSで「AAがあると何が何だか分からなくなる」っていう書き込みを見た事があります。
まあ、2chくらいの規模になると２ちゃんねる”を音声で読み上げてくれるWebブラウザもあるみたいですけれど。

概要

益子さんのセッションは大人気で、当初の予定を変更して、二部屋をブチ抜いて行われる事になりました。
内容はXHTML+CSSのガイドラインを、みんなで作っていこう！ というものでした。

スライドを中心に進んでいく形式だったので、セッションを受けていない人も、公開されるスライドを見ればかなり理解できると思います（スライドはもう公開されてるんでしたっけ？ 現在探し中です。）
なので、この記事では僕がメモした内容を整理して公開しています。

ガイドラインを作る目的

• 仕事を楽にする事が大切
• 無理無駄ムラを解消する
• クオリティの保障
• ノウハウの共有
• スキルの均一化
• 製作側と運用側の引継ぎをスムーズにする

ガイドラインを作る際の注意点

• あんまりキツく決めすぎないように
• 人間的な作業なので、モチベーションが大事
• ガイドラインはVer,UPする物。 作って終わりでは無い
• 更新履歴や改変者を残す
• 変更点などは、MLで共有する
• 意見は、立場や実力に関係なく、広く受け付ける
• 即座に反映できない意見も、今後の材料として取っておく

ガイドラインを作る際の手順

• （製作側がクライアント側に提案する場合は）キーパーソンの存在を確認する（決定権を持つ人）
• スタッフのスキルの確認
• 現状のガイドラインを把握する

XHTMLのガイドラインで書く内容の一例

• XML宣言の有無
• どの文書型か
• 最低でも仕様書の「Must」レベルは守る など
• link要素のrel属性の指定先
• noscript要素はhead要素内ではなくbody要素内に記述する とか
• dl要素の拡大解釈の範囲
• headerやcontainerなど、ラップ要素の名称を統一

CSSのガイドラインで書く内容の一例

• CSSのバージョン
• プロパティの降順
• ショートハンドを許すプロパティ
• デフォルトスタイルのリセット手法

その他

• CSS2.1が、今から大幅に変更されるという事は考えにくい。 バリデータも2.1に対応している
• Firefoxで確認してからIEで確認するのはよいが、変則的な組み方の場合は早めにIEでも確認しておくとよい
• ガイドラインを作りはじめると、楽しくなってきてどんどん決め事を増やしてしまう事があるが、やりすぎない事が大事

今度やるデザイン勉強会は、イラレがあると理解が深まるらしいです。
でも、さすがに値段が値段なので、今回の為に買うというのは難しいと思います。

そんな中に現れた救世主がInkscapeというソフト。 なんでもフリーソフトでありながら、イラレに匹敵する性能があるんだとか。
という訳で、デザイン勉強会本番までに覚えたい最低限の機能を予想して、ピックアップしてみました。
あ、ちなみにスピーカーの方とは何も相談していないので、完全に僕の予想です。

インストール

ダウンロードはInkscape 公式サイトからどうぞ。

特につまづく所は無いと思います。
日本語以外の言語をオフにすると、40MBくらい軽くなるので、HDDの容量が気になる方はどうぞ。

インターフェイス

クリックで拡大図が出ます。

とりあえずこれだけ覚えておけば、大体の事はできると思います。 イラレに比べてWindowsっぽいインターフェイスなので、そっちの人は比較的馴染みやすいかも。
なお、各ツールの名前はInkscapeの正式名称とは異なります。 hogehogeツール、って方がイラレと似てて覚えやすいかなと。

イラレをさわった事が無い人がパッと見て分かりづらいのは、パス編集ツール、ペンツール、塗りと線、レイヤ、だと思うんですけど、それは勉強会で解説してくれると思うので、ここでは書きません。

操作・ショートカット

基本

ルーラ（定規）

Ctrl+R

拡大縮小

Ctrl+ホイールまわす

拡大ツール

Z

縮小ツール

Shift（押しっぱなし）＋Z

コンテキストメニュー

右クリック押しっぱなし

アンドゥ

Ctrl+Z

リドゥ

Ctrl+Y

グループ化

（複数のオブジェクト（描いた物）を選択して）Ctrl+G

グループ化解除

（グループ化されたオブジェクトを選択して）Ctrl+U

そのオブジェクトが属するレイヤを変更（移動）

オブジェクトを選択してShift+PageDown・Up

（新規レイヤは、上部メニューの「レイヤー」から作るのが分かりやすい）

レイヤ自体の重なり順を変更（移動）

Ctrl+Shift+PageDown・Up

キャンバスの移動

上下

ホイールをまわす

左右

Shift+ホイールまわす

手のひらツールは無いぽい？

ペンツール

次の方向点の向きを変える

Shift+ドラッグ

次の方向点の向きに角度を付ける

Ctrl+ドラッグ

前のアンカーポイントの位置を移動する

Shift+矢印キー（大きく移動）

Alt+矢印キー（小さく移動）

現在のアンカーポイントの位置は移動する事はできないぽい？ イラレに慣れているとこれはツライ。

テキストツール

フォント設定

Ctrl+Shift＋T

書いた後に、選択して実行する事も可能

Tips

1キー

最初は拡大率が35%になっているので、数字の「1キー」を押して100%にする。

線を付ける

デフォルトで円ツールなどを使うと塗りのみで線が無いので、左下の「S：なし」（の「なし」の部分）をクリックして、「ストロークの塗り」に並んでいる正方形のアイコンを適当にクリック。
すると色のバーが出てくるので、任意の色を選択する。 線の太さなどは、上部のタブの「ストロークのスタイル」から選択可能

グラデーションツールの使い方

1. 円とか描く
2. 選択して、グラデツールでドラッグする
3. 一度空白をクリックする
4. 左下が「線形グラデーション」になるので、クリック
5. 「編集」ボタンをクリック。 ここでグラデの設定をする
6. 「色フェーズを追加」でグラデの色ポイントを増やす
7. すぐ上のセレクトメニューで色自体を指定する

ちょっとややこしい。 イラレかフォトショを使った事が無いと、感覚が掴みづらいかも。

あとがき

こんな感じでしょうか。
適当にググると、解説サイトも出てくるみたいです。

あと、ノートPCのタッチパッド等を普通のマウスと同じレベルで扱える人でない限り、普通のマウスとマウスパッドを持ってきた方が無難です。
できれば使い慣れているやつがいいのかな。

FrontPage - デザイン勉強会まとめサイト - livedoor Wiki（ウィキ）

1. デザイナーでない人のデザイン入門
2. ベジェ曲線で行こう
3. 簡単に名刺を作ろうぜ！
4. Webサイトのあり方と考え方
5. 総括

Twitter繋がりのまめこが主催するデザイン勉強会に行ってきました。 という訳でまとめです。
この勉強会は、デザイナー向けではなく、デザイナー以外に向けたデザイン勉強会です。

会場は今回も株式会社ノッキングオン様に提供していただきました。 いつもありがとうございます！

なお、まだ資料とか公開されていないセッションもあると思うので、タイトルとか微妙に間違ってるかもしれません。 間違ってたらごめんなさい。

デザイナーでない人のデザイン入門

資料

トップバッターは先生もされているcremaさんです。 話の仕方もさすがスムーズで、会場を暖めてくれました。
ちなみにcremaさんは「くれま」さんって読みます。「クリーム」のスペイン語なんだそうです。

さて、cremaさんが話してくれたのは、デザインの4原則に則った内容です。
デザインの4原則とはこれらです。

• 近接の原則
• 整列の原則
• 対比の原則
• 反復の原則

近接の原則

情報は、グループ分けが肝心。 意味的に近い情報同士は、近くに配置するとよい。
その為には、情報を分析する必要がある。 例として資料に載っていたチラシには、タイトル・製品紹介・申し込み情報・講師紹介、などの情報があった。

まずは、グループ化した要素ごとに間隔をとってみる。
写真と紹介文で一組として、それが複数並ぶようなデザインの場合は、一組ごとに間隔を空ける。

整列の原則

基準線、という存在が重要。 グラフィックソフトで言うところの「ガイド」や「グリッド」。
これに沿ってテキストの端を揃える。 左揃え、中央揃え、右揃え、両端揃えが考えられるが、中央揃えと右揃えは行の開始位置がバラバラになってしまうので、バランスを取るのが難しい。
よって最初は左揃えや両端揃えにするとよい。

また、イラレやInkscapeなどのソフトを使用する際には、数値を過信しすぎてはいけない。
数値上では揃っていても、人間の目と脳がズレていると認識してしまう事がある。

対比の原則

重要な部分とそうでない部分に差を付けて、目立たせる事。
大きくしたり太くしたり色を変えたりする手法が考えられる。 普段何気なく行っている、ヘッダ部分にメインビジュアルを置いたり、見出しのフォントサイズを大きくするのもこれ。

また、「ジャンプ率」という用語がある。
これは見出しと本文などの文字サイズの比率を変える事。 例えば、スポーツ新聞の見出しと本文のような差は「ジャンプ率が高い」と言える。
ジャンプ率が高いと目立ちやすいが、下品な印象を与えやすいので注意が必要。

反復の原則

繰り返しの要素を入れて、リズム感を出す。
通常、同じレベルの見出しは同じ色、同じ文字サイズにするが、これは反復の原則に則っての事である。

tips：デザインはどこから行う？

ありがちなのが、上から下へ、順番に行う方法。
しかしこれでは、最後にスペースが余ってしまった場合に対応できない。

そこで、上→下→中央、という順番にデザインするとよい。
中央でスペースが余りそうになった場合、ビジュアル要素のサイズを変えるなどで自然な形で対応できる。
（これはWebというよりは、スペースが決まっている紙デザインで特に言える事だと感じました）

tips：イラレの使いこなし術

キャンバス内に同じ枠を複数並べたい時（4コママンガの枠みたいにしたい時）には、

1. 矩形ツールで大枠となる四角形を描く
2. その四角形を選択して、上部のメニューのオブジェクト→パス→段落設定 を開く
3. そこで「プレビュー」にチェックが入っている事を確認して、数値を色々変えてみる
4. 入力した数に四角形が分割される

なお、分割した四角形の内、任意の数をShift+クリックで選択すると、更に分割したり、或いは結合したりもできる。
こうすると、4コママンガではなく普通のマンガのコマ割みたいな事が簡単にできる（文字で読むより、リストの順にやってみた方が解りやすいです）。

まとめ

「4つの原則」は凄く大事。 これを守るだけで、かなり「デザイン」できる！

おまけ

デザインもやはり、数をこなさないと自分の物にならない。
という訳で、cremaさんオススメのサイトや本を紹介してくれました。 公開される資料をチェックしてください。

ベジェ曲線で行こう

資料

多くの人はプログラマだと認識していたcheebowさん。
実は過去には看板や駅の時刻表を作る仕事をされていたんだとか。 その業界のおっちゃん達にドローソフトを教えていた事もあったらしく、ドローソフトのキモとなる「ベジェ曲線」に特化した話をしてくれました。

そもそもベジェ曲線とは？

N個の制御点から得られるN-1次曲線である。

何それ？

ってWikipediaに書いてあるけど訳わからないよね！との事。 解りません。
実はベジェ曲線とは、OSのAPIとして用意されている物なんだとか（Winの資料　Macの資料）。
そうなるとエンジニア思考としては、コードの方がラクなんじゃない？→APIでベジェ曲線を描こう！ となる人もいるけど（上記の資料にサンプルコードが載っています）、それはやりすぎ。

ベジェ曲線を解りやすく

「点」と、その点から出る「方向線（・―――・―――・ ←こんなの）」で描く曲線の事。
この「点」は「アンカーポイント」。「方向線」は「ハンドル」と呼ばれる（ソフトによって文言は微妙に変わる）。

アンカーポイント（点）とアンカーポイント（点）をつなぐ事で、線ができる。
アンカーポイントに対してハンドル（方向線）を操作する事で、なめらかな曲線が描ける。
･･････とか、ここで読んでも意味不明だと思うので、Inkscapeをインストールして、左のメニューから「ベジェ曲線」を選んで色々やってみるといいと思います。

基本のキ

直線は、クリックのみで描ける。
曲線は、アンカーポイントとハンドルを使って描く。
また、例えばマクドナルドの「ｍ」の字のように折り返す線を書く場合には、クリック→Shift+ドラッグとする（これもソフトによって多少変わる）。
･･････とか、これも読んでも意味不明だと思うので、とりあえずインストールして手を動かすといいと思います。

線を決める要素

• アンカーポイント（線）の場所
• ハンドルの長さ
• ハンドルの方向

アンカーポイントの場所は自由！
ハンドルの長さも方向も自由！

「自由」と言われても、どうすればいいのか分からないよね。 これはPerlとかでも同じかもしれない。
だからベストプラクティスとか読んじゃうのかも。 との事。

シンプルに考える

書きたい絵の、全ての点の場所や長さを最初に考えるのは大変。 なので、まずは「アンカーポイント（点）の場所」と、「ハンドルの水平・垂直」だけを考える。
もちろん、それでは描けない物も出てくるけど、練習の段階として。

細かい事は後まわし

なお、プログラマーは「例外」を考えてしまいがちだけれど、ベジェ曲線に関しては考えないで大丈夫。
「これで本当に描けるの？」とか思っても、とりあえず描いてみる。 後から修正するのは簡単。

プログラムを書く時も、人によってフローが違ったりする。
まずはコメントだけを書いていって、やる事を把握して、それからコメントの場所にコードを書いていく人もいれば、
イチからガーっと書いていく人もいる。
ベジェ曲線では最初から完璧を目指すのは大変なので、まずは大まかに描いて、それを修正していく方がオススメ。 彫刻とかもそうなのでは。

習作：トランプのマーク

トランプのマーク（ダイヤ・ハート・スペード・クローバー）は練習材料に最適。
jpgとかでトランプのマークを用意して、それを読み込んで、ペンツール（ベジェツール）でトレースして（なぞって）練習する。

クローバーは、よく見ると3つの丸と一つの楔形でできている。 実際の業務としてこういった図形を作る場合は、円系ツールと矩形ツールで作った方が効率がよい。

もっと知りたい人

トランプのマークのように、何かを読み込んで、トレースの練習をするとよい。
（ちなみに、このサイトのヘッダにいる動物達もそうやって作りました）

tips：アンカーポイント（点）だけで絵を描ける？

ぶっちゃけると描ける。 絵の曲線に沿って超細かく点を打っていけば、結果的に曲線を描ける。
でも、CPUの負荷が比例して上がっていくので、よくない。

tips：左右対称のロゴとかを描く時にラクする手段は？

半分だけ描いてコピペ。 それを反転すれば半分の作業量で済む。

まとめ

ベジェ曲線とは、アンカーポイント（点）とハンドル（方向線）でできている。 それぞれの役割は、アンカーポイントで線を繋いでハンドルで曲線の具合を決める、という物。
最初は、アンカーポイントを打つ場所は（図柄の）線の頂点・折り返しで、ハンドルは水平・垂直に出す（・―――・―――・ ←こういうのが一直線になるように）ようにする。 それで思い通りの物ができなかったら、編集ツールで調整する。

ツールは、とりあえずInkscapeがオススメ。 無料だし。
トランプのマークをトレースして練習する。

簡単に名刺を作ろうぜ！

資料

主催者であるまめこは、名刺作りを例に一連のフローを話してくれました。 まめこナイト。
後半は大分専門的な内容が入ってきて、結構難しかった。
使ったソフトはイラレとフォトショ。

ケースバイまめこ

名刺を作成する最初の流れはこんな感じ。 あくまでまめこの場合なので、こうしなければいけない、という物ではない。

1. 原稿を考える（名前や各種アドレス、アイコンやIDなど）
2. コンセプトを考える（好きな音楽のジャンルをテーマにする、とか）
3. ラフを紙に書く（超簡単でOK。 ラクガキっぽいのを紙に書く）

ちなみに、スライドに載っていた原稿に、twitterIDはあったのにlivedoorIDが無かった。 きっと公開の時にはこっそり追加されているはず。

アイディアを膨らませる

コンセプトを元に連想や妄想を膨らませて、ビジュアル的なアイディアを出していく。
例えば音楽だったら、そのジャンルで使われる楽器や服装や色。

素材を探す

写真やフォントなど。 素材集や無料素材のサイトを探す。
素材サイトの場合、商用利用に制限がある場合が多いので注意。
（特にGIGAなんとかとかで紹介されている海外のサイトとか注意した方がいいと思います）

仕様について考える

色は1色、2色、4色があるが、名刺なら4色で。
サイズは91mm×55mm。
紙の種類はマットとかツヤツヤとかあるけど、それもデザインに盛り込むのはもうちょっと成長してからで。 最初は好みでOK。
ちなみに、変形名刺（細長い形とか）にすると印刷屋の料金が跳ね上がる。

まずは名刺の形の枠線を作る

1. イラレで新規ファイルを作成し、サイズはミリメートル、色はCMYKを選択する
2. 長方形ツールを選択し、画面をクリック
3. 数値の入力欄が出るので、91×55で長方形を作成
4. 長方形をカットしてペーストすると、画面の中央に置ける（作業しやすい）
5. 四角を選択して、上部メニューのフィルタ→クリエイト→トリムマーク で、トンボを出す（四角を選択しないとダメ）
6. このトンボ、実は正確ではない。それは、四角の線の中央を基準に表示してしまうから。 つまり、線と塗りを一度非表示にしてからトンボを出す必要がある
7. そうすると、91×55の領域が分からないので、Ctrl+Rでルーラー（定規）を出して、そこからドラッグする事でガイド（基準線）を引く

ちなみにトンボとは紙を裁断する時の目安となるもの。 由来はそのまんまで、虫のトンボのように見える事から。 トンボは虫の動物（まめこ語録）。

また、ドブや断ち切りと呼ばれる空間を用意しておく。 現在の技術では数百枚を裁断していくとどうしてもズレが生じてしまうので、その誤差を埋める為の物。
サイズは内側が最低3mm、外側は3mm以上あればよい。

テキスト情報を流し込む

これで準備完了。 ここから実際に作っていく。
まずは用意した原稿を流し込む。 住所などのサブ情報は6ptがまめこの流儀。
文字数の関係で入りきらない場合は、改行して調整する。

名前は今回の作例では明朝体を選択。 漢字が分かりづらい場合には読み仮名を用意する。

まめこメソッド1：写真から素材作成

1. 素材探しで見つけた写真素材を、フォトショップで開く
2. 上部のメニューから、イメージ→モード→グレースケール→OK
3. 上部のメニューから、イメージ→色調補正→トーンカーブ→「右上から左下にかかっている斜線を『√』の記号のようにドラッグで変形させる」
4. 写真が黒い感じになった
5. 上部のメニューから、選択範囲→色域選択→写真の黒い部分をクリック
6. レイヤウィンド（大抵右下にある）の「パス」タブをクリックして、下部メニューの「選択範囲から作業用パスを作成」をクリック
7. 左上のフローティングメニューから、パスコンポーネント選択ツール（下の方のの矢印のアイコン）を使って、写真の左上から右下まで選択
8. それをコピーして、クリップボードに入った状態のまま、イラレにペーストする
9. 塗りと線を指定すると、いい感じに仕上がる
10. あとは回転させたり、素材同士をくっつけたり、コピーして反転させたり、拡大縮小したりでロゴっぽくするだけ

まめこメソッド2：Web2.0ぽい集中線

1. 円系ツールで正円を書く
2. 円を選択し、線のみにする
3. 線の太さを300とかにする
4. 線を破線にすると、Web2.0ぽい集中線になる
5. 線の色を変えたり、位置を変えたり、破線の間隔を変えたりしていい感じにする

タイトルを作る

ロゴの画像要素の上に配置する文字の事。
フォントを選んでテキストを入力し、選択して右クリック。 コンテキストメニューから「アウトラインを作成」。
これでそのテキストは、テキストデータではなくパス（画像）として扱える。 逆にいえば、文字を打ち直す事はできなくなる。
（不安だったら、一度コピペして保険として残しておくといいよね）

パス（画像）になったので、1文字づつ回転させたり大きさや色を変えたり、シャドウを入れたりしていい感じにする。

詰め

これでロゴや名前、住所などのパーツができた。
詰めとして、これらをバランスよく配置して調整、細かいデザインを追加していく。

• 罫線を引いて情報をグループ化する際には、罫線の上にワンポイントの要素を置いたりするとプロっぽい
• 背景に色を敷く
• ペンキを散らせた紙をスキャナで読み込んで、上記まめこメソッド1で背景画像を作り、配置する（これは使いまわせるので、アイディア次第でストックしておくといい感じかも）
• ロゴにグラデを使って色味を出す
• テキストの色を指定する
• 空間が空いたら、何か入れて埋める（まめこは屋号のロゴを入れていた）
• 全体的な位置の微調整は、モニタから遠ざかってチェック

裏面を作る

表面を全部コピーしてペーストする。
そこからいらない物を削除したり、色を変える。 空間が空いたら、何か文言とか入れる。
ロゴは表だけでいいので、Webサービスで使っているアイコンを入れたりしてもよい。

入稿の方法

• データはCMYKで
• テキストはアウトライン化する
• 断ち切りは端まであるかどうか
• 拡張子があるか

これらをチェックした上で、データとキャプチャ（印刷屋の人が見る確認用画像）を用意する。
表面と裏面は、それぞれ別のファイルにする。
CMYKのチェックは、全てを選択して上部メニューからフィルタ→カラー→CMYKに変換 で行う。
テキストをアウトライン化したら、もうテキストを編集できないので、別名で保存しておくとよい。
保存の際のバージョンは余り気にする必要は無い。 自分のバージョンに対応できる印刷屋を探すようにする。

なお、まめこオススメの印刷屋さんが資料に載っているはずなので、公開されたらチェックするといいと思います。

tips2種

• とにかくたくさんのデザインを見る。 可能なデータ形式なら、パスを見る（つまりソース嫁、って事）
• 文字数が多い場合、改行以外にも、文字の幅や高さを変える事でも対応できる。
  この手法は、フォントが持つデフォルトの特性も調整する事ができる（例えば、丸々ふっくらしたフォントの幅を狭めると、少しシャープに調整できる）。

Webサイトのあり方と考え方

色んなセミナーなどでも講演されているガクさん。 まめこの熱烈ラブコールに答えてトリを飾ってくれました。
ガクさんはデザイナーでは無く、また今回の内容もデザインとは少し離れた物でした。 しかし、主催まめこがその考え方に非常に共感する所があったようで、拝み倒されて（？）の講演となったようです。

まめこは過去に「人とのコミュニケーションもデザイン」と言っていました。
これは僕の主観なのですが、「デザインとは、目的や問題を解決するための手段」と考えるなら、こういったアプローチもまたアリかな、と思いました（プロダクトデザインで見かける考え方かも？ 雑誌Penとか）。 参加者の意識とはズレがあったかもしれませんが。
その辺を念頭に置いて、このセッションのまとめを書きました。

WebとWebに関連する企業の歴史

2000年頃のWebは、リンクでサイト同士が繋がっている程度だった。
それが2003年、2004年と年を重ねていくに連れて、企業が戦略的にWebを使用するようになった。
現在は様々なサイトが繋がっているだけでなく、ユーザー同士も繋がっている（口コミの効果）。
また閲覧する為の媒体（ケータイとかPSPとか）も広がりを見せている。

昔は買い物に行くとしたら、消費者は小売店舗に出かけていた。 しかし、最近はネットを通して企業から直販で買う事も可能になっている。
つまり、昔は企業にとって顧客とはあくまで小売店舗であり、消費者は直接的にお金を落としてくれる存在では無かった。 最近はそれが変わってきている、という事。
（企業が消費者を「顧客」と呼ぶ場合、その意識がある。 「消費者」と呼ぶ場合には、そういった意識が低い。 または無いと考えられる）

One to Oneマーケティング

販売者と消費者が取引（やりとり）する場合、大切なのはマニュアル以外の部分である。
例として分かりやすいのは、地元の馴染みの八百屋や魚屋のイメージ。

• 「いつもありがとうね！ 今日はサービスしちゃうよ！」
• 「お宅の息子さん、悪そうな連中とつるんでたよ？ 大丈夫かい？」
• 「今日は夕方から雨って言ってたから、早く帰った方がいいぜ」

こんな感じ。
そういった事を意識している仕事は他にもあって、新幹線パーサーやキャバクラ、コールセンターやメイドさん・執事などがそれにあたる。
共通するのは、1対多の接し方ではなく、1対1の接し方であるという事。
（この辺り、いわゆるホスピタリティにも通じる話かな、と思いました）

それをWebにあてはめてみると、PCの画面というのは、多くは一人で見る。
であるならば、WebにもOne to Oneマーケティングの方法が使えるのではないか。

One to Oneマーケティングで大切な事

キーワードとなるのは、4C。

• 顧客価値
• 対価
• 利便性
• コミュンケーション

簡単に言うとこう。

• 価値ある存在か？
• 価値に見合った対価か？
• わかりやすい場所にあるか？
• コミュニケーションは良好か？

Webデザインにあてはめて考える

例えば、プロダクトデザインでは美しさ、見易さ、扱いやすさの3つが重要としたら、Webデザインでは配色、配置、ユーザビリティの3つがそれにあたる。

tips：配色バランス

ベースカラー、サブカラー、アクセントカラーの割合は、70：25：5の割合が定番。
もし色を足したい場合には、最も多い割合を半分の35%にする。

tips：名刺を貰う時のマナー

名刺を貰ったら、相手より一秒でも早く上に持ち上げる。

この辺りから、上司にご馳走してもらった時のマナーやメールの書き方を間違うと職を失いかねないなど、マナーについての話になったんですが、これはさすがに蛇足だったかな、と感じました。
なんとなく、（マナーの話をするのは）ガクさんの本意では無いような気もしました。 あくまで予想ですが。

まとめ

• 情報は整理して、誰に伝えたいかを考える
• One to Oneコミュニケーションでは、相手の喜ぶ姿を考える
  例えばソースコードを書く職では、読みやすいコードを心がけるなどにも繋げられる
• マナーは大事

総括

デザインって、なんとなく「才能」とか「神が降りてきた」とか、天性の物が必要とされるイメージがありますけど、必ずしもそうでは無いんですよね。
理屈を学んで経験を積めば、ある程度のデザインはできるんだと思います。 ビジュアルデザインって言うか、絵を描いたりはまた違いますけど。

今回のセッションでも、「4つの原則」や「ベジェ曲線とは」など、理論的な説明が多くて解りやすかったです。
ビジュアル的な要素では「ごにょごにょして」という説明もありましたけどｗ まあそこは感性に基づく部分なのかな。

今回の勉強会を通して、デザインに関する興味が深まりました。
IAとかUIとかは（色の使い方とかに比べて）マークアッパーにも近い分野だと思うので、そういった方面で積極的に勉強したいです。

おかげさまで勉強会のまとめ記事が人気です。
知り合いからもまとめ方を知りたいと言われたので、hamashunのやり方を書いてみます。
ノートPCの使用が前提になっています（ある程度のタイプ速度が出せないと手書きの方がいいかも）。

勉強会当日のメモを取る時

多少の誤字は気にしない

「くだしあ」とか「でうｓ」とか、その程度の誤字は無視します。 あくまでメモなので、読み返した時に記憶を蘇らせるキーにする事が重要です。
あんまりにもひどい誤字は、スピーカーさんの喋りが一息ついた時に直します。 喋っている間はタイプし続けた方がいいと思います。

見出しを作る

スピーカーさんの話し方やスライドの雰囲気から察して、いわゆる大見出し的な発言は目立つようにします。 頭に■とか付けるだけでも大分違います。
僕が使っているez-htmlというエディタは、txtファイルでも色指定を設定できるので、視覚的に区別しやすいです。

example

■メモの取り方その１
◎メモの取り方その１
■□メモの取り方その１□■

インデントを使う

インデント無しで書くのは、中見出し的な言葉にします。 その見出しについての内容はインデントを一つ入れて書きます。
その内容から更に派生した内容がある場合には、更にインデントを入れます。 その繰り返しです。
と、文字で書いても解りづらいと思いますので、例をどうぞ。

example

■□マークアップのフロー□■

素のテキストをマークアップする
　その文書で最もレベルの高い見出しをh1で
　　トップページならタイトル
　　例えばBlogの個別記事ページなら記事タイトル
　その他もマークアップしていく
　divはまだ使わない
　　今はデザインの事は考えない

divでラップする
　ただし文書的に不自然にならないように
　　デザインを優先して、見出しと段落を分離とかダメじゃね？

スピーカー以外の言葉に目印を付ける

セッションの最中に参加者から突っ込みが入ったり、自分なりの解釈をメモする事があると思います。
後になって見返してからそれがスピーカーさんの発言では無い事が解るように、行頭に目印を付けておきます。
スピーカーさんの補足的発言に使ってもいいと思います。
今回は、＃をスピーカーの補足、＄を参加者の突っ込み、％を自分が思った事、としました。

example

■□マークアップのフロー□■

素のテキストをマークアップする
　その文書で最もレベルの高い見出しをh1で
　　トップページならタイトル
　　例えばBlogの個別記事ページなら記事タイトル
　　％SEO効果もありそうやね
　その他もマークアップしていく
　divはまだ使わない
　　今はデザインの事は考えない
　　＃考えると文書中心のマークアップに雑念が入るｗ
　　％雑念てｗ

divでラップする
　ただし文書的に不自然にならないように
　　デザインを優先して、見出しと段落を分離とかダメじゃね？
　　＄divで分離されていても、同じclassを付ければよいのでは？（○○さん
　　＃NGでは無いけど一般的では無いと思う
　　％classよりも更にdivでラップするとか。　いやそれもうざいか

ただ、これは意識しててもいざタイピングしていると混同しがちなので、『スピーカーの発言とそれ以外』を最低限分けられればいいと思います。

家に帰ってからまとめる時

対象を定める

まとめ記事の対象を決めます。
完全に自分用、勉強会に参加した人向け、勉強会に参加してない人にも解るように、の3段階があると思います。 当然、後になる程作業的には大変になります。

僕は『勉強会に参加した人向け』で書く事が多いです。 なので、ここでは主にその解説です。
参加していない人にも解りやすく書くには、ソースや図版をふんだんに盛り込む必要があるのでは。

構成をまとめる

スピーカーさんも人間なので、スライドが進んでから「あ、まだ喋ってない事があった」とページを戻して喋る事があります。
その間にメモが進んでしまっていると順番がゴチャゴチャになってしまうので、それを整理して順番を正しくします。

内容の割合

記事中に自分の意見はあまり混ぜません。 内容を中心に書いていきます。
自分の文章は補足的に持ちいる以外は、最後か最初に書きます。 逐一感想を書いていくと、かなり文章量が増えてしまって読む方も大変です。

できるだけ早くまとめる

なんだかんだ言っても、これが一番大事だと思います。 時間が経てば経つほど、記憶は薄れていきますよね。
打ち上げなどで家に着くのが深夜という事もあると思いますが、メモをざっと読み返しておくだけでも理解度が変わってくると思います。

公開した後の事

記事を公開した後に、スピーカーさんが資料を公開する事はよくあります。
そうすると資料へのリンクを追加すると思うんですが、記事の冒頭にその旨を追記しておくと、フィードを読んでいる人に優しいです。

ご注意

サンプル中のテキストは、あくまでサンプルです。

おまけ

先日のデザイン勉強会の時のメモを公開します。 資料を公開されていないガクさんのセッション部分は削除しましたが、その他の部分は全てそのままです。
見て貰うと分かるんですけど、ここまで偉そうにアレコレ語ってるわりに実際のメモはかなり乱雑です。 ま、まあ、ヘタに形式を守ろうとして進行に付いていけないよりはいいと思うんです。

関連リンク

アクセシブルなPDFとFlash のまとめ

JavaScriptを利用した動的なWebのアクセシビリティ のまとめ

先月の事になってしまいましたが、Webアクセシビリティ ~標準準拠でアクセシブルなサイトを構築/管理するための考え方と実践~の出版記念セミナーに行ってきました。 という訳で遅まきながらまとめです。

6章～8章の翻訳をされた梅垣さんは、「アクセシブルなコンテンツ、ナビゲーション、フォーム」という内容でした。
実装寄りでアクセシビリティを考える時は、HTML、CSS、JSと、別々で考える必要がある、との事でした。
資料へのリンク

著者について

原著を書いたJim Thatcherは、情報科学を専門とする博士で、IBMスクリーンリーダーを作った人。 だからなのか、視覚障碍者やスクリーンリーダーを強く意識した内容になっている。
なお、便宜上この記事では音声支援技術をスクリーンリーダーと呼んでいます。

画像

代替テキストとは

代替テキスト、と聞くとイコールalt属性を連想しがちだが、それだけに限った事ではない（alt属性は代替テキストの内の一つ）。 代替テキストとは、（例えば）画像の代替となるテキストの事（そのまんまだけど）。 つまり、代替になればalt属性に限らないという事。
これはlongdesc属性や画像（など代替テキストを必要とするコンテンツ）の近くに記述するテキストが挙げられる。

よくある代替テキストの例

意味を持つ画像（見出しなど）

その意味をalt属性の値とする

意味と機能を持つ画像（ナビゲーションなど）

基本的には見出しなどと同様。 ただ、例えばロゴマークにトップページへのリンクを貼っている場合には、画像にあるテキストが社名であっても「hoge社トップページ」などの文言にする

意味を持たない画像（装飾用画像、スペーサー）

alt属性の値に何も含めない。 半角スペースではなくいわゆるnull。 その理由は装飾およびレイアウト目的の画像の代替テキスト | アクセシビリティBlog | ミツエーリンクスに詳しい

グラフの代替テキストの例

longdesc属性

理想的な代替テキストだが、日本で主に使われているスクリーンリーダーは非対応

alt属性に内容を記述

長文になってしまう（例えばブラウザシェアのグラフなら、「ブラウザシェアは、Internet Explorer 7が20%、Internet Explorer 6が70%、Firefox2が・・・」となってしまう）。 JAWS（高機能のスクリーンリーダー）でもalt属性の値は150文字までしか読み上げてくれないので、これでは代替にならない

alt属性に概要を記述

例えば「ブラウザシェアは、IEだけで90%を占めます」など。

そもそもグラフにする必要があるのか考える

テーブルで表として表現する事も可能

文脈的に書く

グラフの画像の近くに説明テキストを記述するなど

hamashun注

こういう例を出すと、「どれがベストか？」という話に終始しがちですが、僕個人としてはその考え方自体が既にベストでは無いと思います。
その情報の種類や対象ユーザーに合わせて、毎回最適な選択をする事がベストなのではないでしょうか。

音声

音声ファイルの等価テキスト

対談などで、音声ファイルを配布する場合には書き起こしテキストも提供する。 これには重要な音響的手がかりも記述する（例えば「ここで大きな拍手！」とか）。
（そういえば、「辻ちゃん・ウエちゃんのアクセシビリティPodcast」でも提供されていますね）

色

色のみの情報にしない（「赤いテキストが最新です」だと、色覚に障碍のある人が分からない可能性）。
また、コントラストを十分に取る事も重要。 カラー・コントラスト・アナライザー 2.0 日本語版が参考になります。

テーブル

アクセシビリティーの世界では、データテーブルとレイアウトテーブルの2種類に分類している。

レイアウトテーブル

スクリーンリーダーの読み上げ順に気をつける。 また、th要素やthead要素などは使用せず、table要素、tr要素、td要素のみを使用する。

データテーブル

見出しは必須。 1行目や1列目に記述する（普通は自然にそうするけど）。 昔のスクリーンリーダーは1列目や1行目を強制的に見出しとしていたので、その為。
その見出しがどの方向の見出しかを示すにはscope属性を使用する。 参考：テーブルとアクセシビリティ -- ごく簡単なHTMLの説明

階層型テーブル

複雑な構造のテーブルにはheaders属性とid属性を使用する。 参考：テーブルとアクセシビリティ -- ごく簡単なHTMLの説明
ただし、日本のスクリーンリーダーは余り対応していない（ホームページリーダーは対応しているらしい）。

視覚障碍者が複雑な表の内容を理解するのは難しい。 なので、1つの複雑な表にまとめるよりは、シンプルな2つの表に分割できないかなどの対応も考えるべき。

画面の点滅

フリッカーと呼ばれる現象（写真サイトではない）。 Flashゲームなどを作る際には留意する。

ナビゲーション

JAWSは各hn要素にジャンプできる機能がある（きちんとしたマークアップをすれば、それだけで便利になる）。
JAWSとホームページリーダーは、ナビゲーションスキップ機能がある（何の事かよく解りませんでした。 連続するリンクをスキップできるという事？）

音声リーダーを使用するユーザーは、tabキーでリンク部分のみを選択してブラウジングする事がある。 リンクテキストが「ここをクリック」などであると、何の事か解らない（これはSEO的にもよくないと言われていますね）。

フレーム

framesetのぺーじではたいとるぞくせいをつかう。 各ふれーむには、head要素にたいとるぞくせい。

イメージマップ

クライアントサイドの画像を使う。 サーバーサイドの画像を使う場合には代替リンクが必要。 area要素にはalt属性が必須。

フォーム

labelは明示的に付ける。 label付けが無くてもスクリーンリーダーがある程度推測してくれるが、これに依存しないように。

フォームのマークアップにテーブルを使う事はよくある。 スクリーンリーダーは、テーブルモードとフォームモードを両立できないが、labelを正しく付ければ読み上げる事ができる。
しかし、idはUniqなのでlabelが複数ある場合には対応できない（これがよく解らなかったんですが、資料を見ると、左と上に二つあるthの事？）。

fieldset要素とlegend要素でフォームをグループ化する事ができるが、日本のスクリーンリーダーはlegend要素に対応していない。

フォームの設計段階の話だが、聴覚障碍者は電話番号の入力を求められても躊躇する。 それ以外の連絡手段が必要である。

日本のスクリーンリーダーは力不足である

仕様通りに作ったとしても、UA側の実装が追いついていないのでアクセシブルにならない。 製作者はこの問題に対して選択が求められる。
一つは仕様を重視して特に対処はしない。 もう一つは情報が正しく伝わる事を重視して、冗長な表現やバッドノウハウの使用も検討する。 或いは、その中間を取る。

関連リンク

アクセシブルなコンテンツ、ナビゲーション、フォーム のまとめ

JavaScriptを利用した動的なWebのアクセシビリティ のまとめ

前回の記事同様、Webアクセシビリティ ~標準準拠でアクセシブルなサイトを構築/管理するための考え方と実践~の出版記念セミナーのまとめです。

11章と12章を翻訳されたのはインフォアクシア代表の植木さんです。 内容はPDFとFlashのアクセシビリティについてです。
なお、便宜上この記事では音声支援技術をスクリーンリーダーと呼んでいます。
資料へのリンク

イントロダクション

FlashやPDFを取り巻く環境はコンテンツ、オーサリングツール、UAの3つに分けられる。 そしてそれぞれに対応するのがWCAG、ATAG、UAAGの3つのガイドライン（ちなみに作っているのはW3C）。
コンテンツは仕様とWCAGに準拠し、オーサリングツールは仕様通りに生成し、UAはコンテンツを忠実に変換して読み上げる必要がある。
これらが正しく動作して、はじめてアクセシブルになる。

課題はUA

コンテンツとオーサリングツールに比べて、UAの実装が遅れている。 更に日本で大きなシェアを持つホームページリーダーは、VistaとIE7はサポートしないと言っている。
FlashやPDFも、オーサリングツール側ではアクセシブルにする手段が用意されているが、やはりUA側がネックになっている。

PDFのアクセシビリティ

12章。 原著はAndrew Kirkpatrick。
Andrewはアドビ全製品のアクセシビリティ統括責任者。 以前は公共放送の字幕や副音声に関わっていた。

過去の問題と現在の状況

過去には、PDFはスクリーンリーダーでは読む事ができなかった。 また、キーボードでの操作も難しかった。
読み上げに対応した後も、セキュリティを設定するとアクセシビリティが犠牲になったりしていた。

しかし、バージョンを重ねるごとにアクセシビリティも向上してきている。
現在ではタグを埋め込む事で、HTMLに近い読み上げが可能（日本ではFocusTalkが対応）。

作成する方

アクセシブルなPDF作成フロー

Word文書を元にPDFファイルを作成する流れを解説。 Wordは2007との事。

1. 文書構造を、書式→スタイル で定義する。 これはHTMLのマークアップと同じ感覚
2. 画像ファイルには代替テキストを付ける。 alt属性のように。 画像を右クリックして設定→代替テキストタブを選択（オフィス2007の場合）
3. 段組を使用する場合は、書式→段組 で設定する（表機能を使わない事）。
4. 箇条書きや見出しも、それぞれのスタイルを使用する
5. WordファイルをPDFに変換する
6. 変換設定の変更 で各種設定を行う 参考：植木さんのプレゼン資料
7. 変換する

InDesignから変換する事もできるが、タグ付けなどの面で厳しい。 要素名を自由に設定できるので、逆に厄介。

アクセシブルチェック機能

詳細チェックはProfessional版を使うとよい。
アドバンスド→アクセシビリティ→完全チェック を選択。 詳細なエラーやその修正方法が表示される。 画像の代替テキストを忘れていた場合など、エラーテキストをクリックすると対象の画像を示してくれるので親切。
たまに関係のないエラーが出る事もあるので注意。

読む方

各種設定を変更する事で、リーダーをアクセシブルにできる。

• 編集→環境設定→アクセシビリティ でコントラスト、背景色、文字色を変更できる
• 表示→折り返し で横スクロールせずに画面を拡大できる
• 表示→自動スクロール で画面の自動スクロールを設定できる（これは使い勝手は微妙）
• 表示→読み上げ で読み上げる事ができる（英語エンジンしか積んでないので、日本語は微妙）

Flashのアクセシビリティ

11章。 原書はBob ReganとAndrew Kirkpatrick。
BobはFlashのアクセシビリティで有名な人だとか。

過去の問題と現在の状況

スクリーンリーダーで読む事ができなかったり、一度Flashにフォーカスするとそこから抜け出せなくなったりしていた（いわゆるフォーカストラップ）。

現在ではFlash（オーサリングツールの方）にアクセシビリティパネルが搭載されている。 これで代替テキストを割り当てたり、フォーカスの順序（tabindexみたいな）を指定できる。
CS3では動画に字幕を付ける事も容易。 また、プレイヤー側でフォーカストラップは解決済みである。

アクセシブルなFlashのベストプラクティス

• 等価テキストを提供する
• 状況を伝える
• 音声読み上げ順序を制御する
• アニメーションを制御する
• キーボードで操作可能にする
• 段階的に情報を公開する
• コンポーネントのアクセシビリティを有効にする
• キャプションを提供する
• 音声再生のコントロールを提供する
• よく考えて色を使用する
• ロービジョンのユーザーをサポートする
• Flashをサクセシブルに埋め込む

書籍の388ページ以降に、詳しい解説が載っています。
下記に、セミナーで解説された内容を記述します。

等価テキスト

アクセシビリティパネルの名前フィールドに、alt属性のように記述する。 説明フィールドは使わない方が無難との事。
等価テキストが不要な場合は、「オブジェクトをアクセス可能にする」のチェックを外す。 これにより「意味を持たない画像」のような扱いになる。

状況を伝える

全体の構成を説明する。 どんな画面で、どんな情報で、どんな機能なのか。 概略ページへのリンクを設置してもよい。

HTMLページの一部にFlashのコンテンツを設置する場合には、Flashと連動する動的なテキストで現在の状況を知らせる。
（感覚的に解りづらいんですが、動的なコンテンツには、その時の状況を知らせるテキストを動的に出力する必要がある、という事だと思います）

CS3の新機能、字幕を簡単に付ける

Flash CS3では、簡単に字幕を付ける機能が追加された。

1. ファイルを開く
2. コンポーネントの選択でビデオ→FLVPlaybackCaptioningをドラッグしてステージへ
3. パラメータを指定する

字幕部分はシンプルなXMLファイルになっていて、表示されるテキストやその文字列が表示されるタイムラインなどが記述されている。

関連リンク

アクセシブルなコンテンツ、ナビゲーション、フォーム のまとめ

アクセシブルなPDFとFlash のまとめ

前回、前々回の記事同様、Webアクセシビリティ ~標準準拠でアクセシブルなサイトを構築/管理するための考え方と実践~の出版記念セミナーのまとめです。

10章の翻訳をされたのは中村精親さんですが、セミナーでは渡辺さんが話をしてくれました。 内容はアクセシブルなJavaScriptについてです。
なお、便宜上この記事では音声支援技術をスクリーンリーダーと呼んでいます。
資料へのリンク

JavaScriptはアクセシビリティ的にも誤解されている

JavaScriptは、アクセシビリティを妨げる使われ方が多かった。 例えば、右クリック禁止やポップアップ・ウィンドウなど。
また、アクセシブルでないスクリプトにより、JavaScriptをオフにすると利用できなくなってしまうコンテンツが（現在でも）ある。

著者の主張

原著を書いたのはChristian Heilmann。 ChristianはWaSPのDOMスクリプティング・タスク・フォースのメンバー。

Christianは、でしゃばらないJavaScriptがよいと言う。 JavaScriptが無い環境でも得られる情報は同じで、JavaScriptが利用できる環境では更にリッチな体験ができる、というように。
（この辺、Webデザインで言うところのMOSeを連想させますね。 アクセシビリティ関係ないですけど）

JavaScriptは「振る舞い」を担当する

HTMLが構造、CSSが表現であるなら、JavaScriptは振る舞いであると言える。

RIAのアクセシビリティ

これは、書籍から離れた内容。 GoogleのiGoogleとGoogleドキュメントのアクセシビリティについて。
なお、この調査は渡辺さんの生徒さんによるものだそうです。

渡辺研究室の2007年度卒業研究「JavaScriptを利用した動的なWebのアクセシビリティ」（松田理沙）から，GoogleのRIAのアクセシビリティ問題のケーススタディを紹介．

との事。（資料１１ページより）
（セミナーでは悪い点ばかりが取り上げられていましたが、良い点もあったのでしょうか？ 気になるところです）

操作部分のHTML

ホームページリーダーを使用すると、キーボードで操作できない部分がある。 これらは内容を持たない要素と背景画像でコーディングされているので、HTML的には意味の無い存在という扱い。
他にも、Googleドキュメントにある「新規作成」というタブをクリックすると「リンクではありません」と読み上げられる（div要素やspan要素でマークアップしてあるため）。

ショートカットキー競合

Webアプリケーションのショートカットキーと、スクリーンリーダーのショートカットキーが競合してしまう事がある。 これは本質的な問題である。

追加されるHTML

Googleドキュメントでは、ドロップダウンメニューを開くとHTMLの最後にソースが追加される。 その為、スクリーンリーダーでは開いた時には読み上げられない。

動的なページ書き換え

例えば、nowaの管理画面では自動的に新着記事を表示しますが、スクリーンリーダーでは更新がなされた事を知る術がない。
WAI-ARIAのlive属性はこの問題を解決できるかもしれない。
（WAI-ARIAについては、梅垣さんの（今回のセミナーとは関係の無い）資料Ajaxアクセシビリティ～リッチ・インターネット・アプリケーションのゆくえ～が解りやすいかも）

個人的な意見

アクセシビリティ業界（？）では、JavaScriptは悪役にされがちな気がします。
hamashun個人としては、「全てのWebサイトはアクセシブルなJavaScriptを採用すべき」という必要は無いと思います。
伝えたい情報が伝えたい相手に正しい形で伝わる事が大事なのであって、HTMLやCSSやJavaScriptなどの技術はその手段であるべきだと考えます（ここで言う情報とはテキストのみならず、デザインや操作感も含みます （いわゆるUser Experienceと言えるかも））。

CSS Nite in Ginza, Vol.23に行ってきました。 今回のゲストはあの大藤幹さん。 大藤さんの名著CSSプロフェッショナル・スタイルは、コーディングの勉強を始めたばっかりの頃に買って物凄く役に立った本だった事もあって、かなり期待していました。

開演前

19時開演なので18時30分に到着したんですが、既に座席は満員でした。 さすがに凄い人気です。

テーマ

大藤さんは雑誌Web Designingに『CSS Analysis』という連載をしていて、その内容は世界のWebサイトを取りあげて色んなテクニックを紹介するという物。
今回のテーマはそれの特別版みたいな感じで、『CSS Analysis Live!』でした。
なお、内容はあくまで解析したサイトの結果であり、それが正しいとか、或いは大藤さんの意見である、という訳では必ずしもないようでした。

アジェンダ

• この1年間の流れ
• トピックと事例
• これからのCSS

この1年間の流れ

新しいネタが減ってきた

CSSネタは成熟した感があるのでは。 ブラウザごとの特徴や対策や組み方のTipsなど、大抵の情報は出揃ってしまった。

（hamashun注：以前書いたんですけど、僕も同じような事を感じていました）

ハックを使わないサイトが登場した

CSSハックを全く使っていないサイトを取り上げてから、1年経っている。 しかしハックを使わないサイトは使っているサイトにあらゆる点で勝っている訳ではなく、例えばブラウザによる若干の差異などのデメリットが存在する。

世代交代で繰り返す歴史

画像置換の問題が顕著（後述）。

英語圏以外の国のサイトが増えた

連載当初は英語圏が100%だったが、最近ではドイツ、ブラジル、ルーマニア、チェコ、フランス、イタリアなど多岐に渡っている。
ちなみに取り上げる際は言語は考慮していなく、単にソースコードを見て決めているとの事。

言語圏の違いで制作スタイルの差が出てきた

昔は英語圏がNo,1だったが、最近はそうでもなくなってきている。 ドイツは追いつき追い越している印象。 そういえば思い返すと、2003年のW3Cサイトのリニューアルコンテストで優勝したのはドイツの人だった。
日本も結構イケてる。

トピックと実例

CSSハックの現状

• * html といういわゆるスターハックを殆ど見かけなくなった。
• clearfixも以前より減っている
• CSSハックを一切使わないサイトも登場した

世代交代による画像置換問題

画像置換そのものが悪という風潮で、使われない時期があった。 しかし、最近は普通に使われている。
その手法も、以前は古いブラウザに対応する為にtext-indent: -9999px;などとしていたが、最近は古いブラウザは無視したコードが増えている。 これらは若い製作者に多い傾向な模様。

古いブラウザの対応

英語圏では切り捨て傾向にある。 ドイツやオーストリアでは、IE5.0、IE5.5なども対応している事が多い。

（hamashun注：まあ、この辺はその国ごとのビジネス的、リテラシ的な事情にもよりそうですし、一概に優劣は決められないのではと思います）

CSSファイルの分割について

一時期、非常に細かく分けているサイトがあったが、最近はかなりシンプルな分け方が多い。 例として紹介された分け方で印象に残ったのは、いわゆるLiteboxなどのライブラリ用CSSを別ファイルに分けている事だった（弊社だと開発しちゃう事もあるので同じファイルに記述する事も）。
また、ブラウザの振り分けにはコンディショナルコメントを使っているサイトが多い（hamashun注：スターハックが減った理由も恐らくここにあるのでは）。

リセットCSS

最近は見かけない（！）。 連載で取り上げたサイトでは、英語圏以外では1年前くらいからゼロ件。 ただしこれは、一括してリセットしていないという意味で、marginとpaddingだけはリセットしたり、必要な箇所だけでリセットしているサイトはあるとの事。
でも、本当に全くリセットしていないサイトもあって、そのサイトはブラウザによって若干の表示差異はあるとの事。

（hamashun注：個人的にはこれには結構驚きました。 現状でmarginとpaddingのリセットをしないメリットはあるんでしょうか。
なお、この記事の最初にも書きましたが、この講演はあくまで事例を紹介する物であり、それが必ずしも優れているという訳ではないので注意してください）

ページの上部が大きな画像になっているサイト

ヘッダー部分を大きくとって、そこに大きな画像を配置するサイトが増えた。 これによって文字サイズを極端に変更してもサイトのイメージが損なわれない。

超大きい画像を使ったサイト

3000pxとかの大きな画像を使ったサイトも増えてきた。

（hamashun注：nowaのヘッダ画像も、リキッドレイアウトに対応するために大きな物が多いです。 2000pxとか。 max-widthプロパティと合わせて大きなヘッダ画像を使う方法がわかりやすいのでは）

エラスティックレイアウトの登場

2回取り上げた。 国はイギリスとアメリカ。 最近は余り見かけない。
これは_blankによる別窓問題と似た問題を引き起こす可能性があって、便利だと思う人もいれば迷惑に思う人もいるかもしれない。

これからのCSS

足すコーディングから引くコーディングへ

追加修正などのたびに足せば足すほど、または（ファイルを）分ければ分けるほど問題が増えるのではないか。 例えば、

• 何か問題が起きたらハックを使う
• 何でもかんでもデフォルトスタイルリセット
• CSSファイル自体も分けまくる

これらによって問題が発生する可能性がある。

ドイツ式シンプルコーディング

ドイツのコーディングはシンプルでキレイらしい。 余計な事はせず、見通しのいいCSS.
キレイなソースなどと聞くと「それが何の得になるの？」と言う人がいるが、そういう人はコーディング自体が目的になってしまっている。
コーディングとはあくまで目的を達成するための手段であり、短くキレイに書いておけば、その後の作業もラクになる。

（hamashun注：ここがちょっとピンとこない人もいるかもしれませんが、つまりコーディングが目的になっているというのはその場のコーディングを終わらせる事が目的になっていて、運用を考えていない状態なのではと思います。
自分の書いたコードを半年ぶりに編集する事を考えたら、キレイなコードの方がいいですよね）

プロパティの降順

連載でとりあげた最近のサイトは、結構バラバラ。 でも読みづらくはない。 プロパティは降順よりは数が読みやすさに影響するようだ。
また、重要なプロパティを上の方に持ってくるサイトもあった。

質問コーナー

Q:ドイツはCSSがキレイだというけど、HTMLはどうなんですか？

A:HTMLもキレイ。 というか、この連載はHTMLがキレイである事がまず前提。 そこから更にCSSを見ている。
基準のひとつとなるエピソードは、css Zen Gardenを取り上げようと思ったが、HTMLがアレだったのでやめたというもの。

Q:コンディショナルコメントの是非

A:最近増えている理由は不明。 使っている人が多くなってきたから他の人も使う、という循環かも？
ただし、Microsoftの中の人的には「使わないで」と言っていた。

Q:CSSファイルを分割しないWebサイトの規模は？

A:個人Blogが多い。
余談ながら森田雄さんは「分割するとセッションが増えるからそういう手法を紹介しないでほしい」と言っていたそう（読み込みのロスが増えるという事）。
益子さんはガンガン使う派らしい。

最後に

情報に翻弄されない事が大事。

• 今回の講演に影響を受けて手法を変えても、他の情報でまた変えたくなるかもしれない
• 自分の仕事がラクになるようにしよう
• 労力とメリットをよく考える
• 定番手法はそれだけ多くの人のノウハウが詰まっている
• 最後は自分で考えるべし。 自分の道を行け

感想

久しぶりにガチなCSSネタを聞けて楽しかったです。 業務に使えそうな部分もありました。
お会いするまではなんとなくもっと固い感じの方なのかと思っていたんですが、全然そんな事はなくて打ち上げでも気さくで優しい方でした。

livedoor Blogの第4世代テンプレートがhAtomに対応したりして、最近社内でにわかにmicroformatsが盛り上がっています。
そこで制作グループ（デザイナとマークアッパ）の定例ミーティングの時に、社内勉強会を行いました。
参加者は制作グループに留まらず、ディレクターやエンジニアの人達も聞きにきてくれました。

資料公開

という訳で資料を公開します。
勉強会は前後半に分かれていて、僕の担当はざっくりしたmicroformatsの説明でした。

できるだけ解りやすく伝えようと思ってこんな書き方にしてみたんですけど、逆に解りにくくなっていないか微妙に不安です。
社内勉強会では質問タイムも多めにとっていたので、結構伝わっていたんじゃないかなと思います。

ミツエーリンクスで行われた『マイクロフォーマット』出版記念セミナーに行ってきました。 今度出版されるマイクロフォーマット本の著者であるJohn Allsopp氏を迎えてのセミナーです。
内容は、第一部が木達さんによるマイクロフォーマットの概要的な話、第二部が木達さんとJohn Allsopp氏の対談でした。

会場は西新宿にあるミツエーリンクスの社内セミナールームでした。
会社の後ろの席の人と「多分いるんじゃね」と言ってたんですけど、思ったとおりネコゼさんとかforestkの人とかがいました。

第一部

第一部の内容は、個人的には大体理解している事だったので、よい復習になりました。 いくつか気になったポイントをピックアップします。

VoteLinks

VoteLinksはシンプルなマイクロフォーマットの一つで、ぼーとりんくす と発音します。
リンク先に対して賛成か反対か、はたまた意見を保留するかを示す事ができるマイクロフォーマットです。

これをlivedoorクリップやはてブなんかが採用したら面白いんじゃないかなと思いました。 何かの議論の時に賛成派の意見だけを取り出したりとか、その人のコメントのネガティブ率とポジティブ率とかも簡単に出せそうです。

参考リンク：vote-links-ja - Microformats

ブラウザのネイティブ対応の話

Firefox3では、機能としての対応は見送られたもののAPIレベルでは実装されているとの事。 つまり、拡張機能とかで今後面白いものがどんどん出てくるかもしれない。

現在開発中のIE8では、hAtomに「よく似た」WebSliceという機能があるとの事。 あーあーまた独自規格かよーと思わなくもないです。
John Allsopp氏的には、「一般の人にまで普及するならそれはそれであり」というような考えのよう。 まあそう言われると、一見遠回りなようで（将来的に規格を統一する事を考えても）結局は早いのかもしれないですね。

hAtomとWebSliceのコードを比較

John Allsopp氏が楽観視ともとれるような考え方をしていた事を少し不思議に思ったので、両者のコードを見比べてみました。

hAtom

<body>
 <div id="wrap">
  <div class="hfeed" id="content">
   ...
   <div class="hentry entry" id="post-60">
    <h3 class="entry-title">
     <a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a>
    </h3>
    <div class="entry-content">
     <p>We had a bit of trouble with ...</p>
     <p>We’ve restored the wiki and ...</p>
     <p>If anyone is working to combat said spammers ...</p>
    </div>

以下省略

WebSlice

<div class="hslice" id="webslice">
   <p class="entry-title"> MSN.com Slideshow </p>
   <div class="entry-content"> Latest content ... </div>
</div>

必要な記述で異なるのはルート要素のみで、タイトルと内容には両者共通のclass名を使用するようです。 つまり、両立は容易です。 それなら尚更hAtom使えよと。
このままIE8がリリースされた場合には、hAtomに対応する場合にひと手間加えてWebSliceにも対応する、というやり方になりそうです。 ああ面倒くさい。
しかし、個人的にはWebSliceのためのid属性には納得いかないです。 「2箇所以上指定されるとめんどくね？」→「じゃあidも指定させちゃおうぜ」とかそんな理由だったりして。

なお、hAtomはドラフト段階ですしWebSliceもIE8がベータの段階なので、今後何か動きがあるかもしれません。

アクセシビリティの話

マイクロフォーマットとアクセシビリティの話になると必ずと言っていい程に取り上げられるのが、abbrデザインパターンです。 これは、本来は略語を示すためのabbr要素を使って、日時を意味づけるというマイクロフォーマットです。
つまり、abbr要素は略語のはずなのに、その内容には日時が記述される事になります。

これで困るのが、音声リーダを使用しているユーザです。 音声リーダが略語として読み上げると、ユーザが混乱してしまう恐れがあるという問題。
文脈に注意すれば上手い事ごまかす事はできるかもしれませんが…まあそういう問題じゃないですよね。 span要素を使っておけば余計なトラブルは起きなかったのではないかなとも思います。

第二部

第二部は、「非常に早口、かつ難しい言い回しをする」John Allsopp氏と、木達さんの対談です。 木達さんは通訳も兼ねているので、かなり忙しそうでした。

Johnの最近のマイクロフォーマット関連の活動は？

• メジャーな製品を作ってはいない
• トレンドを追いかけ、それを広めている
• 企業や製作者からの質問を受けて、それに答えている
• カンファレンスで講演をしたり、企業に行って説明会をしている

今回、日本に来た理由

• SwapSkills for Happy web weekendのため（終了）
• Web Directions East（John Allsopp氏が主催するイベント、の日本版）のための調査

Web Directions Eastについて

• 海外から5,6人、日本から5,6人の講演者を予定している
• 海外からの講演者には同時通訳がつく
• 全部で4日間行われる大きなイベント
• 土日はカンファレンス、月火はワークショップ
• カンファレンスはデザイン系と開発系に分かれる
• デザイン系には、HTML、CSS、マイクロフォーマットなど
• 開発系には、JavaScript、ライブラリ、Ruby・・・（あとなんか早口で言ってたけど聞き取れませんでした）

マイクロフォーマットは、「卵が先か鶏が先か」という状態では？

補足：開発者は「ブラウザがネイティブ対応してないし、マイクロフォーマットの対応はもう少し見送ろう」と思い、ブラウザベンタは「まだあんまり使われていないからネイティブ対応の必要はないな」と思うジレンマについて。

• マイクロフォーマットは素晴らしいアイディアとして生まれてきた。 しかし生まれてすぐには実現していない
• 2,3年が経って、ようやくいくつかの大きなサービスで使われはじめた
• 大事なのは、コンテンツ（情報？）、サービス、ツール
• アメリカでは、Yahoo.comやSBMサービスなどで既に使われている
• とくにYahooではサーチモンキーと呼ばれる検索オプションが存在する

参考リンク：ヤフー、「SearchMonkey」を一般公開 - 開発者のためのオープンサーチプラットフォーム :: SEM R
個人的にはこれ、興味を惹かれました。
Leveraging the Data Webを眺めた感じだと、オレオレマイクロフォーマットではなくて既存の規格でOKみたいな？

ネイティブにサポートしているブラウザがない件について

• 数ヶ月前に、Firefox3がネイティブ実装を見送る決断をした。 我々にとっては残念な事だ
• しかし、彼らは新しい事に対して慎重になる必要がある。 実装してからユーザが見向きもしない、ではダメージになるからだ
• 例えば、マイクロフォーマットに対応しているか否かで、同じようなサイトでありながら一方では使える機能がもう一方では使えない、という事態になりユーザが混乱する恐れがある。 この辺りはユーザの成長も必要だ
• 現在はAPIを利用する事が重要だ
• 今、「マッパーヌーイ」というブックマークレット（？）を作っている。 hCardに関するものだ

IE8のWebSliceについて

• ポジティブな見方をしている
• ユーザが体験するいい機会だ
• 現在はブラウザは、提供されたコンテンツをただクリックするだけだ
• 新しいブラウザは、深い部分の情報を取り出して提供してくれる。 これはブラウザ2.0と言ってよい

アクセシビリティや国際化の際の問題について

補足：これらの問題が解決できれば、もっと広まりやすいのでは？ という意図。

• abbrデザインパターンに関しては、確かにアクセシビリティ的な観点で難しい側面がある
• オンラインコミュニティでの議論でも緊迫した展開になった事がある
• SGMLは巨大で難解な仕様だ。 HTMLはシンプルで、洗練された…スシのようなものだ（Johnにとって寿司は洗練されたものの代表？らしいです）
• その洗練されたものを壊す事なく、増やしていく事はとても難しい。 しかし、マイクロフォーマットならばそれが可能だ
• abbrデザインパターンの問題は、限界を突破しようとした時に生じる避けようのない問題と言えるかもしれない

書籍、マイクロフォーマットについて

• マイクロフォーマットに関する事はこれ一冊で事足りる、という内容
• 売れ行きはいい感じ。 1版は完売した
• amazonでも上位1万にランクインした
• 2版の予定は未定。 もし出るなら、アップデートされた内容を盛り込むので、1版と比べてかなり追加などがありそうだ
• 日本以外にはフランス語版を予定している

日本語版書籍や、読者への期待を

マイクロフォーマットはメタデータである。 コンテンツとはレイヤが違う。 これは言葉の違いを乗り越えられる可能性を持っている。

質疑応答

ここで「いわゆるSNSなどでの友人関係をXFNで表すなら、どの値が適してると思いますか？」という感じの質問をしたんですが、これが解りづらい言い方をしてしまったせいでJohn氏にうまく伝わりませんでした。 あまつさえ貴重な質疑応答の時間を消費してしまい…申し訳ないです＞＜
というか、今Twitterを見たらrel="contact"がついてた！ それでいいんじゃないのか！？ うわああああああバカ！ バカ！ バカ俺！＞＜ 他の参加者の皆様、木達さん、ほんとすみません＞＜

Q:WebSliceが普及したら、標準規格が二つ存在する事になりませんか？

A:それは心配していない。 それはそれでOKだ。

Q:余り詳しくない製作者にも「使いたい！」と思わせるような動機はありませんか？

A:実際に動くところを見せると、便利さが解って貰えるのでは（木達さんの意見）。

hamashunのセッション

先日のCSS Niteで、「Webの世界に情報発信しよう！」というタイトルで喋ってきました。
内容は簡潔に言うと、「ブログ書こうぜ」です。

当日のアンケートを見させてもらったんですが、おおむねいい感じの評判を頂けてたようでほっと胸を撫で下ろしました。
なんて言うか、正統派のプレゼンではなかったので、もっと好みが分かれるかなーとか思ってました。 特に寸劇とか寸劇とか寸劇とか。

スライドはUPしていますが、高橋メソッド風味なので（あくまで風味）、スライドだけ見てもあまり意味は無いっぽいです。 音声とか公開・・・されるのかな？

セミナーのような場所で喋るのは今回が初めてだったので、いろいろと勉強になり、また課題も見つけられました。
喋っている時の姿勢をもうちょっとシャンとした方がいいかなとか、間の取り方をもう少し緩急付けたいなーとか。

小山田さんのセッション

今回のCSS Niteは2本立てで、最初が僕、その後がヨモツネットの小山田さんでした。
小山田さんの講演内容はガチなCSSネタ。 displayプロパティの値inline-blockに関する内容です。

inline-blockはちょっとした工夫をすれば既に使えて、かつ結構便利、という内容でした。
スライドのサンプルコードでは、Firefox2に対応するためにdivを一つ増やしていました。 あくまでサンプルコードなのでdivを増やしていたんだと思うんですが、実際は div > ul とか、なんかうまい事やれればいいのかなとか思いました。 或いはFirefox2は諦めるとか。

打ち上げ

打ち上げは、いつもより少なめの人数でしたが、逆に話しやすくて良かったと思います。
「IAの話とか勉強会とかしたいよね」的な話で盛り上がったり、Firefox3.1βの情報をさっそく交換したり。

私信

IRCの件。 ぜひｗ

EDGEのソースコードをだいぶ修正しました。 article要素とsection要素の辺りが若干もにょもにょしてます。

あと、今週末にある実践CSS3 & HTML5 with Microformats ワークショップに参加します。 東京の方です。
会場でアレな感じのロンゲを見かけたらよろしくお願いします。

実践CSS3 & HTML5 with Microformats ワークショップ :: Web Directions Eastに行ってきました。

会場は恵比寿のとある会議室で、少人数（参加者10人弱くらい）で行われました。
講師はJohn Allsoppさんで、通訳にヤスヒサさん。 色んなお手伝い（という紹介でいいんでしょうか）にOli Studholmeさんというチームでした。 ヤスヒサさんは久しぶりにお会いしましたが、髪が伸びていました（お前が言うな）。

参加者の中で知ってる人はネコゼさんだけでした。 あの人とかあの人とか来ると思ったのになあ。。
休憩時間に技術評論社でHTML5の記事を書いた村田さんと名刺交換をさせてもらったりもしました。

hamashunフル装備

今回のセミナーはノートPCが必須条件で、かつ予定されている時間も長時間だった為、フル装備を持ち込みました。 具体的には以下の物です。

• Thinkpad X61
• センチュリー 液晶ディスプレイ LCD-8000U
• Realforce 89UB（キーボード）
• ロジクール G5 レーザーマウス G-5T（マウス）
• ハンドレスト

はい、殆ど自宅環境ですね。 でもおかげでかなり快適に受講する事ができました（デスクが広くて本当によかった）。
さて、雑談はこれくらいにして、ここから先が本番です。

前説

まずは今回の告知ページを例に出しての前説。 このページを見るだけでCSS3を実感できる。

• @font-faceによるフォントのダウンロード
• border-radiusによる角丸BOX
• text-shadowによるドロップシャドウ

など。 IEやFirefox3.5やOpera10、Safari4で見比べてほしい（IE以外全て開発途中版）。
ちなみにOpera10で見ると、テキストへのシャドウは効くけどオブジェクトへのシャドウは効かない。 Safari4はtransformも効く。

Part 1 ： マークアップ

まずは文書をグループ分けする

Johnは、プレーンテキストを前にして、いきなりタグ付けをするわけでは無い。 まずはテキストを意味で塊に分ける。 そしてその塊に名前を付けていく（実際にタイピングして書き込んでいくよう）。
名前の付け方は、いわゆるヘッダやフッタなど多くのサイトで使いまわせる名前と、そのサイト独自の名前とがある。

このやり方は、レゴ・ブロックのような物。 いきなり全体を見るのではなく、ブロックごとを見る。
そして英語ではこの塊の事を『セクション』と呼ぶ。

ここでヤスヒサさんが「でも、実際の仕事で使うのって、（サンプルファイルのような）キレイな文書じゃないよね？」とツッコミ。 それに対してJohnは「この時点ではデザインの事は考えない。 マークアップする時はコンテンツの事のみを考える。 このような手法の方が、ユーザはコンテンツを見に来るのだから結果的によい結果を与える。 理想的ではあるかもしれないが、この手法を紹介している」と回答。

マーク付け

先ほどグループ分けした塊をマーク付けしていくけど、そのプロセスには二つのステップがある。 一つはHTMLの要素を使う事。 もう一つはmicroformatsなど（つまりclassやid）で意味を与える事。

class名、id名は、さきほどのグループ分け作業で付けた名前を利用する事が多い。

最初の段階で、全ての情報に対して完璧なマークアップをしているわけではない。 ここでも最初は文書のみを意識する。

まあ、デザインを再現する際にはdivが入れ子になったりするので、閉じタグの後にコメントを入れている。

HTML5の要素紹介

ここでHTML5の要素の紹介があった。 ただしその数は多くなく、「セマンティックにするための要素を中心に紹介するよ」との事。

header要素

ヘッダーと聞くと文書のはじめにありそうな気がするが、途中にあっても問題ない。
内容にはhn要素が必須で、自身の入れ子はできない。 また、footer要素やsection要素なども含む事ができない。

footer要素

ページの下のほうにある。 コピーライトなど。
自身の入れ子は禁止。 仕様が固まってないから、まあ今後も色々変更があるかも。

section要素

恐らく一番よく使う新要素。 一つのグループを指す。 一つのテーマとしてグルーピングできる物をセクションとして作る事ができる。
sectionを開始したら、hn要素があった方がよい。 ただしこれば理屈的な事であって、仕様で決められているわけではない。 新しいセクションを開始した時のhn要素はh1でもいいしh2でもいい。
今回の例（サンプルファイルの事）では新しいセクションの開始でh1を使っていて、今回こうしているのは『新たなテーマが開始した』という考えによるもの。
「h1がたくさんあるとスタイルが面倒？」でも、子孫セレクタを活用したりすればいい話だよね。 デザイン優先じゃなくて文書優先だよね。

article要素

section要素は文書の中にある部品を大まかにグループにするけど、意味がわかるわけじゃない。 articleはセクションの中でも、意味があるグループに付ける。 典型例にブログの記事。
articleは難しい。 英語を話す国の人でも難しい！
判断基準を言うなら、『その部分だけでも成り立つものがarticle』。 独立して存在できる物。 検索エンジンが対応したら、ページの中からメインの部分を見つけやすくなるだろう。

article要素の入れ子も、section要素の中にarticle要素を入れる事も可能。

All article are section
not all section are article
（全てのarticleはsectionたるが、その逆は絶対では無い（適当訳：hamashun））

nav要素

ナビゲーション。 これを使うメリットに、アクセシビリティの向上が考えられる。 例えば音声ブラウザがこの部分を抜き出してカスタムナビゲーションにするとか。
あとはXMLサイトマップ（SEOでよくあるアレ）みたいのも自動でできるようになるかもね！

HTML5の構文

DOCTYPEはブラウザを標準モードにするためにある。 これがないと互換モードになっちゃうよ。

ヤスヒサさん：「イベント情報のリストがsection要素になっているけど、これはarticle要素ではダメなの？」 John：「これはあえてsection要素にしていて、これは記事ではなくてイベント情報の単なるリストだよ。 私は読める記事に対してarticle要素を使うようにしている。 まあ、今はまだ策定中の仕様だから、section要素にしておいた方が安心、っていうのもあるけど。」

HTML5とは言うけど、新しい要素こそあれどマークアップの作業は基本的にはHTML4.01やXHTML1.0と同じ手法。

みんな大好きIEの話

8はいいけど、7以下はダメ。 7以下は普通に書いても全部無視されるよ。

JSのライブラリがあって、それを使うとうまい事やってくれる。

JSオフの場合の対策として、HTML4.01などの要素を踏み台にしてユニバーサルセレクタを使って無理やり指定する手法もあるっちゃーあるけど、才能の無駄遣いレベル。 非現実的。

Firefox2について

まあサポートが終了してるよね。 基本的には対応していないんだけど、今回の告知ページを見ると、情報を得るのには問題ない。 ただちょっと見た目がズレたりする。
ちなみに、section要素の中にh1要素が入っている場合、h1が始まった時点でsectionが終了しているっぽい。

ちなみにFirefox2に関してはHTML 5 の新要素の解析のされ方で気をつけるところ | ヨモツネットにとても詳しい解説が載っています。

microformatsについて

大体既知の内容だったので割愛。
「microformatsって何？」という人はhamashunの以前の記事、社内勉強会（microformats）で使った資料を公開しますを読むといいかと思います。

ランチタイム

幕の内弁当と緑茶。 JohnもOliも箸を上手に使っていた！
ちなみにカントリーマァムとキットカットとバナナが食べ放題だったｗ

Part 2 ： floatとposition

だいぶ既知の内容だったので割愛。

Part 3 ： CSS3

Q&Aコーナー

Q:clearfixやoverflowでのclear効果に替わるなんかいい手法ないですか？

A:ないね！

Q：article要素がたくさんあった場合、相対的に重要度は下がるのか？

A:No. article要素の原点はAtom配信フォーマットだと思う。 たくさんあるのは問題ないよ。 検索エンジンはarticleに注目してインデックスするだろうから、ちゃんとマークアップしているなら大丈夫。

Q：IEでHTML5が使えるようになるライブラリは重いの？

A:コード自体はとても短い。 でもスクリプトだから使えばその分重くなる。 逆に考えて、速度がとても重要なサイトなら、今あえてHTML5を使わずにHTML4.01やXHTML1.0を使った方がいいよね。

Q:divは無くなってsectionになる？

A:Yes.

Q:ちょ、「sectionは新しいdivじゃねぇぞ！」ってdisられたんでｓが！！１！（20代男性）

A:ああ、そういう意味ね。 それは、『デザインのためのdiv』って事だと思うけど、そもそも『デザインのための要素』という存在自体がCSSの進化によって無くなっていく。

divは元々『意味を持たない』要素だけど、実際はテキストをグループ化する目的で使われている事が多い。 それに意味を持たせたのがsection要素。 さっきのはそういう意味での『divは無くなってsectionになる』という意味。

懇親会

蕎麦屋でした／(^o^)＼　うどんはなかったです＼(^o^)／　←蕎麦アレルギー
肉とかおいしかったです。

懇親会でもTech話題をしたかったんですけど、あんまりできなかったな…。 ちょっと残念。

感想など

HTML5とCSS3関連の内容は凄くよかったです。 質問がしまくれたのも良かった。 ただmicroformatsやfloat・positionの辺りは既知の内容だったので、ちょっと退屈でした。

進行が同時通訳ではなくて、英語→日本語→英語→日本語 という形式で、これは個人的にはとても良かったです。 このレポートを見れば分かるように僕はメモを取りまくるので、速度的に非常にやりやすかったです。
考える時間や質問したい内容を脳内で熟成させる余裕があったのも良かったです。

価格ですが、やっぱりちょっと高いかなと思います。 早期割引で3万円台、割引が終了したら4万円台なので。
ヤスヒサさんとはよくお会いしているので知ったる仲ですが、JohnさんもOliさんもとても親切でフレンドリーで、質問にはじっとこちらの目を見て聞いてくれて（外国の人らしい仕草！）、とても好印象でした。 技術話以外の雑談も普通に楽しかったです。