[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

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xn--mlform-iua@xn--mlform-i
                   |                            |ua.no

--- Comment #2 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(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?

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

Received on Thursday, 6 February 2014 11:19:37 UTC