Editorial: Clarify what happens to U+0000 chars

This changes updates a non-normative note to clarify that in some cases, the
spec requires parsers to replace U+0000 characters with U+FFFD characters.

Author: sideshowbarker

source

@@ -101391,9 +101391,9 @@ dictionary <dfn>StorageEventInit</dfn> : <span>EventInit</span> {
   <span data-x="parse error">parse errors</span>.</p>
 
   <p class="note">The handling of U+0000 NULL characters varies based on where the characters are
-  found and happens at the later stages of the parsing. In general, they are ignored except where
-  doing so could plausibly introduce an attack vector. This handling is, by necessity, spread across
-  both the tokenization stage and the tree construction stage.</p>
+  found and happens at the later stages of the parsing. They are either ignored or, for security
+  reasons, replaced with a U+FFFD REPLACEMENT CHARACTER. This handling is, by necessity, spread
+  across both the tokenization stage and the tree construction stage.</p>
 
   <p>U+000D CARRIAGE RETURN (CR) characters and U+000A LINE FEED (LF) characters are treated
   specially. Any LF character that immediately follows a CR character must be ignored, and all CR