R903@Vox　ないしょ、ないしょ。

CSS NiteさんとXHTML+CSS (r)evolutionさんの合同企画"Shift to 2008"に参加してきました。
気合い入れて行き過ぎて、２番目の入場でした。（早く行きすぎｗ）

今回特に面白かったのは原 一浩さんの2007年のサイトのビジュアルトレンドについての講演でした。
完全3Dのスライド（http://cssnite.jp/shift2008/cssnite_04_bitmap_f.html）も素晴らしかったです。

【質問】今年どれだけサイトのデザインを見たか・・・。
100以上は見てますね。月に１５～２０くらいでしょうか？
デザインのお仕事が入ったときには、特にその業種のものをガンガン見るので、500近くはみているんじゃないかなぁと思います。

【質問】その中で海外サイトはどれくらい見ましたか。
結構見ていると思います。半分くらいは海外サイトじゃないでしょうか。

ちなみに原さんは月に1000以上のサイトを見ているそうです。
桁が全然違いますね。（＾＾；；

2007年のWebデザインはweb2.0のポップな雰囲気から落ち着いたものになってきたそうです。
特長としては
横に一直線のデザイン。（背景は横方向にリピートしながら伸びていく）
ガラスやメタルの透明感・質感を持ったボタン
光の反射と映りこみ
リアル志向・ガジェット系のアイコン
インプット部分の大きなフォーム
オーガニックカラー

・・・・なんかどこかで見たことあるような・・・？？？

071228

って、うちのサイトじゃん？（＾＾；；
横一直線のデザイン、アースカラー、映りこみ。
フォームはおいておいて、ガジェット系アイコンがないのは自分で上手くつくれないから。

なんていうか、影響を受けすぎ？？
しかも自分で、全然気が付いていないところがダメすぎです。

来年はもっとデザインを勉強して、流行に踊らされないようにしたいと思います。（＾＾；；ハイ。


ちなみにギャラリー内の会場写真、3列目の黄色いセーター着てるのが私です。（＾＾)

大分たちましたが、クリエーター向け契約知識セミナーの続きです。
もう、自分がぐぅたらでやんなっちゃう。（苦笑）

さて、（１）では契約書についてとクリエーターが契約書でおさえておくべきポイントでしたが、今回は秘密保持や下請法についてまとめたいと思います。

■秘密保持
これはそれだけで、契約書が一つできてしまうほどのものなので、こちらも基本契約書に書いておいたほうが良い内容です。

まず秘密についての定義。
秘密は秘密を貰う立場と与える立場で、変わってきます。
秘密の内容が広いと、与える側に有利になります。
基本的にクリエーターは貰う立場の場合が多いので、範囲は狭い方がいいですし、負担も少なくなります。

例えば
「本契約において秘密情報とは、有体物、無体物を問わず、本目的に基づいて相互に開示する情報、並びに本目的の実施において知り得た相手方および相手方の取引先等本牧的の実施に関与する第三者の技術、営業、人事、財務および個人情報を含む一切の情報」
などという内容は大変範囲が広いものになります。

例文にあるように「知り得た」という言葉をいれると、偶然知ってしまったことや推測したことなども全て秘密に含まれてきてしまいます。
ですから、知り得たという言葉を使うのではなく、「秘密情報として開示されたもの」という限定をしていく。
また、秘密情報であることは文面化するようにします。
秘密情報を口頭で伝えられた場合は、●日以内に秘密情報であることを文章で提出するといった感じにすると良いでしょう。

広範囲の契約である場合も以下のような場合には、秘密保持の義務はないことを確認しましょう。

１）情報を知った時点で、その情報がすでに公になっている場合
２）情報を知った後、被開示者（情報を公開された人物）に起因しない理由で公になった場合
３）情報を知るより以前に、被開示者が、第三者から秘密情報の義務なく情報開示されており、正当に保有してる場合
４）情報開示がされた後、被開示者に対して開示者が文章により秘密保持義務を免責した場合
５）被開示者自らが開発した情報

また、秘密を開示できる範囲を明確にすることも大事です。

１）業務の目的に必要な（関与する）人物（被開示者の従業員等）
２）再委託先
３）法律上開示が必要になった場合

秘密保持契約に関しては業務終了後も効力があるというものが多いですが、できるだけ限定していきたいものです。
業務委託契約で限定していくなどの手段を考えましょう。

