Re: Working Group Decision on ISSUE-155 table-border

I'm sorry I did not read the editor's check-in [0] before. Here are two 
additional points. I hope someone spots a clear way out of this ... 

FIRSTLY, The spec now has a section on "Techniques for table layout"- 
[1] (why not 'Techniques for table design' to avoid associations with 
"layout table"?) 

 On the good side, this section now *does* mention use of other 
techniques, such as zebra striping, for highlighting table structure - 
the adopted CP mention this.

 But one should also think that the table design section would be a 
good place to recommend the use of @border too. The fact that the spec 
now, as well, says that """The border attribute may be specified on a 
table element to explicitly indicate that the table element is not 
being used for layout purposes""",  points to the same conclusion.

 But the only thing the table design section says about @border, is 
this:

  ]](Unfortunately, for historical reasons, not rendering borders
    on tables is a common default.) [[
and 
  ]]Authors are encouraged to use CSS to achieve these effects.[[

 Why not mention that UAs fortunately *do* default to display borders 
when a valid HTML5 @border attribute is present?
 Why not *recommend* the use of @border? Like the adopted CP says: [3] 
"""Which is why HTML5 should permit and recommend the use of border="1" 
on table."""
 Regarding CSS, why not present CSS as a way to provide *enhancements* 
for those UAs which do support CSS?

    Above 3 things had been in line with the decision, it seems.

SECONDLY, the check-in added a 'heuristic table' for deciding when a 
table is a "layout-table" vs a "non-layout table". (Why not say "layout 
grid/presentational grid" versus "table" instead of the the odd 
"non-layout-table"?) The intro to the heuristics table says:

]] User agents, especially those that do table analysis on arbitrary 
content, are encouraged to find heuristics to determine which tables 
actually contain data and which are merely being used for layout. This 
specification does not define a precise heuristic, but the following 
are suggested as possible indicators: [[

[ The table, abbreviated for e-mail presentation: ]
_
  role=presentation - Probably a layout table
           border=0 - Probably a layout table
     @cellspacing=0,
     @cellpadding=0 - Probably a layout table
—
            caption,
              thead,
                 th - Probably a non-layout table
           @headers,
             @scope - Probably a non-layout table
          @border=1,
         @border="",
        @border=999 - Probably a non-layout table
visible CSS borders - Probably a non-layout table
—
 @summary attribute - Not a good indicator
—

	On the good side, the heuristics table provides info which is not 
taken out of the air. E.g. it touches upon issues in the adopted CP, in 
the objections and in some bug reports.

 However, there are still a number of problems with it:

 *) Is a table like that within the Decision?
    May be in principle. But not as it stands.
    There were nothing in the decision about how UAs should
    interpret border, semantically.
 0) Is there doubt that role=presentation causes a "layout table"?
 1) What *is* a layout table? It seems that at more correct
    term would be 'presentational grid/layout grid'.
 2) W.r.t the phrase "actually contain data", what is 'data'? Any
    Web page without data is doomed. The real issue is whether
    the table is used because of its table semantics/features,
    and not whether it contains "data". 
 3) Are there any <table role=presentation> tables that should
    *not* be interpreted as presentational/layout tables?
    The first table row of the table hints there could be.
 4) Does the table list features in order of priority? It would
    need to be stated if it is meant that <table border=1>, for the
    heuristic interpretation, is to be considered more important 
    than <style>td{border:0}</style>
 5) The table is very focused on visual matters and IMHO  
    mixes invisible border with presentational/layout table.
 6) W.r.t. 5), in case of <table role=presentation border=1>
    then what? A presentational table might have been used for its
    visual effects, including the borders. It would be wrong,
    for a simplistic text browser, to not render the border just
    because there is a role=presentation.
    (That is: the 1px borders that HTML5's Rendering section
    suggests should be rendered regardless of role=presentation).
 7) The WYM editor is mentioned in my objection [4] as example 
    of an editor which supposedly is semantic but which 
    nevertheless provides neither @border nor CSS borders.
    [This is bad of WYMeditor to do, of course.]
 8) W.r.t. 5), invisible CSS borders sounds like a bad criteria.
    E.g.the author could use empty space as a kind of border. 
 9) The heuristics table attempts a 'semantification' of CSS 
    borders. Not sure it benefits at all to mention CSS here - it 
    only results in blurring the role or @border.
10) The decision makes border="1" valid, but the table
    speaks about: """The use of the border attribute with a value
    other than 0""".  It should single out the border="1" since
    it is a valid value. (Or else HTML5 should make any value
    other than 0 valid - or something like that.)
     
 Summary:

 Should that table, in a edited form, rather go into the 'Techniques 
for table layout' section, as advice about how to author tables? Then 
it would speak about something which the decision spoke.

 I agree that, in general, border=1 and the the elements and attributes 
that the table mentions (if they are valid) *should* at best be 
reserved for tables that are tables, and preferably not be used for 
tables that are layout grids. There are part of the CP and my objection 
which support this (at least w.r.t. @border.) But, nevertheless, <table 
border=1 role=presentation> *is* valid.

 There seems to be an assumption here that 'layout table' = no borders 
= role=presentation. But in reality, with role=presentation, the 
presentation state of the <table> has become completely orthogonal to 
@border.

 The solution to many of the problems that the table assumes, can be 
solved by simply recommending use of @border=1. For any table with 
border=1, the border should be rendered. End of story. We will never 
see a graphical user agent which, unless CSS disables it, fails to 
render borders for <table border=1>.

