Leif Halvard Silli

Objection to the No-Change Proposal for ISSUE-155

I object to making border invalid as it is a key table attribute.


Objections against media & user agent related arguments

  1. The CP claims to have no impact, but actually makes it invalid to tell user agents without CSS support when to render borders. Note: all user agents are from time to time without CSS support, see definition of «without CSS support».
  2. History's (de)fault: in the no-change CP + related comments, author describes borders on tables as important/self-evident. Subsequently he uses the importance as justification for why borders always should be drawn:
    The HTML feature that should trigger them to actually draw table borders is simply <table>
    […] it seems rather self-evident to me. Just look in any book, tables are almost always rendered with borders.

    But, without border present, 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. That borders are «self-evident» is not sufficient justification for saying that some user agents can just break with tradition (including with HTML5 itself).

  3. Default border rendering (when border is lacking) is incompatible with the Web. To test, armour yourself with a user style sheet that forces border rendering on any table and visit a table layout based Web page and watch the confusing, meaningless lines that this results in. Lack of borders doesn't need to be a layout table signal, but it often is a prerequisite if users are meant to not perceive whether tables nor meaningless lines.
  4. That tables in books are almost always rendered with borders, is actually a media related observation caused by the fact that print typically is a monocolored medium, whereas tables on the Web often use background color/zebra striping for the same thing. Example: a GUI user agent/@media screen{} may render backgrounds to hightlight cells/rows/columns (for an example, see the below note about WYMeditor or a zebra striped example), but background-free printing might still be useful to save ink or to support black-white printing of the same document.) Borders are cheap compared with backgrounds, and does much of the same job. Thus the border tradition in books is an example of how border is useful for targetting less capable media. To use table border=1 allows easy support of table borders even in CSS constrained user agents by removing the borders only in the media where fallback styling isn't needed: style media="screen,handheld,tv"td{border:0}style.
  5. The CP claims that WYSIWYG editors don't need border. But without border=1 present, WYSIWYG editors can't default to render borders, as such a thing would break the WYSIWYG expectation. Some WYSIWYG editors default to show borders, some defaults to not show borders. But regardless, when there is a border, then border="1" is what is used, e.g. try browser based CKeditor, SeaMonkey's Composer, Bluegriffon and more. And when the editor or the user sets the table to have no borders, then border="0" is what is used — e.g. check SeaMonkey, Bluegriffon, CKEditor and TinyMC. But even with the value border=0, these editors render a thin, dotted border — to help the user to perceive the cells while at the same time also hinting to the user that these borders will not be visible in the browsers (which they won't). Ironically - but logically - the only graphical editor I have tested which appeared to render borders even with border not present, was browser based WYMeditor - which isn't a WYSIWYG editor but supposedly a "What-You-Mean editor". After a deeper look, it turns out that WYMeditor doesn't render CSS borders: it just makes use of «fake borders», which can be achieved via background colors when the table has the default table{border-collapse:separate}, see Live DOM Viewer demonstration.
  6. The CP claims that RSS readers don't need border: However, while I could imaging that the worst layout table examples do not get syndicated, a precondition for not needing to discern between layout and data tables is that the medium only contains the one or the other kind of tables. I don't know enough about syndication to say layout tables actually do get syndicated or not.

Objections against the «border is a presentational attribute» argument

  1. The history of border indicates that it wasn't conceived as as presentational: Due to RFC 1942, the HTML4 DTD treats the value "border" as equal to border=1 HTML4 deprecated img border="*" but not table border="*".
  2. To describe the attribute that causes user agents to draw borders by default as presentational, does not seem consistent with the view that user agents *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 looks as a link. Similarly table is 'table content' too, but table border=1 is easier to perceive as table content.
  4. border (in the other Change Proposal - 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. 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. Also supporting this view is the fact that when something is declared as having role="presentation", then then what's happen is that the native semantics are removed.
  9. Tables is one of the most complex constructs of HTML. Complext constructs do require some attributes that are not coming from CSS. Just consider SVG.

Objections against points made in some comments in the poll

  1. Regarding 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 *only* data tables *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. Regarding Tab's Lynx claims: Lynx docs say support is limited & hampered by lack of border support.

Objections post scriptum

  1. 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:
    table[border] > tr > td, table[border] > tr > th,
    table[border] > thead > tr > td, table[border] > thead > tr > th,
    table[border] > tbody > tr > td, table[border] > tbody > tr > th,
    table[border] > tfoot > tr > td, table[border] > tfoot > tr > th {
      border-width: 1px;
    Applying that stylesheet to layout table based web pages would result in the messy line problems described above. This bug is yet another result of the no-change proposal’s view of border as a presentational attribute, a thinking which doesn’t stand the test of reality: no user agent renders borders for border="0".
  2. 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:

    The border as an enumerated attribute. How border should be specced.
    Value Example Resulting state Resulting border width
    "1" table border="1" Valid keyword state 1px
    "" (the empty string) table border="" Valid keyword state
    other value than "0", "1"
    or the empty ""
    table border="9" Invalid value default
    table border="foo"
    "0" table border="0" Valid keyword state 0px
    no attribute table Missing value default