- From: Liam R. E. Quin <liam@w3.org>
- Date: Fri, 18 Dec 2015 20:16:28 -0500
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>
On Thu, 2015-12-17 at 14:32 -0800, Tab Atkins Jr. wrote: > On Wed, Dec 16, 2015 at 9:20 PM, Liam R. E. Quin <liam@w3.org> wrote: > > [...] > The big issue to me is still figuring out how to handle merged > elements. As proposed, multiple DOM elements still get merged in > display, and it's unclear how it's supposed to determine which > element the text "ends up in". Yes. For merged numbers, e.g. 14, 15, 16, 17 displayed as 14–17, the 14 needs to be a link to the start of the discussion and, ideally, the 17 a link to the end of it (the dash doesn't need to be a link, but if it is, should go to page 14 again, to make life easier for tablet and telephone users). it's also important that the page numbers in the index are hyperlinks in PDF. So I don't _think_ your string approach would work. In adidtion, note that there is formatting in the list - some numbers are bold, some are italic, some are plain, depending on the nature of the thing being referenced in the index. So a sequence of strings might work but not a single string. (this problem occurs elsewhere in gcpm, and more recent approaches have tried to resolve it, more or less clumsily, but we should take it into account in the design rather than having to retrofit structure later). I think this means we're probably stick with the "hand-generated" list of a elements (there are Python and ruby and XSLT and XQuery scripts that people use in practice), but that's not necessarily a bad thing. At the very least, the formatting and the generation of the "intermediate" form could be considered as separate, related, items. Liam
Received on Saturday, 19 December 2015 01:16:31 UTC