また受け取った資料の返済義務についても触れておいた方がいいです。
資料（機密情報を含む）などを受け取った場合、量が多いなど返済が大変な場合は、自分の方で責任をもって破棄するといった内容を盛り込んでおきましょう。

■下請け法

下請け法は下請代金支払遅延等防止法のことで、下請け取引の公正化・下請け事業者の利益保護を目的とした法律です
情報成果物の制作委託も下請け法の対象となる取引です。

情報成果物とは以下をさします。
・プログラム
（ゲームなどのソフト・家電等の制御プログラム・顧客管理システムなど）
・映画・放送番組その他映像または音声その他の音響により構成されているもの
（TV・CMアニメなど）
・文芸・図形もしくは記号もしくはこれらの結合又はこれらと色彩との結合により構成されているもの
になります。
（ポスターデザイン・商品や容器のデザイン・コンサルティングレポートなど）

また制作委託とは以下をさします。
・情報成果物を業として提供している事業者が、その情報成果物の制作の行為の全部または一部を他の業者に委託。
（ソフトウェアメーカーがゲームソフトやアプリケーションソフトの開発を他のソフトウェアメーカーに委託するなど）
・情報成果物の制作を業として請け負っている業者がその成果物の制作の行為の全部または一部を他の事業者に委託。
（広告会社が、クライアントから受注したCMの制作をCM制作会社に委託するなど）
・自社で使用する情報成果物の制作を業として行っている場合に、その制作の行為の全てｍなたは一部を他の事業者に委託。
（家電メーカーが、内部のシステム部門で制作する自社用経理ソフトの作成の一部をソフトウェアメーカーに委託するなど）

ようするに
商品として提供する業者が、その商品を他に依頼して作らせる　（提供業者→下請け）
クライアントから依頼されて制作を行う業者が、外部に委託して制作させる。（下請け→下請け）
販売用ではなく自分のところで使うものだが、他の業者に委託してつくらせる。
こういったパターン。

下請け法の対象範囲は事業者の資本金規模で決まります。（以下）

親事業者の資本金が５千万超→下請け業者の資本金が５千万以下（個人含む）
親事業者の資本金が１千万超で５千万以下→下請け業者の資本金が１千万以下（個人含む）

プログラムの場合は別で
親事業者の資本金が３億超の場合→下請け業者の資本金が３億以下（個人含む）
親事業者の資本金が1千万超で３億以下→下請け業者の資本金が１千万以下（個人含む）

また、トンネル会社規制というものがあり、資本金１千万以下の子会社を設立して、上記の規制を免れることを防止されています。

親事業者は以下の４つ義務があります。

１）書面の交付義務
　発注の際には直ちに発註内容を記載した書面を交付すること
　この書面は契約書とは違います。
　様式は問いませんが、記載するべき事項が法令で定められています。
　この段階で内容に納得がいかない場合は、その場で異議を伝えましょう。発注を受けてしまってからでは遅いです。

２）支払期日を定める義務
　下請け代金の支払期日を、給付の受領後60日以内に定めること。

３）書類の作成・保存の義務
　下請け取引の内容を記載した書類を作成し、２年間保存すること。

４）遅延利息の支払い義務
　支払いが遅延した場合は遅延利息（年率14.6％）を支払うこと。

また親事業者には以下の禁止行為があります。

１）受領拒否
　注文した物品等の受領を拒むこと。

２）下請け代金の支払い遅延
　下請代金を受領後の60日以内に定められた支払い期日までに支払わないこと　

３）下請代金の減額
　あらかじめ定めた下請代金を減額すること。
　金額を下げる以外に、同じ料金で発注以上のものを作らせる、出資金や協力金などを要求する、これからの価格を現制作物に適応させるなどです。

４）不当返品
　下請け業者に責任がないので、受け取った物を返品すること。
　これは検収規定をきちんと決めて明記することで対応していきましょう。

５）買いたたき
　類似品等の価格、又は市価に比べて著しく低い下請代金を不当に定めること。

６）物の購入・役務の利用強制
　親事業者が指定する物・役務を強制的に購入・利用させること。
　（かならずこの店舗を経由で購入するようにという指示など）

７）報復措置
　下請け業者が親事業者の不公正な行為を公正取引委員会又は中小企業庁に知らせたことを理由として、その下請け業者に対して取引数量の削減・取引停止などの不利益な取り扱いをすること。

８）有償支給原材料等の早期決済
　有償で支給した原材料の対価を、当該原材料を用いた給付に係わる下請け代金の支払期日より早い時期に相殺したり、支払わせたりすること。

