Clarify matching of user input to datalist values

Changes the description of datalist matching to use the term "search within" instead of "substring match", and adds examples of some of the textual variation issues that user agents might consider.

Closes #4814.

source

@@ -49506,11 +49506,12 @@ You cannot submit this form when the field is incorrect.</samp></pre>
 
   <p>The <dfn data-x="concept-input-list">suggestions source element</dfn> is the first element in
   the <span>tree</span> in <span>tree order</span> to have an <span data-x="concept-id">ID</span>
-  equal to the value of the <code data-x="attr-input-list">list</code> attribute, if that element is
-  a <code>datalist</code> element. If there is no <code data-x="attr-input-list">list</code>
+  equal to the value of the <code data-x="attr-input-list">list</code> attribute, if that element
+  is a <code>datalist</code> element. If there is no <code data-x="attr-input-list">list</code>
   attribute, or if there is no element with that <span data-x="concept-id">ID</span>, or if the
   first element with that <span data-x="concept-id">ID</span> is not a <code>datalist</code>
-  element, then there is no <span data-x="concept-input-list">suggestions source element</span>.</p>
+  element, then there is no <span data-x="concept-input-list">suggestions source
+  element</span>.</p>
 
   <p>If there is a <span data-x="concept-input-list">suggestions source element</span>, then, when
   the user agent is allowing the user to edit the <code>input</code> element's <span
@@ -49524,9 +49525,16 @@ You cannot submit this form when the field is incorrect.</samp></pre>
   data-x="concept-input-list">suggestions source element</span> when the number of suggestions is
   large, including only the most relevant ones (e.g. based on the user's input so far). No precise
   threshold is defined, but capping the list at four to seven values is reasonable. If filtering
-  based on the user's input, user agents should use substring matching against both the suggestions'
-  <span data-x="concept-option-label">label</span> and <span
-  data-x="concept-option-value">value</span>.</p>
+  based on the user's input, user agents should search within both the <span
+  data-x="concept-option-label">label</span> and <span data-x="concept-option-value">value</span>
+  of the suggestions for matches. User agents should consider how input variations affect the
+  matching process. Unicode normalization should be applied so that different underlying Unicode
+  code point sequences, caused by different keyboard- or input-specific mechanisms, do not
+  interfere with the matching process. Case variations should be ignored, which may require
+  language-specific case mapping. For examples of these, see <cite>Character Model for the World
+  Wide Web: String Matching</cite>. User agents may also provide other matching features: for
+  illustration, a few examples include matching different forms of kana to each other (or to
+  kanji), ignoring accents, or applying spelling correction. <ref spec=CHARMODNORM></p>
 
   <div class="example">
    <p>This text field allows you to choose a type of JavaScript function.</p>
@@ -125403,6 +125411,9 @@ INSERT INTERFACES HERE
    <dt id="refsCHARMOD">[CHARMOD]</dt>
    <dd>(Non-normative) <cite><a href="https://www.w3.org/TR/charmod/">Character Model for the World Wide Web 1.0: Fundamentals</a></cite>, M. D&uuml;rst, F. Yergeau, R. Ishida, M. Wolf, T. Texin. W3C.</dd>
 
+   <dt id="refsCHARMODNORM">[CHARMODNORM]</dt>
+   <dd>(Non-normative) <cite><a href="https://w3c.github.io/charmod-norm/">Character Model for the World Wide Web: String Matching</a></cite>, A. Phillips. W3C.</dd>
+
    <dt id="refsCOMPOSITE">[COMPOSITE]</dt>
    <dd><cite><a href="https://drafts.fxtf.org/compositing/">Compositing and Blending</a></cite>, R. Cabanier, N. Andronikos. W3C.</dd>