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

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

Andrea Rendine <master.skywalker.88@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |master.skywalker.88@gmail.c
                   |                            |om

--- Comment #3 from Andrea Rendine <master.skywalker.88@gmail.com> ---
(In reply to Robin Berjon from comment #1)
>There is no useful way in which border can be considered semantic.

Here's a way. Below I present 2 different tables. 

The first one can be reasonably considered a "layout table", not in the sense
of paging table, but because it serves the same purpose of a <dl>. I chose a
table because it is easier to represent name-value data this way, it's tidier
and can also be copypasted and inserted in non-HTML document (e.g. personal
database) without losing the relationship between the name field and the value
field. It also allows different blocks of data. But it cannot be defined
"tabular data" as the one I'll present later.
<table>
 <tbody> 
  <tr>
   <th>name</th>
   <td>John Doe</td>
  </tr>
  <tr>
   <th>region</th>
   <td>Georgia</td>
  </tr>
 </tbody>
 <tbody>
  <tr>
   <th>job</th>
   <td>research assistant</td>
  </tr>
  <tr>
   <th>Web reference</th>
   <td>www.JohnnyD.com</td>
  </tr>
 </tbody>
</table>
Here I wouldn't even draw borders with CSS i think. Anyway I wouldn't need them
in any browser, because the relationship is made clear by the bold-normal font
weight contrast. Borders, as you said, mean nothing here.

Now consider another example. Follow the link
http://en.wikipedia.org/wiki/2014_Winter_Olympics_medal_table , just as an
example of a real data table.
Here the grid is necessary. The authors not only convey the content of the
table, they state a horizontal relationship (country) and a vertical
relationship (medal class) for data. Without borders the table itself is not
readable at all, and the meaning is lost. In other elements it is commonplace
to rely on browsers' native support (see <details> and <meter> for some
examples). But I don't think browsers will redefine their default rendering for
tables, and this for 2 reasons.
1. Too many old-style pages will be presented useless borders. It would break
background compatibility with a really widely used element
2. inserting borders is anyway arbitrary (see example 1). To say that a table
MUST have rules is like saying that, as <details> is an element meant to design
a disclosing widget, it is a UA decision that it must be undisclosed by default
and authors are not meant to change it.
The difference can also be made with @role, but I wouldn't define AT ALL
example 1 "presentation". 

There is an attribute which servese this purpose, it has always been considered
conforming, everything authors need is to have it changed from a
"parsed-integer value" attribute to a "boolean" attribute, with almost perfect
backward compatibility and legacy UAs compatibility. And it would greatly help
authors define 2 different fallbacks (borders for data tables, border-less
non-data tables) which can both have purposes in cases when stylesheets are not
available.

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

Received on Thursday, 13 February 2014 14:00:50 UTC