W3C home > Mailing lists > Public > www-validator-cvs@w3.org > February 2014

[Bug 24559] Nu Markup Checker emits "Use CSS instead" help message for table@border=1

From: <bugzilla@jessica.w3.org>
Date: Thu, 13 Feb 2014 02:09:31 +0000
To: www-validator-cvs@w3.org
Message-ID: <bug-24559-169-k7KveUQd4G@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24559

--- Comment #21 from Andrea Rendine <master.skywalker.88@gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 13 February 2014 02:09:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:17:56 UTC