仕様書
- [1] HTML Standard ( 版) http://www.whatwg.org/specs/web-apps/current-work/#serializing-xhtml-fragments
- [4] DOM Parsing and Serialization Standard ( 版) http://domparsing.spec.whatwg.org/#serializing
[2] >>1 では Document や Element の子孫の直列化が規定されています。
>>4 では各種 Node の直列化が規定されています。
誤り処理
[3] >>1 は名前空間整形式にならない場合例外を投げると規定しています。また適宜名前空間の fixup
を行うよう指示しています。 >>4 でも例外は投げられますが名前空間の fixup はされないことがあります。
[5] Chrome はそれなりに名前空間の fixup を行なっているようです。しかし正しく直列化できない場合であっても例外は投げないようです。
[6] HTMLの直列化との整合性を考慮するなら、例外は投げないで無理に直列化する方が一貫した動作ではあります。
もちろんその場合再度構文解析しても元には戻りませんが。名前空間 fixup
[7] Chrome は XML文書での innerHTML 取得の時、
- 元の要素・属性の QName をそのまま使います。
- 名前空間接頭辞が宣言されていなければ、初出の属性の直後 (要素名なら最初) に追加の属性として名前空間宣言が出力されます。
- 名前空間接頭辞のない属性なら、
xmlns になります。 - その結果属性が重複したり、他の QName の解釈に影響してしまったりしても気にしません。
- 同じ名前空間URLで他の名前空間接頭辞が宣言されているかどうかはこれに影響しません。
[8] Firefox は XML文書での innerHTML 取得の時、
- 元の名前空間接頭辞が有効ならそのまま使います。
- そうでなければ同じ名前空間URLで最後に宣言された名前空間接頭辞があれば使います。
- 要素の名前空間接頭辞が宣言されていなければ、最初に追加の属性として名前空間宣言が出力されます。
- 属性の名前空間接頭辞が無いか宣言されていなければ、
a0、a1、... と順に割り振られた名前空間接頭辞が使われます。属性の直後に追加の属性として名前空間宣言が出力されます。
- null名前空間の要素に
xmlns 属性で名前空間URLが指定されている場合、最上位の要素ならその属性は削除され、他の既定名前空間がある要素の子要素なら xmlns="" が追加されます。 - 要素の名前空間URLが名前空間属性と矛盾するなら、
a0、... が割り振られます。
文字参照
[9] Chrome の innerHTML は、
属性値中の<、&、>、" を文字参照にします。
それ以外の U+00A0 や C0 や C1 やサロゲートや非文字はそのままにします。
[10] つまり C0 が含まれると整形式になりません。[11] Serialize non-well-formed documents too
(annevk著, )
https://github.com/whatwg/xhr/commit/59c9cd9ae31fc8fafd1c327f2d2a1ca1e88da28f
[12] XSLT and XQuery Serialization 3.1
()
https://www.w3.org/TR/2017/REC-xslt-xquery-serialization-31-20170321/#xml-output