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

Sam Ruby, Sat, 16 Apr 2011 06:05:43 -0400:

> In general, there are two basic approaches for dealing with changes 
> that are found to be inaccurate, incomplete, or go beyond the 
> decision in ways that are problematic:
> 
> 1) Agreeing that the change is a reasonable new baseline, and working 
> with the editor, via discussion and/or bug reports, to refine and 
> improve the specification.
> 
> 2) Objecting to a commit on the basis that it doesn't reflect the 
> decision, and asking that it be reverted.

I hereby object to the commit. Below follows annotated text from the 
check-in, [1] to show what I object to:  4 pieces of it is marked up as 
<INTOLERABLE>. 9 pieces are marked up as <QUESTIONABLE>. A 
<!--comment--> follows each marked up text bit. 2 of the questionable 
bits depends on a fix in '4.9.1.2 Techniques for table layout': fix 
those and they are not questionable anymore. The other questionable 
items can, if Ian doesn't agree in this round, be tracked separately.

]] 
and the user agent has not classified the table as a 
<QUESTIONABLE>layout table</QUESTIONABLE>
<!--
BECAUSE: a) Decision/CP1 doesn't talk about 'layout table'; 
         b) 'layout table' is undefined;
         c) Since ISSUE-130, spec already uses "layout aid"
         d) ISSUE-130 also gave us "presentation"
INSTEAD: Either borrow 'layout aid' or use 'presentation grid'.
-->
[[

]]
<INTOLERABLE>
The border attribute may be specified on a table element to explicitly 
indicate that the table element is not being used for layout purposes.
</INTOLERABLE>
<!--
BECAUSE: a) seems to forbid <table role=presentation border=1 >,
            which was never the intention the prevailing CP.
         b) border=1 should remain orthogonal to 'layout purposes'
            and not thread on the toes of ISSUE-130.
         c) prevailing CP1 says "recommend" and not "may" about 
            use of border=1
         d) a consequence of c) is to use positive language rather
            than "is not" language.
INSTEAD: "It is RECOMMENDED to specify the border attribute on a 
          table element that is used for table purposes."
-->

If specified, the attribute's value must either be the empty string or 
the value "1". 
<!-- Good, Ian, that you say that value can be empty string! -->
<INTOLERABLE>The attribute is used by certain user agents as an 
indication that borders should be drawn around cells of the 
table.</INTOLERABLE>
<!--
BECAUSE: CP1/objections: only Lynx doesn't support @border/borders
         Thus there are no exceptions to this rule. It is Lynx that
         needs to be repaired and it should be encouraged to do so.
         The word "certain" is misleading.
         Aryeh's objected to no-change CP by stating that _all_ 
         UAs are obligated to follow HTML5's Rendering section.
INSTEAD: "The attribute is used by user agents, when CSS styling
         is unavailable, as an indication that borders should be
         drawn around cells of the table."
-->

Tables can be complicated to understand and navigate. To help users 
with this, user agents should clearly dilineate cells in a table from 
each other 
<QUESTIONABLE>
, unless the user agent has classified the table as a layout table.
</QUESTIONABLE>
<!--
BECAUSE: a) borders might be used on tables used for layout;
         b) gives the impression that UA can choose to not 
            display borders if it finds it is a layout table
            - or is this meant to justify that lack of @border
            causes no borders to be drawn? Very unclear.
         c) Please note that <table>s by default has cell-spacing,
            which could be said to be something that delineate
            cells. 
         d) the prevailing CP and the prevailing objections 
            recognize that UAs draw borders when @border is
            present, irrespective of whether the table has
            role=presentation
INSTEAD: Delete it. Or add more info. E.g. state that the above 
         only counts for non-visual user agents.
         PS: 'delineate' and not 'dilineate' 
         http://dictionary.reference.com/browse/delineate?db=dictionary
-->

