W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2004

Re: Suggestions?

From: David Woolley <david@djwhome.demon.co.uk>
Date: Thu, 2 Dec 2004 22:58:41 +0000 (GMT)
Message-Id: <200412022258.iB2Mwfn13924@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org

> 
> Usually you could create two paragraphs with four span elements each
> (including the corresponding text parts) and then use the CSS snippet "p {
> display: table-row; }" and "span { display: table-cell; }". Unfortunately,
> this doesn't work in certain major user-agents.

The problems with this approach are that:

- the second line is not actually a paragraph;
- you've split the labels from what they label, and because of this layout,
  it is unlikely that normal "screenreaders" will put it back together
  sensibly;
- you've broken the ablility to sensibly reflow, and may, with some layouts,
  actually get the text clipped or overwriting sidebars.

Whilst this isn't really Ruby, which would have the translation and/or
transliteration in parallel,  rather than just reference tags, Ruby should
probably be considered as it is supported by most installed browsers, and
it does fallback reasonably well (tags interleaved with user chose 
punctuation).

The disadvantages of Ruby are that:

- not many browsers other than IE support it at all;
- IE doesn't fully support it;
- there isn't a standard HTML DOCTYPE that covers its use in HTML browsers;
- I think the standard simply Ruby fallback would put the labels after the
  phrase to which they apply, when the correct linearised form is almost 
  certainly for them to precede the phrase.

Treating this as simply marking sections for reference, I would think
that the most accurate markup is actually to use target type anchor
elements, rather than span.  Of course, normal browsers don't indicate
the target of taken links precisely enough to simply use links.  Logically
this would be an appropriate place to use title attributes, but I don't 
think these would be prominent enough for visual users in this application.
One could colour the phrases, but you can't rely on that as the only
method, and probably shouldn't use more than two colours (one light, one
dark).  I'm not sure what DOM based "screenreaders" will do with any of 
these approaches.

> 
> Alternatively, you can use one paragraph which includes all the eight span
> elements and then float all these: "p span { float: left; width: 7em; }" --
> but don't forget to donate the fifth span element a "clear: left;". Its flaw
> is that the text in the first row, your sample sentence, will look

As well as some of the problems for the first approach, this is stricly
a visual only hack.

> "interrupted", which you can in turn try to avoid by giving visually
> associated span elements individual width assignments.

width is not a valid CSS attribute for span unless you first force that to
display: block, which is getting very messy.

> > Line	Donec lacus nulla, blandit scelerisque, consequat vitae, sollicitudin
> > 5	  vel, lacus. [...]
> 
> The basic problem I see here is text scaling, so all usual attempts (the
> table approach, too) will fail when text is scaled -- so a block originally

If this isn't line oriented poetry, I would say that it is too far into
the presentational camp to use HTML.  First, as I said before (with some
typos), he should try thinking outside the box and address the real problem,
which is presumably telling the user where to find specific features in the
text.  However, if this really is prose which has to be in a fixed layout
purely to allow parts of it to be referenced from other text without 
hyperlinks, I would have to make the controversial suggestion that he
should use (hand) tagged PDF, which can ensure a fixed layout but also 
exclude the extraneous line number from the underlying true content.
Received on Friday, 3 December 2004 07:36:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:18 GMT