- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Thu, 2 Dec 2004 22:58:41 +0000 (GMT)
- 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 UTC