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

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

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

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

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

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

Received on Tuesday, 11 February 2014 23:44:40 UTC