[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