W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: Working Group Decision on ISSUE-155 table-border

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 15 Apr 2011 15:11:33 -0700
Cc: HTMLWG WG <public-html@w3.org>
Message-id: <AF8FB434-7772-45FF-925E-A224E07F4A18@apple.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

On Apr 15, 2011, at 2:54 PM, Tab Atkins Jr. wrote:

> On Fri, Apr 15, 2011 at 2:51 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> On Apr 15, 2011, at 11:30 AM, Tab Atkins Jr. wrote:
>>> On Wed, Apr 13, 2011 at 8:01 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>>  If this is a generic problem (that is, if tables in non-CSS UAs
>>>>  should basically always have borders), then tying border-drawing to
>>>>  an optional attribute which is *not* present on the vast majority of
>>>>  legacy tables is completely the wrong solution.
>>>> Only two solutions were proposed.  We only consider proposals which
>>>> actually are put forward.  Furthermore, no substantiation is provided
>>>> for the assertion that this is "completely the wrong solution".
>>> Note, this was not an attempt to suggest another solution, it was an
>>> objection against the <table border> CP.
>> Be that as it may, it remains the case that no substantiation was provided.
>> If you have new information to provide, whether supporting arguments for the claim that this is "completely the wrong solution", or a new Change Proposal calling for visual non-CSS UAs to always draw borders on tables, then you may make a request to reopen the issue.
> Does the rest of my email count as "support arguments for the claim",
> given that I expanded my claim to make the substantiation more
> obvious?

Are you asking to reopen the issue? Note that if so, in addition to providing clear new information that is relevant to the decision, you will likely be expected to provide a new or revised Change Proposal, and that the issue will become a Last Call issue, as for other reopen requests.

Reviewing the information informally, it seems you make an argument that one of two alternatives is true:

(1) Non-CSS UAs (presumably including CSS-stripping environments such as syndication clients) should always draw table borders.

 ==> This objection was considered in the decision, and was rebutted by stronger objections (mainly that it's not sufficiently Web-compatible, even for text browsers or syndication clients)

(2) Making border=1 valid does not serve the use case of making content that will be properly readable in non-CSS or CSS-stripping environments, because most existing Web content does not specify border=1 in the cases where it would be needed (i.e. on data tables rather than layout tables).

 ==> This could be new information if it was substantiated by evidence. Whether it's *relevant* new information is a judgment call. The use case accepted was creating content that would work well in certain classes UAs, not enabling those classes of UAs to better display existing Web content, and your information seems relevant only to the latter.

Thus, the information provided likely would not be sufficient by itself, but it could potentially be expanded into information that might be sufficient.

Received on Friday, 15 April 2011 22:12:01 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:36 UTC