2018年の抱負の進捗状況 (3月1日時点)

Life

この記事は自分向けの記事です

もうちょっと頻繁にblogを更新する

個人的にはもうちょっと更新したいのですが、更新自体を目的として書くこともないのに記事を書くと碌なことがないので書くことが出来たら、と言う事で

体重を60kgまで落とす

の朝が72.5kgでの朝が71.30kgでした

一応年内に60kgに到達可能な状況ですが、もう少し速度を上げたい所

HTML5.2の仕様書を一通り読む

自分の覚書を2.6. Fetching resourcesまで公開

下読みなら2章は全部終わっているのですが、3月と4月は他の事を優先したいので今以上に進捗は落ちる見込みです

年内に読み切るのは絶望的ですが、仮に2年がかりになってもとりあえず読み切る心算なので無理して速度は上げずにちまちまやっていきたい所存です

応用情報技術者試験に合格する

Bridge Constructor Portalの60面はどうしても解けなくてにYoutubeで解法を検索してクリアしました

そのあとStellarisに手を出したのですが、これが本気で数百時間平気で持っていく4X strategyゲームで流石に封印して、いまはMinecraftをメインに遊んでます

さてはお前合格する気ないな

HTML5.2の見出し毎の内容を雑にまとめる、2.6. Fetching resources (リソースの取得)

HTML

2. Common infrastructure (共通基盤) の中の 2.6. Fetching resources (リソースの取得) について

もし、HTML5をWeb Applicationの為でなく、単なる文書 (form要素やJavaScriptによる従来のXMLHttpRequestのような処理、あるいはCookieなどを一切使わない文書) を書くために勉強するなら、恐らく「こういう章が存在する」以上のことを覚えておく必要はない

ただし、そのような単なる文書であっても真にスタンダロンな文書でなければ、例えばimg要素のようなリソースの埋め込みや、link要素で指定されたスタイルシートの取得などもUAはfetchで定められた仕様に従って動いており、この章の内容は無関係ではない

また、もし、HTML5を (User Agentを実装する為でなく) Web Applicationを作成するために勉強するなら、恐らくこの章で定義されている用語や概念は知っておくべきであろう

ただし、そのような Web Application開発者であっても、例えばFetch 概説 - Web API インターフェイス | MDNなどで十分足りる場合が多いであろう

Fetchを全く知らない場合、予備知識なくこの章を読むより、先にLiving StandardのFatch Standardを読んだ方が理解が早いと思われる (非公式版ではあるがFetch Standard （日本語訳）も存在する)

更に併せて読んでおくと良いかもしれない文書を以下に列挙する (なお、筆者は読めていない)

なお、内容についてはあくまで初学者の覚書ですので、正式な仕様はW3CのHTML5.2を確認してください

また、勉強のため、各仕様の邦訳文書、解説文書を読まずに自分で翻訳して覚書を書き終わってから答え合わせとして邦訳文書を参照するようにしています

このため、多くの訳語が一般的な訳と異なっていますのでご注意ください

2.6. Fetching resources (リソースの取得)
2.6.1. Terminology (用語)

ユーザーエージェントは様々な転送プロトコルを実装しているが、この仕様ではもっぱらHTTPに関する動きを定義する

HTTP取得メソッド (HTTP GET method) はプロトコルのデフォルトの検索動作 (例えばFTPのRETR) と同じであり、HTTP用語において安全かつ等冪 (複数回の実行を行っても結果が同じ演算) である

FTPのRETRとは、FTPのリモートファイルをダウンロード（Retrieve）するコマンド、RFC 959参照

HTTP応答コード (HTTP response codes)は他のプロトコルの持つ同様の基本的な意味のステータスと同等である。

例えば "ファイルが見つからない" エラーは 404 コードと同様で、サーバーエラーは500番台のエラーと同様など、と言う事です。

HTTPヘッダー (HTTP heade) 他のプロトコルの分野と基本に同じ意味を持っている

例えばHTTP認証ヘッダー (HTTP authentication headers) は、FTPプロトコルの認証と同じである

参照元ソース (referrer source) はDocumentまたはURLである

ほか、潜在的CORS要求の作成 (create a potential-CORS request) についての記述がある (が、自分は輪をかけて理解できていない)

2.6.2. Processing model (処理モデル)

ユーザーエージェントが基点からURLやリソースを取得する場合の処理

iframe内の場合や、data:URL、about:blankなどの場合の処理が記述されており、更にCookie更新についてフラグ処理、リダイレクトの場合 (HTTPのステータス301/302/303/307の場合)、などユーザーエージェントが実装すべき処理について記述されている

ユーザーエージェントの実装者やWebApplication製作者は把握すべき内容だと思われるが、単にHTMLで文章をマーク付けしたいだけの自分には荷が重くフレーズレベルで単語を眺め、内容は把握していない

2.6.3. Encrypted HTTP and related security concerns (暗号化HTTPとそれに関するセキュリティ上の懸念)

この仕様でHTTPを参照する場合、HTTPsプロトコルで表現されるHTTP-over-TLSにも適用される

ユーザーエージェントは証明書にエラーがあった場合ユーザーに報告し、併せてリソースのダウンロードを拒否するか、又は暗号化なしの時と同様の挙動にしなければならない

ユーザーエージェントはユーザーが以前訪問したサイトに再び訪問した時に暗号化が使用されていなければ、訪問する度に潜在的な問題があることを警告しなければならない

そうしなければユーザーは中間者攻撃に気付くことが出来ない

ほか、デジタル証明書が自己署名、期限切れ、あるいは以前CA署名付きのデジタル証明書だったサイトが自己署名のデジタル証明書に切り替えた場合のユーザーエージェントの振る舞いについて

2.6.4. Determining the type of a resource (リソースタイプの決定)

コンテンツ型メタ情報 (Content-Type metadata) はMIMEスニッフィング仕様 (MIME Sniffing Standard) に従って取得しされ、解釈されなければならない

計算されたリソースの型 (computed type of a resource) 関連した連続する8bitの計算されたメディアタイプを見つけるためのMIME Sniffing Standardで与えられた一貫した方法に基づかねばならない (7. Determining the computed MIME type of a resource - MIME Sniffing Standard 参照)

画像をスニッフィングするための規則 (rules for sniffing images specifically) とリソースがテキストかバイナリィかを区別するための規則 (rules for distinguishing if a resource is text or binary) はMIMEスニッフィング仕様でも定義されており、両方のルールセットはMIMEタイプを返却する

