[61] ネットワークの入出力 (に伴い文字コードの変換が発生するもの) だけでなく、 URL でも USVString が使われています。利用箇所数でいえば USVString のほとんどは URL文字列です。 JavaScript や DOM が符号単位列 (DOMString) ベースである以上 URL にサロゲートが混入する可能性は排除できないのですが、 Ian Hickson は URL の構文解析器で行うべきと主張したのに対し、 Anne は URL の構文解析器の入出力はUnicodeスカラー値列だと定め、 URL を使うあらゆる API のデータ型を USVString に書き換えていきました。 (つまり URL の構文解析器の入力時ではなく、 メソッドの呼び出しや IDL属性の設定器の呼び出しの時点でサロゲートの検査を行うこととしました。)

[62] 内容属性を反映する USVString の IDL属性経由で属性値を設定するとサロゲートの検査が行われ、 setAttribute などを使うと検査が行われません。 サロゲートがそのまま URL Standard の構文解析器に渡るとすると素片識別子部分ならそのまま、 それ以外なら UTF-8パーセント符号化されるはずで、前者の場合サロゲートのまま出力されるはずですが、 Chrome では U+FFFD に置き換わっています。 (Firefox では素片識別子全体がUTF-8パーセント符号化されるので、そもそも URL Standard と動作が違います。) WebIDL レベルで変換しても、結局 URL の構文解析器に渡す直前またはその中でまた検査するのが現実の実装ということになるので、 WebIDL レベルでの変換が本当に必要だったのかに疑問が生じます。