[Bug 24647] Define table@border as explicit indication that the *borders* are meaningful

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

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

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

Received on Friday, 14 February 2014 23:04:20 UTC