９）割引困難な手形の交付
　一般の金融機関で割引をウケルことが困難であると認められる手形（120日を超える長期の手形）を交付すること。

１０）不当な経済上の利益の提供要請
　下請け業者から、金銭、労務の提供等（協賛金、従業員の派遣など）をさせること

１１）不当な給付内容の変更および不当なやり直し
　下請け業者に責任がないのに、費用を負担せずに注文の内容を変更し、又は受領後にやり直しをさせること。

で、この下請法をどうやって使っていくかということですが、
実際に違反されてから訴えるというのもなかなか難しいところもあると思うので、事前に防ぐようにするのがいいでしょう。
契約交渉段階で下請法にひっかかりそうな時に「これは違反ではないですか」という警告をしましょう。

でも、思うんですけど私たちみたいな個人でやっていて1千万超の企業と直接取引ってあまりないと思うんですよね。
その点を質問してみたら、その場合はまず
１）トンネル会社ではないかの調査
２）トンネル会社でなかった場合、「独禁法」に抵触していないかを確認
というのがいいそうです。
独禁法はまたいろいろあるらしいのですが、強い立場を利用して不当な取引をさせないような内容らしいので、そのあたりと照らし合わせてみるのがいいそうです。

ということで長くなったので（３）に続きます。

PECさんで開催されていた「クリエイター向け契約知識セミナー」というのに参加してきました。
契約って大事だなと思って、自分でいろいろ調べて勉強したけど、やはりちゃんと弁護士さんがしてくれるセミナーは受けておいたほうがいいかなと。
セミナーの内容は契約書に関する知識と制作に当たっての注意点、下請法、著作権、個人情報保護法についてです。

■契約書に関する知識

まず「契約」と、「契約書」は別物で、「契約」するのに書面は必ずしも必要なモノではありません。
口約束でもそれは契約になります。

それでは契約書を作る意義はどこにあるのでしょう。
まず、書面化することで客観的に何に合意したのかという点を明白にすることが一つ。
これにより、言った言わないの水掛け論が減ります。
次に法律上のルールを変更する場合。　
そしてリスクを軽減し、保証や賠償の範囲を明確化できるという点です。

ただ、契約書を作るには専門家に頼む費用がかかったり、制作に時間がかかります。
また言及しなければ法律上は問題にならかなかったのに、契約書を作ったことにより不利になる場合もあったりします。（やぶへびってやつですね）

契約書は特に定まったフォーマットはなく、内容も独禁法や公序良俗に違反しているなどの「強行法規」がなければ何を書いてもOKです。
また、タイトルに法的効力はなく、内容に影響は与えないので、たとえば「覚え書き」としていても「契約書」となんら変わるものではありません。
例えばタイトルが「業務委託契約書」であっても、その内容が「雇用契約」的なものだった場合、それは「雇用契約の契約書」と判断されます。

先に契約書にフォーマットはないと言いましたが、「契約書」とするためには、書面の最後に両者の署名捺印をし、両者が1部づつその契約書を保管することが必要になります。
このサインの段階で注意するべき点は、「自分が誰と契約を交わしているか」ということです。
契約書にサインしている相手が、法人格であるのか、またサインしている相手に本当に代表権や代理権があるのかという点を確認しましょう。
例えば、「●●委員会」や「■■プロジェクト」などというものは法人格がない場合もあります。
口頭でも良いので、相手が代表として契約できるのかなど相手の身分や信用度を確認したほうが良いでしょう。

また、契約はサインをした人にしか効力はありません。
例えばA社と契約した場合、子会社のb社にもその契約書を適応する、と言ったようなことはできません。
第三者に義務を履行をするにはそのための手続きが必要になります。

■制作受託契約の注意点

まず「自分が何を受託するのか」をはっきりとさせましょう。
「なにをやるのか」（仕様の特定）
「どこまでやるのか」（業務の範囲）
「何をもって完成とするか」｛業務の完成）
「どの範囲まで保証するか」（瑕疵（かし）担保）
といったことを決めていきます。

それと同時に検収（チェック作業）についても決めていきましょう。
検収方法や、その基準、仕様の範囲、検収期間などです。
特に検収期間は大事で、「納品してから●日以内に連絡がない場合は、検査に合格したモノとする」などといった文面をいれておくのが良いでしょう。

