[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK-APPS: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC