[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Need Clarification on Implications of Different List Markup Patterns
I'm trying to do a little implementation work on the DITA2InDesign processor and worked yesterday on implementing the mapping of list items to the appropriate InDesign paragraph styles. Because InDesign has a weak notion of containment, each level of a list has to be mapped to a different paragraph style that defines the formatting details for that level (e.g., 2nd-level numbered item within 1st-level numbered item). In trying to work out the rules I realized that the 1.1 spec is silent on what the implications of these two markup patterns are: <ol><li><ol> and <ol><li><p><ol> Both are allowed. The question is: should the intervening <p> element establish a new list sequence or should the list sequence continue from the nearest containing list element? In a similar vein, there is inconsistent implementation behavior for the presentation of list items that do and don't start with nested <p> elements between the Toolkit's built-in HTML renderer and the PDF2 renderer. This has been discussed before on this list. But I think a formal decision needs to be made about what the intended implications, if any, of nested <p> elements within <li> are, even if the intent is "rendering effect is implementation defined". My personal opinion is that the current HTML formatting implementation is incorrect and that <li> should always be rendered the same regardless of whether it has an initial <p> or not. If there is a requirement to distinguish compact from non-compact lists (which is the practical effect of the HTML behavior [but not the PDF behavior]) that would be better handled with either a new attribute for lists (analogous to expanse or width or other format hints) or as a conventional value for outputclass=. It's too late for DITA 1.2 but I'm also finding that it would be really handy to have a base type underlying all the lists (e.g., topic/list) that would make it easy to implement a check for whether an element is or is not a list. Cheers, Eliot -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 610.631.6770 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]