[Bug 24647] New: Define table@border as explicit indication that the *borders* are meaningful

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24647

            Bug ID: 24647
           Summary: Define table@border as explicit indication that the
                    *borders* are meaningful
           Product: HTML WG
           Version: unspecified
          Hardware: PC
               URL: http://www.w3.org/html/wg/drafts/html/master/tabular-d
                    ata.html#attr-table-border
                OS: All
            Status: NEW
          Keywords: a11y
          Severity: normal
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: xn--mlform-iua@xn--mlform-iua.no
        QA Contact: public-html-bugzilla@w3.org
                CC: eoconnor@apple.com, faulkner.steve@gmail.com,
                    mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org,
                    rubys@intertwingly.net,
                    xn--mlform-iua@xn--mlform-iua.no
            Blocks: 24642

See: http://www.w3.org/TR/html5/index.html#attributes-1
And: http://www.w3.org/TR/html5/tabular-data.html#attr-table-border

Text at the first URL defines the table@border attribute as ”Explicit
indication that the table element is not being used for layout purposes”.

Problem: To attribute that meaning to @border sends the signal that it is (at
little bit more) acceptable for tables without the border attribute to ne used
as layout tables. This is at odd with the spec statement that says that ”Tables
should not be used as layout aids” - a statement which makes no distinction
between tables with or without @border. 

Proposal: Replace current definition table@border with a statement that focuses
on whether *borders* would be semantic/meaningful or presentational. For
example, something like this :

]]
border - Explicit indictation that it would benefit users to
         hightlight some or all table structures (cells, rows,
         columns, row groups, column groups, the table itself).
[[

This statement simply says that it makes sense to have borders between/around
some of the table cells/structures. 

Positive effects:

1. It is simple for authors to answer the question
   ”Does it makes sense to add some borders to this table?”
   Or ”Does it make sense to highlight structures in this
   table?” These questions also come across as useful to
   ask - and answer.
   Wherease to answer the question ”Is this table
   not used for layout purposes” is a convoluted
   and difficult question to answer. How useful it is to
   ask - and answer - this question, is also unclear.

2. Currently, table@border and table@role=presentation
   are permitted, but at odds with each others. They
   send contrary messages. To change the defition of
   table@border to focus on the semantic purpose of the
   borders themselves rather on the semantic purpose of
   the entire table, removes the semantic clash between
   table@border and table@role=presentation - allowing
   authors to use both, at once.
   Table@border would still count as a signal that the 
   table is a data table. However, it would not be in
   direct conflict with table@role=presentation.

3. The proposed new text does not focus on borders as such
   but allows the author and/or user agent to pick other 
   means such as ”zebra striping”, white space or methods
   that works in AT.

4. While @border by default highligts *all* table structures
   (with the exception of caption), the proposed new text
   is compatible with the view that actual use of borders
   should be kept at a minum. For example, a rather common
   and old table styling guideline is to avoid rules/borders
   that are vertical. (See for instance the following LaTeX guide:
http://anorien.csc.warwick.ac.uk/mirrors/CTAN/macros/latex/contrib/booktabs/booktabs.pdf)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 13 February 2014 09:59:06 UTC