また支払い条件なども決めておくとリスクが回避できます。
沢山の業務を一度に受けた場合や、作業工程がいくつかに分かれている場合など、「１部が終了したら」「この行程まで行ったら」支払いをしてもらうなどの形をとると良いでしょう。

また再委託についても、契約書に盛り込んでおいた方が良いです。
すでに、委託する人が決まっている場合には、その法人や個人名をだして、決まってない場合には、第三者に委託することを、合理的な理由がないかぎり拒否をしないという内容です。

■権利の帰属について

ほとんどの場合、著作権は委託者に譲渡するという形式になっていると思います。
同時に記載されている内容として
著作権法27条・28条（翻案権や二次的著作物の利用に関する原著作者の権利）を含む
著作者人格権を行使しない
といった内容があります。

クリエーター側にとって一番いいのは、著作権や27条・28条、著作者人格権が手元に残ることですが、それでは委託者側にとっては不都合なのでなかなか合意が得られないのが現状です。

このような場合でも、業務を受託する以前に自分が作ったものを使って、成果物を作るような場合は、その以前に作ったものの部分は譲渡しないように気をつけてください。（受託者が以前から有している著作権を留保する）
例えばプログラムで作ったモジュールを、案件で使って全ての権利を譲渡してしまった場合、別の案件でそのモジュールを使うと、著作権法違反となってしまいます。

■瑕疵（かし）担保

「瑕疵（かし）」とはその製品にあるべき品質や性能が欠如していることを言います。
「瑕疵（かし）担保」は欠陥があった場合に負う責任のことです。損害賠償や契約の解除などがあります。
これらは合意されている基準をもって瑕疵（かし）とし、契約書で基準が設けられていない場合は業界の基準を適応します。

責任を限定するためにも、瑕疵（かし）とする範囲や、期間を制限する必要があります。
また、委託者の要求に従ったことによって生じた瑕疵（かし）や、仕様に起因する瑕疵（かし）は除外されます。

■表明保証

表明保証とは義務・責任を契約書上に明文化し約束することです。
例えば、「成果物が他人の著作権を侵害していないことを保証する」などがこれにあたります。

受注側の立場としては、この表明保証は無いにこしたことはありません。
ただし、書面に書かなかくても、暗黙の合意としてあったととられる場合もあります。

クリエーター側の手続きとしては
１）第三者からクレームが来た場合にはすぐに連絡をしてもらう
２）勝手に合意・和解しないようにする
３）期間を制限する
４）金額を制限する　→制作費を以上は払わないなど
といったことがあげられます。

実際に著作権侵害じゃないかというクレームが来て、企業側が和解金をだしたが本当は著作権侵害じゃなかったという裁判もあったりしたそうです。
企業側はトラブルを起こしたくない、金銭的なものを全て受注側に被せられるということで、安易に合意・和解するケースもあります。

特許などの場合は、「自分が知っているかぎり」「知り得る限り」といった文面を使う場合もありますが、著作物の場合はゼロから制作すれば問題がないので、入れる場合はあまりないです。

■損害賠償

損害賠償は書面になくても認められます。
金額の上限を制限したり、期間を制限するいことで、リスクを減らしていきましょう。

ということで（２）に続きます。

１日目の３セッション目はX3「これからはじめるCSSレイアウト術。読めるソースが優良といっても過言ではないのだ」を受講。
講師はウィルシステムの伊藤学さんです。
ワークショップを交えながらCSSの概念や記述についてコツを解説され、非常にわかりやすい内容でした。
以下まとめです。
------
CSSはCascadingStyleSheetの略です。
Cascadingを辞書で引くと、「段々になっている滝」という訳されています。つまりは階層構造のことをさしています。

ブラウザーはデフォルトでCSSを持っていますので、まずはこれらのデフォルトCSSをリセットしてあげる必要があります。
頭に『＊』をつけるユニバーサルリセットが一般的ですが、最近、海外では要素毎にリセットするタイプが多く見られるようになりました。ユニバーサルリセットは要素に関係なく反映されてしまうため、リソースを喰うから、必要な要素だけリセットしようという考えのようです。
http://meyerweb.com/　などリセットソースを配布しているサイトもあります。

続けてセレクタについて
・親子関係
・グルーピング
・スタイルシートの順位
・個別性
というものがあります。

親子関係とは
p.note em { color: red; }　の場合p.noteが親要素、emが子要素となるというもの。
なぜ「親子」なのかというとhtml headの部分を「祖先タグ」body以下を「子孫タグ」というからだそうです。

