EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: none
Rationale: Indicating whether it would be good to highlight table structures is a UA decision to make, not an author decision. There is no useful way in which border can be considered semantic.

(In reply to Robin Berjon from comment #1)

> Status: Rejected
> Change Description: none
> Rationale: Indicating whether it would be good to highlight table structures
> is a UA decision to make, not an author decision. There is no useful way in
> which border can be considered semantic.

Apparently, the editor does not understand the proposal. The proposal is that border serve as a strong indication to the user agent to highlight the table structures.

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

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

(In reply to Leif Halvard Silli from comment #4)
>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.
You are right. I used that term only because W3C spec talks about "allowed layout tables". As a matter of fact, none of the tables produced as example here are "layout", so from now on I'll avoid defining them that way and invite anybody else doing the same. @border and data/non-data tables are unrelated. And while everywhere pure layout tables must be discouraged (i.e. tables used for 2-columns pages for example), tables with particular requisites for readability need borders. Period.

>take a look at the table at the HTML WG’s Publications page: <http://www.w3.org/wiki/HTML/Publications>
I'm happy I hadn't seen it without borders. We are talking about readability here! Whether they are data or not, some tables can't live without border and that is the perfect example.

(In reply to Leif Halvard Silli from comment #2)

> 
> Apparently, the editor does not understand the proposal. The proposal is
> that border serve as a strong indication to the user agent to highlight the
> table structures.

can you provide data that there is a strong correlation between the presence of <table border=1> and the table being used as a data table?

I looked at the latest http://webdevdata.org data set and could find no such correlation, in fact I found the opposite.

(In reply to steve faulkner from comment #6)
> (In reply to Leif Halvard Silli from comment #2)
> 
> > 
> > Apparently, the editor does not understand the proposal. The proposal is
> > that border serve as a strong indication to the user agent to highlight the
> > table structures.
> 
> can you provide data that there is a strong correlation between the presence
> of <table border=1> and the table being used as a data table?
> 
> I looked at the latest http://webdevdata.org data set and could find no such
> correlation, in fact I found the opposite.

a link to the grep results: https://dl.dropboxusercontent.com/u/377471/border1.html you can view the site page by getting the URL from the path string:

for example: 
C:\Users\steven\Downloads\webdevdata.org-2013-10-30\webdevdata.org-2013-10-30-231036\00\al-tagheer.com_00d1d0b582e294705574ce74e364275e.html.txt 

al-tagheer.com

I can't talk in stead of the publisher of this (IMO important) issue and proposal. But I can suggest one possible answer, from a quick review of the data you have linked.
I made the same mistake above. To link a data table stating that it needs borders because of its data-type content. Now I don't think that it's the point here if tables are used for data or not. The fact is, sometimes borders greatly improve readability of content in a table. When? these can be some relevant points for a reasonable choice:
 - a table with several cells in a row, and multiple rows
 - a complex grid layout, with some cell sistematically spanning over multiple rows/columns
 - content primarily constituted by text, with no further significant box model
 - in some cells the data take more lines, or are extremely compact.
In these cases, but perhaps even in other ones, without borders it becomes difficult to understand what correlations a table is going to show. Borders (as zebra stripes, as other visual improvements) are simply a visual way to represent the structure of content. The difference between <table> and <table@border> is that the latter needs a visual aid to be comprehended. This kind of border goes beyond the aesthetical purposes, exactly like <ol@type> goes beyond the purposes of simply choosing a point style (and in effect in <ul> element the list type is now a matter of stylesheet).
Finally, you must admit that authors unfortunately follow the 100th monkey effect, and they apply what they know by tradition. In the most recent Webdevdata survey the number of border attributes goes far beyond the number of occurrances of <table> because it is used aesthetically in several places (e.g. images). It's still a world with 7306 occurrances of the string <font!!!

(In reply to Andrea Rendine from comment #8)
> The fact is, sometimes
> borders greatly improve readability of content in a table. When? these can
> be some relevant points for a reasonable choice:

OK, why isn't CSS fit for the job of providing these improvements?

(In reply to steve faulkner from comment #9)
CSS can't do everything. Exactly as @type on <ol> and @width / @height on embedded elements (but for reasons which are not the same), this attribute can be used as a suggestion about how to render the element when the related property is relevant. Visual aspect of web pages is essentially meant for UAs which also process the style layer. But a web page must be autonomous. It must be rendered in a readable way even when its own CSS is for some reason not available:
 - when loading the resource fails
 - when the data are retrieved by data mining tools and displayed in other pages not fitted for the element
 - when displayed by those user agents which do not process CSS at all, such as text-based browsers. 
   * And more significantly a markup trigger for "readability border" could be used by search engines.
These are just examples.

(In reply to steve faulkner from comment #6)
> (In reply to Leif Halvard Silli from comment #2)
> 
> > 
> > Apparently, the editor does not understand the proposal. The proposal is
> > that border serve as a strong indication to the user agent to highlight the
> > table structures.
> 
> can you provide data that there is a strong correlation between the presence
> of <table border=1> and the table being used as a data table?

What I said above was simply my way of statating that ”look, I don’t wanna challenge what HTML5 says about heuristics, namely  that tables with border=1 are most likely to be non-layout tables”. (See what I say about heuristics below.)

I should probably rather have said that ”this change of the semantics of @border= would not affect how it partakes in the heuristics for determining whether a table is a layout table or not.”

> I looked at the latest http://webdevdata.org data set and could find no such
> correlation, in fact I found the opposite.

So interesting. It would be coold to see examples of ”page layout tables” which contains the border attribute!

But what are the implications of your finding? Do you disagree with the spec’s table over ”heuristics” that makes it less or more likely that the table is a ”layout table”? For example, for ”The use of the border attribute with a value other than 0” the tables says that it is ”Probably a non-layout table”.  Are you saying that you can’t find evidence for this in the data you look at?

Anyway, from where I stand, this only makes it *more* and not *less* correct to change the focus from ”meaningful borders”. For instance, if a table is used for a two column page layout - or a four grid layout, a border could indeed help keep the page sections apart. :-)

Btw, I think, if you are challenging the heuristics table, that it should go into another bug.

(In reply to Leif Halvard Silli from comment #11)


> Anyway, from where I stand, this only makes it *more* and not *less* correct
> to change the focus from ”meaningful borders”. 

Typo. :-) It makes it more correct to change the focus *to* ”meaningful borders”.

(In reply to steve faulkner from comment #7)

> > I looked at the latest http://webdevdata.org data set and could find no such
> > correlation, in fact I found the opposite.
> 
> a link to the grep results:
> https://dl.dropboxusercontent.com/u/377471/border1.html

Ah, thanks for the examples!

> you can view the
> site page by getting the URL from the path string:
> 
> for example: 
> C:\Users\steven\Downloads\webdevdata.org-2013-10-30\webdevdata.org-2013-10-
> 30-231036\00\al-tagheer.com_00d1d0b582e294705574ce74e364275e.html.txt 
> 
> al-tagheer.com

It is a bit hard to interpret the results. E.g. take http://ntvtelugu.com. 

1. It contains a very complicated structure of layout tables.
2. However, in the middle of all those tables, there is a ”main content table” with border="1". I say ”main content table” because if I look at the page in a text browser, the border makes sense ... it draws my eyes to that table, as the center - and perhaps the main content - of the page.
3. The table with border=1 has only two cells, spread on two rows ...  The top heading cell says ”recent video updates” and a bottom cell turns out to contain another table, in which each cells contains a description of a recent video.
4. The innter table in cell two has  cellpadding="6", which means that, according to HTML5’s heuristics table, the it does not fit the bill of a table that is ”probably a layout table”. 

Thus, for this one web site that I have inspected, I would say that my inspection more or less confirms that the HTML5’s heuristics table is not that bad ... it is quite correct.

Thus, I have still not seen a page layout table with border=1.

(In reply to steve faulkner from comment #9)
> (In reply to Andrea Rendine from comment #8)
> > The fact is, sometimes
> > borders greatly improve readability of content in a table. When? these can
> > be some relevant points for a reasonable choice:
> 
> OK, why isn't CSS fit for the job of providing these improvements?

The spec - HTMl5 - correctly states that in some user agents, border=1 is needed to draw borders.

(In reply to Leif Halvard Silli from comment #13)
> (In reply to steve faulkner from comment #7)

> > a link to the grep results:
> > https://dl.dropboxusercontent.com/u/377471/border1.html

> > al-tagheer.com
> 
> It is a bit hard to interpret the results. E.g. take http://ntvtelugu.com. 

Or take http://www.futbolecuador.com, where I find no table@border=1 - in fact, the output you cite shows that your script has detected img elements with border=1.

Or take http://myownfreehost.net/, where there is a single table, which happes to ahve <table border=1>. This table is near the bottom of the page and it has 6 cells with one piece of advertisement in each cell. I would not call this a ”layout table”. ALthough, it is perhaps debatable. THe table has much in common, I wold say, with navigation bars. And, btw, is a navigation bar in the form of a single row table with one link per cell a ”layout table”? 

You need to go over the data. It contains lots of false hits (e.g. border on <img>, data-border="1", frameborder="1" and so on). And you need to analyse the findings.

For some of the pages, such as holiday-rental-homes.de, then I think your results must stem from a sub page - at least the border="1" is not on the front page.

(In reply to steve faulkner from comment #7)

> > I looked at the latest http://webdevdata.org data set and could find no such
> > correlation, in fact I found the opposite.
> 
> a link to the grep results:
> https://dl.dropboxusercontent.com/u/377471/border1.html 

Another of your results, polizei-bwl.de, which expands to 

   http://www.polizei-bw.de/Seiten/default.aspx

in by browser, contains 3 tables at the bottom of the page. However it is only if I load the page in a textbrowser, such as W3M (or switch the user agent to Lynx), that those tables are given border="1". If I load the page in Firefox, then border is set to "0" - or at least, border="1" is not there.

Are these tables layout tables? When I look at the page in text browser mode, the tables with border=1 each consist of two cells - a ”heading cell” and a ”content cell”. Even so, in the ”heading cells” there is a h3 element.

I don’t know how you would define those 3 tables, Steve. Perhaps that is an issue for bug 24654 ? From one angle, they look like data tables consisting of just two cells ... At any rate, thera are a special kind of ”layout tables”.

(In reply to Leif Halvard Silli from comment #16)

>    http://www.polizei-bw.de/Seiten/default.aspx

> I don’t know how you would define those 3 tables, Steve.

Hm ... I guess the 3 border=1 tables there are best treated as page layout tables. A the same time, each of them constitute a ”section” or ”article” and so, visually, they make sense in a text browser.

(In reply to Leif Halvard Silli from comment #16)
 However it is
> only if I load the page in a textbrowser, such as W3M (or switch the user
> agent to Lynx), that those tables are given border="1". If I load the page
> in Firefox, then border is set to "0" - or at least, border="1" is not there.

which text browsers display <table border=1> with a border?

(In reply to Leif Halvard Silli from comment #15)

> You need to go over the data. It contains lots of false hits (e.g. border on
> <img>, data-border="1", frameborder="1" and so on). And you need to analyse
> the findings.

I provided the data as is, you can do with it what you will.

(In reply to steve faulkner from comment #19)
> (In reply to Leif Halvard Silli from comment #15)
> 
> > You need to go over the data. It contains lots of false hits (e.g. border on
> > <img>, data-border="1", frameborder="1" and so on). And you need to analyse
> > the findings.
> 
> I provided the data as is, you can do with it what you will.

Sure. But it was your claim that the data shows that table@border is not particulary linked to tables. Let me put it differently: You have not provided that that demonstrates that it is like that. To do so, you need to collect better data and/or analyse your data better.

(In reply to steve faulkner from comment #18)

> which text browsers display <table border=1> with a border?

Answer: Those text browsers that fully supports <table>. Via Homebrew (http://brew.sh/) I have installed Lynx, Links, Elinks and W3m.

A test page with a complex table:
http://www.w3.org/wiki/HTML/Publications

Links, Elinks, W3m draws border.
Lynx simply do not support rendering that table as  table. Instead, it displays it as some kind of list.

Lynx only supports very simple tables, such as the one that Andrea pointed to, for such tables, borders is not very important:

http://en.wikipedia.org/wiki/2014_Winter_Olympics_medal_table

I think the discussion of the heuristical effects of table@border, should continue in bug 24679.

(In reply to Leif Halvard Silli from comment #20)
> (In reply to steve faulkner from comment #19)
> > (In reply to Leif Halvard Silli from comment #15)
> > 
> > > You need to go over the data. It contains lots of false hits (e.g. border on
> > > <img>, data-border="1", frameborder="1" and so on). And you need to analyse
> > > the findings.
> > 
> > I provided the data as is, you can do with it what you will.
> 
> Sure. But it was your claim that the data shows that table@border is not
> particulary linked to tables. Let me put it differently: You have not
> provided that that demonstrates that it is like that. To do so, you need to
> collect better data and/or analyse your data better.

you opened a bug "Define table@border as explicit indication that the *borders* are meaningful"

I have asked you to provide data to support this. The data I looked at didn't support this, the onus is on you to provide data to support your request.

(In reply to steve faulkner from comment #23)


> you opened a bug "Define table@border as explicit indication that the
> *borders* are meaningful"
> 
> I have asked you to provide data to support this. The data I looked at
> didn't support this, the onus is on you to provide data to support your
> request.

Steve, do you say that my critisism of your data is uniteresting to you? Then why tell me should I interest me for your data?

At any raate: I *have* already provided more analysis of your data than you have provided. Please inform me whether my analysis is wrong.

Btw, tt is fine that you emphasise *border*. However you said that your data analysis related not to border but to ”data table”.

]]
can you provide data that there is a strong correlation between the presence of <table border=1> and the table being used as a data table?

I looked at the latest http://webdevdata.org data set and could find no such correlation, in fact I found the opposite.
]]

(In reply to Leif Halvard Silli from comment #24)
> (In reply to steve faulkner from comment #23)

> Btw, tt is fine that you emphasise *border*. However you said that your data
> analysis related not to border but to ”data table”.
> 
> ]]
> can you provide data that there is a strong correlation between the presence
> of <table border=1> and the table being used as a data table?

Steve,

it seems I need to stress that this bug does not seek to justify table@border.

(I choose to trust that the accident caused by Hixie, and which caused @border to be removed from the list of ”content attributes” for <table>, will not be used as pretext for anything: <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24591#c10>. There is a decision to have border in the spec as conforming etc. If border is removed from the spec, then it will happen in a way that respects the rules of our working group.)

So what does this bug seek to do?

This bug merely seeks to change the semantic meaning of table@border, *from* the definition that is currently recorded in the spec (and which says that there *is* a correlation between table@border and ‘data table’/’non-layout table’) *to* a definition of @border that focuses on the borders themselves as significant.

So regardless of whether your interpretation (that table@border is not particularly linked to data tables) is correct or not, it seems to me that your interpretation is compatible, rather than incompatible, with what this bug proposes.

How come?

Take for instance, once again, the table with border=1 at <http://ntvtelugu.com/>. I have looked at that page in W3M.

Let’s say that this is a layout table, at least in some ATs (for example VoiceOver does see all tables of that page as layout tables, it seems). Still, my claim is that borders are significant: The first cell of the table contains an <img>, without @alt, where the @src says src="titles/recentvideos.png". And W3m thus renders the text ”recentvideos” inside the first cell. The cell is clearly distinguishable thanks to the border - visually, it looks like a paragraph. But if I remove the border, the text ”recentvideos” no longer looks as a paragraph. Instead, it looks like the first line in cell number two (on the next row.) So, in a browser like W3m, the borders are still significant and quite helpful despite that the table may be seen as a layout table.

(In reply to Leif Halvard Silli from comment #0)

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

New proposal:

]]
border - Explicit indictation that it benefits SOME MEDIA to 
         hightlight some or all table structures (cells, rows,
         columns, row groups, column groups, the table itself)
         WITH THE HELP OF BORDERS OR BY OTHER MEANS.
[[

Justification for change: It seems that borders are particularly useful for certain media such as print media, tty media (text terminals etc).

(In reply to Leif Halvard Silli from comment #15)
> Or take http://myownfreehost.net/, where there is a single table, which
> happes to ahve <table border=1>. This table is near the bottom of the page
> and it has 6 cells with one piece of advertisement in each cell. I would not
> call this a ”layout table”. ALthough, it is perhaps debatable.

It totally, unquestionably is a layout table. I don't even understand how one could come to any other conclusion, or believe that it is debatable. But then again, as you are so fond of saying, the editor doesn't really understand that much.

This table is not used with anything remotely resembling the semantics of a table. It is just there because the author didn't know how (or care) to lay out those items horizontally in any other way.

> THe table has much in common, I wold say, with navigation bars.

Yes, it does. Which is why it is presentational.

> And, btw, is a navigation
> bar in the form of a single row table with one link per cell a ”layout
> table”? 

What else could it possibly be? Have you ever designed with tables?

(In reply to Leif Halvard Silli from comment #24)
> (In reply to steve faulkner from comment #23)
> > you opened a bug "Define table@border as explicit indication that the
> > *borders* are meaningful"
> > 
> > I have asked you to provide data to support this. The data I looked at
> > didn't support this, the onus is on you to provide data to support your
> > request.
> 
> Steve, do you say that my critisism of your data is uniteresting to you?
> Then why tell me should I interest me for your data?
> 
> At any raate: I *have* already provided more analysis of your data than you
> have provided. Please inform me whether my analysis is wrong.
> 
> Btw, tt is fine that you emphasise *border*. However you said that your data
> analysis related not to border but to ”data table”.
> 
> ]]
> can you provide data that there is a strong correlation between the presence
> of <table border=1> and the table being used as a data table?
> 
> I looked at the latest http://webdevdata.org data set and could find no such
> correlation, in fact I found the opposite.
> ]]

Steve's data very clearly shows that there are tables out there with @border that are indeed presentational. Your "analysis" of his data mostly indicated that you don't seem to have a clear grasp of what a presentational table is.

So, indeed, the onus is on you to show that a) this is not an issue and b) your proposal has merit.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: none
Rationale:
There *never* is a situation in which a proper use of table would not, potentially, on some medium, benefit from having its structure highlighted. *That is what a table is.*

Authors who do not want to have their table structure highlighted in any context can use role=presentational.

UAs are free to use @border as a heuristic, but the data show that it is imperfect.

The text that is currently in the specification seems strange because it is trying to justify the strange idea that one could want to use an attribute to indicate that a semantic element really is semantic. It's not strange because it is poorly written, it's strange because it's capturing a strange idea.

Switching that to talk about highlighting is just playing a synonyms game. It is only different if you believe that tables are not semantic — and therefore open to highlighting on some media — by default.