This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why "listitem" is not parallel with (X)HTML "li"?(was RE: DOCBO OK-APPS: ListItem)


/ "Prikryl,Petr" <PRIKRYLP@skil.cz> was heard to say:
| To summarize my question...
|
|    What are the reasons not to define DocBook "listitem" 
|    similarly to HTML's or XHTML's "li" element?  Why it cannot
|    contain #PCDATA?  How the above (and below -- as described
|    by Lars) case should be solved?

Because allowing mixed content or element content would be wrong.
Well, perhaps that's a little flip, but it would certainly be unlike
every other element in DocBook with the exception of table cells and
I've more often than not had reason to believe we should have done
those differently. (See the discussion of pernicious mixed content and
the problems it causes in the discussion of the table entry element.)

What we have here, plain and simple, is broken browsers. Given that
HTML allows <li><p>text</p></li>, rendering such a construction as:

  * 
    text

is just wrong. I have precious little desire to change DocBook to work
around bugs in browsers.

The concern I have about a switch to make a listitem with a single
para discard the para wrapper is that it would be performed on an
item-by-item basis and a mixture of styles in the same list strikes me
as even more likely to be rendered badly.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | A lie is an abomination unto the
http://www.oasis-open.org/docbook/ | Lord and a very present help in
Chair, DocBook Technical Committee | time of trouble.--Adlai Stevenson


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]