W3C home > Mailing lists > Public > www-style@w3.org > March 2015

Re: [css2.1] Block element inside list-style-position: inside item

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 13 Mar 2015 16:51:24 -0700
Message-ID: <CAAWBYDDdOJTj-oHPnEwOsjy-EtkHqFc9QWvxQ4d5GhpyhsM2_A@mail.gmail.com>
To: Bogdan Brinza <bbrinza@microsoft.com>
Cc: W3C www-style mailing list <www-style@w3.org>
On Tue, Mar 10, 2015 at 6:07 PM, Bogdan Brinza <bbrinza@microsoft.com> wrote:
> I want to ask for group clarification on an interoperability issue we’ve
> uncovered recently while improving IE interop. Consider the following repro
> [1]:
>
> ul { list-style-position: inside; }
>
> <ul><li><p>Text</p></li></ul>
>
> IE and Firefox position content on the new line relative to marker, while
> Chrome uses the same line. It looks like the spec supports IE/Firefox here
> both in CSS2.1 [2] and CSS3 WD [3]. There is also a CSS2.1 test case for
> this behavior that IE/Firefox pass and Chrome fail [4].
>
> So it looks like Chrome issue, which we can file as usual, however in our
> internal discussions we have discussed that Chrome behavior does make sense
> here and might align better with web developer expectations.
>
> What’s WG opinion on this?

Yay list-style-position interop bugs! They're the absolute worst,
everyone's terrible, they made me very sad when I investigated them in
depth. :(

The correct behavior is that list-style-position:inside makes the
::marker pseudo an ordinary position:static element.  By default, it's
a display:inilne immediately preceding the ::before pseudo.  The
behavior of blocks inside the list item should then fall out in the
obvious fashion - the marker, being inline content, gets wrapped in an
anonymous block before the block element.

In other words, the *correct* behavior (in terms of being sensible and
matching the spec) is for your example to render exactly the same as:

<div class='ul'>
  <div class='li'><p>Text</p>
</div>
<style>
div.li::before { content: "\2022"; }
</style>

~TJ
Received on Friday, 13 March 2015 23:52:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC