Editorial nits suggested by Addison

index.html

@@ -967,7 +967,7 @@ <h5>How to's</h5>
 
 
 <section id="operations" class="topic">
-<h2>Text-based transforms &amp; operations</h2>
+<h2>Text-processing</h2>
 
 <p>In this section:</p>
 	<ul class="summary">
@@ -1126,7 +1126,7 @@ <h5>How to's</h5>
 
 
   <section id="text_case" class="subtopic">
-    <h3> Case Folding</h3>
+    <h3>Case folding</h3>
 
     <p class="advisement" id="text_case_options"><a class="self" href="#text_case_options">&#x200B;</a>Specifications and implementations that define string matching as part of the definition of a format, protocol, or formal language (which might include operations such as parsing, matching, tokenizing, etc.) MUST define the criteria and matching forms used. These MUST be one of: (a) case-sensitive (b) Unicode case-insensitive using Unicode full case-folding (c) ASCII case-insensitive.</p>
 
@@ -1173,7 +1173,7 @@ <h5>How to's</h5>
 
 
 <section id="char_truncation" class="subtopic">
-   <h3>Truncating or Limiting the Length of Strings</h3>
+   <h3>Truncating or limiting the length of strings</h3>
 
     <p>Some specifications, formats, or protocols or their implementations need to specify limits for the size of a given data structure or text field. This could be due to many reasons, such as limits on processing, memory, data structure size, and so forth. When selecting or specifying limits on the length of a given string, specifications or implementations need to ensure that they do not cause corruption in the text.</p>