I've tweaked Docutils' HTML writer to produce more visually compact HTML (less vertical whitespace). HTML's mixed content models allow list items to contain "<li><p>body elements</p></li>" or "<li>just text</li>" or even "<li>text<p>and body elements</p>combined</li>", each with different effects. I'd prefer to stick with strict body elements in list items, but they affect vertical spacing in browsers (although they really shouldn't). Does anybody know of a good discussion of vertical space issues for HTML and/or CSS? After trying various algorithms, I've settled on a hybrid: - Check for and omit <p> tags in "simple" lists: list items contain either a single paragraph, a nested simple list, or a paragraph followed by a nested simple list. This means that this list can be compact: - Item 1. - Item 2. But this list cannot be compact: - Item 1. This second paragraph forces space between list items. - Item 2. - In non-list contexts, omit <p> tags on a paragraph if that paragraph is the only child of its parent (footnotes & citations are allowed a label first). - Regardless of the above, in definitions, table cells, field bodies, option descriptions, and list items, mark the first child with 'class="first"' if it is a paragraph. The stylesheet sets the top margin to 0 for these paragraphs. I'd appreciate feedback, especially from people using different browsers (I've checked IE and Mozilla on both MacOS & Win2K, and Netscape 4 & 6 on MacOS). Please browse the following files: - http://docutils.sf.net/tools/test.html - http://docutils.sf.net/spec/pep-0287.html - http://docutils.sf.net/spec/pep-0000.html Is the above approach correct? Does the generated HTML come out right? Should the compact output be optional (i.e. should there be an option to turn it off)? Any suggestions? Get your snapshots here: http://docutils.sf.net/docutils-snapshot.tgz -- David Goodger <goodger@users.sourceforge.net> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/
Of course, this is a doomed excercise (doomed, I tell you), but a brave one nonetheless... David Goodger wrote:
I'd appreciate feedback, especially from people using different browsers (I've checked IE and Mozilla on both MacOS & Win2K, and Netscape 4 & 6 on MacOS). Please browse the following files:
Hmm - well, I'll try to remember to look at the pages with Opera and Galeon on Debian some evening (at home).
- http://docutils.sf.net/tools/test.html - http://docutils.sf.net/spec/pep-0287.html - http://docutils.sf.net/spec/pep-0000.html
Is the above approach correct? Does the generated HTML come out right? Should the compact output be optional (i.e. should there be an option to turn it off)? Any suggestions?
The last two look very good to me (using IE 5.50 on Windows/NT). In particular, I think that the handling of list spacing in the second looks good. The first exposes some niggles (well, hardly surprising): * In "Bullet Lists", and the other examples with sublists, the gap around each internal list seems a bit big. This is a minor grumble as it is plainly difficult to decide what to do here. * In "Definition Lists", there is no extra space between the first item and the second - done in bad ASCII art, the effect is:: Term Definition Term: classifier Definition paragraph 1. Definition paragraph 2. Clearly some of the same work done for lists needs promulgating here. * In "Field Lists", the effect is not so bad, but the vertical gap between the first item and the second is about half the size of that between the two paragraphs of the second item. * In "Option Lists", there is again the problem of "internal paragraphs" - so the separation between the paragraphs in ``--very-long-option`` is much greater than the separation between each option. But, as I said, for "normal" documents, it's looking rather fine - I like the handling of literal blocks (with the grey background). Admonition boxes are a bit oversized for their content, but since we're not meant to be generating those (!) I'm much less fussed about that. Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ Give a pedant an inch and they'll take 25.4mm (once they've established you're talking a post-1959 inch, of course) My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)
David Goodger wrote:
- Check for and omit <p> tags in "simple" lists: list items contain either a single paragraph, a nested simple list, or a paragraph followed by a nested simple list.
It would be more flexible for the author if you based the omission of <p> tags in single-paragraph lists on whether the list is spaced out or not. For example, this: - apples - oranges - pears would not have paragraph tags whereas this: - This is really a paragraph, even though it's the only block of content in the list item. - A paragraph is the basic structural unit in prose. would. Another option is to trigger <p> tags only for multi-line paragraphs.
- Regardless of the above, in definitions, table cells, field bodies, option descriptions, and list items, mark the first child with 'class="first"' if it is a paragraph. The stylesheet sets the top margin to 0 for these paragraphs.
Have you tried using p:first-child? It would be nice to avoid cruft like 'class="first"'. ~fantasai
fantasai wrote:
It would be more flexible for the author if you based the omission of <p> tags in single-paragraph lists on whether the list is spaced out or not. For example, this:
I'm happy with the current behavior, but that may have potential. I'll add it as a "to do?" item and await a patch.
Another option is to trigger <p> tags only for multi-line paragraphs.
Too arbitrary IMO.
Have you tried using p:first-child? It would be nice to avoid cruft like 'class="first"'.
I did try it, but it didn't do what I needed. The 'class="first"' isn't added in all contexts, but selectively. A 'p:first-child' style isn't selective. I don't remember the details, but a lot of things were tried, and I feel the current code works best. -- David Goodger <goodger@python.org> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/
participants (4)
-
David Goodger -
David Goodger -
fantasai -
Tony J Ibbs (Tibs)