<QUESTIONABLE>
Authors and implementors are encouraged to consider using some of the 
table layout techniques described below to make tables easier to 
navigate for users.
</QUESTIONABLE>
<!--
BECAUSE: As long as the table layout techniques doesn't mention 
         use of @border, then this advice is questionable.
-->

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:

<QUESTIONABLE>
 [ There lacks a mention of the hierarchy in the table below.
   The table seems to violate layers.]
</QUESTIONABLE>
<!--
BECAUSE: a) Table steps on the toes of ISSUE-130 (see below)
         b) for AT role=presentation *declares* = doesn't indicate
         c) non-AT shouldn't remove borders due to role=presentation
INSTEAD: Add a caption which says that the table rows appears in order
         of importance. E.g. border=1 is more important than 
         td{border:0}. And role=presentation is even higher, and yet
         does't matter for non-AT.
-->

<TABLE>
 - Feature 
 = Indication
  ------------
<QUESTIONABLE>
 - The use of the role attribute with the value presentation
</QUESTIONABLE>
<!--
BECAUSE: a) AT consider role=presentation as layout table signal
         b) it's layer violation to ask other UAs remove borders
            because role=presentation is present
INSTEAD: Add a separate, *certain* indication for this option and
         say that only AT respects it.
-->
 - The use of the border attribute with the non-conforming value 0
 - The use of the non-conforming cellspacing and cellpadding 
   attributes with the value 0
 = Indication: Probably a <QUESTIONABLE>layout table<QUESTIONABLE>
<!--
BECAUSE: see above
INSTEAD: "Probably a layout aid/presentation grid."
-->
  ------------
 - The use of caption, thead, or th elements
 - The use of the headers and scope attributes
 - The use of the border attribute with a value other than 0
 - Explicit visible borders set using CSS
 = Indication: Probably a <QUESTIONABLE>non-layout table
</QUESTIONABLE>
<!--
BECAUSE: enforces the 'layout table' terminology.
INSTEAD: just say 'table'.
-->
  ------------
 - The use of the summary attribute
 = Indication: Not a good indicator (both layout and non-layout
   tables have historically been given this attribute)
</TABLE>
[[

]]
  4.9.1.2 Techniques for table layout
  Good table layout is key to making tables more readable and usable.
  In visual media, providing column and row borders and alternating row 
backgrounds can be very effective to make complicated tables more 
readable.
  For tables with large volumes of numeric content, using monospaced 
fonts can help users see patterns, especially in situations where a 
user agent does not render the borders. 
<INTOLERABLE>
(Unfortunately, for historical reasons, not rendering borders on tables 
is a common default.)
</INTOLERABLE>
<!--
BECAUSE: - doesn't say that @border makes UAs render borders by default
         - the word "common" gives impression that there are exceptions
         - the word "unfortunately" adds nothing, and is unhelpful for
           authors.
INSTEAD: "(For historical reasons, unless the border attribute is 
          specified, not rendering borders on tables is the default.)"
-->

  In speech media, table cells can be distinguished by reporting the 
corresponding headers before reading the cell's contents, and by 
allowing users to navigate the table in a grid fashion, rather than 
serialising the entire contents of the table in source order.

<INTOLERABLE>
  Authors are encouraged to use CSS to achieve these effects.
</INTOLERABLE>
<!--
BECAUSE: It goes against Decision to not mention @border as 
         a technique.
INSTEAD: "Authors are encouraged to specify the border attribute
         and to use CSS to achieve these effects."
-->
<QUESTIONABLE>
  User agents are encouraged to render tables using these techniques 
whenever the page does not use CSS and the table is not classified as a 
layout table.
</QUESTIONABLE>
<!--
BECAUSE: The last line above is implementation advice (it has 
         class="impl"). To say that implementations should be 
         "using these techniques" is not OK as long as you don't
         mention border as one of the techniques.
-->
[[

[1] http://html5.org/tools/web-apps-tracker?from=6007&to=6008
-- 
Leif Halvard Silli

Received on Sunday, 17 April 2011 03:06:36 UTC