Re: ISSUE-130 table-layout - Chairs Solicit Alternate Proposals or Counter-Proposals

Doug Jones, Fri, 14 Jan 2011 17:16:02 -0500: 
> On 2011 Jan 14, at 15:31, Leif Halvard Silli wrote:
>> Doug Jones, Fri, 14 Jan 2011 14:34:48 -0500:

>> http://www.w3.org/html/wg/wiki/ChangeProposals/NoLayoutTable

> 
>> Some comments:
> 
>> FIRSTLY: The HTML4 yoru CP points to says 'should not' and not 'must 
>> not'. Thus it is incorrect to claim that HTML4 does not permit tables 
>> to be used for presentational forces.
> 
> Yes, you are correct. However, I take it that since 1999 the 'should 
> not' is a strong suggestion not to use tables for page layout.

If you think that HTML4's 'should not' can be interpreted like that, 
then it should be ok to simply change your CP into saying what HTML4 
actually says - it won't weaken your argument.

>> SEONDLY: Those problems that HTML4 describes are much less relevant 
>> today. It is enough to look at the dichotomy that HTML4 describes - and 
>> which you echo: 'authors should use style sheets to control layout 
>> rather than tables'. As things have developed, this has become largly 
>> false dichotomy - exactly via CSS, authors can control tables. In fact 
>> is possible to read what HTML4 says as saying «rather than trusting 
>> tables, authors should trust css». Those problems which HTML4 describes 
>> are such that I have trouble understanding what the description is 
>> about - but it is more about function than about philosophy.
> 
> I interpret it that the function of a table in HTML4.01 and HTML5 is 
> to provide information in a specific semantic form. More styling for 
> this purpose has been moved from HTML to CSS today.

Agreed. And my principal standpoint is that one shouldn't use table for 
layout purposes.

> Just because a 
> table can be styled via CSS doesn't mean it is part of CSS intended 
> for gross page layout.

But it might mean that the problems listed then could be styled away. 
The start of your CP simply qutoes the two reasons found in HTML4:

1) "may present problems when rendering to non-visual media"
2) "with graphics, these tables may force users to scroll 
    horizontally to view a table designed on a system with
    a larger display"

I don't know what a 'larger display' was in 1999. But I believe it 
would be possible to style away the scroll problem. It is also, the 
opposite way, possible to apply display:table etc to non-table 
elements, thus reproducing the horizontal scroll problem, even without 
using a table. I therefore think that the second problem is somewhat 
irrelevant.

It would be interesting to know more about the non-visual media 
rendering problems. We know that, as things are, screenreaders have to 
find out, by themselves, which tables are layout tables. Seemingly, 
they do a decent job. But that is also a category of UAs which can 
benefit from permittance to use @role for declaring layout tables.

>> THIRDLY: No risks, you say. But perhaps there is a risk that authors, 
>> who could have increased their pages' accessibility by  adding aria to 
>> their table based pages, just let their pages be as they are, because, 
>> after all, their pages causes no error in theor current state, while 
>> they would get validation errors if they added aria to their tables.
> 
> It sounds like you are assuming that authors who thought little of 
> accessibility would go back and edit those pages now. Hopefully, 
> they would want to, but there would need to be more work done than 
> just marking the role of the page table. Changing the page table 
> layout to sections would seem trivial in comparison.

In HTML4, as things developed, authors ended up with an illogical 
choice between transitional and strict modes - illogical because the 
first option included not only another mode but also more features 
(e.g. the target attribute) than the latter option. 

I don't think that we should produce a situation where authors have to 
make the same illogical choices again.

Example: The current (i.e. year 2010 ) versions of Freeway, an WYSIWYG 
HTML generator from Softpress, allows authors a choice betwen table 
based and non-table based design. And for the non-table modes, it 
allows 3 levels: IE6-compatible, IE7-compatible and "normal". It also, 
regardless of mode, produces valid HTML. It also offers an 
accessibility report.

If a Freeway user can produce table based layout, with HTML5 video 
elements and more accessibilty by adding ARIA, then that should be an 
option. I doubt that a professional HTML generator can tell authors 
that "ok, you may use table based designed, but if you do that, then 
you aren't allowed to use the HTML5 video element" - or "then you may 
use the HTML5 video element, but you may not use ARIA" - or "then you 
may use the HTML5 video element, but we won't help your users with 
regard to the layout tables".

>> As for the third, point, then I don't agree with myself. I tend to 
>> agree with Ian in that an honest @role is a 'godsend', which allows 
>> authors to check whether they have used an element for a valid purpose. 
>> Perhaps the solution is to place ARIA validation in another cathegory 
>> in 'normal' validation.
> 
> I am not a professional web developer. Although my comments may 
> (even to me, after feedback) sometimes seem naive, I believe they 
> are a type that are important. I require a clear spec, and I view 
> HTML5 (compared to HTML4) a godsend. It is people like me that have 
> to have the opportunity of clarity and relative simplicity of 
> explanation so we don't make a 'mess' of the web.

Our design principles says that we should consider users over authors 
... 

But any way, HTML5 have at least two alternative options: 

1) it could say that tables should not be used for layout - and nothing 
more. It doesn't need, for that reason, to require validators to emit 
an error when @role is used to express that a table is used for layout 
purpose.

2) it could do the same as in 1) but also introduce some sort of 
consistensy validation. As an example of what validators could do: 
validator.nu offers an optional, extended image validation feature to 
help authors analyse if they have added <img>s correctly. Validator.nu 
could offer something similar for tables.

[ snip ]
-- 
leif halvard silli

Received on Friday, 14 January 2011 23:38:09 UTC