OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dita] Proposal for Consideration: Default Behavior for List Items

A few points:

- This would be a backwards-incompatible change. That is, it would render invalid a large proportion of the existing DITA content out there. I think we could consider this for 2.0 if the cost of converting all back-level content was justified by the benefits (I'm not currently convinced myself, but that would be the timeline to make the arguments)
- This would also render the current task specialization invalid, since it specializes a <ph> element as the first child of <step>. As an exercise, see what any of the list specializations would look like, if only block-level elements were allowed (I suspect it would break most of them).

Finally, and leaving aside the pragmatic reasons not to make a backwards-incompatible change to the schemas and DTDs at this point, I'm still not sure why this:

<li><p>Do something</p>
       <p>One of three things happens:</p>

Is better than this:

<li>Do something.
      <p>One of three things happens:

If it's a relic of HTML, I'm not sure why it's a bad relic. The adoption of HTML hasn't exactly been crippled by this approach.        

Michael Priestley
Lead IBM DITA Architect

"Bruce Nevin (bnevin)" <bnevin@cisco.com>

06/10/2008 12:22 PM

"Bruce Nevin (bnevin)" <bnevin@cisco.com>
RE: [dita] Proposal for Consideration: Default Behavior for List Items

[Not sure if this is the right way to contribute to this thread, but I don't see any contributor hooks on the page or in the Help. Responding to http://lists.oasis-open.org/archives/dita/200804/msg00060.html.]
I agree that rendering is an OT issue.
The real issue IMO is that <li> permits #PCDATA and phrase-level elements. These should only be permitted in paragraph-level elements, and any element that permits paragraph-level or "larger" elements as children should not permit #PCDATA and phrase-level elements. This behavior seems to be a relic of the HTML standard.
It is easy for OT and vendors to insert <p> by default, and if <li> begins with some other child element it is only a minor nuisance to delete <p> or insert that child ahead of <p>.
This would simplify the work of rendering and remove the ambivalence that is the topic of this thread.
Perhaps this is already being considered for 1.3 or 2.0.
    /Bruce Nevin

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]