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
http://dita.xml.org/blog/25
"Bruce Nevin (bnevin)"
<>
06/10/2008 12:22 PM
To
<>
cc
"Bruce Nevin (bnevin)" <>
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
