Skip to content
MINAZUKI, Bakera edited this page Apr 17, 2020 · 15 revisions

雑なメモ

全体方針について

本書の目指すところは、「仕様を読んだことのない人が、この本を読むことで仕様を読めるようになる」ということ。 以下の2点を意識する。

  • 仕様を読むために必要になる知識をしっかり抑える
    • 仕様を読むための基本的な知識を書く必要がある
    • 仕様を読む上では専門用語の理解が重要なので、用語はしっかり強調したい。
  • とっつきやすい文章にする
    • 入り口として使って欲しい本なので、そのことを意識する
    • 対象読者は技術文書にあまり慣れていない前提

書く内容

  • HTMLのセマンティクスに関わらない部分は、いちおう説明するがあまり紙面を割かないスタンス。
    • template要素、script要素のさまざまな属性など
    • もちろん書きたければ書いても良い、コラム扱いもあり
  • 基本、本文ではHTML構文を前提に話をする
    • 冒頭で「基本的にHTML構文を前提にする」という話をする
    • XML構文でルールが異なる重要なポイントについては、コラムや注釈でフォローする
    • 「XML構文について」という話をどこかに設ける (コラムか、節扱いか。最大でも2ページ程度)

要素説明に書く内容

各要素について以下を書く

  • セマンティクス
    • 基本、仕様にある情報を書く
    • 本来の意味と異なるような要素の使い方をしてしまう誤りが多い場合は注意を促す
    • HTML4から要素の意味が再定義されたものは明示的に説明する
  • 内容モデル
    • 経験的に間違えやすい場合は書く。内容モデルが比較的自明で間違えにくい場合は、特に書かない。
    • 基準の明確な定義は難しいが、自身がPhrasingではなく内容モデルがPhrasingのものは書くと良いかも
    • labelは自身がPhrasingだが、中にdivやpを入れてしまう間違いが割と多いので書いた方が良い。皮肉にも「labelに説明文も入れる」という a11y対応で入りがち。
    • HTML4 Strictから内容モデルが変わったものは明示的に説明する。a, addressなど
  • タグ省略
    • 省略可能な時だけ省略可能な旨を書く
  • アクセシビリティ上の注意点
    • 要素のデフォルトロールがどうなるか書く (仕様の Accessibility considerations: For authors のリンク先の内容)
    • スクリーンリーダーで特別な扱いをされる場合は書く。特別な読まれかたをされる、ランドマーク扱いされてジャンプできるなど
    • 要素選択のヒントになる話は書く
  • 仕様と実装の乖離
    • 仕様通りに書いてもUA側が対応していないケースがあれば書く
    • 今は少ないが、ないわけではない。アウトラインアルゴリズムや、WAI-ARIA関連など

コードのスタイル

  • HTML構文を使用する (必要のないところでXML構文を使用しない)。
  • サンプルコードでは、基本的にタグの省略はせずにフルで書く。もちろん説明上の必要がある場合は省略して良い
    • 属性の省略は要検討。<span hidden="hidden"> と書くべきかどうか

太田が個人的に考えているもの

  • 「書けない」「エラーになる」という場合、結果としてどうなるか (どういうDOMツリーができるか) もできるだけ書く
  • 用語の初出時はカギカッコくくり+原文併記とする。例: 「開始タグ」(start tag)

トピック

未対応

  • 空白類文字の扱いについて
  • MIME Typeの説明がないかも (HTML構文とXML構文の説明)

対応済み

  • URL Standard について触れた方がいい → 2章で扱うことにした。

細かいメモ

「DOM」と「DOMツリー」「DOMノード」は、全部ひっくるめて「DOM」と呼びがちだがしっかり使い分けたい。 DOMはデータモデル。なのでDOMを読み書きする、というのは厳密にはおかしい。DOMツリーは読み書きできる。 DOM操作の対象となるのはDOMツリーでありDOMノード。