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

[Michael Priestley <mpriestl@ca.ibm.com>]

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>
       <ul><li><p>A</p></li>
           
   <li><p>B</p></li>      
 
           
   <li><p>B</p></li>      
 
       </ul>
</li>

Is better than this:

<li>Do something.
      <p>One of
three things happens:
          <ul><li>A</li>
           
      <li>B</li>        
           
      <li>B</li>        
          </ul>
      </p>
</li>

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 
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

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

06/10/2008 12:22 PM

To	<dita@lists.oasis-open.org>
cc	"Bruce Nevin (bnevin)" <bnevin@cisco.com>
Subject	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