[html5] r1001 - /
whatwg at whatwg.org
whatwg at whatwg.org
Tue Aug 14 03:12:04 PDT 2007
Author: ianh
Date: 2007-08-14 03:12:03 -0700 (Tue, 14 Aug 2007)
New Revision: 1001
Modified:
index
source
Log:
[e] (0) add some red boxes to label controversial stuff as known-controversial
Modified: index
===================================================================
--- index 2007-08-14 09:18:28 UTC (rev 1000)
+++ index 2007-08-14 10:12:03 UTC (rev 1001)
@@ -12275,6 +12275,11 @@
</dl>
<!-- XXX see also http://www.cs.tut.fi/~jkorpela/html/alt.html -->
+ <p class=big-issue>There has been some suggestion that the <code
+ title="">longdesc</code> attribute from HTML4, or some other mechanism
+ that is more powerful than <code title="">alt=""</code>, should be
+ included. This has not yet been considered.
+
<p><strong>User agent requirements</strong>: When the <code
title=attr-img-alt><a href="#alt">alt</a></code> attribute is present and
its value is the empty string, the image supplements the surrounding
@@ -18161,6 +18166,11 @@
title=dom-tr-cells><a href="#cells">cells</a></code> collection. If there
is no such parent element, then the attribute must return 0.
+ <p class=big-issue>There has been some suggestion that the <code
+ title="">headers</code> attribute from HTML4, or some other mechanism that
+ is more powerful than <code title="">scope=""</code>, should be included.
+ This has not yet been considered.
+
<h4 id=the-th><span class=secno>3.15.10. </span>The <dfn
id=th><code>th</code></dfn> element</h4>
<!-- element has no special category -->
@@ -22976,6 +22986,16 @@
href="#title">title</a></code> attributes to mark up semantics common to a
group of consecutive elements.
+ <p class=big-issue>Allowing <code><a href="#div">div</a></code> elements to
+ contain inline elements makes it easy for authors to abuse <code><a
+ href="#div">div</a></code>, using it with the <code>class=""</code>
+ attribute to the point of not having any other elements in the markup.
+ This is a disaster from an accessibility point of view, and it would be
+ nice if we could somehow make such pages non-compliant without preventing
+ people from using <code><a href="#div">div</a></code>s as the extension
+ mechanism that they are, to handle things the spec can't otherwise do
+ (like making new widgets).
+
<h2 id=web-browsers><span class=secno>4. </span>Web browsers</h2>
<p>This section describes features that apply most directly to Web
@@ -41274,6 +41294,12 @@
"<code title="">(WYSIWYG editor)</code>". Non-WYSIWYG authoring tools must
not include this string in their generator string.
+ <p class=big-issue>This entire section will probably be dropped. The intent
+ of this section was to allow a way for WYSIWYG editors, which aren't going
+ to use semantic markup, to still write conforming documents, while not
+ letting it be ok for hand-coding authors to not use semantic markup. We
+ still need some sort of solution to this, but it's not clear what it is.
+
<h4 id=the-font><span class=secno>9.1.2. </span>The <dfn
id=font><code>font</code></dfn> element</h4>
@@ -41314,6 +41340,14 @@
};</pre>
</dl>
+ <p class=big-issue>This entire section will probably be dropped. The intent
+ of this section was to allow a way for WYSIWYG editors, which don't have
+ enough information to use the "real" "semantic" elements, to still make
+ HTML pages without abusing those semantic elements (since abusing elements
+ is even worse than not using them in the first place). We have still got
+ to find a solution to this, while not letting it be ok for hand-coding
+ authors to abuse the style="" attribute.
+
<p>The <code><a href="#font">font</a></code> element doesn't represent
anything. It must not be used except by <a href="#wysiwyg1">WYSIWYG
editors</a>, which may use it to achieve presentational affects. Even
@@ -41362,7 +41396,12 @@
<p>The <dfn id=style0 title=attr-font-style><code>style</code></dfn>
attribute, if specified, must contain only a list of zero or more
- semicolon-separated (;) CSS declarations. <a href="#refsCSS21">[CSS21]</a></p>
+ semicolon-separated (;) CSS declarations. <a href="#refsCSS21">[CSS21]</a>
+
+ <p class=big-issue>We probably need to move this attribute to more
+ elements, maybe even all of them, though if we do that we really should
+ find a way to strongly discourage its use (and the use of its DOM
+ attribute) for non-WYSIWYG authors.</p>
<!-- XXX deal with each of the use cases in this:
http://lists.w3.org/Archives/Public/www-html/2003Jan/0277.html -->
Modified: source
===================================================================
--- source 2007-08-14 09:18:28 UTC (rev 1000)
+++ source 2007-08-14 10:12:03 UTC (rev 1001)
@@ -10297,6 +10297,12 @@
<!-- XXX see also http://www.cs.tut.fi/~jkorpela/html/alt.html -->
+ <p class="big-issue">There has been some suggestion that the <code
+ title="">longdesc</code> attribute from HTML4, or some other
+ mechanism that is more powerful than <code title="">alt=""</code>,
+ should be included. This has not yet been considered.</p>
+
+
<p><strong>User agent requirements</strong>: When the <code
title="attr-img-alt">alt</code> attribute is present and its value
is the empty string, the image supplements the surrounding
@@ -15735,7 +15741,12 @@
there is no such parent element, then the attribute must return
0.</p>
+ <p class="big-issue">There has been some suggestion that the <code
+ title="">headers</code> attribute from HTML4, or some other
+ mechanism that is more powerful than <code title="">scope=""</code>,
+ should be included. This has not yet been considered.</p>
+
<h4>The <dfn><code>th</code></dfn> element</h4>
<!-- element has no special category -->
@@ -20621,10 +20632,20 @@
common to a group of consecutive elements.</p>
+ <p class="big-issue">Allowing <code>div</code> elements to contain
+ inline elements makes it easy for authors to abuse <code>div</code>,
+ using it with the <code>class=""</code> attribute to the point of
+ not having any other elements in the markup. This is a disaster from
+ an accessibility point of view, and it would be nice if we could
+ somehow make such pages non-compliant without preventing people from
+ using <code>div</code>s as the extension mechanism that they are, to
+ handle things the spec can't otherwise do (like making new
+ widgets).</p>
+
<h2>Web browsers</h2>
<p>This section describes features that apply most directly to Web
@@ -37186,6 +37207,12 @@
authoring tools must not include this string in their generator
string.</p>
+ <p class="big-issue">This entire section will probably be
+ dropped. The intent of this section was to allow a way for WYSIWYG
+ editors, which aren't going to use semantic markup, to still write
+ conforming documents, while not letting it be ok for hand-coding
+ authors to not use semantic markup. We still need some sort of
+ solution to this, but it's not clear what it is.</p>
<h4>The <dfn><code>font</code></dfn> element</h4>
@@ -37215,6 +37242,15 @@
</dd>
</dl>
+ <p class="big-issue">This entire section will probably be
+ dropped. The intent of this section was to allow a way for WYSIWYG
+ editors, which don't have enough information to use the "real"
+ "semantic" elements, to still make HTML pages without abusing those
+ semantic elements (since abusing elements is even worse than not
+ using them in the first place). We have still got to find a solution
+ to this, while not letting it be ok for hand-coding authors to abuse
+ the style="" attribute.</p>
+
<p>The <code>font</code> element doesn't represent anything. It must
not be used except by <span>WYSIWYG editors</span>, which may use it
to achieve presentational affects. Even WYSIWYG editors, however,
@@ -37266,6 +37302,11 @@
semicolon-separated (;) CSS declarations. <a
href="#refsCSS21">[CSS21]</a></p>
+ <p class="big-issue">We probably need to move this attribute to more
+ elements, maybe even all of them, though if we do that we really
+ should find a way to strongly discourage its use (and the use of its
+ DOM attribute) for non-WYSIWYG authors.</p>
+
<!-- XXX deal with each of the use cases in this:
http://lists.w3.org/Archives/Public/www-html/2003Jan/0277.html -->
More information about the Commit-Watchers
mailing list