[html5] r7507 - [e] (0) Remove use of the word 'recommended'. Fixing https://www.w3.org/Bugs/Pub [...]
whatwg at whatwg.org
whatwg at whatwg.org
Mon Nov 5 17:06:21 PST 2012
Author: ianh
Date: 2012-11-05 17:06:19 -0800 (Mon, 05 Nov 2012)
New Revision: 7507
Modified:
complete.html
index
source
Log:
[e] (0) Remove use of the word 'recommended'.
Fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=18761
Affected topics: DOM APIs, HTML, HTML Syntax and Parsing, Security, Web Storage
Modified: complete.html
===================================================================
--- complete.html 2012-11-05 21:38:04 UTC (rev 7506)
+++ complete.html 2012-11-06 01:06:19 UTC (rev 7507)
@@ -248,7 +248,7 @@
<header class=head id=head><p><a class=logo href=http://www.whatwg.org/><img alt=WHATWG height=101 src=/images/logo width=101></a></p>
<hgroup><h1 class=allcaps>HTML</h1>
- <h2 class="no-num no-toc">Living Standard — Last Updated 5 November 2012</h2>
+ <h2 class="no-num no-toc">Living Standard — Last Updated 6 November 2012</h2>
</hgroup><dl><dt><strong>Web developer edition:</strong></dt>
<dd><strong><a href=http://developers.whatwg.org/>http://developers.whatwg.org/</a></strong></dd>
<dt>Multiple-page version:</dt>
@@ -308,7 +308,7 @@
<li><a href=#presentational-markup><span class=secno>1.12.1 </span>Presentational markup</a></li>
<li><a href=#syntax-errors><span class=secno>1.12.2 </span>Syntax errors</a></li>
<li><a href=#restrictions-on-content-models-and-on-attribute-values><span class=secno>1.12.3 </span>Restrictions on content models and on attribute values</a></ol></li>
- <li><a href=#recommended-reading><span class=secno>1.13 </span>Recommended reading</a></ol></li>
+ <li><a href=#suggested-reading><span class=secno>1.13 </span>Suggested reading</a></ol></li>
<li><a href=#infrastructure><span class=secno>2 </span>Common infrastructure</a>
<ol>
<li><a href=#terminology><span class=secno>2.1 </span>Terminology</a>
@@ -3154,7 +3154,7 @@
</dd>
- </dl><h3 id=recommended-reading><span class=secno>1.13 </span>Recommended reading</h3>
+ </dl><h3 id=suggested-reading><span class=secno>1.13 </span>Suggested reading</h3>
<p><i>This section is non-normative.</i></p>
@@ -3605,13 +3605,11 @@
non-normative, as are all sections explicitly marked non-normative.
Everything else in this specification is normative.</p>
- <p>The key words "MUST", "MUST NOT", "REQUIRED", <!--"SHALL", "SHALL
- NOT",--> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
- "OPTIONAL" in the normative parts of this document are to be
- interpreted as described in RFC2119. The key word "OPTIONALLY" in
- the normative parts of this document is to be interpreted with the
- same normative meaning as "MAY" and "OPTIONAL". For readability,
- these words do not appear in all uppercase letters in this
+ <p>The key words "MUST", "MUST NOT", "REQUIRED", <!--"SHALL", "SHALL NOT",--> "SHOULD", "SHOULD
+ NOT", <!--"RECOMMENDED", "NOT RECOMMENDED",--> "MAY", and "OPTIONAL" in the normative parts of
+ this document are to be interpreted as described in RFC2119. The key word "OPTIONALLY" in the
+ normative parts of this document is to be interpreted with the same normative meaning as "MAY" and
+ "OPTIONAL". For readability, these words do not appear in all uppercase letters in this
specification. <a href=#refsRFC2119>[RFC2119]</a></p>
<div class=impl>
@@ -26213,16 +26211,13 @@
known to the author, such as documents on a Web site, e-mails sent
to public mailing lists, or software documentation.</i></p>
- <p>When an image is included in a private communication (such as an
- HTML e-mail) aimed at a specific person who is known to be able to
- view images, the <code title=attr-img-alt><a href=#attr-img-alt>alt</a></code> attribute may
- be omitted. However, even in such cases it is strongly recommended
- that alternative text be included (as appropriate according to the
- kind of image involved, as described in the above entries), so that
- the e-mail is still usable should the user use a mail client that
- does not support images, or should the document be forwarded on to
- other users whose abilities might not include easily seeing
- images.</p>
+ <p>When an image is included in a private communication (such as an HTML e-mail) aimed at a
+ specific person who is known to be able to view images, the <code title=attr-img-alt><a href=#attr-img-alt>alt</a></code>
+ attribute may be omitted. However, even in such cases authors are strongly urged to include
+ alternative text (as appropriate according to the kind of image involved, as described in the
+ above entries), so that the e-mail is still usable should the user use a mail client that does not
+ support images, or should the document be forwarded on to other users whose abilities might not
+ include easily seeing images.</p>
@@ -60707,9 +60702,8 @@
<a href=#as-a-download>as a download</a>, it should select one using the following
algorithm.</p>
- <p class=warning>This algorithm is intended to mitigate security
- dangers involved in downloading files from untrusted sites, and user
- agents are strongly recommended to follow it.</p> <!-- but it's
+ <p class=warning>This algorithm is intended to mitigate security dangers involved in downloading
+ files from untrusted sites, and user agents are strongly urged to follow it.</p> <!-- but it's
optional, since it's not really an interoperability issue -->
<ol><li><p>Let <var title="">filename</var> be the void value.</li>
@@ -62434,7 +62428,7 @@
<h4 id=footnotes><span class=secno>4.13.5 </span>Footnotes</h4>
<p>HTML does not have a dedicated mechanism for marking up
- footnotes. Here are the recommended alternatives.</p>
+ footnotes. Here are the suggested alternatives.</p>
<hr><p>For short inline annotations, the <code title=attr-title><a href=#attr-title>title</a></code> attribute could <!-- SHOULD, modulo
title-warning --> be used.</p>
@@ -77453,11 +77447,10 @@
trivially tracked, and would allow user information, even in secure
connections, to be collected.</p>
- <p><strong>Hijacking defaults.</strong> It is strongly recommended
- that user agents do not automatically change any defaults, as this
- could lead the user to send data to remote hosts that the user is
- not expecting. New handlers registering themselves should never
- automatically cause those sites to be used.</p>
+ <p><strong>Hijacking defaults.</strong> User agents are strongly urged to not automatically change
+ any defaults, as this could lead the user to send data to remote hosts that the user is not
+ expecting. New handlers registering themselves should never automatically cause those sites to be
+ used.</p>
<p><strong>Registration spamming.</strong> User agents should
consider the possibility that a site will attempt to register a
@@ -87261,10 +87254,8 @@
title="dom-Storage-setItem">setItem()</code> call, the method will
throw an exception.</p>-->
- <p>A mostly arbitrary limit of five megabytes per
- <a href=#origin>origin</a> is recommended. Implementation feedback is
- welcome and will be used to update this suggestion in the
- future.</p>
+ <p>A mostly arbitrary limit of five megabytes per <a href=#origin>origin</a> is suggested. Implementation
+ feedback is welcome and will be used to update this suggestion in the future.</p>
<h3 id=privacy><span class=secno>11.4 </span>Privacy</h3>
@@ -87417,12 +87408,10 @@
<h4 id=cross-directory-attacks><span class=secno>11.5.2 </span>Cross-directory attacks</h4>
- <p>Different authors sharing one host name, for example users
- hosting content on <code>geocities.com</code>, all share one local
- storage object. There is no feature to restrict the access by
- pathname. Authors on shared hosts are therefore recommended to avoid
- using these features, as it would be trivial for other authors to
- read the data and overwrite it.</p>
+ <p>Different authors sharing one host name, for example users hosting content on
+ <code>geocities.com</code>, all share one local storage object. There is no feature to restrict
+ the access by pathname. Authors on shared hosts are therefore urged to avoid using these features,
+ as it would be trivial for other authors to read the data and overwrite it.</p>
<p class=note>Even if a path-restriction feature was made
available, the usual DOM scripting security model would make it
@@ -89177,11 +89166,11 @@
<hr><p>User agents must not support the CESU-8, UTF-7, BOCU-1 and SCSU
encodings. <a href=#refsCESU8>[CESU8]</a> <a href=#refsUTF7>[UTF7]</a> <a href=#refsBOCU1>[BOCU1]</a> <a href=#refsSCSU>[SCSU]</a></p>
- <p>Support for encodings based on EBCDIC is not recommended. This
- encoding is rarely used for publicly-facing Web content.</p>
+ <p>Support for encodings based on EBCDIC is discouraged. This encoding is rarely used for
+ publicly-facing Web content.</p>
- <p>Support for UTF-32 is not recommended. This encoding is rarely
- used, and frequently implemented incorrectly.</p>
+ <p>Support for UTF-32 is also discouraged. This encoding is rarely used, and frequently
+ implemented incorrectly.</p>
<p class=note>This specification does not make any attempt to
support EBCDIC-based encodings and UTF-32 in its algorithms; support
@@ -101039,8 +101028,7 @@
<meta name="eGMS.subject.keyword" scheme="LGCL" content="Abandoned vehicles">
<meta name="eGMS.subject.keyword" scheme="ORLY" content="Mah car: kthxbye"></pre>
- <p>The recommended processing of this markup, however, would be
- equivalent to the following:</p>
+ <p>The suggested processing of this markup, however, would be equivalent to the following:</p>
<pre><meta name="eGMS.subject.keyword" content="Abandoned vehicles">
<meta name="eGMS.subject.keyword" content="Mah car: kthxbye"></pre>
Modified: index
===================================================================
--- index 2012-11-05 21:38:04 UTC (rev 7506)
+++ index 2012-11-06 01:06:19 UTC (rev 7507)
@@ -248,7 +248,7 @@
<header class=head id=head><p><a class=logo href=http://www.whatwg.org/><img alt=WHATWG height=101 src=/images/logo width=101></a></p>
<hgroup><h1 class=allcaps>HTML</h1>
- <h2 class="no-num no-toc">Living Standard — Last Updated 5 November 2012</h2>
+ <h2 class="no-num no-toc">Living Standard — Last Updated 6 November 2012</h2>
</hgroup><dl><dt><strong>Web developer edition:</strong></dt>
<dd><strong><a href=http://developers.whatwg.org/>http://developers.whatwg.org/</a></strong></dd>
<dt>Multiple-page version:</dt>
@@ -308,7 +308,7 @@
<li><a href=#presentational-markup><span class=secno>1.12.1 </span>Presentational markup</a></li>
<li><a href=#syntax-errors><span class=secno>1.12.2 </span>Syntax errors</a></li>
<li><a href=#restrictions-on-content-models-and-on-attribute-values><span class=secno>1.12.3 </span>Restrictions on content models and on attribute values</a></ol></li>
- <li><a href=#recommended-reading><span class=secno>1.13 </span>Recommended reading</a></ol></li>
+ <li><a href=#suggested-reading><span class=secno>1.13 </span>Suggested reading</a></ol></li>
<li><a href=#infrastructure><span class=secno>2 </span>Common infrastructure</a>
<ol>
<li><a href=#terminology><span class=secno>2.1 </span>Terminology</a>
@@ -3154,7 +3154,7 @@
</dd>
- </dl><h3 id=recommended-reading><span class=secno>1.13 </span>Recommended reading</h3>
+ </dl><h3 id=suggested-reading><span class=secno>1.13 </span>Suggested reading</h3>
<p><i>This section is non-normative.</i></p>
@@ -3605,13 +3605,11 @@
non-normative, as are all sections explicitly marked non-normative.
Everything else in this specification is normative.</p>
- <p>The key words "MUST", "MUST NOT", "REQUIRED", <!--"SHALL", "SHALL
- NOT",--> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
- "OPTIONAL" in the normative parts of this document are to be
- interpreted as described in RFC2119. The key word "OPTIONALLY" in
- the normative parts of this document is to be interpreted with the
- same normative meaning as "MAY" and "OPTIONAL". For readability,
- these words do not appear in all uppercase letters in this
+ <p>The key words "MUST", "MUST NOT", "REQUIRED", <!--"SHALL", "SHALL NOT",--> "SHOULD", "SHOULD
+ NOT", <!--"RECOMMENDED", "NOT RECOMMENDED",--> "MAY", and "OPTIONAL" in the normative parts of
+ this document are to be interpreted as described in RFC2119. The key word "OPTIONALLY" in the
+ normative parts of this document is to be interpreted with the same normative meaning as "MAY" and
+ "OPTIONAL". For readability, these words do not appear in all uppercase letters in this
specification. <a href=#refsRFC2119>[RFC2119]</a></p>
<div class=impl>
@@ -26213,16 +26211,13 @@
known to the author, such as documents on a Web site, e-mails sent
to public mailing lists, or software documentation.</i></p>
- <p>When an image is included in a private communication (such as an
- HTML e-mail) aimed at a specific person who is known to be able to
- view images, the <code title=attr-img-alt><a href=#attr-img-alt>alt</a></code> attribute may
- be omitted. However, even in such cases it is strongly recommended
- that alternative text be included (as appropriate according to the
- kind of image involved, as described in the above entries), so that
- the e-mail is still usable should the user use a mail client that
- does not support images, or should the document be forwarded on to
- other users whose abilities might not include easily seeing
- images.</p>
+ <p>When an image is included in a private communication (such as an HTML e-mail) aimed at a
+ specific person who is known to be able to view images, the <code title=attr-img-alt><a href=#attr-img-alt>alt</a></code>
+ attribute may be omitted. However, even in such cases authors are strongly urged to include
+ alternative text (as appropriate according to the kind of image involved, as described in the
+ above entries), so that the e-mail is still usable should the user use a mail client that does not
+ support images, or should the document be forwarded on to other users whose abilities might not
+ include easily seeing images.</p>
@@ -60707,9 +60702,8 @@
<a href=#as-a-download>as a download</a>, it should select one using the following
algorithm.</p>
- <p class=warning>This algorithm is intended to mitigate security
- dangers involved in downloading files from untrusted sites, and user
- agents are strongly recommended to follow it.</p> <!-- but it's
+ <p class=warning>This algorithm is intended to mitigate security dangers involved in downloading
+ files from untrusted sites, and user agents are strongly urged to follow it.</p> <!-- but it's
optional, since it's not really an interoperability issue -->
<ol><li><p>Let <var title="">filename</var> be the void value.</li>
@@ -62434,7 +62428,7 @@
<h4 id=footnotes><span class=secno>4.13.5 </span>Footnotes</h4>
<p>HTML does not have a dedicated mechanism for marking up
- footnotes. Here are the recommended alternatives.</p>
+ footnotes. Here are the suggested alternatives.</p>
<hr><p>For short inline annotations, the <code title=attr-title><a href=#attr-title>title</a></code> attribute could <!-- SHOULD, modulo
title-warning --> be used.</p>
@@ -77453,11 +77447,10 @@
trivially tracked, and would allow user information, even in secure
connections, to be collected.</p>
- <p><strong>Hijacking defaults.</strong> It is strongly recommended
- that user agents do not automatically change any defaults, as this
- could lead the user to send data to remote hosts that the user is
- not expecting. New handlers registering themselves should never
- automatically cause those sites to be used.</p>
+ <p><strong>Hijacking defaults.</strong> User agents are strongly urged to not automatically change
+ any defaults, as this could lead the user to send data to remote hosts that the user is not
+ expecting. New handlers registering themselves should never automatically cause those sites to be
+ used.</p>
<p><strong>Registration spamming.</strong> User agents should
consider the possibility that a site will attempt to register a
@@ -87261,10 +87254,8 @@
title="dom-Storage-setItem">setItem()</code> call, the method will
throw an exception.</p>-->
- <p>A mostly arbitrary limit of five megabytes per
- <a href=#origin>origin</a> is recommended. Implementation feedback is
- welcome and will be used to update this suggestion in the
- future.</p>
+ <p>A mostly arbitrary limit of five megabytes per <a href=#origin>origin</a> is suggested. Implementation
+ feedback is welcome and will be used to update this suggestion in the future.</p>
<h3 id=privacy><span class=secno>11.4 </span>Privacy</h3>
@@ -87417,12 +87408,10 @@
<h4 id=cross-directory-attacks><span class=secno>11.5.2 </span>Cross-directory attacks</h4>
- <p>Different authors sharing one host name, for example users
- hosting content on <code>geocities.com</code>, all share one local
- storage object. There is no feature to restrict the access by
- pathname. Authors on shared hosts are therefore recommended to avoid
- using these features, as it would be trivial for other authors to
- read the data and overwrite it.</p>
+ <p>Different authors sharing one host name, for example users hosting content on
+ <code>geocities.com</code>, all share one local storage object. There is no feature to restrict
+ the access by pathname. Authors on shared hosts are therefore urged to avoid using these features,
+ as it would be trivial for other authors to read the data and overwrite it.</p>
<p class=note>Even if a path-restriction feature was made
available, the usual DOM scripting security model would make it
@@ -89177,11 +89166,11 @@
<hr><p>User agents must not support the CESU-8, UTF-7, BOCU-1 and SCSU
encodings. <a href=#refsCESU8>[CESU8]</a> <a href=#refsUTF7>[UTF7]</a> <a href=#refsBOCU1>[BOCU1]</a> <a href=#refsSCSU>[SCSU]</a></p>
- <p>Support for encodings based on EBCDIC is not recommended. This
- encoding is rarely used for publicly-facing Web content.</p>
+ <p>Support for encodings based on EBCDIC is discouraged. This encoding is rarely used for
+ publicly-facing Web content.</p>
- <p>Support for UTF-32 is not recommended. This encoding is rarely
- used, and frequently implemented incorrectly.</p>
+ <p>Support for UTF-32 is also discouraged. This encoding is rarely used, and frequently
+ implemented incorrectly.</p>
<p class=note>This specification does not make any attempt to
support EBCDIC-based encodings and UTF-32 in its algorithms; support
@@ -101039,8 +101028,7 @@
<meta name="eGMS.subject.keyword" scheme="LGCL" content="Abandoned vehicles">
<meta name="eGMS.subject.keyword" scheme="ORLY" content="Mah car: kthxbye"></pre>
- <p>The recommended processing of this markup, however, would be
- equivalent to the following:</p>
+ <p>The suggested processing of this markup, however, would be equivalent to the following:</p>
<pre><meta name="eGMS.subject.keyword" content="Abandoned vehicles">
<meta name="eGMS.subject.keyword" content="Mah car: kthxbye"></pre>
Modified: source
===================================================================
--- source 2012-11-05 21:38:04 UTC (rev 7506)
+++ source 2012-11-06 01:06:19 UTC (rev 7507)
@@ -2000,7 +2000,7 @@
- <h3>Recommended reading</h3>
+ <h3>Suggested reading</h3>
<!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
@@ -2500,13 +2500,11 @@
non-normative, as are all sections explicitly marked non-normative.
Everything else in this specification is normative.</p>
- <p>The key words "MUST", "MUST NOT", "REQUIRED", <!--"SHALL", "SHALL
- NOT",--> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
- "OPTIONAL" in the normative parts of this document are to be
- interpreted as described in RFC2119. The key word "OPTIONALLY" in
- the normative parts of this document is to be interpreted with the
- same normative meaning as "MAY" and "OPTIONAL". For readability,
- these words do not appear in all uppercase letters in this
+ <p>The key words "MUST", "MUST NOT", "REQUIRED", <!--"SHALL", "SHALL NOT",--> "SHOULD", "SHOULD
+ NOT", <!--"RECOMMENDED", "NOT RECOMMENDED",--> "MAY", and "OPTIONAL" in the normative parts of
+ this document are to be interpreted as described in RFC2119. The key word "OPTIONALLY" in the
+ normative parts of this document is to be interpreted with the same normative meaning as "MAY" and
+ "OPTIONAL". For readability, these words do not appear in all uppercase letters in this
specification. <a href="#refsRFC2119">[RFC2119]</a></p>
<div class="impl">
@@ -28218,16 +28216,13 @@
known to the author, such as documents on a Web site, e-mails sent
to public mailing lists, or software documentation.</i></p>
- <p>When an image is included in a private communication (such as an
- HTML e-mail) aimed at a specific person who is known to be able to
- view images, the <code title="attr-img-alt">alt</code> attribute may
- be omitted. However, even in such cases it is strongly recommended
- that alternative text be included (as appropriate according to the
- kind of image involved, as described in the above entries), so that
- the e-mail is still usable should the user use a mail client that
- does not support images, or should the document be forwarded on to
- other users whose abilities might not include easily seeing
- images.</p>
+ <p>When an image is included in a private communication (such as an HTML e-mail) aimed at a
+ specific person who is known to be able to view images, the <code title="attr-img-alt">alt</code>
+ attribute may be omitted. However, even in such cases authors are strongly urged to include
+ alternative text (as appropriate according to the kind of image involved, as described in the
+ above entries), so that the e-mail is still usable should the user use a mail client that does not
+ support images, or should the document be forwarded on to other users whose abilities might not
+ include easily seeing images.</p>
@@ -71176,9 +71171,8 @@
<span>as a download</span>, it should select one using the following
algorithm.</p>
- <p class="warning">This algorithm is intended to mitigate security
- dangers involved in downloading files from untrusted sites, and user
- agents are strongly recommended to follow it.</p> <!-- but it's
+ <p class="warning">This algorithm is intended to mitigate security dangers involved in downloading
+ files from untrusted sites, and user agents are strongly urged to follow it.</p> <!-- but it's
optional, since it's not really an interoperability issue -->
<ol>
@@ -73107,7 +73101,7 @@
<h4 id="footnotes">Footnotes</h4>
<p>HTML does not have a dedicated mechanism for marking up
- footnotes. Here are the recommended alternatives.</p>
+ footnotes. Here are the suggested alternatives.</p>
<hr>
@@ -90738,11 +90732,10 @@
trivially tracked, and would allow user information, even in secure
connections, to be collected.</p>
- <p><strong>Hijacking defaults.</strong> It is strongly recommended
- that user agents do not automatically change any defaults, as this
- could lead the user to send data to remote hosts that the user is
- not expecting. New handlers registering themselves should never
- automatically cause those sites to be used.</p>
+ <p><strong>Hijacking defaults.</strong> User agents are strongly urged to not automatically change
+ any defaults, as this could lead the user to send data to remote hosts that the user is not
+ expecting. New handlers registering themselves should never automatically cause those sites to be
+ used.</p>
<p><strong>Registration spamming.</strong> User agents should
consider the possibility that a site will attempt to register a
@@ -101496,10 +101489,8 @@
title="dom-Storage-setItem">setItem()</code> call, the method will
throw an exception.</p>-->
- <p>A mostly arbitrary limit of five megabytes per
- <span>origin</span> is recommended. Implementation feedback is
- welcome and will be used to update this suggestion in the
- future.</p>
+ <p>A mostly arbitrary limit of five megabytes per <span>origin</span> is suggested. Implementation
+ feedback is welcome and will be used to update this suggestion in the future.</p>
<h4>Privacy</h4>
@@ -101658,12 +101649,10 @@
<h5>Cross-directory attacks</h5>
- <p>Different authors sharing one host name, for example users
- hosting content on <code>geocities.com</code>, all share one local
- storage object. There is no feature to restrict the access by
- pathname. Authors on shared hosts are therefore recommended to avoid
- using these features, as it would be trivial for other authors to
- read the data and overwrite it.</p>
+ <p>Different authors sharing one host name, for example users hosting content on
+ <code>geocities.com</code>, all share one local storage object. There is no feature to restrict
+ the access by pathname. Authors on shared hosts are therefore urged to avoid using these features,
+ as it would be trivial for other authors to read the data and overwrite it.</p>
<p class="note">Even if a path-restriction feature was made
available, the usual DOM scripting security model would make it
@@ -103706,11 +103695,11 @@
href="#refsUTF7">[UTF7]</a> <a href="#refsBOCU1">[BOCU1]</a> <a
href="#refsSCSU">[SCSU]</a></p>
- <p>Support for encodings based on EBCDIC is not recommended. This
- encoding is rarely used for publicly-facing Web content.</p>
+ <p>Support for encodings based on EBCDIC is discouraged. This encoding is rarely used for
+ publicly-facing Web content.</p>
- <p>Support for UTF-32 is not recommended. This encoding is rarely
- used, and frequently implemented incorrectly.</p>
+ <p>Support for UTF-32 is also discouraged. This encoding is rarely used, and frequently
+ implemented incorrectly.</p>
<p class="note">This specification does not make any attempt to
support EBCDIC-based encodings and UTF-32 in its algorithms; support
@@ -118253,8 +118242,7 @@
<meta name="eGMS.subject.keyword" scheme="LGCL" content="Abandoned vehicles">
<meta name="eGMS.subject.keyword" scheme="ORLY" content="Mah car: kthxbye"></pre>
- <p>The recommended processing of this markup, however, would be
- equivalent to the following:</p>
+ <p>The suggested processing of this markup, however, would be equivalent to the following:</p>
<pre><meta name="eGMS.subject.keyword" content="Abandoned vehicles">
<meta name="eGMS.subject.keyword" content="Mah car: kthxbye"></pre>
More information about the Commit-Watchers
mailing list