[css-highlights-api] Rewrap some text

See https://rhodesmill.org/brandon/2012/one-sentence-per-line/

Author: frivoal

css-highlight-api-1/Overview.bs

@@ -464,40 +464,43 @@ Priority of Overlapping Highlights</h4>
 <h4 id=highlight-types>
 Highlight types</h4>
 
-	A [=custom highlight=]'s {{Highlight/type}} attribute is used by authors to specify the semantic
-	meaning of the highlight. This allows assistive technologies to include this meaning when
-	exposing the highlight to users.
-
-	A custom highlight will have a default type of {{HighlightType/highlight}} if its
-	{{Highlight/type}} attribute has not been explicitly set.
-
-	Note: Authors should set a [=custom highlight=]'s {{Highlight/type}} to
-	{{HighlightType/spelling-error}} when that [=custom highlight=] is being used to emphasize
-	misspelled content. Authors should set a [=custom highlight=]'s {{Highlight/type}} to
-	{{HighlightType/grammar-error}} when that [=custom highlight=] is being used to emphasize
-	content that is grammatically incorrect. For all other use cases {{Highlight/type}} should
-	be left as {{HighlightType/highlight}}.
-
-	UAs should make [=custom highlight=]s available to assistive technologies. When exposing a
-	highlight using a given platform accessibility API, UAs should expose the semantic meaning of
-	the highlight as specified by its {{Highlight/type}} attribute with as much specificity as
-	possible for that accessibility API.
-
-	Note: For example, if a platform accessibility API has the capability to express spelling errors
-	and grammar errors specifically, then UAs should use these capabilities to convey the semantics
-	for highlights with {{HighlightType/spelling-error}} and {{HighlightType/spelling-error}}.
-	If an accessibility API only has the capability to express spelling errors, then UAs should
-	convey both highlights with {{HighlightType/spelling-error}} and with
-	{{HighlightType/grammar-error}} using spelling error semantics. If an accessibility API has
-	support for expressing neither spelling errors nor grammar errors, then UAs should expose all
-	highlights as generic {{HighlightType/highlight}} regardless of their actual {{Highlight/type}}.
-
-	Note: This initial set of types was chosen because they are expected to be popular use cases
-	for Highlight API and there is some existing support for expressing their semantics in platform
-	accessibility APIs today. Accessibility APIs currently don't have any way to express the
-	specific semantics of other expected Highlight API use cases. More types may be added to
-	{{HighlightType}} as accessibility APIs gain support for expressing additional popular use
-	cases of Highlight API.
+	A [=custom highlight=]'s {{Highlight/type}} attribute is used by authors
+	to specify the semantic meaning of the highlight.
+	This allows assistive technologies to include this meaning
+	when exposing the highlight to users.
+
+	A custom highlight will have a default type of {{HighlightType/highlight}}
+	if its {{Highlight/type}} attribute has not been explicitly set.
+
+	Note: Authors should set a [=custom highlight=]'s {{Highlight/type}} to {{HighlightType/spelling-error}}
+	when that [=custom highlight=] is being used to emphasize misspelled content.
+	Authors should set a [=custom highlight=]'s {{Highlight/type}} to {{HighlightType/grammar-error}}
+	when that [=custom highlight=] is being used to emphasize content that is grammatically incorrect.
+	For all other use cases {{Highlight/type}} should be left as {{HighlightType/highlight}}.
+
+	UAs should make [=custom highlight=]s available to assistive technologies.
+	When exposing a highlight using a given platform accessibility API,
+	UAs should expose the semantic meaning of the highlight
+	as specified by its {{Highlight/type}} attribute
+	with as much specificity as possible for that accessibility API.
+
+	Note: For example,
+	if a platform accessibility API has the capability to express spelling errors and grammar errors specifically,
+	then UAs should use these capabilities to convey the semantics for highlights
+	with {{HighlightType/spelling-error}} and {{HighlightType/spelling-error}}.
+	If an accessibility API only has the capability to express spelling errors,
+	then UAs should convey both highlights with {{HighlightType/spelling-error}}
+	and with {{HighlightType/grammar-error}} using spelling error semantics.
+	If an accessibility API has support for expressing neither spelling errors nor grammar errors,
+	then UAs should expose all highlights as generic {{HighlightType/highlight}} regardless of their actual {{Highlight/type}}.
+
+	Note: This initial set of types was chosen
+	because they are expected to be popular use cases for Highlight API
+	and there is some existing support for expressing their semantics in platform accessibility APIs today.
+	Accessibility APIs currently don't have any way to express the specific semantics
+	of other expected Highlight API use cases.
+	More types may be added to {{HighlightType}}
+	as accessibility APIs gain support for expressing additional popular use cases of Highlight API.
 
 <h2 id=responding-to-changes>
 Responding to Changes</h2>