ちょっとしたメモ - CSS 2.1「内容高算出」の補遺
『セオリー・オブ・スタイルシート』のPart.1として出版されたCSS 2.1の解説において、ボックス高の「内容高算出」と呼んでいる規則について、説明に少し不備が見られるので若干の補足を。対象箇所は「3.4.1.4 絶対位置決めボックスの高さの計算」で、記述をシンプルにしようと説明を端折ったために、正確さを欠く結果になっている。 ここで「内容高算出」とは、通常のボックスの高さを算出する際に、ボックス内容がインラインかブロックか、枠やパディングを持つかどうかで少々違いが出る算出規則を、後で参照して簡潔に記述するために仮につけた呼称。この同じ名前を、絶対位置決めボックスの高さ計算の説明でもそのまま使ったのだが、絶対位置決めの場合はマージンの折り畳みが生じないので、枠やパディングの有無に関係なく子ボックスの外辺によって高さを計算する。したがって、これでは不正確な説明になってしまうという次第。 と
ちょっとしたメモ - CSS2.1の勧告候補と検討事項リスト
CSS2.1がようやく（再度）勧告候補にこぎつけた。今度こそは草案差し戻しなどということなく進んでいくだろうが、テストケースや実装確認もあるので、年内はCRに留め置くということだ。このCSS2.1は、PDF版で405ページ。1998年のCSS2勧告は338ページだから、単純に分量だけでも2割増で、記述の修正なども含めると、実はかなり大きな違いがある。バグ修正やブラウザの実装に合わせただけのものではなく、よりモデルを厳密に定義したり詳しく説明しているので、CSSに関心がある人は、そろそろ2.1の内容を確認しておくのがよいかも。 今回の勧告候補は、昨年11月の草案をおおむね引き継いでおり、かなり安定しているといえるが、多少の修正や明確化もある。11月草案との違いが検討事項リストの形で示されているので、主なものを確認しておこう（以下、項目名の数字は検討事項番号、リンク先は検討事項リストの対応する
Web 2.0からセマンティック・ウェブへ
“Web 2.0”の主張 Tim O'Reillyによれば プラットフォームとしてのウェブ（The Web As Platform） 集合知の利用（Harnessing Collective Intelligence） データが重要（Data is the Next Intel Inside） 商品としてのソフトからサービスとしてのソフトへ（End of the Software Release Cycle） ハッキングと連動が容易な軽量プログラミング（Lightweight Programming Models） PCに限定されない利用（Software Above the Level of a Single Device） Ajaxに代表されるリッチなUI（Rich User Experiences） （What Is Web 2.0 Design Patterns and Busin
テーブルとアクセシビリティ -- ごく簡単なHTMLの説明
大きなテーブルは、音声読み上げで内容を聞いているとき、データが何を示す値であるかが混乱してきます。音声ブラウザは、th要素の内容やtd要素のheaders属性を利用して、補助的な情報を読者（聴取者）に伝える機能を持っています（WebSite DesignのVol.3で「音声ブラウザでもまだサポートされていない」と書いてしまいましたが、新しいバージョンはかなり対応が進んできました）。 音声ブラウザとth要素 長い見出し項目の省略形 セルの関係を示す属性 scope属性 headers属性 データの次元と軸 補足：テーブルsummary属性の読み上げ 音声ブラウザとth要素 表（テーブル）は、大量のデータを縦横の二次元に整理することで、視覚的に把握しやすくします。しかし、音声合成でテーブルを読み上げる場合、データは順番に一次元的に読み上げられるため、全体像を把握することが難しくなります。たとえ
ちょっとしたメモ - CSS 2.1の最終草案再び
CSS 2.1仕様のラストコールが11月6日付でまたまた（何回目？）登場。本質的なところでは変化はないものの、4月の草案と比べると多少の手直しが見られる。いい加減に勧告候補に進んで欲しいものだ。 大きな見直しの一つは、min/max-width/heightと画像のような内在アスペクト比を持つ置換要素との関係（セクション10.4）。こうした要素のwidthもしくはheightだけを明示的に指定して、もう一方をmin/max指定したとき、内在比と矛盾が出たらどうしよういう部分だ。たとえば縦横比1:1である画像に対して、 {width:200px; min-height:300px} というスタイルを宣言すると、画像は正方形ではなく縦長になってしまう（というのが従来の仕様）。これに対して、min/maxの場合は内在比を尊重すべきではないかという意見が出て、WGでまとまらないのでコメントを求むと
ちょっとしたメモ - IE7、Firefox2でもRSS1.0にXSLTを適用させる
IE7やFirefox2は、「フィード」をMIMEタイプで判別できないときは、コンテンツの先頭部分のテキストマッチで判断して「フィードプレビュー」を起動しているらしい。判定用の文字列パターンをRSSファイルで直接用いないようにしたら、確かにどちらのブラウザもプレビューではなくてXSLTを適用するようになった。ただし、一般のフィードリーダーの中にも同じような文字列マッチを使っているものがある模様で、方法によってはこれらのフィードリーダーでも修正版RSSを読めなくなってしまうので注意が必要だ。 Microsoft Team RSS BlogのWindows RSS Publisher's Guideによれば、MIMEタイプがapplication/xmlもしくはtext/xmlであるときは、IE7はコンテンツ冒頭の512バイトを読んで、その中に次の3つの文字列があればRSS1.0と判定するのだ
ちょっとしたメモ - HTMLの再構築？
GRDDL仕様の最初の公開草案が出ていよいよXHTMLの出番だと思っていた矢先に、バーナーズ=リーからReinventing HTMLなどという話が出てきてびっくり。W3CのHTMLに対する取り組みへの不満は各地で書かれているし、WHATなんていう分派がHTML 5を起草したりしているから、本家としても何とかしなければならんということだろう。しかし、新しいHTML部会を設立する（to charter a completely new HTML group）と個人ウェブログでいきなり宣言するのは異例で、かなり唐突な感じがする。 もちろんこれは、XHTMLに向かう動きを逆流させようということではない。新しいHTML部会は、現在のHTML WGを置き換えるのではなく、並行して設置されるのだという。XMLの方向へ一度に切り替えようとしたのでものごとが動かなかった（The attempt to ge
ちょっとしたメモ - application/jsonがRFC4627に
3月末にアナウンスされていたJSON仕様のRFCが、RFC 4627 The application/json Media Type for JavaScript Object Notation (JSON)として公開された。メディアタイプは表題の通りapplication/jsonで、標準ファイル拡張子は.jsonとなっている（拡張子の話は前回書き忘れた）。一部のミス修正以外は最終I-Dとほぼ同じ内容でRFCとなった。 XMLHttpRequestでの処理にはメディアタイプはあまり関係ないが、ブラウザで直接ファイルを開こうとするとapplication/jsonの場合はダウンロードが始まってしまう（Opera9では「XMLの解析に失敗しました」となる…？？）。実用には支障ないものの、手軽にデータを確認できないのは残念なところ。.jsonにapplication/jsonをマッピングするか
ちょっとしたメモ - バーナーズ＝リー vs. Google
バーナーズ＝リーが18日のアメリカ人工知能学会の基調講演を行ったときに、Googleの検索担当ディレクタのPeter Norvigが疑問を投げかけたという話がZDNetで取り上げられている（Google exec challenges Berners-Lee）。内容は特に目新しくはないのだが、Googleという立場でセマンティック・ウェブの課題に対する考えが述べられているのは、興味深いところ。 基調講演でバーナーズ＝リーは、永続的なURIとRDFで情報を識別することの重要性を強調し、これらの仕様を一貫して用いることで、ウェブが本来目指していた協調的な性質をセマンティック・ウェブが獲得できるのだという持論を展開する。その講演後のQAセッションで、最初にマイクを握ったのがNorvigだったというわけだ。 Norvigは、セマンティック・ウェブに反対するわけではないが、Googleの視点からする
ハンディがあっても利用できるページづくり：Webアクセシビリティについて
様々な環境に配慮して、どんなユーザーでも使いやすい方法で提供されている情報はアクセシビリティ (accessibility) が高いと言います。アクセシブルなコンテンツづくりとは、ウェブでのコミュニケーションに誰もが参加できるよう設計すること。情報の利用者であると同時に提供者でもある私たちは、常にこの点に配慮していきたいものです。 なぜアクセシビリティか コミュニケーションとしてのアクセシビリティ：WCAG 2.1 1. 全ての機能と情報が誰にとっても認識可能であること 2. 全ての機能は誰にでも操作可能であること 3. コンテンツの内容、および機能が誰にとっても理解可能であること 4. 将来にわたってコンテンツの力を最大限に発揮できる技術を用いること 元祖ガイドライン：WCAG 1.0 アクセシビリティのJIS規格（2004年初出時の情報） JISの改定：X 8341-3:2010と20
読みやすいテキスト -- Style Guide for Online Hypertext
あなたの（ハイパー）テキストを読みやすく これは、私がよく目にする、そしてあまり好きではない、ハイパーテキストのスタイルを巡る２つの問題について少々文句をつけようというものです。 一つ目は「ここ」症候群です。すなわち： これこれに関する情報は _ここ_ をクリックすると入手できます。 というもの。この場合、「ここ」はリンクになっています。このスタイルは全くもって奇妙奇天烈です。「ここ」をクリックするには、*本当に* ここでいいのかどうかを確かめるために、周囲を見回さなければなりません。声を大にして言いますが、HTMLページを作成するにあたっては、クリックする場所は、それが指し示す内容のタイトルのようなものにしてください。すなわち、 _これこれ_ に関する情報が用意されています。 そして、 _検索の方法についての情報_ が用意されています。 のように記述し、 検索の方法についての情報は、_こ
色の組み合わせチェック - 読みやすい前景色と背景色
誰にも読みやすいコンテンツとするためには、文字色と背景色のコントラストをしっかり確保しなければなりません。これを客観的にチェックするため、色の明るさの差などを計算する仕組みを用意してみました。 色の組み合わせ検証 テストの手法 コントラストの計算 色覚偏位のシミュレーション 当サイトが独自に加えたコントラストの段階評価 コントラストと読みやすさの相関関係 色の組み合わせ検証 検証してみたい文字色と背景色の組み合わせを入力してみてください。色の指定には3桁もしくは6桁の16進数カラーコード、あるいは色名（CSS2の色名＋SVGの色名、計147色）およびrgb()の表現が使えます（初期値は、読みにくい例が入っています）。また、入力欄左ボックスから216色のパレットを呼び出して入力することもできます。文字色2、3は、複数の文字色の組み合わせを表示するためのオプションで、コントラストなどの計算は行
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
