Working Group Decision on ISSUE-92 cleanuptable

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:

== 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

Additionally, we find unanimity (as in considerable support from people
who supported both alternatives, and zero objections) on the following

    "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

* "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

== 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

== 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

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.

Received on Thursday, 10 March 2011 17:36:42 UTC