グルーピングは同じ内容のもを『,』で区切って一括設定すること。

スタイルシートの順位は
デフォルトCSS＜ユーザーCSS＜制作者CSS
という順で適応されます。

また!importantがある場合は
デフォルトCSS＜ユーザーCSS＜制作者CSS＜制作者CSS＋!important＜ユーザーCSS＋!important
の順になります。

そして一番重要なのが個別性になります。
これは、CSSの優先順位を位置づけるもので、点数として計算できます。

•style 属性がある場合は、1をカウント (= a)
•セレクタに含まれている id 属性の数をカウント (= b)
•セレクタに含まれている id 以外の属性と、擬似クラスの数をカウント(= c)
•セレクタに含まれている 要素、擬似要素の数をカウント (= d)

といった計算方式があるそうですが、わかりにくいとのことで益子さんが簡単な計算方式を考えられたそうです。

* (0点) < 要素タイプ (1点) < class/属性 (10点)< id (100点) < style= (1,000点)

として計算します。
この式に当てはめると
p.note em { color: red; }　は　p（要素タイプ/１点）、.note（class属性/10点）、em（要素タイプ/1点）で合計12点になります。
が、同じCSSでも
div#content p.note em { color: blue; }とした場合、div（要素タイプ/１点）、#content（id/100点）、p（要素タイプ/１点）、.note（class属性/10点）、em（要素タイプ/1点）で113点となってしまいます。
そうすると、12点の赤字よりも、113点の青字の方が優先されます。
なんかCSSが効かないという場合、この1点の差で効かない場合があります。
ですから、CSSはできるだけ省略せずにbody（あるいはdivから）書くことが望ましいです。

CSSを設計するにあたり、モジュール化、バリューデザインというものを考える必要があります。
モジュール化とはパーツ毎に分けること、バリューデザインとは作業を効率化しデザインの価値を高めることを言います。

一枚のスタイルシートに全てのCSSを書き込むのではなく、
baseのCSS、layoutのCSS、classをまとめたCSSという具合に分割し、それらをインポート用のCSSに読み込ませてから、htmlに読み込ませるといったものがモジュール化です。

CSSを設計する場合
・カラムレイアウト
・セレクターリセット
・モジュール化
の3点を押さえましょう。

実際にCSSを作るにあたり大事なポイントは以下になります。

・親子関係はしっかり
・要素はできるだけ省略しない
・インデントで見やすく
・適宜コメントアウト&目次
・グルーピング
・全部入りリーフページをつくろう

もちろん(X)HTMLをしっかりと書くことも重要です。
divばかりのxhtmlにしないように気をつけましょう。

そのためにはまずdiv要素を考えずにマークアップしていき、一つにまとめられる部分をdivでまとめます。
divは輪ゴムのようなものと考えてください。

次にid属性とclass属性ですが、id属性は固有名詞、class属性はグループ名やモジュール名になります。
つまり名札のようなものです。

CSSを記述するにあたり、見やすいように書くことが大事です。
省略せず、階層構造が分かるように書くこと、またインデントを効果的に使い見やすく整理することも大事です。

さらにCSSの頭に見だしや目次をつけることでわかりやすすがぐっと違ってきます。

/*
======Contents=======
last-update：　17.jun 2007;

1.univaersal reset[2007.07.15]
2.~~~~~
3.~~~~~
====================
*/

と言った感じで、修正日の日付をいれるとわかりやすいです。
また、修正を行った行にも同様に日付を入れると良いでしょう。

また共通している部分は一つにまとめてしまいましょう。
省略せずに書くことは、共通部分が見つけやすくするためでもあります。

サイト内でもっともテンプレートを使うのはリーフページ（末端ページ）になります。
ならば、全ての要素をリーフページに入れることで、第二のデフォルトページを作りましょう。

カラム分けはテトリスの要領で。
背景に色をつけると、どこが崩れているのか一目でわかります。
IEではwidthの値が変わってしまう、ボックスバグがあるので注意してください。
まずIE以外のブラウザーで設計し、途中途中でIEで確認するのが良いでしょう。

自分の為にも、他人の為にも見やすいソースとバージョン管理をしていくべきです。
要素タイプのdivについては、慣れてきたらつけなくてもOKですが、1点の違いで変わってきてしまいます。
仕様書も一度はちゃんと読むようにしましょう。
------

