Re: Nested Lists and adjacent bullets

From: Ian Hickson <py8ieh=mozilla@bath.ac.uk>
Date: Tue, Jun 13, 2000, 1:45 PM

<snip>

> All fine and good so far. However, if you have the nested list as the
> first node of the outer list, you end up with this:
>
>    Document:
>
>       <ol>
>         <li>
>           <ol>
>             <li>
>               <p>bar</p>
>             </li>
>           </ol>
>         </li>
>       </ol>
>
>
>    Frame construction:
>
>       +<ol>--------------------------------------+
>       |       +<li>----------------------------+ |
>       |       | +<ol>------------------------+ | |
>       |       | |       +<li>--------------+ | | |
>       | +---+ | | +---+ | +<p>-----------+ | | | |
>       | | 1 | | | | 1 | | | bar          | | | | |
>       | +---+ | | +---+ | +--------------+ | | | |
>       |       | |       +------------------+ | | |
>       |       | +----------------------------+ | |
>       |       +--------------------------------+ |
>       +------------------------------------------+
>
>
>    Rendering:
>
>       1 1 bar

FWIW, this is how IE5/Mac renders the above markup.  Actually, with periods
after the numbers, more like this:

        1. 1. bar

> This is, I am told, against standard publishing practices, and
> apparently "anyone in the publishing industry would faint if they saw
> multiple list symbols on the same line."

There is a quite a bit of stuff in HTML/CSS which is against standard
publishing practices - standard publishers are only one of the customers of
HTML and CSS.

> So to be good publishers, what we want for the second case is:
>
>    Frame construction:
>
>       +<ol>--------------------------------------+
>       |       +<li>----------------------------+ |
>       | +---+ | .............................. | |
>       | | 1 | | : (anonymous empty inline)   : | |
>       | +---+ | :............................: | |
>       |       |                                | |
>       |       | +<ol>------------------------+ | |
>       |       | |       +<li>--------------+ | | |
>       |       | | +---+ | +<p>-----------+ | | | |
>       |       | | | 1 | | | bar          | | | | |
>       |       | | +---+ | +--------------+ | | | |
>       |       | |       +------------------+ | | |
>       |       | +----------------------------+ | |
>       |       +--------------------------------+ |
>       +------------------------------------------+
>
>
>    Rendering:
>
>       1
>
>         1 bar
>
>
> So. How can we reconcile the CSS2 specs with standard publishing
> practice?
>
> Padding and margins won't cut it (because the book says:
>
> # For the :before pseudo-element, the baseline in the marker box will
> # be vertically aligned with the baseline in the first line box of the
> # principal box. If the principal box contains no line boxes, or if
> # there is a block box within the principal box that is above the
> # first line box, the top outer edge of the marker box will be aligned
> # with the top outer edge of the principal box.
>    -- CSS2, 12:6:1
>
> ...so it matters not how much padding you use, the marker box will
> just move down with the text).
>
> Also, we can't simply add empty content using :before, since the
> marker itself is the :before pseudo-element.

Interesting - perhaps this example illustrates the separate need for a
":marker" pseudo-element which you could place on any element, instead of
the ":before {display:marker}" hackery.  Then you could use :before to add
the line-feed (like the informative default rule for <br>).

> Therefore, it would seem that we need a rule which will place an
> anonymous empty inline box as the first child of any element which has
> a generated marker box, if any of the elements between the element
> with the marker box and the first descendant line box of that element
> have a generated marker box.
>
> This probably needs to be a property (say, 'adjacent-markers' with
> values "allow || never || inherit" or something, inherited and with
> the initial value "allow").
>
> Are there any other possibilities?

Perhaps the :marker selector (as referenced above).

Either way, this looks like a good issue to be raised for the CSS3 Generated
Content / Markers / Lists module, and perhaps for the CSS3 Selectors module
(editors cc'd).

References:
 http://www.w3.org/TR/css3-roadmap
 http://www.w3.org/TR/css3-selectors

Tantek

----------------------------------------------------------------------------
I didn't come here to tell you how it's going to end.  microsoft.com/mac/ie/

Received on Tuesday, 13 June 2000 17:48:36 UTC