MIMEスニッフィング仕様を厳密に守らない場合、セキュリティ上の問題が生じる可能性がある

2.6.5. Extracting character encodings from <meta> elements (meta要素による文字エンコーディングの抽出)

文字列sを与えられた場合のmeta要素からの文字エンコーディングを抽出するアルゴリズムについて

このアルゴリズムは文字エンコーディングを返却するか、何も返却しない

HTTPの仕様とは異なることに注意すること

2.6.6. CORS settings attributes (CORS設定属性)

CORS設定属性は列挙型の属性となる

CORSモードで資格がsame-originとなる匿名 (Anonymous)または空文字列と、CORSモードで資格がincludeとなる資格情報を使用する (Use Credentials) と、属性が省略された場合のNo CORSモードが存在する

詳細は仕様参照

2.6.7. Referrer policy attributes (リファラーポリシィ方針属性)

リファラーポリシィ属性は、列挙型の属性である

空文字列を含め、リファラーポリシィはこの属性へのキィワードであり、同じ名前の状態にマッピングされる

属性の無効な値のデフォルト値と属性がない場合のデフォルト値は空文字列の状態となる

これらの値による処理への影響の詳細は、この仕様、Fetch Standard仕様、Referrer Policy仕様に定められている

幾つかの信号がFetchの処理モデルに寄与でき、リファラーポリシィ属性はその一つである

一般にこれらの信号が処理される順序は以下のとおりである

  1. リファラーのない (noreferrer) リンクタイプ
  2. リファラーポリシー属性の値
  3. name属性がreferrerに設定されたmeta要素
  4. HTTPヘッダーのリファラーポリシィ

(現在の) HTML 5.3 Editor’s Draftでは、dates and timesの先発グレゴリオ暦の紀元前1年と10000年以降は妥当でない

HTML

HTML5.2のdates and timesで先発グレゴリオ暦の紀元前1年と10000年より未来は妥当な値になるのかについて、issueを立てていたのですが、その結果がHTML5.3 Editor's Draftに反映されています

それによりのHTML5.3のEditor's DraftではDates and timesの先発グレゴリオ暦は0001年から9999年までになり、0000年と10000年以降はinvalidになります

Living Standardでvalidである限りUAは西暦10000年以降を今後とも処理し続けると思いますが、もし、HTML5.3でも西暦10000年以降が扱えないと困る人が居たら今のうちにissueを立てることをお勧めします

2.4.5. Dates and times - HTML5.3 Editor's Draft

Dates are expressed in the proleptic Gregorian calendar between the proleptic year 0001, and the year 9999 inclusive. Other years cannot be encoded.

2.4.5.1. Months - HTML5.3 Editor's Draft

Four ASCII digits, representing year, where year >= 1