メンテナンス性というのはいつも気になっていました。
CSSの最初に目次などを入れるというのはすごく良いアイディアだと思うので、今後実践してみたいと思います。
たまにCSS効かないなーってのはこの個別性のせいだったんですねー。（＾＾；；
全部の要素を書くのは見た目ももったりしてめんどくさそうですが、やっぱりいろいろ考慮すると書いた方がいいんですかねぇ・・・。
とにかくわかりやすく勉強になる講義でした。

講演の資料はこちらで公開されています。
http://www.freesia.org/2007/07/webx3.html

１日目の２セッション目はX2「名前のウェブとXHTML文書のプロファイル」を受講。
講師は神崎正英さんです。

最初は「名前のウェブ（仮）」というタイトルだったので、クラスやIDの名前の付け方とかに関する講義かなーと思ったのですが、情報の伝達についてのお話から最後はRDFに至り、凄すぎて半分魂が抜けかけていました。
以下、分かる範囲でまとめ
-----
まずはじめに西垣通氏の『ウェブ社会をどう生きるか』という本のお話がでました。
その本の中では情報は「生命情報」「社会情報」「機械情報」というものがあると書かれているそうです。
「生命情報」は個人個人のとらえ方のようなもので、個体差があるため完全に伝えることはできません。
「社会情報」は「生命情報」を言葉や文章という形にして、人々が共通の情報としてもてるようにしたもののことです。
「機械情報」は言葉の記号表現だけをとりだしたもので、いわゆるデーターと言われるものにあたります。

情報はまず生命情報として発生し、言葉や文章となることで社会情報になります。
それらがデータ化されて蓄積され必要に応じて取り出せるようになります。
機械情報を元に社会情報が再現され、再現された社会情報は受信者に渡ることで、受信者の生命情報となります。
ですから、情報が伝わるためには、まず社会情報として適切に再現されないといけません。
そこで名前というものが重要になってきます。

社会情報は様々な名前によって構成される、まさに「名前のウェブ」です。
「ウェブ標準」とは、WWW層においての社会情報を適切に伝えるための基準のこと。
名前の要素は「主語」「述語」「目的語」の３点セットで考えられます。
たとえばCSSなら「セレクタ（主語）」「プロパティ（述語）「値（目的語）」と言った感じになります。
また、Web文書は「グローバルな名前」「文書ツリーの要素の名前（相対的な名前）」「任意の名前」として表現されます。

グローバル名

• 名前空間URI＋要素型名
• 文書URI＋フラグメント識別子（ｉｄ属性もしくはXPointer）
• 仕様で定義されたrel属性値

文書ツリーの要素の名前

• DOM
• XPath
• CSS（子孫セレクタ）

任意の名前

• class属性値（一般には通じない）・未定義のrel属性値
  
• meta要素のname属性値
• その他文中に出現する様々な名前（地名・人名等）

ウェブ上で名前をつけることにより識別が可能になり、それらの名前を使ってデータアクセスができるようになります。
また情報コンテンツの表現と操作が可能になります。

XHTMLの場合、「xhtml:title」のように仕様など共通の了解のある名前と、「class＝"fn"」のように限られた範囲でしかわからない名前があります。
ではなぜ、”fn”をtaitleのように共通認識をもてる要素としないのか。
それは、あらゆる役割を要素型として定義するには無理があるためです。
また、最小限の共通部分をグローバルな要素型として定義し、@classなどで個別の役割を細分化させるためでもあります。

表現したい文章構造は人によって異なります。
基本はシンプルに。そこに拡張機能を加えていく方が、柔軟で互換性が高くなります。
またシンプルであるということは記述が簡単であるということです。それは普及の要因につながります。

それでも、任意でつけた名前をグローバルに共有したいという場合・・・。

XHTML文書で用いる名前を拡張する方法は以下があります。
１）新しい要素型を定義する
２）XHTMLモジュールを追加する
３）名前空間を利用した語彙併用
４）XHTMLプロファイル
５）＠ｃｌａｓｓ、＠relのみ

この中でもっとも現実的なのが４）のXHTMLプロファイルになります。

@profile属性はHTMLの意味を各自が拡張していけます。
プロファイルを用意することで、ローカルな名前をフォーマルに変えることができるのです。
ただし、基本的にはメタデータ用の名前で機能拡張向けではなく、また、共有プロファイルの場合、意味定義の恒久性はプロファイルの管理者に依存することになってしまうという短所があります。

