- From: WBS Mailer on behalf of xn--mlform-iua@xn--mlform-iua.no <webmaster@w3.org>
- Date: Sat, 02 Apr 2011 02:30:18 +0000
- To: xn--mlform-iua@xn--mlform-iua.no,www-archive@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:27:49 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:30:20 UTC