- From: Sam Ruby <rubys@intertwingly.net>
- Date: Fri, 21 May 2010 13:25:35 -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/21/2010 12:49 PM, Tab Atkins Jr. wrote: > On Fri, May 21, 2010 at 9:38 AM, Sam Ruby<rubys@intertwingly.net> wrote: >> 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. > > Because confusing tables exist, and authors need to be aware of good > ways to mark them up. > > Non-confusing tables (which, luckily, are the majority of tables) > don't need any special help or summary, because their structure is > obvious. > > >>> 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? At least one person was confused, or at least that is your assertion. Several possibilities exist. I'll state the most unlikely first. Perhaps you believe that it is a good thing that specs promote confusion. Alternately, perhaps you believe that nobody else will be confused. More realistically, perhaps you believe that merely relocating this text will address the confusion? If so, state so. Or is it that something additional is required, perhaps just a paragraph or even a sentence or even a few words that provides additional context to this paragraph? Note: I am not trying to argue the case, I am trying to coach. I believe that this change proposal focuses too narrowly on stating what is wrong with the original proposal. It would make a stronger case if it balanced that with more of a rationale as to why the existing prose is useful. I am not going to make the case for you. Given that you have taken the time to write up a counter proposal, I have to assume that you believe that the current text is important. Additionally, if you can find ways to mitigate the problems identified in the original proposal, state them too. You are welcome to proceed with the counter proposal as is. All I am suggesting is that it would be stronger if these items were addressed. I've placed more context here: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9792 > I'm not sure I understand your question. > > ~TJ - Sam Ruby
Received on Friday, 21 May 2010 17:26:10 UTC