D&C Lug - Home Page
Devon & Cornwall Linux Users' Group

[ Date Index ][ Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] CSS reference extended, as requested



On Wednesday 25 Jun 2003 5:47 pm, Jonathan Melhuish wrote:
> > Access for those who cannot read the page for whatever reason is
> > improved if the layout is rendered in CSS rather than tables.
>
> Can screen-readers not cope with tables?  What is it about CSS that makes

Screen readers cannot cope with LAYOUT tables. A table used for tabulated data 
is more or less manageable and is made easier with the newer table related 
HTML tags like <colgroup> <col>, more use of older ones that aren't used 
much: <th>, <caption>, and most importantly, proper use of the "one cell - 
one line - one row" principle:

cell1     cell2    cell3
cell4     cell5    cell6

This table segment should be created thus:
<tr><td>cell1></td><td>cell2</td><td>cell3</td></tr>
<tr><td>cell4></td><td>cell5</td><td>cell6</td></tr>

NOT:

<tr><td>
cell1<br>
cell4</td>
<td>cell2<br>
cell5</td>
<td>cell3<br>
cell6</td></tr>

The first table can be easily parsed by speech browsers: each cell will be 
read in the correct sequence. The second will parse as cell1 cell4 cell2 
cell5 cell3 cell6 - completely losing the 'meaning' of 
the table. If you need to break a line, use rowspan and colspan, NOT br.

<colgroup> and <col> are useful because (used properly) they allow the browser 
to predict the absolute size of the table and all cells before receiving the 
entire table HTML code. So for long tables, the text/speech can begin at row 
1 without having to wait for row 100 to download.

The CSS comes in at this point - CSS REMOVES the need for layout tables and 
therefore is intended to leave only genuine tabulated data in tables.

> it easier to "read"?

The W3C HTML4 intention is for layout tables to be made extinct and all layout 
to be done utterly and solely by CSS. The remaining tables should then use 
the newer and less common tags to correctly represent the data in a usable 
sequence.

It is ongoing - there are still some pages where problems arise:
1. Browser support is almost there but not quite.
2. Some pages just seem to be awkward to get the correct CSS layout. It'll 
take me a bit longer but I am still working on those pages.

Next on the agenda is for the stylesheet to automatically take into account 
the 'media' in use - screen, print, speech, text, etc. With ALL the layout 
and presentational constructs solely in CSS, the 'media' setting can control 
the rest of the job.

HTML is for information.
CSS is for presentation.

>
> Sorry for my ignorance, I'm afraid I shall probably stay that way unless
> somebody gives me a compelling reason to change ;-)

Your code will simply not work. Browser support for deprecated tags WILL be 
withdrawn - the conflicts with the new HTML4/CSS methods are too widespread 
to maintain, especially with the new CSS2 properties. Only the simplest pages 
and the standard compliant pages may survive. No Bad Thing. As CSS2 becomes 
more widespread, things like <font>, <center>, hspace, background, align and 
<align> will simply become impossible to fit into the engine - the deprecated 
tags are too crude and blunt, coping with the older tags whilst still 
rendering the detail and precision of CSS2 just doesn't appear worthwhile.

Bad HTML code (like using <p><p> instead of <p></p>, missing of </li> or 
</option>) already causes the page to be displayed wrongly. It can only get 
worse.

-- 

Neil Williams
=============
http://www.codehelp.co.uk
http://www.dclug.org.uk

http://www.wewantbroadband.co.uk/

Attachment: pgp00011.pgp
Description: signature


Lynx friendly