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

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

--- Comment #4 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(In reply to Andrea Rendine from comment #3)
> (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 want to arrest you (and some others) on the use of ”layout table” for any
table were the table’s default role has been overruled, see bug 24654.

It is evident that by ”layout table”, the spec has tables of
role="presentation" in mind. Such tables are semantically more or less equal to
a collection of <div> or <span> elements that have been styled to look like a
table.

While I agree that such a ”dl table” as yours perhaps could be said to make use
of the table structure - even if it they are not tables in the super strictest
sense,  they are not ”layout tables” unless you - or the user agent - sets its
role to ”presentation”.

> Borders, as you said, mean nothing here.

Also, as I say in bug 24654, for some ”non-table tables”, it may make sense to
have borders. For instance, I myself have produced quite a few glossary lists
in my life - both with <table> gloassairs and <dl> glossarie, and in each case,
I made use of borders (and display:table!) to highlight the structure. 

(Of course, for <dl> lists, then, even in ”challenged” web browsers, borders
are not much in need since the default styling of <dl> is to place the DT
content one line, and the DD content on the next line.)

Thus I doubt that it is fruitful to say that <table> for name-value pairs
represents ”layout table” usage is fruitful language in a HTML5 context.

The current definition of border as “not for layout purpose” makes sense.
However, it does not make sense if ”not layout” is interpreted a ”data table”.
At least not, if ”data table” is interpreted as a table where <table>’s default
semantics always are intact.

>From my point of view, speaking of ”semantic border" and/or "semantic
highlighting of the table structure” is meaningful precisely because we then
speak about the border - and avoid discussing whether the table is a data
table, layout table or some other kind of table.

> Now consider another example. Follow the link
> http://en.wikipedia.org/wiki/2014_Winter_Olympics_medal_table

> Without borders the table itself is not
> readable at all, and the meaning is lost.

For that particular table, the text browsers Elinks, Links, Lynx  and W3m
mostly render the table OK even if they don’t display borders, even if the <th>
cells that span more than a single row offers some challenge and inspection to
be *really* sure. Thus it helps readability to have borders. But I would not
say that meaning is lost without border. I would rather say that it requires
more effort from the reader when borders are omitted.

For other tables, the need for borders is such that it feels like a reall loss
to not have them. The more ”stuff” there is inside the cells, the more it is
needed. For instance, take a look at the table at the HTML WG’s Publications
page: <http://www.w3.org/wiki/HTML/Publications>
Earlier, the table on that page used to not have borders. And because many of
the cells include multiple “stuff items” (such as lists and more), the table is
*significantly* harder to read without borders.

> 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". 

+1

> 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.

Personally I think an analogy to SVG and MathML is reasonably: No one would
dream of completely switching to CSS for SVG elements or MathML elements.
Tables, like SVG and MathML, is a sufficiently complex matter that on-element
attributes can be defended.

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

Received on Thursday, 13 February 2014 16:31:50 UTC