From HTML WG Wiki
Jump to: navigation, search

ISSUE-155: table@border: enable all users to distinguish the cells of a table


The basic purpose of cell borders according to HTML4, is to

help distinguish the cells of a table

Juxtaposition: column and row borders are often as essential for the interpretation of tables as paragraph margins are essential for the interpretation of where an paragraph begins and ends: borders help distinguish the cells as margins help distinguish the paragraphs. Therefore column and row borders ought to be possible to offer also to users of CSS-hindered browser environments. Which is why HTML5 should permit and recommend the use of border="1" on table.


Why a table needs column and row borders:

  1. without a miniumum of visualization of columns and borders, tables often become hard for sighted humans to recognize, consume or edit. This is backed up by Jessica Enders' zebra striping research. That research tells us that users strongly prefer — as well as make less errors — when the table structure is visualized. (42% of her test users disliked tables without whether borders or zebra stripes).
  2. for the purpose of column and row visualization, borders have broader media support and safer user support. For example, unlike the background colors used in ‘zebra striping’ and similar visualization techniques, border colors default to the text color and thus do not depend as much — as zebra striping does — on whether the browsing environement supports color or on whether the colors are compatible with the requirements of color blind users or not.); That e.g. text-based browsers do benefit from borders can be examplfied the bug that was filed against WikiMedia for its failure to provide borders for that browser group.

Why CSS borders need to be complemented with <table border="1">

  1. Firstly, because there, in addition to GUI and AT environments, exists an important third group of user environments for which it is important to care, namely the CSS-hindered environments where CSS either isn't supported, isn't attached or is switched off. (A definition of non-CSS UAs can be seen in Ian Hickson's Change Proposal for ISSUE-129: « 3. User agents without CSS support or without scripting support, and certainly without ATs, which always use the default semantics of the elements. Some examples of #3 are the text-based browsers, most search engines, and graphical browsers in which CSS or scripting are disabled.»);
    • @border="1" works for this group;
    • examples of user agents which benefits from @border="1":
      1. text-based web browsers such as w3m, links and elinks.
      2. GUI browsers with limited CSS support
      3. WYSIWYG-editors that operate under limited CSS support or are temporarily CSS-hindered.
        PS: Note that all "fresh" tables that are edited in a WYSIWYG tool requires a strategy for handling the lack of borders. For example, to help in the table edititing, some WYSIWYG-editors display a dotted border around the cells, during editing, while other WYSIWYG-editors are quite difficult for table editing without either adding @border="1" or CSS before starting to edit.
  2. 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”. However such “survival” is not only an issue in syndication, but in any process where a table is moved from one address to another: if the page uses an external stylesheet, the move can cause the columns and rows styling to fall apart because the contact with the original stylesheet was lost.
  3. Finally, because, @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;
    • @border="1" offers a useful styling default which the author can edit further: it is often more straight forward to style (including remove) — via CSS — the borders that border="1" adds, than it is to add borders solely via CSS;
    • @border is very basic while CSS-styling of table borders can be confusing. A comparision:
      Except when overridden by CSS, @border="1" always causes column and row borders to be drawn.
      In contrast, a stylesheet such as <style>col,tr{border:1px solid}</style> will not work at all unless border-collapsing is enabled as well. And, in addition, for the column borders to be drawn, this stylesheet also requires that <col> elements are present in the table. (Yes, once one is aware of this, one may of course replace col,tr{} by td,th{}.)


Edit instructions:

  • In section 4.9.1 The table element,
    1. add border in the list of table's “Content attributes”
    2. add prose describing the importance of helping users to “distinguish the cells of a table”.
    3. mention methods that can help to that end: using column and row borders, using “zebra striping”, trimming the the table content into a very simple table - possibly with monospaced fonts, so that the table looks very structured even without borders or zebra stripes. State that CSS can be used for these purposes.
    4. add to this that, for very basic styling and in order assist users of CSS-hindered environments in distinguishing the cells, the border attribute with the string "1" is available for fallback-styling.
  • In section 11.1 Obsolete but conforming features,
    1. insert the following paragraph:
      The border attribute on the table element can be used to provide basic fallback-styling for the purpose of making tables elligible for CSS-hindered browsing environements such as text-based browsers, WYSIWYG-editors and in situations where CSS-support is disabled or the stylesheet is lost. When used for this purpose, its value must be the string "1". Other values are considered obsolete — to regulate the thickness of such borders, authors should instead use CSS.


Positive Effects

  • Secures that the broadest possible set of users can be offered basic column and row styling of tables, regardless of CSS-support, without breaking HTML5-conformance;
  • Offer some authoring benefits and authoring simplifications;
  • Ensures that a broader set of existing table elements can avoid the not-HTML5-conforming stamp. (For example, according to Opera's MAMA project, 93% of table elements in the wild have the border attribute set. Unfortunately, most of those pages also apparently contains cellspacing="*" and cellpadding="*", so the pages as such would still be invalid.)
  • Reflects HTML5's recommended default rendering of for <table border="*"> better since the Rendering section of HTML5 treats @border as a more or less boolean attribute: when present, it is supposed to cause a 1px wide border - even when its value is zero:
    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;

    (Testing shows that, apart from bugs, this is a very widely implemented in user agents.)

Negative Effects

This proposal incorporates some compromises. Compromises do often have some negative effects:

  • It might be considered slightly more complicated that border is permitted, but only with the value 1. However, this compromise is based on the fact that HTML5 recommends a 1px border even when the value is empty or zero. In a somewhat similar fashion, HTML5 already operates with the complicating rule that border="0" on the <img> element is permitted, while all other values for border on <img> are forbidden.
  • Claim: It makes authors use @border instead of CSS. Well, may be. But firstly, if — as it has been claimed — user agents should default to display simple borders on tables, why does it matter if authors have a simple method, direclty in the table element, which enables this default? And, anway, this CP doesn't hinder authors from using CSS: one can "overstyle" the CSS that user agent default for tables with a border attribute. And, in the moment one wants more complicated, prettier styling, one cannot rely solely on @border anyhow. (It can, however, be somewhat difficult to — uniformly — "'overstyle'" the default CSS which user agents apply to tables with a @border, but this should be possible to improve by filling bugs against user agents as well as, possibly, improving the CSS that HTML5 recommends.)
  • Claim: It demotivates vendors from making their user agents default to display borders? May be. But facts in the wild are more important thant theory: Due to the widespread use of layout tables, including the fact that HTML5 makes such tables permitted via @role="presentation", it seems impossible for a user agents to default to render borders on tables - one quickly ends up with very funny pages if one attempt at such a thing.

Conformance Classes Changes

  • Conformance checkers:
    1. should stamp <table border="1"> as valid;
    2. when <table border="*"> has other values, validators should say that 1 is the only permitted value.


No known risks.