Update Mutated XSS chapter to reference the current API. (#219)

* Update text.

* Fix grammar error.

* Review feedback.

index.bs

@@ -853,20 +853,18 @@ into a different parent element. An example for carrying out such an attack
 is by relying on the change of parsing behavior for foreign content or
 mis-nested tags.
 
-The Sanitizer API offers help against Mutated XSS, but relies on some amount of
-cooperation by the developers. The `sanitize()` function does not handle strings
-and is therefore unaffected. The `setHTML` function combines sanitization
-with DOM modification and can implicitly apply the correct context. The
-`sanitizeFor()` function combines parsing and sanitization, and relies on the
-developer to supply the correct context for the eventual application of its
-result.
-
-If the data to be sanitized is available as a node tree, we encourage authors
-to use the `sanitize()` function of the API which returns a
-DocumentFragment and avoids risks that come with serialization and additional
-parsing. Directly operating on a fragment after sanitization also comes with a
-performance benefit, as the cost of additional serialization and parsing is
-avoided.
+The Sanitizer API offers only functions that turn a string into a node tree.
+The context is supplied implicitly by all sanitizer functions:
+`Element.setHTML()` uses the current element; `Document.parseHTML()` creates a
+new document. Therefore Sanitizer API is not directly affected by mutated XSS.
+
+If a developer were to retrieve a sanitized node tree as a string, e.g. via
+`.innerHTML`, and to then parse it again then mutated XSS may occur.
+We discourage this practice. If processing or passing of HTML as a
+string should be necessary after all, then any string should be considered
+untrusted and should be sanitized (again) when inserting it into the DOM. In
+other words, a sanitized and then serialized HTML tree can no
+longer be considered as sanitized.
 
 A more complete treatment of mXSS can be found in [[MXSS]].