XHTMLからメタデータを抽出する汎用ルールとしてGRDDLというものがあります。
GRDDLを適用するにはいくつかの方法がありますが、まずは整形式のHMLになっていることが前提となります。
だからXHTMLはきちんと書きましょう。

&は&amp;と書く。（リンクを張るときに&がそのままのことが多い）
属性値は必ず引用符で囲む。
空要素は/>を忘れない。

といったものはよくあるエラーです。
また属性と属性の間にスペースがないなどValidatorが通ってしまうエラーもあります。
拡張子を.xmlとして、ブラウザーで読み込むと比較的簡単にチェックができます。
------
その先もいろいろ続くのですが、申し訳ない、私にはこれ以上まとめるのは無理。（＾＾；；
講演データはここで見られます。
http://www.kanzaki.com/works/2007/pub/0715dws.html
あとはCSSNiteで音声データを配信するのをお待ちください。

よく使う名前を共有して使おうという考えはしっくりくるし、Web標準にかなっていると思いますが、いかんせんそこに至る過程が私には難しすぎました。

７月１５日、１６日とCSSNiteさんの主催で「Web標準の日々」というWeb系イベントが開催されました。
２日間で72セッションが行われ、最高で8セッションを受講することができます。

１日目の1セッション目はV1「明日から使えるタイポグラフィ」を受講。
講師はデジパ株式会社の両見英世さんです。
タイポグラフィとは何かからはじまり、フォントについて、それらを使うときの注意点などのお話をされ、最後にワークショップとして「コミュニケーション」をタイポグラフィで描くという内容でした。
以下に覚えている内容をまとめました。
-----
「文字」とは線や点を使って形づくられるもので、言葉を伝達し記録するコミュニケーションツールです。
タイポグラフィはこれら文字のサイズや字間などを調整する技術で、これらをデザインに組み込むことにより、感情や雰囲気を伝えたり、あるいは感じさせないようにすることができます。

たとえば「わかりました」という文字でも
「わかりました！」「わかりました・・・」「わかりました！」「わかりました・・・」
というふうに約物をつけたり、サイズを変えることで様々な感情を表現することができます。

またフォントや大きさ、ウェイト、感覚、色を使うことで情報の雰囲気をさらに強調して伝えることもできます。
たとえば
「ゆったりとした空間」よりも「ゆ　っ　た　り　と　し　た　空　間」
「涼」よりも「涼」
といった感じ。

そしてもっとも重要なのは「感じさせない」ということ。
人は「読みやすい」とは思わなくても「読みづらい」といは思うものです。
ですから、文章を読むときに不都合がないようにすることが大事なのです。
つまり、「読みやすいとは思わないけど、読みにくいとも思わない」　それが「感じさせない」ということです。

文章を読みやすくするためには
・文字の色と背景色の十分なコントラスト
・十分な文字サイズ
・視線移動が容易となる行送り
がポイントです。

フォントを使い分けることで、印象をコントロールすることができます。
フォント自身がもつ雰囲気が、受け手への印象をコントロールします。

セリフ体なら「正統・格調・まじめ・伝統・信頼感・品・高級感」
サンセリフ体なら「モダン・ポップ・無機質・力強さ」
明朝体なら「伝統的・高級感・信頼性・洗練」
ゴシック体なら「力強さ・男性的・現代的・カジュアル」
と言ったイメージを持っています。

他にも等幅書体やプロポーショナル書体、長体、平体、斜体、イタリックといったフォントに関しての説明もありましたが、メモがおいつかなかったので配信待ちです。（汗）
フォントを変形するときには細かいディティールに気をつけましょうということもおっしゃられていました。
また、タイポグラフィをするにあたり、数値に頼るのではなく最終的には目視し、自身の感覚で選択していくことが必要とのこと。
これは数値では錯覚に対応しきれないためです。

タイポグラフィの役割を理解した上で感情を表現していくことが不可欠となっています。
そのためには内容を理解してからデザインに取りかかることが大事です。
-----

抜けてるところもかなりあると思いますので、配信されたらチェックしてくださいね。

「読みやすく」という意識はしていたものの「感じさせない」という考えは今まで持っていなかったので衝撃的でした。
確かに自身を振りかえっても「白背景に#ddddddのグレー文字で10ピクセルなんてサイテー、読めん」とは思うけど、それが「アイボリーの背景に#333333の濃いグレー文字で14ピクセル」になっても普通に読むだけですものね。
そして、1級のデザイナーさんたちは文字を変形した後の微妙な線の太さの違いなどまで気を遣われているんだなぁと、感嘆。
ズボラーな私ですが、そういう細部まで気を配るようにしていきたいと思います。

