W3C home > Mailing lists > Public > www-style@w3.org > November 2010

Re: list-style-position and text-align

From: David Hyatt <hyatt@apple.com>
Date: Tue, 23 Nov 2010 00:14:32 -0600
Cc: www-style list <www-style@w3.org>
Message-id: <2F502173-9879-49E0-BF97-15B1EF475CF6@apple.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
On Nov 23, 2010, at 12:07 AM, Boris Zbarsky wrote:

> I'm having trouble telling what webkit is actually doing based on this testcase:
> <body>
>  <ul style="list-style-position: inside">
>    <li>
>      <ul>
>        <li>
>          <div style="">aaa</div>
> </body>
> It seems like the outer bullet is placed on a line by itself but the inner is not, right?

Watch out for quirks mode.  Go to strict mode, and the bullets will be on the same line.

<!doctype html>
 <ul style="list-style-position: inside">
         <div style="">aaa</div>

WebKit has a quirk for nested lists that prevents the bullets from being on the same line.  It's ancient code, so I'm not sure how sane it is.  Anyway, use strict mode.

>> The only differences between the two are that the outside marker doesn't affect the placement of objects on the line, and the outside marker gets a paint translation applied to shove it outside.
> The outside bit there seems like an implementation detail... In Gecko, the same effect is achieved through totally different means.

Yeah, I would like painting to remain an implementation detail for CSS2.1, but I think the spec dictating that the marker is not clipped by overflow and that it doesn't scroll with overflow is indirectly implying paint order and stacking rules.  The fact that no engines respect this text concerns me as well.

Mostly, though, I just want a clarification on text-align, since WebKit is the only engine to ignore text-align on outside bullets.  However, if we decide outside bullets *should* respect text-align, then the other stuff (especially the overflow clipping and scrolling) comes into question as well.

Received on Tuesday, 23 November 2010 06:15:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:41 UTC