The decision follows. The chairs made an effort to explicitly address
all arguments presented in the Change Proposals on this topic in
addition to arguments posted as objections in the poll.
*** Question before the Working Group ***
There is a basic disagreement in the group as to the appropriateness of
the example that explains the structure of HTML tables as it appears in
the current draft. The result was an issue, two change proposals, and a
straw poll for objections:
http://www.w3.org/html/wg/tracker/issues/92http://www.w3.org/html/wg/wiki/ChangeProposals/cleanuptablehttp://lists.w3.org/Archives/Public/public-html/2010May/0362.htmlhttp://www.w3.org/2002/09/wbs/40318/issue-92-objection-poll/results
== Uncontested observations:
* "Current draft indicates that summary is obsolete but conforming."
* "If the [example] text is moved elsewhere, it is possible that less
authors will see it."
None of these were decisive. There were people who supported either of
the two change proposals even after taking these facts into
consideration. The fact that they were acknowledged up front was
appreciated.
Additionally, we find unanimity (as in considerable support from people
who supported both alternatives, and zero objections) on the following
observation:
"I agree that the text should be moved somewhere else (with the
details depending on the outcome of ISSUE-32)."
However, this falls short of unanimity:
"I disagree that this is sufficient; there should be a good example
for a table in the text (as suggested by the other change proposal)"
With consensus being found to move the table and examples to a separate
section, what remains is to evaluate the objections to the text itself.
== Objections to current draft text
The table example in the proposal is too complex...Otherwise I can
live with the text
A self-labeled weak objection.
The space would be better used by providing a table listing that uses
all of the table child elements, demonstrating how the elements work
together, and then providing a screenshot of the table. By creating a
listing, people can see how the table is put together; the figure
demonstrates the visual rendering of the table.
Given the overall size of the document, and the relative size of this
specific example, this is at best a weak objection.
== Objections to alternate example
Given that all of the objections to the example as it appears in the
draft were found to be weak, we simply list the objections to the
proposed alternative without assessing how strong they are beyond
stating that they are stronger than the objections to the alternative.
Note: each are direct quotes from the survey, two of which themselves
quote from the alternative for the proposed example.
* This Change Proposal misses the entire point of the example in the
spec, which is to illustrate a table which has a structure that
*can't* be easily and automatically inferred by just naively
inspecting the first row/columns for headers, and thus actually has
need of a structural description. Replacing the current spec example
and text with the example and text given in this Change Proposal would
remove important and useful information in return for a basic tutorial
example.
* "The table element represents data with more than one dimension,
organized into non-empty columns and rows." -- this replaces a
must-level requirement not to have empty rows or columns with a phrase
not expressed as a conformance requirement.
* "Tables are used for data display, only, and should not be used for
layout purposes." -- This sentence (replacing "Tables must not be used
as layout aid") makes a false statement of fact about how tables *are*
used in place of a conformance requirement, makes ungrammatical use of
the comma, and replaces a must-level requirement with a should-level
for no reason stated in the Change Proposal.
* The replacement text is more vague about when additional structural
description for a table should be provided, using the vague "complex
table" instead of the more informative "tables that consist of more
than just a grid of cells with headers in the first row and headers in
the first column, and for any table in general where the reader might
have difficulty understanding the content"
* The replacement omits examples or even mention of additional
techniques that could be used to describe a table's structure, besides
the summary attribute. These techniques can be useful in a variety of
circumstances, and omitting them makes the spec less useful to authors
on the whole.
*** Decision of the Working Group ***
Therefore, the HTML Working Group hereby adopts the "Move table and
examples to a separate section" Change Proposal for ISSUE-92. Of the
Change Proposals before us, this one has drawn the weaker objections.
== Next Steps ==
Bug 8449 is to be REOPENED and marked as WGDecision.
Since the prevailing Change Proposal does call for a spec change, the
editor is hereby directed to make the changes in accordance to the
change proposal. Once those changes are made, ISSUE-92 is to be marked
CLOSED.
== Appealing this Decision ==
If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition
request.
== Revisiting this Issue ==
This issue can be reopened if new information come up. An example of
possible relevant new information:
* specific, non-subjective, and independently verifiable evidence that
the current example is actively harmful.
== Arguments not considered
I think it's highly inappropriate to use this change proposal as a
"stealth" way to reintroduce the summary="" attribute, given how
controversial that issue has been.
No previous decision covered the summary attribute.
I object to this change proposal containing a resolution to ISSUE-32
as a rider.
We are looking for objections to this change proposal. It would have
been valid to list a set of objections to one or more of the proposals
for ISSUE-32 and say that they apply in this case. That being said, if
it had looked like the decision on this issue would have required
ISSUE-32 to have been decided first, then the chairs would have deferred
posting a decision on this issue until ISSUE-32 was resolved.
However, since @summary *is* in HTML5 today, it is wholly appropriate
to provide an example of how it is used, and how it should be written
(if an author chooses to use this mechanism)
Objection entirely consists of an unsubstantiated assertion as to what
is appropriate.
I object to this proposal since examples that are contained in the
element description are more consistent with previous versions of
HTML.
Does not cite any specific inconsistency, and fails to explain why the
alleged break with the past is harmful.
The current text is inappropriate and unclear. It should be replaced
and a simple, clear, relevant example provided. The other change
proposal does this very well
Entirely lacking in specifics.
The current table element section provides one very small and
inadequate table example, with a great deal of prose basically telling
people what to put in text surrounding the table. None of this prose
is related to the purpose and interoperable use of the table or its
child elements.
A series of assertions, none with any form of substantiation.
... seemingly added to the section only as a way of justifying
removing the summary attribute. I hate to use cliches, but this seems
like a true case of the tail wagging the dog.
We are looking for objections to the actual text being proposed, not on
the imputed motives of the author of the text.
Throwing lots of irrelevant text at authors does not make the table
element any clearer, or ensure they use the element in the proper way.
What's needed is a good, succinct example, with a clear explanation of
the element, and the table's only unique attribute, summary.
The only objection found in such a statement is 'irrelevant', and even
this objection is unsubstantiated.
What people incorporate into the text surrounding an HTML table is not
the business of the W3C HTML Working Group. Such over-specification
only adds to the noise, and if you throw enough noise at people, all
they'll do is tune out the important bits.
This objection presumes that the case has already been made that this
example is noise.