経緯についてはissueのやり取りを見ていただくとして (The range of years is incorrect in note of 2.4.5. Dates and times. · Issue #1141 · w3c/html)、issueを立てた身として思いを箇条書きにするとこんな感じです

  1. Noteとはいえ仕様内で矛盾があるのは解消されて良かった
  2. 0000はLiving Standardでもinvalidだし、紀元前1年と解釈されるはずなので、invalidになって良かった
  3. 10000年以降はLiving Standardでもvalidであるし、過去のW3CのHTML5.xでもvalidだし、実装上何か困るとも思えないのだが、Issueのやり取りの通り西暦1万年以降の正確な日付の出番は稀であろうし、どうしても必要な人はdata-*で足すことが出来るので、実際困らないだろうと思って強く反対もしなかったが、その変更は不要だったのではと実は今でも思っている
  4. W3CのEditorが大きな問題の提示なく後方互換やLiving Standardとの互換性を捨てる変更をあっさり受け入れたのが意外だった

2018年の抱負の進捗状況 (2月1日時点)

Life

この記事は自分向けの記事です

もうちょっと頻繁にblogを更新する

今のところ「HTML5.2の仕様書を一通り読む」の進捗報告みたいな状態ですがそれなりに満足しています

2月半ばからから4月半ばまで止まる予定なので、暇つぶしレベルで書ける何かを考える予定です

体重を60kgまで落とす

の朝が74.3kgで、の朝が72.5kgでした

1か月で2%減らせば11月中旬に目標の60kg達成となるのですが、過去の経験から68kgの辺りで体重が落ちにくくなる筈なので、2月はもう少し速度を上げたい所です

HTML5.2の仕様書を一通り読む

現在読んだ結果の覚え書きを記事にして 2.5. URLs まで公開

覚え書きを書くには、少なくとも一通りの文字を読んで（内容を理解できていないにせよ）自分なりの言葉で書き直す必要があるので「文字だけ目で追ったので読んだ、終わり」とするのに対して記憶に定着して勉強になるのですが、時間がかかります

2月以降は1月ほどには注力できない見込みなので、早くも「年内に5章まで」という大幅下方修正が現実ラインとして見えてきました

HTML5.3が出るまでに間に合わないので、その時は読み終わっているところまでのHTML5.2と5.3の差分を追いなおすか、一旦HTML5.2を一旦読み終わるまで作業を続けるか、悩ましいところです

応用情報技術者試験に合格する

春期試験の申し込みをしました

肝心の勉強の進捗状況ですが、いまBridge Constructor Portalの60面で1週間ほど詰まっている状態です

勉強しろ

HTML5.2の見出し毎の内容を雑にまとめる、2.5. URLs

HTML

2. Common infrastructure (共通基盤) の中の 2.5. URLs について

知っているようで知らない URLs

知らないならWHATWGのURL Living Standardを読むべきですが、私は読めていません

内容についてはあくまで初学者の覚書ですので、正式な仕様はW3CのHTML5.2を確認してください

また、勉強のため、各仕様の邦訳文書、解説文書を読まずに自分で翻訳して覚書を書き終わってから答え合わせとして邦訳文書を参照するようにしています

このため、多くの訳語が一般的な訳と異なっていますのでご注意ください

2.5. URLs (URLsはURLの複数形; Uniform/Universal Resource Locator)
2.5.1. Terminology (用語)
妥当なURL (valid URL)

WHATWG URL仕様のオーサリング適合要件に適合する文字列

最終的には4.1. URL representation - URL Standard参照

妥当な空文字列ではないURL (valid non-empty URL)
空文字列ではない妥当なURLの文字列
空白文字で囲まれているが、潜在的には妥当なURL (valid URL potentially surrounded by spaces)
先頭と末尾の空白文字を取り除く (strip leading and trailing white space) 処理をすると妥当なURLになる文字列
valid non-empty URL potentially surrounded by spaces
空文字列ではない先頭と末尾の空白文字を取り除く (strip leading and trailing white space) 処理をすると妥当なURLになる文字列

この仕様では、XMLツールとの互換性のためにHTML文書のDOCTYPEで使用するのでURL "about:legacy-compat" を予約済みの、解決できない、"about:" URLとして定義する

この仕様は、メディアトラックの識別子で使用するのでURL "about:html-kind" を予約済みの、解決できない、"about:" URLとして定義する

この仕様は、iframe srcdoc文書の文書のURLで使用するのでURL "about:srcdoc" を予約済みの、解決できない、"about:" URLとして定義する

他に、"fallback base URL" (絶対URL) と "document base URL" (絶対URL) の取得処理についての定義について

文書オブジェクトのフォールバック基礎的URL (fallback base URL) は、次の処置を実行することで得られる絶対URLである

  1. 文書がiframe srcdoc文書の場合、文書のブラウジング文脈 (browsing context) のブラウジング文脈格納容器 (browsing context container) のノードドキュメント (node document) の文書基礎的URL (document base URL) を返す
  2. もし、文書URL (document’s URL) がabout:blankで、ブラウジング文脈 (browsing context) がクリエーターブラウジング文脈 (creator browsing context) を持つならクリエイター基礎的URL (creator base URL) を返す
  3. (上記の条件でないなら) 文書URL (document’s URL) を返す

文書オブジェクトの文書基礎的URL (document base URL) は次の処置を実行することで得られる絶対URLである

  1. もし文書にhref属性を持つbase要素がなければ、文書基礎的URLはフォールバック基礎的URL (fallback base URL) になり、処理を中断する
  2. そうでなければ (ドキュメントにhref属性を持つbase要素があれば)、文書基礎的URLは文書内の (木構造の順で) 最初のhref属性を持つbase要素の固定された基礎的URL (frozen base URL) です

フォールバック基礎的URLとか、文書基礎的URLは、自分で書いた説明が知識不足で我ながら何を言っているのかさっぱり分からないのだが、内容からするとHTML文書内で相対パスを解決する場合の基となるURLを取得する際に、iframeの中かどうか、href属性を持つbase要素があるか判定して取得している処理と思われる

2.5.2. Parsing URLs (URLsの解析)

URLの解析は、URL文字列を取得し、それが示す URL レコードを取得する手続きである

この手続きはWHATWG URL仕様で定められており、本仕様では便宜的にラッパーを定義している

ラッパーの手続きについての説明は本文参照

2.5.3. Dynamic changes to base URLs (基礎的URLsの動的変更)

文書の文書基礎的URLが変更されると、その文書すべての要素は基礎的URL変更の影響を受ける

具体的な影響を受ける内容は以下の通り

要素によって生成されるハイパーリンク

ハイパーリンクによって識別されたURLがユーザーに示されていたり、派生して生成されたデータがユーザーに影響を与えている場合、新しいURLで再解析して更新する

例えば、CSSの :link や :visited の疑似要素など

q、blockquote、ins、del要素のcite属性

cite属性で識別されたURLがユーザーに示されていたり、派生して生成されたデータがユーザーに影響を与えている場合、新しいURLで再解析して更新する

その他

影響を受けない

img要素のscr属性なども影響を受けない

ただし、基礎的URL変更後にスクリプトからアクセスすると新しい絶対URLが得られる (結果として表示されているイメージと不一致の値となる)

HTML5.2の見出し毎の内容を雑にまとめる、2.4. Common microsyntaxes (共通のマイクロ構文)

HTML

2. Common infrastructure (共通基盤) の中の 2.4. Common microsyntaxes (共通のマイクロ構文)

ここの理解が不足していると、正しい属性値などを設定することができなくなってしまうので、気合を入れてひたすら読みます

2.4.5. Dates and times (日付と時刻) ではどう読んでも矛盾する箇所があり、結局issueを立てました

結果、以下の内容が変わってしまうかもしれません

内容についてはあくまで初学者の覚書ですので、正式な仕様はW3CのHTML5.2を確認してください

また、勉強のため、各仕様の邦訳文書、解説文書を読まずに自分で翻訳して覚書を書き終わってから答え合わせとして邦訳文書を参照するようにしています

このため、多くの訳語が一般的な訳と異なっていますのでご注意ください

2.4. Common microsyntaxes (共通のマイクロ構文)

この章ではHTMLで使う日付とか数字とかのデータの適合基準や解析方法を説明する

ユーザーエージェント実装者はこれらのデータを共有するサードパーティー製品のエラー処理の挙動がHTMLの定義する挙動とは異なる、そもそも未定義の可能性があるので注意が要る

2.4.1. Common parser idioms (共通の構文解析慣用句)

以下の用語についての説明がある

空白文字 (space characters)

次のいずれかの文字

  1. U+0020 " " SPACE
  2. U+0009 " " CHARACTER TABULATION (tab)
  3. U+000A " " LINE FEED (LF)
  4. U+000C " " FORM FEED (FF)
  5. U+000D " " CARRIAGE RETURN (CR)
空白類文字 (White_Space characters)
UnicodeのPropList.txt 参照 (リンクはUnicode 10.0.0の物)
制御文字
UnicodeのUnicodeData.txt 参照 (リンクはUnicode 10.0.0の物)
大文字ASCII文字
文字コード順で文字A (U+0041 "A" LATIN CAPITAL LETTER A) から文字Z (U+005A "Z" LATIN CAPITAL LETTER Z) の範囲の文字
小文字ASCII文字
文字コード順で文字a (U+0061 "a" LATIN SMALL LETTER A) から文字z (U+007A "z" LATIN SMALL LETTER Z) の範囲の文字
ASCII文字
大文字ASCII文字または小文字ASCII文字の文字
ASCII数字
文字コード順で文字0 (U+0030 "0" DIGIT ZERO (0)) から文字9 (U+0039 "9" DIGIT NINE (9)) の範囲の文字
ASCII英数字
大文字ASCII文字または小文字ASCII文字とASCII数字の文字
ASCII16進数
文字コード順で文字0 (U+0030 "0" DIGIT ZERO (0)) から文字9 (U+0039 "9" DIGIT NINE (9)) または文字A (U+0041 "A" LATIN LETTER A) から文字F (U+0046 "F" LATIN LETTER F)、文字a (U+0061 "a" LATIN SMALL LETTER A) から文字f (U+0066 "f" LATIN SMALL LETTER f) の範囲の文字
大文字ASCII16進数
文字コード順で文字0 (U+0030 "0" DIGIT ZERO (0)) から文字9 (U+0039 "9" DIGIT NINE (9)) または文字A (U+0041 "A" LATIN LETTER A) から文字F (U+0046 "F" LATIN LETTER F) の範囲の文字
小文字ASCII16進数
文字コード順で文字0 (U+0030 "0" DIGIT ZERO (0)) から文字9 (U+0039 "9" DIGIT NINE (9)) または文字a (U+0061 "a" LATIN SMALL LETTER A) から文字f (U+0066 "f" LATIN SMALL LETTER f) の範囲の文字
一連の文字の収集 (collect a sequence of characters) のアルゴリズム
呼び出したアルゴリズムと同じ判定によって行われる文字の収集アルゴリズム
(連続した複数の) 空白文字を飛ばす (skip white space)
空白文字を飛ばす場合、ユーザーエージェントは対象の文字列から(連続した複数の) 空白文字を収集し、収集した空白文字を使わないようにする必要がある
改行を取り除く (strip line breaks)
改行を取り除く場合、ユーザーエージェントは対象の文字列からLF (U+000A " " LINE FEED) 及びCR (U+000D " " CARRIAGE RETURN (CR)) を取り除く必要がある
先頭と末尾の空白文字を取り除く (strip leading and trailing white space)
先頭と末尾の空白文字を取り除く場合、ユーザーエージェントは連続した空白文字をスペース(U+0020 " " SPACE) 1文字に置き換えた上で、先頭と末尾のスペースを取り除く必要がある
厳密に文字列を分割する (trictly split a string) アルゴリズム

厳密に文字列を分割する場合、ユーザーエージェントは特定の区切り子 (delimiter character) を用いて次のアルゴリズムで処理を行う

  1. 入力された文字を解析対象とする
  2. 最初は入力の先頭となる、入力へのポインタをポジションをとする
  3. 最初は空の順序付きトークンを用意する

  4. ポジションが入力の末尾を超えない限り次を繰り返す

    1. 区切り子ではない連続する文字列を収集する
    2. 前項で収集した文字列をトークンに追加する
    3. ポジションを入力の次の文字に移動させる
  5. トークンを返す

スペース (U+0020 " " SPACE) とカンマ (U+002C "," COMMA) を区切り子とする特殊なケースではこのアルゴリズムを適用しない (そのような場合、空白の除去をおこなうアルゴリズムになる)

カンマ区切りトークンは 2.4.8. Comma-separated tokens 参照

2.4.2. Boolean attributes (ブール型 (真偽値) 属性)

ブール型 (真偽値) 属性を属性についての説明

属性自体の記述 (属性値は属性の名前と同じか、空白か、省略) があればtrueとなり、記述がない事でfalseになる (本文の例を参照)

ブール型属性の属性値はtrue、falseではない

2.4.3. Keywords and enumerated attributes (キィワードと列挙型属性 (列挙型は有限の識別子の集合))

列挙型属性 (値が有限のキィワードセットの内の1つを取る属性) についての説明

空白文字列は妥当なキィワードになる (そういう列挙型属性が存在し得る)

2.4.4. Numbers (数値)
2.4.4.1. Signed integers (符号付整数)

1桁以上のASCII数字と、先頭にマイナス (-) が付いているかも知れない10進数の整数についての説明

符号付整数 (Signed intege) であるが、プラス (+) を付けると (処理上は無視されるので意図通りに構文解析されるかもしれないが) 不適合である

2.4.4.2. Non-negative integers (負ではない整数)

1桁以上のASCII数字の10進数の負ではない整数についての説明

ゼロを含む

2.4.4.3. Floating-point numbers (浮動小数点数値)

浮動小数点数値及び、浮動小数点数値を解析するアルゴリズムについての説明

数値 n を浮動小数点数値にする最も良い方法は JavaScriptのToStrigを n に適用する事である

概ねIEEE Standard for Floating-Point Arithmetic (ANSI/IEEE Std 754-2008) の倍精度浮動小数点数値と思ってよい

ただし、負のゼロを除くIEEE 754の有限数値の集合に (内部でエラーとする値として) 21024と-21024を加えたものに変換される (Conversion: Let S be the set of finite IEEE 754 double-precision floating-point values except -0, but with two special values added: 21024 and -21024.) ので無限大、負の無限大、非数 (Not-a-Number (NaN)) はHTML5.2の妥当な浮動小数点数値ではなく、-0 は 0 と同じになり、更に内部でエラーとして扱われる数値として21024と-21024が存在する

2.4.4.4. Percentages and lengths (百分率と長さ)

大きさの値を解析する規則 (rules for parsing dimension values) についての説明と、それによって得られる 0.0 以上の10進数の数値となる百分率または長さについての説明

最後がパーセント文字 (%) の場合は値が百分率となり、そうでない場合は値が長さとなる

2.4.4.5. Non-zero percentages and lengths (ゼロではない百分率と長さ)

ゼロ以外の大きさの値を解析する規則 (rules for parsing non-zero dimension values) についての説明と、それによって得られる 0.0 より大きい10進数の数値となる百分率または長さについての説明

大きさの値を解析する規則 (rules for parsing dimension values) による処理を行った上で、更に解析結果が0の場合エラーとする

2.4.4.6. Lists of floating-point numbers (浮動小数点数値リスト)

浮動小数点数値をカンマ (U+002C "," COMMA) で区切って列記した数値

区切り子はカンマ (U+002C "," COMMA) であり、他の文字 (例えば空白文字) ではない

浮動小数点数値リストを解析する規則 (rules for parsing a list of floating-point numbers) が定められているが、見る限り空白文字やセミコロン (U+003B ";" SEMICOLON) を区切り子としても非適合だが意図したエラーとならず解析結果が得られるように思える

おそらくカンマ前後の空白文字と終端記号としてセミコロン (U+003B ";" SEMICOLON) を許容するための処理であろう

また、解析できなかった浮動小数点数値 (のようなもの) は非適合だが 0 として扱われる

2.4.4.7. Lists of dimensions (大きさの値リスト)

数値と単位 (パーセンテージ、絶対値、相対値) からなるゼロ個以上のペアリストの説明

大きさの値リストを解析する規則 (rules for parsing a list of dimensions) が定められている

区切り子はカンマ (U+002C "," COMMA) であり、小数点を持つ 0.0 以上の10進数の数値、更に単位としてパーセント (%) を持つ百分率、または単位としてアスタリスク (U+002A "*" ASTERISK) を持つ相対値からなるリスト

2.4.5. Dates and times (日付と時刻)

この仕様は日時の記述方法を ISO 8601 (Data elements and interchange formats – Information interchange – Representation of dates and times) の共通サブセットとして規定しているが、解析規則はISO 8601より詳細であるためユーザーエージェント実装者は注意を要する (単にISO 8601に対応したライブラリで解析すると誤りとなる場合がある)

先発グレゴリオ暦を用いており、グレゴリオ暦以外の暦が使われている地域や時代の日付はグレゴリオ暦に変換する必要がある

また、うるう秒の書き方は存在しない

ASCII数字を用いて表現する場合、10進数となる

その年の月の日数 (number of days in month month of year year) は

  1. 月が1、3、5、7、8、10、12なら31
  2. 月が4、6、9、11なら30
  3. 月が2で年が400で割り切れるか、4で割り切れて100で割り切れないなら29、そうでないなら28

となる

先発グレゴリオ暦は先発グレゴリオ暦 - Wikipediaから引用すると1582年から施行されたグレゴリオ暦の暦法を、1582年以前にも適用したものである。この語は英語を翻訳したものだが日本語の定訳がなく、遡及グレゴリオ暦、予測的グレゴリオ暦、予期的グレゴリオ暦などとも訳されるとの事。

NOTEの Dates are expressed in the proleptic Gregorian calendar between the proleptic year 0000, and the year 9999. Other years cannot be encoded. の記述は恐らく誤りであろう

上記に関する考察は別記事 HTML5.2のdates and timesで先発グレゴリオ暦の紀元前1年と10000年より未来は妥当な値になるのかに詳しく書いた

2.4.5.1. Months (月 (年と月))

月は、特定の先発グレゴリオ暦の月で、時間帯の情報を持たず、年と月以上の情報を持たない (この場合、年と月以上の情報とは、情報の精度なので日にちや時刻を指す)

妥当な月の文字列は以下の通り

  1. 年を表す4桁以上の0以上のASCII数字 (ゼロパディング)
  2. ハイフン (U+002D "-" HYPHEN-MINUS)
  3. 月を表す01から12まで2桁のASCII数字 (ゼロパディング)

桁指定があるのでゼロパディングする必要がある

例えば2005年2月は2005-02となる

325年3月を325-03と書くのは誤りである

2.4.5.2. Dates (日付 (年月日))

日付は、特定の先発グレゴリオ暦の日付で、時間帯の情報を持たず、年月日以上の情報を持たない (この場合、年月日以上の情報とは、情報の精度なので時刻を指す)

妥当な日付の文字列は以下の通り

  1. 月を表す文字列
  2. ハイフン (U+002D "-" HYPHEN-MINUS)
  3. 日にちを表す01からその年の月の日数までの2桁のASCII数字 (ゼロパディング)

桁指定があるのでゼロパディングする必要がある

例えば2016年2月29日は2016-02-29となる

325年3月3日を325-03-03と書くのは誤りである

2.4.5.3. Yearless dates (年の無い日付 (月と日))

年がない日付はグレゴリオ暦の月と日で構成され、年の情報はない

妥当な年の無い日付の文字列は以下の通り

  1. 2文字のハイフン (U+002D "-" HYPHEN-MINUS)があってもよい
  2. 月を表す2桁の01から12までASCII数字 (ゼロパディング)
  3. ハイフン (U+002D "-" HYPHEN-MINUS)
  4. 日にちを表す01からその年の月の日数までの2桁のASCII数字 (ゼロパディング) からなる文字列が妥当な年がない日付の文字列となる (2月はうるう年として29日にすることができる)

桁指定があるのでゼロパディングする必要がある

例えば2月29日は02-29となる

2.4.5.4. Times (時刻 (時分秒))

時刻は時間帯の情報を持たない特定の時、分、秒及び小数点以下の秒で構成されます

妥当な時刻の文字列は以下の通り

  1. 時を表す0以上23以下の2文字のASCII数字
  2. コロン (U+003A ":" COLON)
  3. 分を表す0以上59以下の2文字のASCII数字

  4. 秒が0でないか、0を書く場合

    1. コロン (U+003A ":" COLON)
    2. 秒を表す0以上59以下の2文字のASCII数字

    3. 秒が0が整数ではないか、整数だが小数点以下を書く場合

      1. ピリオド (U+002E "." FULL STOP)
      2. 小数点以下の秒を表す1桁から3桁のASCII数字

60秒や61秒は書けないため、うるう秒は表現できない

例えば時は24時制で記述するため、午後7時45分は19:45となり、19:45は午後7時45分0秒となる

19:45:45.456は午後7時45分45.456秒となる

秒を書かなかった場合は0.0秒と見做され、小数点以下の秒を書かなかった場合は小数点以下0秒と見做される

2.4.5.5. Floating dates and times (浮動日時 (時間帯の情報がない日時 (年月日時分秒)))

浮動日時 (時間帯の情報がない日時)は特定の先発グレゴリオ暦の日付で、年月日時分秒及び小数点以下の秒をもち、時間帯の情報を持ちません

妥当な浮動日時の文字列は以下の通り

  1. 妥当な日付の文字列
  2. T (U+0054 "T" LATIN CAPITAL LETTER T) またはスペース (U+0020 " " SPACE)
  3. 妥当な時刻の文字列

正規化した (normalized) 妥当な浮動日時の文字列は以下の通り

  1. 妥当な日付の文字列
  2. T (U+0054 "T" LATIN CAPITAL LETTER T)
  3. 可能な限り短い文字列になるよう表記された妥当な時刻の文字列 (例えば秒が0.0の場合、秒の記述そのものを省略する)

年月日と時分秒の間に挿入されるスペースは、厳密にASCIIの文字コード U+0020 " " SPACEであって、2.4.1. Common parser idiomsの空白文字 (space characters) ではない

正規化した場合、日付と時刻の区切り子としてスペースは使えない為、Tにしておいた方が無難

2.4.5.6. Time zones (時間帯)

時間帯の相殺分 (time-zone offset; 以下単に時間帯) は符号付の時と分で構成される

妥当な時間帯の文字列は以下の通り

  • 時間帯が標準時間帯 (UTCと同じ) 場合、Z (U+005A "Z" LATIN CAPITAL LETTER Z) 1文字

  • または、次の順序の構成要素

    1. 時間帯の符号を表すプラス (U+002B "+" PLUS SIGN) または、時間帯の相殺分が0でない場合、マイナス (U+002D "-" HYPHEN-MINUS)
    2. 時間帯の時を表す0以上23以下の2文字のASCII数字
    3. コロン (U+003A ":" COLON) があってもよい
    4. 時間帯の分を表す0以上59以下の2文字のASCII数字

実際の時間帯の範囲は-12:00から+14:00で、時間帯の分は00、30、45のしかないが、将来を保証するものではないため、この書式では-23:59から+23:59となっている

正式な時間帯成立前の時代の時刻で時間帯を使用する場合、global date and timeも参照すること

ちなみに時点ではReady to check - Nu Html Checkerだと<time>2018-01-13T00:34-00:00</time>でもエラーもワーニングも表示されない

Microsyntax descriptions · validator/validator Wiki · GitHub でdatetime-tzの記載がthe time-zone information must be either “Z” or in the form “+hh:mm” or the form “-hh:mm”となっている為と思われる (実装は仕様だが、その仕様がHTML5.2の記述と異なっている)

2.4.5.7. Global dates and timesのvalid normalized global date and time stringを考えると、UTCと時差がない場合、必ずZを書くのが無難か

2.4.5.7. Global dates and times (世界的な日時)

世界的な日時は特定の先発グレゴリオ暦の日付で、年月日時分秒及び小数点以下の秒と時間帯の情報を持つ

妥当な世界的な日時の文字列は以下の通り

  1. 妥当な日付の文字列
  2. T (0054 "T" LATIN CAPITAL LETTER T) またはスペース (U+0020 " " SPACE)
  3. 妥当な時刻の文字列
  4. 妥当な時間帯の文字列

正規化した (normalized) 妥当な世界的な日時の文字列は以下の通り

  1. UTC時間帯に変換された妥当な日付の文字列
  2. T (0054 "T" LATIN CAPITAL LETTER T)
  3. UTC時間帯に変換された可能な限り短い文字列になるよう表記された妥当な時刻の文字列 (例えば秒が0.0の場合、秒の記述そのものを省略する)
  4. Z (U+005A "Z" LATIN CAPITAL LETTER Z) 1文字

年月日と時分秒の間に挿入されるスペースは、厳密にASCIIの文字コード U+0020 " " SPACEであって、2.4.1. Common parser idiomsの空白文字 (space characters) ではない

正規化した場合、日付と時刻の区切り子としてスペースは使えない為、Tにしておいた方が無難

20世紀半ばに世界標準時が形成される前の日時は、UTCではなくUT1 (経度から算出する太陽時) を用いる

また、ある場所の時間帯は夏時間の為に異なる可能性がある。

詳しくは W3C Working Group NoteのWorking with Time Zones参照

2.4.5.8. Weeks (週)

週は週の年と、月曜日から始まる7日間の期間を表す週の番号で構成されている

週の年、52または53の7日間の期間を有している

グレゴリオ暦のに始まる7日間の期間は、1970年の週番号1と定義されている

グレゴリオ暦のに始まる7日間の期間は、1970年の週番号1と定義されている

連続する週には順番に番号が割り振られる

その1年の週は、先発グレゴリオ暦でが木曜日である場合53週になる

また、先発グレゴリオ暦でが水曜日で年が400で割り切れるか、4で割り切れるが100で割り切れない場合53週になる (要するにうるう年)

それ以外の年は52週である

週の最終番号は、その年が53週の時53で、52週の時52である

その年の最初の週は先発グレゴリオ暦でも最初の木曜日を含む週である

ここで定義している週はISO 8601の週に相当する

妥当な週の文字列は以下の通り

  1. 年を表す4桁以上の0以上のASCII数字 (ゼロパディング)
  2. ハイフン (U+002D "-" HYPHEN-MINUS)
  3. W (U+0057 "W" LATIN CAPITAL LETTER W)
  4. 週番号を1以上、その年の最終番号以下の2文字のASCII数字 (ゼロパディング)
2.4.5.9. Durations (期間)

期間は特定の秒数で表す事の期間で構成される

月や年 (12か月) は特定の秒数ではないため、この仕様では月 (や年) を期間とすることはできない

妥当な期間 t を表す文字列は次の何れかの構成となる

  • P (U+0050 "P" LATIN CAPITAL LETTER P) とそれに続く1つ以上の順序性のある副構成要素で構成される

    日数、時数、分数は同数の秒数に対応する

    1. 日数を表す、1文字以上のASCII数字と D (U+0044 "D" LATIN CAPITAL LETTER D)

    2. T (U+0054 "T" LATIN CAPITAL LETTER T) とそれに続く1つ以上の順序性のある副構成要素で構成される

      1. 時 (間) 数を表す、1文字以上のASCII数字と H (U+0048 "H" LATIN CAPITAL LETTER H)
      2. 分数を表す、1文字以上のASCII数字と H (U+004D "M" LATIN CAPITAL LETTER M)

      3. 続く構成要素として

        1. 秒数を表す、1文字以上のASCII数字
        2. 秒数を表す、1文字以上のASCII数字
        3. ピリオド (U+002E "." FULL STOP) とそれに続く小数点以下の秒を表す1桁から3桁のASCII数字があってもよい
        4. S (U+0053 "S" LATIN CAPITAL LETTER S)

    この章の他の日付や時刻のマイクロ構文同様、ISO 8601で定義された形式の一つに基づく書式である

  • 任意の順序の、1つ以上の尺度 (scale) の異なる期間構成要素で、各構成要素を秒数で表した時の合計したものが、期間 t を秒数のみで表した場合と等しくなる

    妥当な継続時間 (duration time) を構成する文字列は次の通り

    1. 0文字以上の空白文字 (HTMLの用語でいうところの空白文字)
    2. 次に述べる秒数に等しい継続時間の尺度を時間単位とした、秒数を表す1文字以上のASCII数字
    3. もし、継続時刻の構成要素の尺度が1 (すなわち秒) である場合、ピリオド (U+002E "." FULL STOP) とそれに続く小数点以下の秒数を表す1から3文字のASCII数字
    4. 0文字以上の空白文字 (HTMLの用語でいうところの空白文字)

    5. 継続時間の数値時部分の尺度を表す文字を次の内から1文字

      W (U+0057 "W" LATIN CAPITAL LETTER W)
      w (U+0077 "w" LATIN SMALL LETTER W)
      週、尺度は604800
      D (U+0044 "D" LATIN CAPITAL LETTER D)
      d (U+0064 "d" LATIN SMALL LETTER D)
      日、尺度は86400
      H (U+0048 "H" LATIN CAPITAL LETTER H)
      h (U+0068 "h" LATIN SMALL LETTER H)
      時、尺度は3600
      M (U+004D "M" LATIN CAPITAL LETTER M)
      m (U+0006D 073 "m" LATIN SMALL LETTER M)
      分、尺度は60
      S (U+0053 "S" LATIN CAPITAL LETTER S)
      s (U+0073 "s" LATIN SMALL LETTER S)
      秒、尺度は1
    6. 0文字以上の空白文字 (HTMLの用語でいうところの空白文字)

    人間への可読性を優先し、ISO 8601に基づかない書式にしている

2.4.5.10. Vaguer moments in time (時刻が曖昧な瞬間)

次のいづれかに該当する文字列は、任意の時刻となる妥当な日付の文字列である

2.4.6. Colors (色)

単純な色、それぞれがsRGB色空間の赤緑青の色味を表す (10進法で) 0から255の3桁の8-bitの数値で構成されます

妥当な単純な色 (simple color) の文字列は7文字で、最初の文字は # (U+0023 # NUMBER SIGN)で、残り6文字はASCII16進数となり、最初の2桁が赤色、中間の2桁が緑色、最後の2桁は青色を表した16進数の数値になる (全てゼロパディング)

妥当な小文字の単純な色 (lowercase simple color) の文字列は7文字で、A (U+0041 "A" LATIN CAPITAL LETTER A) から F (U+0046 "O" LATIN CAPITAL LETTER F) を使わない妥当な単純な色である

HTML執筆者向けには大文字を使わない単純な色 (simple color) は小文字の単純な色 (lowercase simple color) と言う名前で記載されているが、ユーザーエージェント実装者向けの解析規則では連続する単純な色 (serializing simple color values) という表現が用いられているが、内容は同じようである

また、仕様では廃れた使われなくなった属性の中の色 (obsolete legacy attributes parse colors) を解析する為に、使われなくなった色の値の解析規則 (rules for parsing a legacy color value) も定められている

2.4.7. Space-separated tokens (空白区切りトークン)

一揃えの空白区切りトークン (set of space-separated tokens) とは、1文字以上の空白文字 (space characters) で区切られた0個以上の単語 (トークン (token)) 含む文字列で、単語は空白文字 を含まない1文字以上の文字列である

一揃えの空白区切りトークンの文字列は先頭または末尾に (連続する複数の) 空白文字を持っても良い

順不同の一揃えの一意の空白区切りトークン (unordered set of unique space-separated tokens) とは、トークンが重複していない一揃えの空白区切りトークンである

順序あり一揃えの一意の空白区切りトークン (ordered set of unique space-separated tokens) とは、トークンが重複していない一揃えの空白区切りトークンだが、トークンの順序に意味がある

一揃えの空白区切りトークンは、時に使える値が定められている

使える値が定められている場合、すべてのトークンは使える値でなければならず、他の値は不適合となる

使える値が定められていない場合、どんな値でも適合となる

一揃えの空白区切りトークンの値がどのようであるか (例えば、大文字小文字を区別するかどうか) は、その空白区切りトークン毎に定められている

区切り子としての連続する空白文字は、空白文字を飛ばす (skip white space) 処理により一括して飛ばされ、トークンとして収集されないアルゴリズムとなっているため、連続する空白文字 (space characters) は単一の区切り子となる

split a string on spacesのアルゴリズムにはLet tokens be an ordered list of tokens, initially empty.と書かれているので、順不同の一揃えの一意の空白区切りトークン (unordered set of unique space-separated tokens) であっても内部的には順序を保持した状態のトークンに分割される

2.4.8. Comma-separated tokens (カンマ区切りトークン)

一揃いのカンマ区切りトークンは、カンマ (U+002C ","COMMA) で区切られた文字0個以上のトークンを含む文字列で、各トークンは0文字以上のカンマを含まない任意の文字で、トークンの前後を空白文字が囲んでいてもよい

例えば " a ,b, ,d d "は"a"、"b"、空文字列、"d d"の4つのトークンになる

各トークンの先頭と末尾の空白文字はトークンに含まれず、空文字列 (0文字の文字列) はトークンになる

一揃いのカンマ区切りトークンは、時に使える値が定められている

使える値が定められている場合、すべてのトークンは使える値でなければならず、他の値は不適合となる

使える値が定められていない場合、どんな値でも適合となる

空白区切りトークン (Space-separated tokens) と異なり、unorderedまたはordered Comma-separated tokensの記載は見当たらないが、split a string on commasのアルゴリズムにはLet tokens be an ordered list of tokens, initially empty.と書かれているので内部的には順序を保持した状態のトークンに分割される

また、仕様に制約として記述はないがsplit a string on commasのアルゴリズム上、emptyのトークンが1つだけのカンマ区切りトークンは記載できないものと思われる (""は0個のトークンとなり、","は2つのemptyのトークンとなるため)

2.4.9. References (参照)

Type型の要素に対する妥当なハッシュ名による参照 (valid hash-name reference) は、1文字の # (U+0023 "#" NUMBER SIGN) に続く、文書内のtype型の要素のname属性の値と正確に一致する文字列です

Type型の要素に対するハッシュ名による参照の解析規則は、コンテキストノードから解析範囲 (scope) が与えられた場合次の通りです

  1. 解析対象の文字列に # (U+0023 "#" NUMBER SIGN) が含まれていないか、文字列の最初の文字が最後の文字である場合、null を返却して処理を中断する
  2. 解析対象の文字列の # (U+0023 "#" NUMBER SIGN) の直後の文字から最後の文字までを文字列 s とする
  3. 文字列 s と大文字小文字を区別する (case-sensitive>) 比較で同一の値を持つid属性か、文字列 s と互換活字状態を区別しない (compatibility caseless) 比較で同一の値を持つname属性を持つ、解析範囲 (scope) をルートとした木構造の順序 (tree order)で最初の type 型を持つ要素を返す

自分で翻訳しておいて何ですが、何言っているかさっぱり分からない

文脈から、そのHTMLのURL末尾に#とname属性やid属性の値を記述すると、その属性を持つ要素をアンカーとして参照できる奴なのは分かるのだが

2.4.10. Media queries (メディアクエリー)

妥当なメディアクエリーリスト (valid media query list) の文字列は、Media Queriesの仕様の<media-query-list>製造物に一致するものである

空文字列、空白文字 (space characters) のみの文字列、メディアクエリーの仕様で定義されたユーザーの環境に一致するメディアクエリーリストの何れかに一致する場合、文字列はユーザの環境に一致する

自分で翻訳しておいて何ですが、何言っているかさっぱり分からない、その2

とりあえず、Syntaxの文脈なので Media Queries 参照

更に3. Syntax - Media Queries中でThe media query syntax is described in terms of the CSS2 grammar. As such, rules not defined here are defined in CSS2. The media_query_list production defined below replaces the media_list production from CSS2. [CSS21] と書かれているので更に 7.Media types - CSS2.1 も参照

HTML5.2の見出し毎の内容を雑にまとめる、2.3. Case-sensitivity and string comparison (大文字と小文字及び文字列の比較)

HTML

2. Common infrastructure (共通基盤) の中の 2.3. Case-sensitivity and string comparison (大文字と小文字及び文字列の比較) について

仕様の範囲は短めですが、compatibility caseless が理解できずかなりの時間を費やしています

そしても結局理解できていません

内容についてはあくまで初学者の覚書ですので、正式な仕様はW3CのHTML5.2を確認してください

また、勉強のため、各仕様の邦訳文書、解説文書を読まずに自分で翻訳して覚書を書き終わってから答え合わせとして邦訳文書を参照するようにしています

このため、多くの訳語が一般的な訳と異なっていますのでご注意ください

2.3. Case-sensitivity and string comparison (大文字と小文字及び文字列の比較)

大文字小文字を区別する (case-sensitive) と言うときは厳密に区別し、大文字小文字を区別しない (ASCII case-insensitive) と言うときは大文字小文字以外を厳密に区別しA-Zの大文字小文字は区別しない

互換活字状態を区別しない (compatibility caseless) は、言語固有の調整をしない (no language-specific tailorings) でUnicodeの互換活字状態を区別しない比較(Unicode compatibility caseless match) を行う

特に指定がない場合、大文字小文字は区別する

ほか、大文字小文字の変換方法についてと、パターンマッチが接頭辞一致である事が書いてある

"互換活字状態を区別しない (compatibility caseless)" について

互換活字状態を区別しない (compatibility caseless) は以下の通りに説明されている

Comparing two strings in a compatibility caseless manner means using the Unicode compatibility caseless match operation to compare the two strings, with no language-specific tailorings. [UNICODE]

木俣の直訳は以下の通り

2つの文字列を互換活字状態を区別しない (compatibility caseless) で比較するとは、言語固有の調整をしない (no language-specific tailorings) でUnicodeの互換活字状態を区別しない比較 (Unicode compatibility caseless match) を行う事を意味する

なるほど、さっぱりわからん

で、調べた結果、おそらく言語特性による上位プロトコルのカスタマイズがされていない、つまり、Unicodeのデフォルトのアルゴリズムで、UnicodeのCharacter Names Listで等価とされる文字を一致とする比較を行う意味であろうと思われる

以下、Unicodeの仕様の調査の経緯 (というか、羅列) を書くが、で確証は全くない

  1. Compatibility caselessの意味を調べるためGlossary of Unicode Termsで compatibility を引く

    Compatibility. (1) Consistency with existing practice or preexisting character encoding standards. (2) Characteristic of a normative mapping and form of equivalence specified in Section 3.7. Decomposition.

  2. (2) Section 3.7. Decompositionを更に読む

    Each character has at most one decomposition mapping. The mappings in Section 3.12, Conjoining Jamo Behavior, are canonical mappings. The mappings in the character names list are identified as either canonical or compatibility mappings (see Section 24.1, Character Names List)

  3. Jomoはハングルの音節の関する概念らしいので飛ばして、どうやらmatchingに関係しそうなcompatibility mappingsに関して更にSection 24.1, Character Names Listを読む。

    ここまできてどうやら U+00E5 "å" latin small letter a with ring above は U+0061 "a" latin small letter aとU+030A "̊" combining ring above の合字 "å" に等しいとかそういう話らしいと認識する (ここまで来てあやふやな結論)

  4. 更に no language-specific tailorings の tailorings の意味確認するためGlossary of Unicode Termsで tailoringsを調べると、tailorableがあったのでそちらを参照してみる

    Tailorable. A characteristic of an algorithm for which a higher-level protocol may specify different results than those specified in the algorithm. A tailorable algorithm without actual tailoring is also known as a default algorithm, and the results of an algorithm without tailoring are known as the default results.

  5. 以上により、言語特性による上位プロトコルのカスタマイズがされていない、つまり、Unicodeのデフォルトのアルゴリズムで、UnicodeのCharacter Names Listで等価とされる文字を一致とする比較を行うと言う意味であろうと認識した

なお、compatibility caselessの処理は 2.4.9. References (参照) の中で使われている

The rules for parsing a hash-name reference to an element of type type, given a context node scope, are as follows:

  1. If the string being parsed does not contain a U+0023 NUMBER SIGN character, or if the first such character in the string is the last character in the string, then return null and abort these steps.
  2. Let s be the string from the character immediately after the first U+0023 NUMBER SIGN character in the string being parsed up to the end of that string.
  3. Return the first element of type type in tree order in the subtree rooted at scope that has an id attribute whose value is a case-sensitive match for s or a name attribute whose value is a compatibility caseless match for s.

つまり、ハッシュ名参照ではid属性は大文字小文字を区別する (case-sensitive) 文字比較を行うが、name属性は互換活字状態を区別しない (compatibility caseless) 比較である、と

と言う訳で以下のようなHTML断片を用意してFirefoxとEdgeで確認してみた

<div><a href='#å'><code>U+0061</code> "&#x0061;" latin small letter a + <code>U+030A</code> "&#x030A;"</a></div>

<div><a name='å'><code>U+00E5</code> "&#x00E5;" latin small letter a with ring above</a></div>

私の理解通りの実装であれば、U+00E5とU+0061U+030Aの合字は同じものと見做されHyperLinkによるジャンプが発生するのだが、少なくともFirefox 58 と Microsoft Edge ではジャンプは発生しなかった

わからない