Working Group Decision on ISSUE-155 table-border

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 whether or not the
HTML5 specification should define the border attribute on the table
element to be conforming.  The result was an issue, two change
proposals, and a straw poll for objections:

http://www.w3.org/html/wg/tracker/issues/155
http://www.w3.org/html/wg/wiki/ISSUE-155-CP1
http://lists.w3.org/Archives/Public/public-html/2011Mar/0519.html
http://www.w3.org/2002/09/wbs/40318/issue-155-objection-poll/results

== Uncontested observations:

In this case, we have one change proposal that concedes nothing, and
another that concedes concerns that nobody raised.  As such, the
negative effects and risks sections did not contribute to this
decision.

=== Objections on the basis of Use Cases

One key question is whether the border attribute on table serves any
valid use cases.

From the "No change" Change Proposal we have the following objection:

  There is no use case that requires the changes in scope for this
  issue

However, several concrete use cases were proposed, as objections to
the no-change Change Proposal. 

First, writing content that displays reasonably in text-based
browsers:

  text-based web browsers such as w3m, links and elinks.

Second, adding borders to tables in a way that survives syndication:

  Secondly, because, any user agent — and some (e.g. syndicators) more
  systematically than others — from time to time belong in the third
  group of CSS-hindered browsing environment because they‚ more or
  less accidentically, from time to time are parsing documents where
  the original, intended stylesheet is unavailable. To avoid the worst
  effects of such stylesheet loss during syndication, Sam Ruby prefers
  to use @border="1" (as well as cellpadding and cellspacing), because
  “the alternatives (including inline CSS) are clumsy and are less
  likely to survive the process of syndication intact”.

And similarly:

  Authors need to be able to mark up data tables in a readable manner
  & such markup should survive syndication. Currently, <table border>
  is the only way for authors do do so. The fact that <table> defaults
  to having no borders is indeed a bug in the Web platform, but it is
  a bug that will never go away due to the large quantity of legacy
  content that requires <table>'s default rendering. Because such
  legacy content may be syndicated, it is unreasonable to expect feed
  readers to change their default <table> rendering.

Additionally, from the survey itself, we find a claim about non-CSS
user agents more generally:

  There is a use-case: making it clear to non-CSS user-agents that a
  table is not presentational, so they can draw it the way a
  non-presentational table should be drawn, which means with borders.
  The large majority of presentational tables will want no borders,
  while the large majority of non-presentational tables will want
  borders. Ideally, authors would not use presentational tables, but in
  reality some do, and user-agents need some way to reliably detect
  this before they can safely draw borders.

Another use case is WYSIWYG editors:

  @border="1" provides some authoring benefits that can help making
  sure that authors actually do add borders: @border="1" can help
  during editing of HTML in WYSIWYG mode, especially when CSS is
  disabled

And specific WYSIWYG editors were identified that use border:

  CKeditor, SeaMonkey's Composer, Bluegriffon and more use border="1"

Yet another use case is adding table borders in a way that survives
copy and paste:

  For a real-world user who was hurt by the fact that MediaWiki stopped
  including border=1 on some tables, for validity reasons, see this bug
  report (which is indirectly referred to from the other Change
  Proposal):

  https://bugzilla.wikimedia.org/show_bug.cgi?id=18829

Examining the bug showed that the CSS alternatives used instead of
border=1 did not survive copy/paste equally well.

Given that we have numerous tangible real-world use cases as well as
rationale, we find the objection to the "No change" Change Proposal on
the basis that it fails to address these use cases to be strong.

It remains to be examined whether these use cases could be served in
some other way.


=== Objections to the use cases on the basis of alternate default rendering

As we have found a strong objection to one change proposal, we turn to
evaluate the remaining objections to the other proposal that we
received in order to see if we find one that is stronger. There was a
claim that border is not required to satisfy the use cases claimed for
it, because:

  Nothing is stopping non-CSS UAs from rendering tables as appropriate
  for tables.

and

  If there is a problem with displaying table borders in non-CSS UAs,
  they can draw the table borders themselves

