- From: Sam Ruby <rubys@intertwingly.net>
- Date: Fri, 21 May 2010 12:38:22 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: Maciej Stachowiak <mjs@apple.com>, Shelley Powers <shelley.just@gmail.com>, "public-html@w3.org WG" <public-html@w3.org>
On 05/20/2010 07:04 PM, Tab Atkins Jr. wrote: > Issue 92 Counter Proposal > ========================= I've recorded the counter proposal in the issue-status page, but I encourage you to consider improving the rationale and details. > Summary > ------- > The current text in the spec is adequate, but misplaced. This > information and the examples are useful information for authors > dealing with a non-intuitive table, but it does not belong directly in > the definition of the<table> element, as it is only tangentially > related to the element itself. It should be placed in a separate > subsection of the spec, near the<table> element. > > Rationale > --------- > The example table code given in the original Change Proposal misses > the point of this section of text; it is not meant to illustrate the > structure of a table, but rather to illustrate a *confusing* table > that may be difficult to automatically deduce the correct heading/cell > relationships out of. Producing a simple, clear table with > well-placed header cells defeats the purpose of this section. While > an clear example of a table with an explanation of each part may be > useful on its own, it is not appropriate to use to replace the > disputed text in the spec. Please consider adding rationale as to why you feel that it is necessary or appropriate to illustrate a *confusing* table. > Details > ------- > Move the text, starting with "There are a variety of ways..." and > ending just before "The summary attribute on table elements...", from > its current location to a new subsection placed after the current > "4.9.13 Examples" section. > > In its place, at the end of the previous paragraph, place a sentence > explaining that guidance for this case can be found in the new > section, with a link to that section. It is your assertion that Shelley missed the point. How does moving this text address that confusion? Alternately, why do you believe that such is not necessary? > Positive Effects > ---------------- > This guidance about ways to explain the structure of a confusing table > is maintained, and further no longer distracts from the main thrust of > this section, which is to explain the<table> element itself. > > > Negative Effects > ---------------- > Now that the advice is in a somewhat more remote section of the spec, > it is possible that less authors will see it. > > > Costs > ----- > Minimal editing time to rearrange the content. > > ~TJ >
Received on Friday, 21 May 2010 16:38:51 UTC