W3C home > Mailing lists > Public > www-archive@w3.org > April 2011

[wbs] response to 'ISSUE-155: Make border attribute conforming on table element - Straw Poll for Objections'

From: WBS Mailer on behalf of xn--mlform-iua@xn--mlform-iua.no <webmaster@w3.org>
Date: Sat, 02 Apr 2011 02:27:21 +0000
To: xn--mlform-iua@xn--mlform-iua.no,www-archive@w3.org
Message-Id: <wbs-ff07dd1fc4d767a1bab69379d62262b8@cgi.w3.org>

The following answers have been successfully submitted to 'ISSUE-155: Make
border attribute conforming on table element - Straw Poll for Objections'
(HTML Working Group) for Leif Halvard Silli.



---------------------------------
Objections to the Change Proposal to enable all users to distinguish the
cells of a table.
----
We have a Change Proposal to enable all users to distinguish the cells of
a table. If you have strong objections to adopting this Change Proposal,
please state your objections below.
Keep in mind, you must actually state an objection, not merely cite
someone else. If you feel that your objection has already been adequately
addressed by someone else, then it is not necessary to repeat it.
Objections: 





---------------------------------
Objections to the Change Proposal for no change since there is no use case
that requires the changes in scope for this issue
----
We have a Change Proposal to make no change because there is no use case
that requires the changes in scope for this issue.  Keep in mind, you must
actually state an objection, not merely cite someone else. If you feel that
your objection has already been adequately addressed by someone else, then
it is not necessary to repeat it.
Objections: 
I object to making @border invalid as it is a key table attribute.

@media & UA related arguments:

1) CP claims to have no impact, but makes it invalid to tell UAs without
CSS support <http://tinyurl.com/without-CSS-support-definition> when to
display borders.
2) History's (de)fault: in the CP + related comments, author appears to
view borders as important & self-evident so much that he suggests UAs
without CSS support to default to display borders:

]The HTML feature that should trigger them to actually draw table borders
is simply <table>[
http://lists.w3.org/Archives/Public/public-html/2011Mar/0553

][…] it seems rather self-evident to me. Just look in any book,
  tables are almost always rendered with borders.[
http://lists.w3.org/Archives/Public/public-html/2011Mar/0555

But, without @border, no known HTML UAs have drawn borders by default
(tested Mosaic). HTML5's Rendering section thus follows the tradition when
it makes border-display-by-default depend on @border. A test of a layout
table based page (e.g. <http://www.ist-inc.com>) with borders forced to
display, shows how disturbing and Web incompatible default borders would
be. Lack of borders does not need to be a layout table signal, but it often
is a prerequisite if sighted users are meant to not perceive whether a
table nor a lot of messy border lines.
3) CP author says (above): ]in any book, tables are almost always rendered
with borders[. But this is because books (@media print{}) like text
browsers (@media tty{}) did and do tend be color (and CSS) constrained. For
these media, borders - including as fallback via @border - therefore is
efficient: GUI UAs (@media screen{}) may display cell/row/column
backgrounds instead of borders but still offer background-free printing to
save ink.
4) WYSIWYG editors: Unless table has @border, they cannot default to
border display without breaking WYSIWYG expectations. (Editors which do not
assume that author wants borders tend to use dotted outlines until authors
eventually add borders.)
5) Are layout tables removed before syndication? If so RSS readers could
perhaps defaul to borders…

@border = presentational attribute arguments:

1) Due to RFC1942, the HTML4 DTD treats ]the value "border"[ as equal to
border=1. <http://www.w3.org/TR/html401/struct/tables#adef-border-TABLE>
That @border thus was defined more or less boolean indicates it wasn't seen
as presentational. That HTML4 deprecates img@border but not table@border
indicates the same. HTML5's Rendering section takes the boolean
interpretation to its logical end by treating even border=0 as border=1.
2) To describe the attribute that causes UAs to draw borders by default as
presentational, does not seem consistent with the view that UAs *should*
draw borders by default.
3) <table> isn't the only element that depends on an attribute in order
attain its most archetypical default rendering. E.g. HTML5 sees <a> as
'interactive content' even without @href. But it is only with an @href that
<a> is *looks* as a link. Similarly <table> is 'table content' too, but
<table border=1> is easier to perceive as table content.
4) @border (in CP1) isn't about CSS border-width, -style or -color, but
only about basic highlighting of data tables' most basic feature: the cell
structure.
5) Defenders of what CP author describes as "presentational" often cite
compatibility & simplicity while opponents cite D.I.Y. CSS + classes as
better. Truth is probably that both approaches have their advantages -
which is a reason to not forbid @border.
6) The problems of moving to CSS all that it is capable of taking is that
a) authors must learn CSS to do simple things, b) it adds to the form of
indirection known as "class-itis"/"id-its": a mess of class names over
which the author looses oversight. <http://wordnik.com/words/classitis> As
border on all tables isn't (and shouldn't) be an option (unless table has
@border), authors could add a class for each table that needs border (which
would typically result in a new one for each context...) instead of
attaching semantics to border=1.
7) border=1 is not anti-CSS: Like authors can alter the default styling of
<a href>, they can remove the 1px border default too.
8) If tables ought to have borders, then it is lack of borders that is
presentational. That layout tables seldom have whether @border or CSS
borders supports this view.

Comments in the poll:

1) Ian's claim that @border=1 would: "encourage … to write layout tables
by suggesting … there are valid reasons to distinguish tables _with_
borders from tables _without_ borders".
   That's fine, if it leads authors to add @border! Theoretical grasp
isn't as important as author behaviour. And data tables -only- *should*
have border=1 as only <a> with @href should behave like interactive content
etc. Besides, HTML5's permission to use @role=presentation clarifies that
any other table is a data table.
2) Tab's Lynx claims: Lynx docs say support is limited & hampered by lack
of border support http://tinyurl.com/lynxtabledoc


These answers were last modified on 2 April 2011 at 02:26:26 U.T.C.
by Leif Halvard Silli

Answers to this questionnaire can be set and changed at
http://www.w3.org/2002/09/wbs/40318/issue-155-objection-poll/ until
2011-04-04.

 Regards,

 The Automatic WBS Mailer
Received on Saturday, 2 April 2011 02:27:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:35 GMT