[css3-fonts] alter wording based on wg feedback

Author: John Daggett

css3-fonts/Fonts.html

@@ -1255,7 +1255,12 @@ <h3 id=font-style-prop><span class=secno>3.4 </span>Font style: the <a
    always lack italic or oblique faces. Fonts that support a mixture of
    scripts will sometimes omit specific scripts such as Arabic from the set
    of glyphs supported in the italic face. User agents should be careful
-   about making character map assumptions across faces.</p>
+   about making character map assumptions across faces.
+
+  <p class=issue>For synthetic italics in vertical runs of Chinese, Japanese,
+   or Korean text, is there a need to define explicitly the direction of the
+   faux oblique for runs that include a mixture of ideographic and Latin
+   text?</p>
   <!-- prop: font-size -->
 
   <h3 id=font-size-prop><span class=secno>3.5 </span>Font size: the <a
@@ -2889,14 +2894,16 @@ <h3 id=font-family-casing><span class=secno>5.1 </span>Case sensitivity of
    specified by this algorithm uses the case mappings with status field
    ‘<code class=property>C</code>’ or ‘<code class=property>F</code>’
    in the CaseFolding.txt file of the Unicode Character Database.
-   Implementors should take care to verify that a given caseless string
-   comparison implementation uses this precise algorithm and not assume that
-   a given platform string matching routine follows it, as many of these have
-   locale-specific behavior or use some level of string normalization.
-
-  <p>For authors this means that font family names are matched case
-   insensitively, whether or not those names exist in a platform font or in
-   the <code>@font-face</code> rules contained in a stylesheet. Authors
+
+  <p class=note> Implementors should take care to verify that a given
+   caseless string comparison implementation uses this precise algorithm and
+   not assume that a given platform string matching routine follows it, as
+   many of these have locale-specific behavior or use some level of string
+   normalization.
+
+  <p class=note> For authors this means that font family names are matched
+   case insensitively, whether or not those names exist in a platform font or
+   in the <code>@font-face</code> rules contained in a stylesheet. Authors
    should take care to normalize the names they use when using combining
    diacritics, since names containing combining diacritics won't match
    equivalent names that use precomposed characters. For example, a family
@@ -3275,23 +3282,25 @@ <h3 id=language-specific-support><span class=secno>6.2
   <div class=featex><img alt="language specific forms, french"
    src=locl-3.png></div>
 
-  <p>Users agents are required to infer the OpenType language system from the
-   value of the ‘<code class=property>lang</code>’ attribute and use that
-   when selecting and positioning glyphs using an OpenType font. If the
-   ‘<code class=property>lang</code>’ attribute is not defined, the
-   default OpenType language system must be used.
-
-  <p>In some cases it may be necessary to explicitly declare the OpenType
-   language to be used, for example when displaying text in a given language
-   that uses the typographic conventions of another language, or when the
-   font does not explicitly support a given language but supports a language
-   that shares common typographic conventions. The ‘<a
+  <p>If the content language of the element is known, according to the rules
+   of the <a
+   href="http://www.w3.org/TR/CSS21/conform.html#doclanguage">document
+   language</a>, user agents are required to infer the OpenType language
+   system from the content language and use that when selecting and
+   positioning glyphs using an OpenType font.
+
+  <p>For OpenType fonts, in some cases it may be necessary to explicitly
+   declare the OpenType language to be used, for example when displaying text
+   in a given language that uses the typographic conventions of another
+   language or when the font does not explicitly support a given language but
+   supports a language that shares common typographic conventions. The ‘<a
    href="#propdef-font-language-override"><code
    class=property>font-language-override</code></a>’ property is used for
    this purpose.
 
   <p class=issue>Should user agents be allowed to infer the OpenType language
-   or simply use only the default language system?</p>
+   or simply use only the default language system? Do we also need a
+   normative definition of how the script system is inferred?</p>
   <!-- prop: font-kerning -->
 
   <h3 id=font-kerning-prop><span class=secno>6.3 </span>Kerning: the <a
@@ -5645,6 +5654,8 @@ <h3 class=no-num id=recent-changes> Changes from the <a
    <li>Added specification of Unicode caseless matching for font family names
     based on WG resolution
 
+   <li>Include issue of synthetic oblique angle in CJK vertical text runs
+
    <li>Minor editorial tweaks hither and thither
   </ul>
 
@@ -5658,11 +5669,11 @@ <h2 class=no-num id=acknowledgments>Acknowledgments</h2>
    and Unicode variation selectors. The idea for supporting font features by
    using font-variant subproperties originated with Håkon Wium Lie, Adam
    Twardoch and Tal Leming. Elika Etemad supplied some of the initial design
-   ideas for the <code>@font-feature-values</code> rule along with later
-   syntax dithering. Several members of the Google Fonts team provided
-   helpful feedback on font load events, as did Boris Zbarsky, Jonas Sicking
-   and ms2ger. Thanks also to House Industries for allowing the use of Ed
-   Interlock in the discretionary ligatures example.
+   ideas for the <code>@font-feature-values</code> rule. Several members of
+   the Google Fonts team provided helpful feedback on font load events, as
+   did Boris Zbarsky, Jonas Sicking and ms2ger. Thanks also to House
+   Industries for allowing the use of Ed Interlock in the discretionary
+   ligatures example.
 
   <p>A special thanks to Robert Bringhurst for the sublime mind expansion
    that is <em>The Elements of Typographic Style</em>.