Re: list-item alignment in CSS

On Jun 4,  5:32pm, David Perrell wrote:

> As for what happens when a block element has been declared inline...my
> first inclination is to say it should be appended to the preceding
> element, so that if an inline list were to follow this comma-terminated
> paragraph, 1. The list would be a continuation of the paragraph. 2.
> Without special treatment of :before and :after pseudo-elements --
> which could be different on the first and/or the last list element --
> it would be of limited usefulness.

Not at all, you have a very compact presentation there. Once we start
thinking about the presentations of a document rather than the presentation,
what you described above becomes a valuable display method for fitting a lot
into a small space. Which may be because I am using a PDA, or because my
browser window is one of the less important windows and I want it small and
compact for looking up information while carrying out some other activity
with the greater part of my screen real-estate.


> If :before and :after applied to all elements it would be relatively
> simple to construct inline lists from existing elements, using classes
> for first and last element and given some counter mechanism.

I am really glad to hear that. Most interesting propsal. Yes, I agree that
constructing either inline lists or the more usual block-style indented
lists or indeed other types is best acheived with a :before and a :after.

The cue-before and cue-after properties in ACSS could also disappear.


> And
> speaking of counters, why not treat decimal | lower-roman | upper-roman
> | lower-alpha | upper-alpha | as sibling-counters in any :before and
> :after pseudo-element? The counter would have to increment with each
> subsequent base element occurrence regardless of class.

Yes, I would not expect a <li class=foo> to screw up the numbering

> > Actually there has been recent discussion about what happens with a
> multiply
> > nested list where different list items have left-to-right and
> right-to-left
> > directionality and then some joker sets the entire enclosing UL to be
> > display: inline.
>
> You mean like (1) A phrase in english. .cibirA ni noitinifed A (a)
> .cibirA ni noitinifed rehtonA (b)
>
> That seems kinda silly. Perhaps a new line should occur when direction
> changes, regardless of display type.

That would make sense in some but not all situations, because you don't want
simple inline quotes to cause a newline.

The arabic word for foo is OOF and the Hebrew translation is OOF.

The arabic word for foo is
OOF
and the Hebrew translation is
OOF
.

<aside> a real, genuine use for a full stop in a line all by itself</aside>

It's specifying what happens in the screwball cases that takes the time,
because the software has to cope with this stuff without a pilot. But simple
one or two-level embeddings are reasonably foresable

The israeli interpreter said  OOF IS foo ROF DROW WERBEH EHT.


-- 
Chris Lilley, W3C                          [ http://www.w3.org/ ]
Graphics and Fonts Guy            The World Wide Web Consortium
http://www.w3.org/people/chris/              INRIA,  Projet W3C
chris@w3.org                       2004 Rt des Lucioles / BP 93
+33 (0)4 93 65 79 87       06902 Sophia Antipolis Cedex, France

Received on Wednesday, 4 June 1997 20:55:05 UTC