※講義の中でフォントを使う上ではライセンスの問題に触れられて「文字で語る」（http://glyph-on.jp/）という特別なライセンス契約をしているサイトの名前があがっていたのでメモで置いておきます。

近所の最新投稿メールという機能がいつのまにかできてますね。

毎日、もしくは週１で近所が投稿した記事をまとめて送ってくれます。
これがウザイという人は　上の【設定】から入って【各種メール設定】を開き、【以下の情報メールを受信する】の下にある【近所の最新投稿メール】のチェックをはずしましょう。

面倒だけど、やっぱり毎月やっておいた方がいいよね。
今は外付けHDDにまるまるバックアップしてるけど、それ以外にもデータ毎にメディアに焼いて保存していこうかと思っている。

いっつもこんがらがるので、一応メディアの覚え書き

CDとDVD…容量が違う
　　　　　　　　一般的に　CDは650MB、DVDは4.7GB

規格いろいろ
・CD-ROM、DVD-ROM
　　　…読み取り専用。
　　　　　データの書き込み、削除はできない。

・CD-R、DVD+R 、DVD-R
　　　…データを一度だけ書き込める。
　　　　　書き込みデータの消去、移動はできない。
　　　　　容量が空いていれば追記できる。

・CD-RW、DVD+RW、DVD-RW
　　　…データの書き換えができる。
　　　　　書き込みデータの削除ができる

規格はドライバによって使えなかったりもするので、メディア購入前にドライバの種類は要チェック。
うちは　-RWがOKだから、基本的にDVD-RWを買ってくればまず間違いはないんだよな。（高いけど）

できることならリアルタイムで同期して自動的にバックアップをとってくれるようになるといいんですけど、それはそれでお金と知識が必要そう。（＾＾；

覚え書きなのでパブリック公開。
Web勉強仲間のゆきひとさんが、JavaScriptが上手く動かないといってソースをあげていたので、AKIも一緒に勉強してみました。
ゆきひとさんのソースから問題の箇所を洗い出して修正できればいいのですが、スクリプトがダメダメなAKIに他人の書いたスクリプトがわかるはずもなく、結局使われている変数名などだけを流用して自分で書いてしまいまいた。
これじゃぁ、どこが悪いんだか全然わかりませんね。（汗
計算をする簡単なスクリプトのはずなんですが・・・。

以下、ソース。htmlは簡易版
----------------------------------------------------------------
<html>
<head>
<title></title>
<script language="JavaScript">
<!--
function Tanka_1(){
var index = eval(document.form1.Select_1.value);
document.form1.Syouhinn_1.value = eval(document.form1.Kakaku_1.value)*index;
}
//-->
</script>
</head>

<body>

<form name="form1">
<table width="250" border="1">
<tr>
<td>商品１</td>
<td><input type="hidden" name="Kakaku_1" value="50000" />\50,000</td>
</tr>
<tr>
<td><select name="Select_1" onChange="Tanka_1(this.form)" >
<option value="0">0</option>
<option value="1">1</option>
<option value="2">2</option>
<option value="3">3</option>
</select>点</td>
<td><input type="text" name="Syouhinn_1" value="0" />円</td>
</tr>
</table>
</form>

</body>
</html>
----------------------------------------------------------------

スクリプトの内容はプルダウンメニューで個数を選び、商品単価をかけた結果を表示するというもの。
ということで、onChangeのイベントが起きたら計算処理を行うというスクリプトを記述します。

onChangeの変数名はTanka_1。これを関数で定義します。
プルダウンメニューに個数をValueで設定し、evalで数値化したものを変数宣言したindexに代入。
商品の単価をevalで数値化し、indexの値を掛けることで、単価×個数の値がでるので、それをフィールドに表示します。

たぶん、もっといいやり方もあるんだと思うけど、私にはこれが限界。（＾＾；；
もっと勉強します。

新しい物にはすぐに飛びつく悪い癖ではじめてみたVoxですが、案の定すぐ放置になりました。（これもまた悪い癖）
今回Voxの記事公開範囲機能に目をつけて、フレンドメインで記事を書いていこうかと思います。（フレンド少ないけどね）
主に仕事関係のお話になるかとおもいますが宜しくお願いします。
追記：更新はボチボチになると思いますので、メールでお知らせが欲しい方はご連絡ください。