Re: Nested Lists and adjacent bullets

I did some further testing on this and found that in MS IE on win32, the
bullets render on separate lines as does NS 4.x. If MS IE on mac renders
differently, then MS has inconsistencies across platforms. I sent a side note
to Tantek, the body of the note contained this:

I can't imagine that having two bullets side-by-side is the appropriate
rendering for that coding. Where in practical usage would that be the norm?
Instead of having line feed.

My understanding of the spec is that ol, ul and dl are block elements, which I

understood meant they be given a newline -- is that not the case? My basis for

that conclusion is that %block contains %list and dl, consequently I would
expect lists to have the same level of block qualities as other %block
elements:

( <!ENTITY % block
               "P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT
|
                BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">).

Am I wrong in that premise?

---------------

I am waiting on the response.

> Nested Lists and adjacent bullets
>
> From: Ian Hickson (py8ieh=mozilla@bath.ac.uk)
> Date: Tue, Jun 13 2000
>
> *Next message: Tantek Celik: "Re: Nested Lists and adjacent bullets"
>
>    * Previous message: Matthew Brealey: "Re: BeCSS"
>    * Next in thread: Tantek Celik: "Re: Nested Lists and adjacent bullets"
>    * Reply: Tantek Celik: "Re: Nested Lists and adjacent bullets"
>    * Reply: Matthew Brealey: "Re: Nested Lists and adjacent bullets"
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>    * Other mail archives: [this mailing list] [other W3C mailing lists]
>    * Mail actions: [ respond to this message ] [ mail a new topic ]
>
>   ------------------------------------------------------------------------
>
> Date: Tue, 13 Jun 2000 21:45:28 +0100 (BST)
> From: Ian Hickson <py8ieh=mozilla@bath.ac.uk>
> To: www-style <www-style@w3.org>
> Message-ID: <Pine.GSO.4.21.0006132139290.22830-100000@mary.bath.ac.uk>
> Subject: Nested Lists and adjacent bullets
>
> There appears to be an inconsistency between CSS1 and standard
> publishing practices with regards to the rendering of nested lists.
>
> In the normal case, if you have a nested list, you will have a
> scenario something like the following.
>
>    Document:
>
>       <ol>
>         <li>
>           <p>foo</p>
>           <ol>
>             <li>
>               <p>bar</p>
>             </li>
>           </ol>
>         </li>
>       </ol>
>
>    Frame construction:
>
>       +<ol>--------------------------------------+
>       |       +<li>----------------------------+ |
>       | +---+ | +<p>-------------------------+ | |
>       | | 1 | | | foo                        | | |
>       | +---+ | +----------------------------+ | |
>       |       |                                | |
>       |       | +<ol>------------------------+ | |
>       |       | |       +<li>--------------+ | | |
>       |       | | +---+ | +<p>-----------+ | | | |
>       |       | | | 1 | | | bar          | | | | |
>       |       | | +---+ | +--------------+ | | | |
>       |       | |       +------------------+ | | |
>       |       | +----------------------------+ | |
>       |       +--------------------------------+ |
>       +------------------------------------------+
>
>    Rendering:
>
>       1 foo
>
>         1 bar
>
> (...where the elements are assumed to have their usual 'display'
> values and generated content as given in the suggested UA stylesheet,
> and the anonymous boxes above are :before marker boxes).
>
> 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
>
> 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."
>
> 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.
>
> 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?
>
> This was escalated from Bugzilla bug 38832:
>    http://bugzilla.mozilla.org/show_bug.cgi?id=38832
>
> --
> Ian Hickson                            ("`-''-/").___..--''"`-._
> http://www.bath.ac.uk/%7Epy8ieh/        `6_ 6  )   `-.  (     ).`-.__.`)
>                                         (_Y_.)'  ._   )  `._ `. ``-..-' fL
> Member, Mozilla Quality Assurance     _..`--'_..-_/  /--'_.' ,'
> Browser Standards Compliance Team    (il).-''  (li).'  ((!.-'
>
>   ------------------------------------------------------------------------
>
>    * Next message: Tantek Celik: "Re: Nested Lists and adjacent bullets"
>    * Previous message: Matthew Brealey: "Re: BeCSS"
>    * Next in thread: Tantek Celik: "Re: Nested Lists and adjacent bullets"
>    * Reply: Tantek Celik: "Re: Nested Lists and adjacent bullets"
>    * Reply: Matthew Brealey: "Re: Nested Lists and adjacent bullets"
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>    * Other mail archives: [this mailing list] [other W3C mailing lists]
>    * Mail actions: [ respond to this message ] [ mail a new topic ]

--
Mgr., Netscape Composer SW Dev
SD: 858.618.2210 (M|Th|F)
MV: 650.937.6835 (Tu|W)
cell: 858.212.7517

Received on Thursday, 24 August 2000 14:27:41 UTC