To which we have the following responses (also from the survey):

  This is not true. The historical default rendering of tables has
  always been without borders, so legacy constraints mean any user
  agent must render them this way if it wants to render webpages
  correctly. The HTML5 rendering section explicitly requires this
  default rendering for visual user-agents, and it says "User agents
  that use other presentation mechanisms can derive their expected
  behavior by translating from the CSS rules given in this section."
  Thus non-CSS user agents are also required to display tables with no
  borders.

and

  Default border rendering (when border is lacking) is incompatible
  with the Web
  
and

  no known HTML user agents have drawn borders by default (e.g. Mosaic
  didn't). HTML5's Rendering chapter thus follows tradition when it
  only requires tables with border present to render borders by
  default. 

The claim that rendering table borders by default is incompatible with
the Web was not materially disputed. That is to say, no one explicitly
claimed that it *is* compatible with the Web to draw table borders by
default, even for a client like a text-based browser or a syndication
client.

The claim that no known HTML user agents draw borders by default was
disputed:

  Lynx, for example, already draws table borders automatically.

However, another commenter disagreed with this claim:

  I just tested in Lynx, and it does not draw table borders by default

Independent testing shows that Lynx does not in fact draw table
borders by default (or, apparently, ever). 

In conclusion: no evidence was provided that even a single non-CSS UA
draws table borders by default. Arguments, though not concrete
examples, were provided that rendering table borders by default was
not Web-compatible, and these arguments were not disputed. 

Thus, the objection on the basis that non-CSS UA are free to render
tables as they see fit to be weak.

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the "enable all users
to distinguish the cells of a table " Change Proposal for ISSUE-155:

  http://www.w3.org/html/wg/wiki/ISSUE-155-CP1

Of the Change Proposals before us, this one has drawn the weaker
objections.

== Next Steps ==

Bug 7468 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 complete ISSUE-155 is to be
marked as CLOSED.

As none of the proposals discussed cellpadding or cellspacing
attributes, the chairs have agreed that this portion of issue-155 is
essentially "closed without prejudice", meaning that receipt of an
acceptable Change Proposal would be sufficient to reactive this
portion of the issue.  In order to reduce confusion, any such
reactivation would likely be tracked with a separate issue number and
the description of such an issue would contain a link back to the
original issue. Note: if the issue is reactivated, on this basis, it
will be treated as a new issue at the time raised, and applied to the
milestone then appropriate.

== 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. Examples of
possible relevant new information include:

  Identification of a substantial number of Non-CSS UAs, syndication
  systems, or editors that do draw borders on HTML tables by default.
  Ideally this would be accompanied by a list of pre-existing
  web pages that depend on this behavior.

=== Arguments not considered:

First an objection made in the "No Change" Change Proposal itself:

  If there are problems with CSS, they should be addressed in CSS, not
  in HTML.

Nobody made the assertion that there is a problem when CSS.  In
particular, there is no disagreement on how tables should be rendered
in the presence of CSS.

Next objections from the survey:

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

  The CP claims to have no impact, but actually makes it invalid to
  tell user agents without CSS support when to render borders.

The observation may be correct, and we can discuss whether or not it is
obvious or should have been included; either way it impact that would
be the objection we would need to evaluate, not the failure to
enumerate such in the change proposal.

  Towards the deadline of the poll, it became obvious that
  HTML5’s Rendering section is more out of tune with the Web that
  originally acknowledged, see Bug 12413. HTML5 simply goes too
  far in making border a boolean attribute, as the proposed CSS
  causes even border="0" to result in a 1 pixel border around
  each cell:

This advocates a proposal not on the table, and therefore was not a
part of this decision.  It can continue to be pursued separately as a
bug.

  From from analysis of Bug 12413, it seems clear that my own
  Change Proposal doesn’t go far enough: border needs to permit
  not only the value "1" but also the value "0". Simply put,
  border needs to be a normal, enumerated attribute with 3
  keywords (1, 0 and the empty string), one missing value default
  (no attribute) and one invalid value default, similar to the
  preload attribute. To sum it up in a table:
 
Again, this isn't actually in a Change Proposal so is out of order.  It
can still be pursued as a bug.

Received on Thursday, 14 April 2011 03:02:45 UTC