This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24559 - Nu Markup Checker emits "Use CSS instead" help message for table@border=1
Summary: Nu Markup Checker emits "Use CSS instead" help message for table@border=1
Status: REOPENED
Alias: None
Product: HTML Checker
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael[tm] Smith
QA Contact: qa-dev tracking
URL: http://lists.w3.org/Archives/Public/w...
Whiteboard:
Keywords:
: 24561 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-02-06 10:29 UTC by Leif Halvard Silli
Modified: 2014-02-13 12:29 UTC (History)
4 users (show)

See Also:


Attachments

Description Leif Halvard Silli 2014-02-06 10:29:10 UTC
A user notified the www-validator@ that NU validator has stopped accepting the border attribute for the table element and questioned the new behavior.

The user is correct because:

> The answer is that @border is conforming in HTML5 and that the validator
> has a bug if it does not allow it. There was a change proposal process to
> have @border added back into the spec, and the CP prevailed.
Comment 1 Michael[tm] Smith 2014-02-06 10:52:30 UTC
I'm pasting below are my comments so far from the related www-validator thread, and moving the bug to resolved=needsinfo awaiting the response. Note that the document under discussion (the document the OP cited in the www-validator thread) is at http://www.w3.org/TR/2014/PR-rdf11-mt-20140109/

As I understand it, you're probably suggesting I should try to answer the
question of why, in the particular document that the OP cited, using legacy
table@border=1 markup for presentational purposes is a better choice than
following the normal longstanding recommended best practice of just using a
couple lines of CSS to achieve the same presentational effect -

  table { border-style: outset; border-width: 1px; border-spacing: 2px; }
  table td { border-style: inset; border-width: 1px; }

Problem is, in looking at the particular document the OP cited, I don't see
any reason why he couldn't or shouldn't be using CSS instead. Can you?

I admit I may be missing something. So can you elaborate on why, for the
particular document the OP cited -- in which to me at least it seems the OP
clearly has no special restrictions preventing him from using CSS instead
of table@border=1 -- he shouldn't choose to add a couple lines of CSS?

The reason the Nu Markup Checker emits a message for table@border=1 is to
make authors aware that their markup may run counter to best practice, and
so help authors make an informed choice for what to do about it. If we don't
emit any message, then we're not making the author aware of the potential
problem in the doc, and not helping them to make an informed choice.

Or do you disagree? Should we not be trying to help the author make an
informed choice here? Are you saying that for authors who want table
borders and can easily add them using CSS (to go along with the normal
best-practice guidelines that all the experts have recommended for many
years now), they should always just be using table@border=1 instead?
Comment 2 Leif Halvard Silli 2014-02-06 11:19:36 UTC
(In reply to Michael[tm] Smith from comment #1)

> Problem is, in looking at the particular document the OP cited, I don't see
> any reason why he couldn't or shouldn't be using CSS instead. Can you?
 

> [...] should always just be using table@border=1 instead?

The CP to instantiate table@border=1 cite “good for the users” as one reason. For example it cited an article which speaked about zebra stripes as one way to help readers read tables. When there is no zebra stripes, then table border can help isntead.

So in a way, table border is a fallback issue, too, as I see it: It is a “backuip” when CSS is disabled or unavable. Better, in my view, to cancel our the default border styling effect of having table@border=1, than to remove border=1.

However, the change proposal that resistantiated border=1 did not go on to prescribe its used. While I personally perhaps would have liked to do that, the result was that it as OK to include border=1 and OK to skip the border attribtue. Authors/Users also would not accept it if suddenly all tables defaulted to dispaly borders.

It is clearly in validation with the spec to issue am *error* when border=1 is used.

It must also be a vialotion of the spec to recommend authors to use CSS if that implies to delete the border=1. 

It would clearly be OK to issue some kind of *warning* if there are no borders and no zebra stripes whether via CSS or @border=1. I don’t think you add any such message?
Comment 3 Leif Halvard Silli 2014-02-06 11:35:06 UTC
Sorry my many typos ... I correct only one of them and hope you understood ther rest:

“It is clearly in <DEL>validation</DEL> <INS>violation</INS> with the spec to issue am *error* when border=1 is used.”
Comment 4 Michael[tm] Smith 2014-02-06 12:51:26 UTC
*** Bug 24561 has been marked as a duplicate of this bug. ***
Comment 5 Leif Halvard Silli 2014-02-07 17:33:46 UTC
Regarding if I can see a need for the document in question  to use border="1", then I think it is positive to use border="1" as this attribute causes borders to be rendered even if you run browser with/in a very simple mode, without CSS. I would not recommend @border on layout tables, but on data tables, I think it is fine.

And since table@border=1 is fully permitted by the HTML5 specificaiton, one can just as well ask: Do you see a need to *not* use it?

Thus, since, regardless of the need to use border=1, HTML5 permits its use, it is clearly erroneous to issue the message that border=1 is obsolete.

Though the issue have been decided by the HTML working group, then, if my opinion is interesting:

I disagree with your attitude of creating a dichotomy between using CSS and using native HTML features, such as table@border=1. It is a false dichotomy. 

When the issue was discussed by the HTMLwg, then, per the understanding of many, the default display for tables *ought to have been* that tables are rendered.

However, that train has passed. Instead we got @border=1 as an optional feature. I personally would recommend always using @border=1 and rather use CSS to disable border display when it should not be there. (Unless, of course, we are speaking layout tables.)

I think you have enough information to remove the message that claims that the border attribute is obsolete. I reopen the issue.
Comment 6 Leif Halvard Silli 2014-02-07 17:52:12 UTC
(In reply to Leif Halvard Silli from comment #5)

> per the understanding of
> many, the default display for tables *ought to have been* that tables are
> rendered.

Typo. Meant ”ought to have been that *borders* are rendered.
Comment 7 Michael[tm] Smith 2014-02-10 04:43:53 UTC
Fixed.
Comment 8 Leif Halvard Silli 2014-02-10 14:36:58 UTC
I am sorry, but I have to reopen the bug. This because of the following:

The fix apparently is that NU validator instead issues a warning claiming that @border=1 is presentational markup. I don’t see that this is acceptable from the point of view of the change proposol that prevailed w.r.t to table=border=1. And I had already indicated that such a fix would not be acceptable:

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

> It must also be a vialotion of the spec to recommend authors to use CSS if
> that implies to delete the border=1. 

By the way: I note that in the thread in www-validator@ you cited HTML5’s claim that all presentational markup has been removed as justification. However, from where I stand - and this was also put forward together with the change proposal - the <table> element has *two* defaults: One default when border is not present, and another default when border is present. Thus, I consider table@border=1 to be compatible with HTML5’s claim that it has removed all presentational markup.

If you disagree with this, then I expect you to file a bug against HTML5’s claim that all presentational markup has been removed.

You should also consider that the chairs, when the CP prevailed, said that it would also be possible to (re)consider the *other* table attributes - frame,rules,cellspacing,cellpadding. Personally I would have liked to see in particular @rules being conforming, as it is such a simple and poweverful way of - literally - highilighing the semantic lines of a table. Som from my standpoint, it was also a compromise - something I chose to live with - that I never has raised the issue of the other attributes. If you are adding this warning, then at least for myself, the compromise is no longer in balance.
Comment 9 Leif Halvard Silli 2014-02-10 14:50:00 UTC
Mike has opened bug 24591 “Make W3C HTML5 spec clearly and correctly state that table@border is obsolete & invalid (nonconforming)”
Comment 10 Leif Halvard Silli 2014-02-10 18:02:20 UTC
For the polyglot markup spec, I have filed a bug to go in the opposite direction, namely to recommend authors and tools to default to use table@border=1, see bug 24605.
Comment 11 Andrea Rendine 2014-02-11 23:44:38 UTC
I don't want to either sustain the need of border rather than the lack thereof. But the problem is another. This thing of @border didn't start from the validator, but rather from the spec.
http://web.archive.org/web/20140113194820/http://www.w3.org/TR/html5/tabular-data.html#the-table-element
http://www.w3.org/TR/html5/tabular-data.html#the-table-element
Who changed the very text of the spec itself? It was told to me that a decision had been made about keeping the border attribute when I noticed this persistent difference between WHATWG's spec and W3C's.

One very very little question. I didn't test but I see that my Chrome and IE(!!!) versions would interpret <table border="border"> correctly (it draws borders), as it was easy to imagine according to the fact that UAs interpret @border="" (empty string value).
Here's my idea. In HTML5 (or, as mr. Hickson loves to say, in HTML) there are attributes that have a direct effect in presentational hints (say, @hidden, or <dialog@open>. They're usually boolean attributes and have a very simple apparent meaning, but a serious syntactic purpose.

Now for tables. It's hard to say that nowadays we still need layout tables as it was the case in the glorious (?!) age of Mosaic. Layout in the sense of "2 sections" page is REALLY obsolete and W3C must strongly discourage this behavior. 
But we are left with something. Last year I used a 2column-table to serve the same purpose that I'd have been able to achieve with a <dl> if the content model of <dl> weren't so poor. My table used no thead nor tfoot, and in the rows <th>s acted as <dt> and <td>s as <dd>. That was a layout table in some sense. Sometimes 1-dimensional data or 2-dimensional with a discreet dimension which equals to 2 can be represented with ("layout") tables. So there's still a need to hint UAs whether to draw borders or not, in all that cases where CSS is unavailable (I usually create pages trying to make them readable in cases when connection fails, which is quite commonplace in some areas of my country) and some secondary resources fail to load. Why? Because if the table is discreet, borders are unnecessary as the author only wants to benefit from some table features.

And how? Maybe with a boolean attribute. @border as we knew it until one month ago was practically an abnormal boolean where the spec had to state that no values other than 1 and the empty string were allowed. Now, these can always be overridden with CSS, whatever value is given to the attribute. And the fact that every value can be present is to save old pages with @border given the desired value for layout. A real boolean would do the same, would be easier to manage in the future (modern browsers can avoid parsing the value at all and only consider its presence) and I hope it can achieve another result. Yes, @border is presentational in that it admits integers and so specifically states a visual representation in detail. Other attributes are still "presentational" like @open but mean more. Let @border belong to this family, keep it as stated in the past and maybe also the WHATwg will accept and suppress this silly gap. Seriously, it's not worth all this trouble.
Comment 12 Leif Halvard Silli 2014-02-12 10:00:30 UTC
(In reply to Andrea Rendine from comment #11)

> <http://web.archive.org/web/20140113194820/http://www.w3.org/TR/html5/tabular-data.html#the-table-element>
> <http://www.w3.org/TR/html5/tabular-data.html#the-table-element>
> Who changed the very text of the spec itself? It was told to me that a
> decision had been made about keeping the border attribute when I noticed
> this persistent difference between WHATWG's spec and W3C's.

Above you pasted a link to old and new version of HTML5.x. These versions are pretty similar. Certainly with regard to @border, I see no difference (unless I overlook *another* passage):

]]If a table element has a (non-conforming) summary attribute, and the user agent has not classified the table as a layout table, the user agent may report the contents of that attribute to the user. [[

Are you referring to even older versions of HTML? Or some in-between version of HTML5.1, were the above passage ”fell out” of the spec?

Now, as for WHATwg’s spec, the difference was introduced with the HTML Working Group decision that you refer to.

I am not familiar with (in this very moment) how the text(s) have developed since the decision. (I must - and will - go through and check.) However, as the person who authored the change proposal that was adopted, I can say that I was never quite satisfied with what Ian stated in the spec, right after the decision, and uttered that view, after his edits back then. However, having got border into the spec as conforming, I chose to not go more into it. I mention this only to underline that I am open to changes as long as it remains conforming.

> One very very little question. I didn't test but I see that my Chrome and
> IE(!!!) versions would interpret <table border="border"> correctly (it draws
> borders), as it was easy to imagine according to the fact that UAs interpret
> @border="" (empty string value).

Where is you question? ;-) I have heard from David Carlisle that he (if I understood him perfectly) interpret the current text to say that *only* “certain” UAs use the @border attribute. But fact is that *all* UAs implements it. Is that your question? (WOuld be useful to know if other persons than David read it that way.)


> Here's my idea. In HTML5 (or, as mr. Hickson loves to say, in HTML) there
> are attributes that have a direct effect in presentational hints (say,
> @hidden, or <dialog@open>. They're usually boolean attributes and have a
> very simple apparent meaning, but a serious syntactic purpose.
> 
> Now for tables. It's hard to say that nowadays we still need layout tables
> as it was the case in the glorious (?!) age of Mosaic. Layout in the sense
> of "2 sections" page is REALLY obsolete and W3C must strongly discourage
> this behavior. 
> But we are left with something. Last year I used a 2column-table to serve
> the same purpose that I'd have been able to achieve with a <dl> if the
> content model of <dl> weren't so poor. My table used no thead nor tfoot, and
> in the rows <th>s acted as <dt> and <td>s as <dd>.

I have done the same. I used to use <dl> for glossaries. But sometimes I use <table>. Once we got feedback from our students that they liked table better than <dl> simply because it was easier to paste it into MS Word, then …

> That was a layout table
> in some sense.

Indeed, there is no clear definition of what a layout table is.

> Sometimes 1-dimensional data or 2-dimensional with a discreet
> dimension which equals to 2 can be represented with ("layout") tables. So
> there's still a need to hint UAs whether to draw borders or not, in all that
> cases where CSS is unavailable (I usually create pages trying to make them
> readable in cases when connection fails, which is quite commonplace in some
> areas of my country) and some secondary resources fail to load. Why? Because
> if the table is discreet, borders are unnecessary as the author only wants
> to benefit from some table features.
> 
> And how? Maybe with a boolean attribute. @border as we knew it until one
> month ago

Please be more specific about what change, 1 month ago, you refer to.

> was practically an abnormal boolean where the spec had to state
> that no values other than 1 and the empty string were allowed. Now, these
> can always be overridden with CSS, whatever value is given to the attribute.
> And the fact that every value can be present is to save old pages with
> @border given the desired value for layout. A real boolean would do the
> same, would be easier to manage in the future (modern browsers can avoid
> parsing the value at all and only consider its presence) and I hope it can
> achieve another result. Yes, @border is presentational in that it admits
> integers and so specifically states a visual representation in detail. Other
> attributes are still "presentational" like @open but mean more. Let @border
> belong to this family, keep it as stated in the past and maybe also the
> WHATwg will accept and suppress this silly gap. Seriously, it's not worth
> all this trouble.

@border already acts as a boolean. Except when its value is "0".  And also, while the empty string is conforming - as in a boolean, the value "border" (border="border"), is not conforming, as one would expect in a true boolean. 

It would certainly be possible to define it as boolean. ANd such a thing should be of help to authors. If this would make @border more ”eatable” for the opponents, the more reason to do it.

Like you, I *think* I disagree with the spec’s links between border and ”non-layout tables”. The spec(s) *only* permit(s) data tables: “Tables must not be used as layout aids.“ Hence, to say that @border indicate that it is a data table, may have the side effect of (under the table [sic! pun not quite intended]) saying that layout tables can be signalled by leaving out the border attribute.

The @border attribute can be likened to the @type attribute of <ol>: <ol type="1">. Except that for <ol>, there is no need to add type="1", as the default rendering is *correct*. And so, if you wish to use <ol> for ”layout” - or simply fine tune it for your needs, you have to use CSS [or, to a limited degree, @type itself] to remove the default  list style for <ol>. The situation for <table>, ought to have been the similar. It ought to have been the case that leaving @border=1 out and leaving it in, had the same effect. (Or better, there should have been a @borderless attribute.)

Borders by default would have made it less tempting to use borders for layout. And so, table borders by default would simply have been a technique for ”nudging”[1] people to use <table> correctly. (One could claim that all the default styles of HTML elements have the purpose of nudging authors to use the elements correctly.) The table@border attribute should be thought of in those terms. So, even if the (data) table in question fails to have border - when viewed in a CSS enabled UA, the table should still have have the border="border" attribute, to ensure a useful fallback styling.

[1] http://en.wikipedia.org/wiki/Nudge_theory
Comment 13 Leif Halvard Silli 2014-02-12 13:27:19 UTC
(In reply to Leif Halvard Silli from comment #12)
> (In reply to Andrea Rendine from comment #11)

Ah, and then cited the para bout @summary:

> ]]If a table element has a (non-conforming) summary attribute, and the user
> agent has not classified the table as a layout table, the user agent may
> report the contents of that attribute to the user. [[

I meant to cite this:

]] The border attribute may be specified on a table element to explicitly indicate that the table element is not being used for layout purposes. If specified, the attribute's value must either be the empty string or the value "1". The attribute is used by certain user agents as an indication that borders should be drawn around cells of the table.[[
Comment 14 Andrea Rendine 2014-02-12 19:16:18 UTC
(In reply to Leif Halvard Silli from comment #12)
>Are you referring to even older versions of HTML? Or some in-between version of HTML5.1, were the above passage ”fell out” of the spec?
Just look at the introduction box, it's what states what can, what cannot and what must be inserted in the element. In the older version, the spec said:
]]Content attributes:
  Global attributes
  border[[
In the current spec @border has disappeared, thus making it not conforming. But as a matter of fact in the prose it is not stated whether @border is conforming or not.

>after his edits back then.
Are you saying that it was the WHATWG (i.e. Mr. Hickson) who moved back from the adoption of conformity for @border? Or did I misunderstand?

>I have heard from David Carlisle that he (if I understood him perfectly) interpret the current text to say that *only* “certain” UAs use the @border attribute. But fact is that *all* UAs implements it. Is that your question?
I spent quite some time reading the bug you filed and Mr Carlisle's answer. Actually he only copypasted a section of W3 spec and stated something relevant about the concept of polyglot definitions. In my opinion "some UAs" refers to visual UAs, like desktop and mobile browsers and webTVs. All of them interpret @border as it is: in absence of CSS it is a fallback value for drawing borders, which are not rendered if neither @border nor CSS{border} is defined on the table. And I also think that most of them even parse the value and draw borders whose thickness is defined by it. Of course if a page is standard compliant this value can only be 1 or the empty string, which means the same.
That was my question indeed. Do browsers parse @border value and render accordingly or do they simply say the machinian translation of: "Hey, this is <table@border>. I can safely ignore the value and draw a 1px border around cells and the whole frame."

>Please be more specific about what change, 1 month ago, you refer to.
The spec as I linked it. With @border accepting only 1 and the empty string as value. Actually idk when the attribute has been removed, i think quite recently.

>@border already acts as a boolean. Except when its value is "0".  And also, while the empty string is conforming - as in a boolean, the value "border" (border="border"), is not conforming, as one would expect in a true boolean. 
At this very moment, according to the spec, nothing in @border is conforming, not even its presence. It's a good point to stop, decide to use it in a good way and give it a meaning. Alas, that value 0 prevents it from being used as a true boolean, because while in booleans all values mean the same (true), here the value 0 means "no border rendering" thus acting as a "false". But in my head canon it should be parsed as a boolean and should BE a boolean too. @border="border" could be allowed.

>to say that @border indicate that it is a data table, may have the side effect of [...] saying that layout tables can be signalled by leaving out the border attribute.
Which is indeed what the spec does.
]]Tables can be complicated to understand and navigate. To help users with this, user agents should clearly delineate cells in a table from each other, unless the user agent has classified the table as a layout table.[[
Look, I don't reject this assumption. You can see it this way: markup is constituted by all those "things" which have a meaning. Well, data table borders DO have a meaning, while a layout table doesn't need them. So it could be used as a way to sniff the purpose of tables: is the content all that matters or is content division (aka border) important too?
That's why even after the sentence I quoted above, I'd rather prefer a @border rather than a @borderless. A table is a table is a table. The default for a table is to be a table, not to have borders. Thus said, if borders have a meaning, we add them via a specific attribute. Does it work for you "logically"?
About <ol>s, also there it's something similar. Think about using an <ol> for a sports tournament, with the list items representing series. Series are usually marked with letters in some countries (e.g. here in Italy). The same for sections in a book/essay, while parts of a law text can be marked with roman numbers which are usually read as ordinals. There's space for meaning, there, too.
Comment 15 Leif Halvard Silli 2014-02-12 22:38:02 UTC
THanks Andrea. Filed a bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24636
Comment 16 Andrea Rendine 2014-02-13 00:02:46 UTC
It's a good point indeed. Now I wonder what can be done about suggesting the new syntax from my comment above. I have no official role, so I can't do a lot.
Comment 17 Leif Halvard Silli 2014-02-13 00:18:49 UTC
(In reply to Andrea Rendine from comment #14)

>> after his edits back then.
>
> Are you saying that it was the WHATWG (i.e. Mr. Hickson) who
> moved back from the adoption of conformity for @border? Or did I
> misunderstand?

Misunderstanding. <small>I don’t know how or when it happened that @border fell out the list of table attributes. What I do know is that when the HTML WG’s border decision had been made, the editor (Hixie) had the task of reflecting the decision in the spec. And he did place @border on the list of permitted attributes. But I personally was not 100% satisfied with the prose the prose he added.</small>

>> the current text to say that *only*
>> “certain” UAs use the @border attribute. But fact is that *all*
>> UAs implements it. Is that your question?

> In my
> opinion "some UAs" refers to visual UAs, like desktop and mobile
> browsers and webTVs. All of them interpret @border as it is: in
> absence of CSS it is a fallback value for drawing borders, which are
> not rendered if neither @border nor CSS{border} is defined on the
> table.

So, the prose might be clear enough, then, in that detail.

> And I also think that most of them even parse the value and
> draw borders whose thickness is defined by it.

I have not seen evidence of that. The UAs I tested do make the frame/border around the very table element thicker - as required by the rendering section of HTML5. However, the very table elements are not made thicker - which is also what the rendering section says.

> Of course if a page
> is standard compliant this value can only be 1 or the empty string,
> which means the same.  That was my question indeed. Do browsers
> parse @border value and render accordingly or do they simply say the
> machinian translation of: "Hey, this is <table@border>. I can safely
> ignore the value and draw a 1px border around cells and the whole
> frame."

Yes they do, for the cells. But not for the very table element.

>> Please be more specific about what change, 1 month ago, you refer to.
>
> The spec as I linked it.

Thanks! As you know, I have now filed a about that detail.

>> @border already acts as a boolean. Except when its value is "0".     
>> And also, while the empty string is conforming - as in a boolean,    
>> the value "border" (border="border"), is not conforming, as one      
>> would expect in a true boolean.                                      
>
> At this very moment, according to the spec, nothing in @border is
> conforming, not even its presence.

Yep. Hence the bug I mentioned above.

> It's a good point to stop, decide
> to use it in a good way and give it a meaning. Alas, that value 0
> prevents it from being used as a true boolean, because while in
> booleans all values mean the same (true), here the value 0 means
> "no border rendering" thus acting as a "false". But in my head
> canon it should be parsed as a boolean and should BE a boolean too.
> @border="border" could be allowed.

It could be a ”true boolean” to authors, I think. The error default of border="not-a-number" is that the user agent defaults to border="1". This is specified in the spec somewhere. (At least it used to be.)

>> to say that @border indicate that it is a data table, may have the
>> side effect of [...] saying that layout tables can be signalled by
>> leaving out the border attribute.

> Which is indeed what the spec does. 
  […]
> That's why even after the sentence I quoted above, I'd rather prefer a
> @border rather than a @borderless. A table is a table is a table. The
> default for a table is to be a table, not to have borders. Thus said,
> if borders have a meaning, we add them via a specific attribute. Does
> it work for you "logically"?

I think I can see your point. E.g. it is not so that data tables in text browsers (like Lynx or W3m) absolutely always ought to have borders.
Comment 18 Leif Halvard Silli 2014-02-13 00:32:08 UTC
(In reply to Leif Halvard Silli from comment #17)
> However, the very table elements are not made thicker - which is
> also what the rendering section says.

Typo: Meant that hte the *cells* are not made thicker.
Comment 19 Leif Halvard Silli 2014-02-13 00:57:07 UTC
(In reply to Andrea Rendine from comment #16)
> It's a good point indeed. Now I wonder what can be done about suggesting the
> new syntax from my comment above. I have no official role, so I can't do a
> lot.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24641
Comment 20 Leif Halvard Silli 2014-02-13 01:17:21 UTC
(In reply to Leif Halvard Silli from comment #19)
> (In reply to Andrea Rendine from comment #16)
> > It's a good point indeed. Now I wonder what can be done about suggesting the
> > new syntax from my comment above. I have no official role, so I can't do a
> > lot.
> 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24641

I wonder if the spec statement that border indicates “not for layout” should just stand as it is.
Comment 21 Andrea Rendine 2014-02-13 02:09:31 UTC
I don't know when @border fell out of allowed values. I think it has been done just to reflect in W3 spec what is stated in WHATWG spec. At least I hope so.

(In reply to Leif Halvard Silli from comment #20)
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24641
>
>I wonder if the spec statement that border indicates “not for layout” should just stand as it is.

Right and clear. This is what I meant some time ago! In my opinion the spec should not focus on "data tables" vs "layout tables", but on "meaningful borders" vs. "presentational borders". Finally it is the same -for readability purposes, when tables are used to display data, borders have to be there, while in presentation they have no meaning. If we assume the ratio
meaning : markup = layout : stylesheet
in data tables, a strong markup trigger (as you wrote in the new report) for the border is needed. So the spec could say that table must not be used for the structure of a Web page, rather than saying generically "for layout" (where such layout is NOT allowed. 
Then the spec should state that tables can be used to display limited amount of content in grid format in a consistent way (perhaps with @role="presentation").
Proceeding, instead of talking about layout/non-layout table, it should take into account that "the content and/or the meaning conveyed by the author is usually beyond the mere content of tabular element, and extends to their representation as a raw-column grid, where horizontal/vertical rules help the user understand data association". And explain that the boolean border attribute can be used for this purpose, thus making it the ideal/necessary choice for data tables (nudge theory, wasn't it?).
Finally it should say that historical number values are derived from the old syntax of the attribute and are **NOT** required to be parsed. Just the presence of the attribute (or lack thereof) is important. Instead, the empty string and every not-a-number string trigger the "invalid value default" in legacy visual user agents.
Just in my mind, of course.
Comment 22 Leif Halvard Silli 2014-02-13 10:02:22 UTC
(In reply to Andrea Rendine from comment #21)

> In my opinion the spec
> should not focus on "data tables" vs "layout tables", but on "meaningful
> borders" vs. "presentational borders". 

I tried to add that perspective in bug 24647.

Also see bug 24642.
Comment 23 Andrea Rendine 2014-02-13 12:29:43 UTC
Dear Mr. Sili, while all these issues were discussed in this bug, which has evidently become our personal message board (as nobody cares to post a reply and discuss it further with us), the other bug files have been resolved with the decision WONTFIX, as nobody is probably interested neither in readability nor in the decisions made by the WG. According to questionable opinions, @border comes in contrast with the statement that presentational attributes have been expunged. Because @hidden, @width, @height, ol@type, are very very very very different from it. And because community decisions aren't worth that much when the bosses speak.
Let's move on.
Regards.