[Pmwiki-users] rendering question about lists (somewhat important)

Reimer Behrends behrends
Tue Feb 3 11:08:42 CST 2004


A note up front: while this is fairly lengthy (mostly due to some
technical points), I think this discussion is also at an "agree to
disagree point", and when I express opinions below, I do not presume to
be "right" at the expense of contrary opinions.

On Mon, Feb 02, 2004 at 10:45:04PM -0700, Patrick R. Michaud wrote:
> On Mon, Feb 02, 2004 at 10:30:38PM -0500, Reimer Behrends wrote:
[...]
> > > dl, ul, ol, pre { margin-top:0; margin-bottom:0; }
[...]
> > This should have a net zero effect on the layout (except that lists
> > following one another will effectively be merged), because the margins
> > of the paragraph before and after will still result in vertical
> > whitespace being inserted (a quick local test confirms that). 
> 
> Ummm...*what paragraphs*?  In the markup:
> 
>    This is some text
>    * bullet 1
>    This is some more text
> 
> there aren't any paragraphs, there's just:

Okay, I didn't get that part. I was assuming that at the top level,
paragraphs would be preserved.

>    This is some text
>    <ul><li>bullet 1</li></ul>
>    This is some more text

That effectively is equivalent to:

  <div>This is some text</div>
  <ul><li>bullet 1</li></ul>
  <div>This is some more text</div>

where each div encloses an anonymous block level element. This "works"
because these anonymous blocks inherit all inheritable properties from
the enclosing block element, and set all non-inherited properties
(including margins) to their default value (in particular, 0 for
margins). Cf. section 9.2.1 of the CSS 2 spec.

This has its own set of problems. To begin with, you cannot really set
the style for those anonymous boxes because you cannot specify a
selector for them. Also, depending on what the anonymous box is
contained in, the layout may vary with respect to all inherited
properties (so that, for instance, paragraphs included in <p> elements
can have a different font from those represented as anonymous block
boxes).

As a practical example, using anonymous block boxes side by side with P
elements breaks usage of the CSS text-indent property in an essentially
unfixable way.

[...]
> I think we must be disagreeing about one or both of the following:
> 1. That text not inside of some sort of list has to be in a paragraph
>    container to be valid (X)HTML  (it does not)

Actually, no. I just didn't realize you were relying on the semantics
of anonymous block-level elements.

> 2. Whether the behavior I'm describing is a "problem" or a 
>    "desirable feature"

There is probably some disagreement here, yes. However, I think the
main difference lies in me seeing blank lines as a logical separator
for top-level elements, whereas you see them as a layout tool. That
is indeed a fundamental difference of opinion, with neither position
being obviously the better one.

That being said, I'd like to clarify my position before we move on
to more important things.

> Authors typically *want* the output to look like what they entered.  

That tends to be a sore spot with me, mostly because I had to deal with
too many Word documents where the authors were using blank lines to add
inter-paragraph spacing. (Such a document is essentially unmaintainable,
because the design decisions regarding spacing are not localized in a
single place.)

> They want a blank line to appear when they put one in the markup, and 
> not appear when they don't have one in the markup.  The browsers' default
> behavior for lists means that an author is always forced to have a blank 
> line appear around lists whether it's appropriate or not.

That has, essentially, be a non-issue for me. When I write a paper for
an ACM conference, for example, I'm expected to rigorously stick to the
ACM style guidelines, and I do not get to decide how much space to add
around lists. The reason is that in typography, consistency generally
trumps individual expression. YMMV, of course.

[...]
> (Put another way, XHTML is inconsistent in the same way that you
> describe--some authors could choose to use <p>...</p> to contain
> text, while other authors might choose <div>...</div>.)

Yes, but it requires conscious effort to shoot yourself in the foot by
replacing P elements with DIV elements and thereby stripping the HTML of
useful semantic information (HTML is not only processed by visual user
agents). Conversely, there is no obvious guideline that indicates
whether to enclose lists in blank lines or not, which is likely to
result in inconsistent results.

> I know that this is also the sort of area where people promote the
> idea that "content markup should be kept separate from layout".  While
> in principle I largely agree with this idea, that's not really PmWiki's
> focus.  PmWiki's focus has always been on providing a simpler markup
> and system for the collaborative authoring and maintenance of web pages.
> In this application, layout *is* something that authors want to have
> some control over.

I'm not a markup-content-separation purist by any means and am generally
happy with whatever works. However, I am not sure why there is a need
for removing white space from around lists. Off the top of my head, I
can't think of any source that advocates not visually separating lists
from the surrounding paragraphs.

> > I think what I'm not getting is why there is a perceived need to
> > remove the whitespace in the first place.
> 
> This came about because I'm introducing a '-->' markup for indented
> text using <div> tags.  The vertical space surrounding lists was
> creating very inconsistent results when indented text items were
> mixed in with list items because the vertical spaces sometimes appear
> and other times do not.  For example,
> 
>    normal text here                      normal text here
>    * list level 1
>    --> text indent level 2                 * list level 1
>    *** list level 3                            text indent level 2
>    normal text here                                 * list level 3
> 
>                                          normal text here
> 
> with blank lines before "list level 1" and after "list level 3",
> but reversing the markup gives
> 
>    normal text here                      normal text here
>    -> text indent level 1                   text indent level 1
>    ** list level 2                           
>    ---> text indent level 3                     * list level 2
>    normal text here                                  text indent level 3
>                                           normal text here

This is due to the default CSS stylesheet, which has a different
style for nested lists than for top-level lists. By starting out
the second example with a div that contains a list, the list
essentially is interpreted as a top-level list. To remove spacing
from around all lists to get the right spacing around the nested
ones strikes me as unnecessary.

> and replacing the '-->' with ':: :' (<dl>) markups gives
> 
>    normal text here                      normal text here
>    : : text indent level 1
>    ** list level 2                          text indent level 1
>    ::: : text indent level 3                    * list level 2
>    normal text here                                   text indent level 3
> 
>                                          normal text here
> 
> While this might seem "consistent" to someone who understands what's
> happening behind the scenes in HTML, on the surface (and to a naive
> author) it looks very inconsistent because the vertical space seems
> to jump from place to place in the output.

I don't consider it consistent either, because some inner lists have
surrounding whitespace while others don't. However, I see the problem
as div-based lists being treated differently from standard lists,
and I would personally solve the consistency problem by adding the
regular whitespace around top-level div-based lists and remove it
from normal lists nested inside div-based lists, which should result
in a layout that matches the style of the standard HTML CSS.

> To me it's much nicer
> and more natural if vertical space appears only where one was 
> explicitly placed in the markup.

That is where we agree to disagree, I think. No offense meant by any of
the above, just an explanation of a different position.

			Reimer Behrends



More information about the pmwiki-users mailing list