[0] http://html5.org/r/6008

[1] http://dev.w3.org/html5/spec/tabular-data#table-layout-techniques

[2] http://dev.w3.org/html5/spec/tabular-data.html#attr-table-border

[3] http://www.w3.org/html/wg/wiki/ISSUE-155-CP1#Summary

[4] 
http://lists.w3.org/Archives/Public/www-archive/2011Apr/att-0043/ISSUE-155-objection-lhsilli.html


Leif Halvard Silli

Leif Halvard Silli, Fri, 15 Apr 2011 21:08:55 +0200:
> Maciej Stachowiak, Wed, 13 Apr 2011 20:01:45 -0700:
> 
> Chairs, thank you. I'm considering follow-ups w.r.t. the "loose ends", 
> such as @cellspacing and the question about whether "0" as well as the 
> empty string should be a conforming value of @border etc.
> 
> However, for now I have some trouble with Ian's implementation of the 
> decision.  Please read my evaluation and below and help directing the 
> editor.
> 
> First the Decision:
> 
>> *** Decision of the Working Group ***
>> 
>> Therefore, the HTML Working Group hereby adopts the "enable all users
>> to distinguish the cells of a table " Change Proposal for ISSUE-155:
>> 
>>   http://www.w3.org/html/wg/wiki/ISSUE-155-CP1

>> 
>> Of the Change Proposals before us, this one has drawn the weaker
>> objections.
>> 
>> == Next Steps ==
>> 
>> Bug 7468 is to be REOPENED and marked as WGDecision.
>> 
>> Since the prevailing Change Proposal does call for a spec change, the
>> editor is hereby directed to make the changes in accordance to the
>> change proposal.  Once those changes are complete ISSUE-155 is to be
>> marked as CLOSED.
> 
> The core of the CP1 is expressed in its Details section. [1]  In 
> checking whether Ian has implemented Details, I find this:
> 
> (1) The Details section lists a spec text to go into the Obsolete but 
> conforming section, of which the gist could be said to be that other 
> values than border="1" are obsolete but conforming. To quote the 
> specific prose suggested in the CP: "Other values are considered 
> obsolete". This has not been added to the spec yet.
> 
> (2) For first list item of Details, then it has 4 sub items:
> 
>  1st sub item is fulfilled - @border has been added.
> 
>     2nd sub item says "add prose describing the importance of helping 
> users to 'distinguish the cells of a table'" (by the use of @border). 
> The phrase 'distinguish the cells of a table' is quoted from HTML4, as 
> the link tells. I suggest that editor uses that quote from HTML4 in in 
> HTML5 too. 
> 
>  3rd sub item says that HTML5 should describe other (CSS) ways to 
> achieve the same effect that @border gives. This is not mentioned in 
> spec yet.
> 
>  4th sub item speaks about how, instead of the CSS etc mentioned in 3rd 
> sub item, @border=1 can be used for fallback styling. And HTML5 now 
> perhaps partly touches this, by stating this: [2]
>     ]] The attribute is used by certain user agents as an indication 
> that borders should be drawn around cells of the table.[[
>  However, "certain user agents" doesn't feel right when it more the 
> opposite: only a certain few fail to draw borders ...
> 
>     W.r.t. sub item 2, 3 and 4, then I'll note that the paragraph 
> beneath Ian's new @border paragraph states: "Tables can be complicated 
> to understand and navigate." In that regard, the gist of CP1 is that 
> borders can help in navigating and understanding tables. So it 
> should/could perhaps be possible to fuse the old and the new text?
> 
> (3) Finally, the editor states one thing that is outside the CP:
> 
> ]] The border attribute may be specified on a table element to 
> explicitly indicate that the table element is not being used for layout 
> purposes.[[
> 
> The same point is repeated in the index section: [3] ]]Explicit 
> indication that the table element is not being used for layout 
> purposes[[
> 
> This is not true. In case of <table role=presentation border=1>, then 
> the table element *is* used for its layout effects. (role=presenation 
> is btw discussed both in objections to the no-change CP as well as in 
> CP1. [4])
> 
> It would instead be in line with CP1 as well as with the objections to 
> the no-change CP to state the *opposite*: to deemphasize that <table> 
> is in fact a table, then the border attribute may be omitted. 
> 
> Even HTML5 itself currently states that the mere presence of @border 
> causes borders to be rendered when its value is the empty string [which 
> is how even HTML4 specs it], as well as when its value is zero 
> (border="0") [which is a new HTML5 invention, for which there already 
> is a bug]. Layout tables will continue to be made, and - with the 
> current status of HTML5's Rendering section - omitting @border is the 
> only way to ensure that CSS-hindered UAs do not render borders.
> 
> Summary:
> 
> Thus, I don't consider that the Decision has been fully fulfilled yet. 
> I perhaps should be more direct in what I expect (or CP1 should have 
> used more spec text). But for now, this is what I have to say. It is 
> difficult to consider the next steps until the Decision has been fully 
> implemented.
> 
> [1] http://www.w3.org/html/wg/wiki/ISSUE-155-CP1#Details

> [2] http://dev.w3.org/html5/spec/tabular-data#attr-table-border

> [3] http://dev.w3.org/html5/spec/index#attributes-1

> [4] http://www.w3.org/html/wg/wiki/ISSUE-155-CP1#Negative_Effects

> -- 
> leif halvard silli
>

Received on Saturday, 16 April 2011 03:23:39 UTC