セマンティックHTML? KISS!
Keep It Simple, Stupid ウェブの文書とデータ 人間が読むためのウェブ文書にはさまざまな情報が詰まっている コンピュータ（エージェント／処理ソフト）はHTMLから文書構造の大枠を把握して提示できるが、内容（データの意味）は基本的に関知しない コンピュータ処理用のデータは別途用意する？ 両方まとめて、シンプルにしよう！ HTML文書中のデータをコンピュータ処理も可能にする HTMLのシンプルさを生かすことが大切 しかしコンピュータにとっても明快でシンプルであること だからセマンティックHTML ウェブリソースの型と関係 ウェブ文書中のデータを明示するためには 文脈によらない識別（名前付け）：何が同じで何が異なるかを明確にする データはどんなタイプ（型）か：文書について？ あるいは文中の映画について？ データどうしの関係：この日付は映画の封切り日？ 映画を観た日？ ウェブ文
XML名前空間の簡単な説明
XMLでは自由に独自のマークアップ言語（タグセット）を設計できますが、ウェブ上で情報を共有するときに、同じタグ名が異なる要素タイプを意味して衝突してしまう可能性があります。この問題を解決するためにXML名前空間は、それぞれのタグセットに固有のURIを割り当て、名前をURIで修飾することでお互いを区別します。名前空間は、ウェブ上で「意味」を明確に定義し、相互理解を可能にするために非常に重要な役割を果たします。 名前空間の導入 名前空間URIによる修飾と接頭辞 デフォルト名前空間 名前空間URIの意味するところ 名前空間の区画と属性の名前空間 参照文献 名前空間の導入 XMLでは独自のマークアップ言語（語彙）を自由に設計できますが、多くの人が利用する語彙は、標準的な語彙を共有する方が効率が良く、相互運用性も高まります。そこで、ひとつのXML文書を作成するのに、さまざまなマークアップ言語から語彙
ごくごく簡単なDTDの説明
例えば、辞書型定義リストDLの場合は <!ELEMENT DL - - (DT|DD)+> となっていますが、これは開始タグ、終了タグとも必須で、内容としてはDTもしくはDDが1回以上出現しなければならないということを意味しています。 例外についての注意 +(E)という書き方は、要素（群）Eは内容モデルの「例外」として出現して良いことを示します。この例外は「その要素の実現値の中の全ての場所に適用する」とされ、その子孫にわたって内容モデルにかかわらず出現して良いという意味になります。これは結果的にDTDの読み方を少し難しくしているので注意が必要です。例えばBODY要素タイプの定義を見てみましょう。 <!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) > BODY要素の内容にはブロックレベル要素（%block;）もしくはSCRIPT要素が1回以上出現
HTMLの基本構造 - 仕様書に見るHTML(1)
3.3 属性リスト宣言と実体宣言 また、DTDでは要素タイプがどんな属性を持つのかも定義します。属性は、<!ATTLIST で始まる宣言文で、属性名、属性値のタイプ、省略時の扱いについて定義します。 さらにDTDでは、さまざまな名前や値の別名を定義しておき、個々の宣言ではこの別名を使うのが普通です。この別名の定義を実体宣言といい、<!ENTITY で始まる宣言で定義しています。 仕様書の3.3ではこれらについても詳しく説明されています。それほど複雑ではないので、できればひととおり目を通して、DTDの読み方を身につけておきましょう。 4 HTML文書の構造 では、HTML4の仕様書のさまざまな要素タイプの定義の中から、注目しておきたい部分を拾い読みしていきます。HTMLを書くときに、「ここはどうなっているんだろう」と疑問に思うような点の多くは、実は仕様書できちんと解説されているものなのです。
名前のウェブとXHTML文書のプロファイル
情報は伝わるか？ そもそも情報は伝わらない… 生命情報：生物が世界と関係することで出現する、意味のある（識別できる）パターン 観察者（主体）が世界をどのように捉えるか（関係）を表すパターン。人によってその関係＝パターンは異なるので、完全には伝えられない。 社会情報：生命情報を人間が（ことばとして）記述する 共同体（国家、コミュニティ…）での共通了解＝意味のとりあえずの固定（規範化作用） 機械情報：言葉の記号作用の「記号表現」だけを取り出したもの コンピュータ、ネットワーク上のデータとして蓄積、交換される （西垣通 『ウェブ社会をどう生きるか』） そこを何とかうまく伝えるためには 明晰な論理と文章 分かりやすい情報のかたち 互いに理解できる名前 情報の伝達と名前 機械情報を介した情報のコード化と再構築 情報が伝わるためには、まず社会情報が適切に再現される必要がある 同じ社会情報でも人によって
XHTMLを拡張し、メタデータを直接記述する
XHTMLは名前空間を使って語彙を拡張できますから、RDFなどのメタデータも直接記述することが可能です。RDFとしてまとまった記述でなくても、Dublin Coreの語彙などでパラグラフをマーク付けしておけば、メタデータを容易に抽出できます。この方法をとる場合は、文書型宣言は省いた、整形式XMLとしてのXHTMLを用います。 名前空間によるXHTML拡張の準備 RDFを直接埋め込む head要素の場合は？ フレーズのマーク付けにDC語彙を用いる RDFをスタイルシートでテーブルとして表示する 注意点、関連事項、未解決な問題など 参考リソース ※このページはまだ検証が必要なテスト段階のものですが、議論の参考に供するために暫定的に公開します。今後、内容を書き換える予定です。 名前空間によるXHTML拡張の準備 XHTMLをはじめとするXMLの言語は、Extensibleの名のとおり、名前空間を
色の組み合わせチェック - 読みやすい前景色と背景色
誰にも読みやすいコンテンツとするためには、文字色と背景色のコントラストをしっかり確保しなければなりません。これを客観的にチェックするため、色の明るさの差などを計算する仕組みを用意してみました。 色の組み合わせ検証 テストの手法 コントラストの計算 色覚偏位のシミュレーション 当サイトが独自に加えたコントラストの段階評価 コントラストと読みやすさの相関関係 色の組み合わせ検証 検証してみたい文字色と背景色の組み合わせを入力してみてください。色の指定には3桁もしくは6桁の16進数カラーコード、あるいは色名（CSS2の色名＋SVGの色名、計147色）およびrgb()の表現が使えます（初期値は、読みにくい例が入っています）。また、入力欄左ボックスから216色のパレットを呼び出して入力することもできます。文字色2、3は、複数の文字色の組み合わせを表示するためのオプションで、コントラストなどの計算は行
ハンディがあっても利用できるページづくり：Webアクセシビリティについて
様々な環境に配慮して、どんなユーザーでも使いやすい方法で提供されている情報はアクセシビリティ (accessibility) が高いと言います。アクセシブルなコンテンツづくりとは、ウェブでのコミュニケーションに誰もが参加できるよう設計すること。情報の利用者であると同時に提供者でもある私たちは、常にこの点に配慮していきたいものです。 なぜアクセシビリティか コミュニケーションとしてのアクセシビリティ：WCAG 2.1 1. 全ての機能と情報が誰にとっても認識可能であること 2. 全ての機能は誰にでも操作可能であること 3. コンテンツの内容、および機能が誰にとっても理解可能であること 4. 将来にわたってコンテンツの力を最大限に発揮できる技術を用いること 元祖ガイドライン：WCAG 1.0 アクセシビリティのJIS規格（2004年初出時の情報） JISの改定：X 8341-3:2010と20
RSSによるサイト情報の要約と公開
メタデータ/RDFの応用として利用されているXMLフォーマットの代表として、RSS (RDF Site Summary) があげられます。共通の書式でドキュメントの見出し、要約などのリストを提供することで、サイトの更新情報などを効率的に公開できます。 RSS 1.0の要素と構文 channel要素 item要素 シンプルなRSSの全体 RSS 1.0全要素のツリー RDFとして見た場合のRSS RSSのRDFモデル RDFモデルの補足説明 RSSの拡張/応用とモジュール Dublin Coreモジュール Syndicationモジュール Contentモジュール そのほかのモジュール RSSとセキュリティ RSSの実際の利用 RSSの歴史〔補足〕 参照文献 ※RDFの体系的な解説『RDF/OWL入門』を上梓しました。 RSS 1.0の要素と構文 RSS (RDF Site Summary)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
