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

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 

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:
> 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 

The same point is repeated in the index section: [3] ]]Explicit 
indication that the table element is not being used for layout 

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.


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 

leif halvard silli

Received on Friday, 15 April 2011 19:09:27 UTC