Bug 23053 – LI element loses its bullet in multi-column mode

• Component: CSS
• Status: RESOLVED CONFIGURATION CHANGED

[Doeke Zanstra]

When setting the CSS property -webkit-column-count, the bullets of the LI-elements disappear. See test-case provided (URL). Also this script:

  <ul style="-webkit-column-count:2">
    <li>One<li>Two<li>Three<li>Four
  </ul>

[Oli Studholme]

also ordered list numerals, and according to Bug 38835 list-style-image images too https://bugs.webkit.org/show_bug.cgi?id=38835

[Oli Studholme]

Workaround: list-style-position: inside; (Webkit default is presumably outside)

[Alexey Proskuryakov]

Still reproducible with r79080.

(In reply to comment #3)
> Still reproducible with r79080.

As per the code what is happening is that when we paint the markers it checks whether the marker position intersects with the paint area rect and it fails in that check and does not draw anything.
So one fix is when we query the marker property for position (inside or outside) we can return true if UL has columns. Please suggest?

*** Bug 38835 has been marked as a duplicate of this bug. ***

Created attachment 224470 [details]
Patch

(In reply to comment #6)
> Created an attachment (id=224470) [details]
> Patch

Please review. Thanks.

[alan]

Comment on attachment 224470 [details]
Patch

and now even OUTSIDE is treated like INSIDE when <ul> has columns? Not sure if that's correct. It'd be great to figure out why the marker is mispositioned as opposed to force it to behave like INSIDE.

[Simon Fraser (smfr)]

Comment on attachment 224470 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=224470&action=review

> Source/WebCore/rendering/RenderListMarker.cpp:1741
> -    return m_listItem.notInList() || style().listStylePosition() == INSIDE;
> +    return m_listItem.notInList() || style().listStylePosition() == INSIDE || m_listItem.parent()->hasColumns();

This doesn't seem like the correct way to fix this.

[Ahmad Saleem]

Changed Comment 0 test case in following fiddle: https://jsfiddle.net/fgax1to4/

Safari 16.5.1 is matching with Chrome Canary 117.

[Darin Adler]

It’s good that Safari and Chrome match.

It’s possible this is just a bug in WebKit that Chrome never tackled though, and we are just comparing WebKit with itself.

Ideally we’d also like to know if this behavior matches the CSS and HTML specification intent and whether it matches Firefox. Also, we’d like WPT test coverage to help flag any future changes in this behavior in any of the browsers.

We can probably close this bug report without all of that, but that seems like what it would take to thoroughly dispatch this issue.

We don’t need WebKit specialists to do any of those things, by the way. That would only be needed if we decided to change WebKit behavior.

[Tab Atkins Jr.]

As far as I can tell, Chrome's behavior is to draw the bullets normally. They're not specially clipped by the column container (as they shouldn't be). So if Safari is matching that and drawing the bullets in the example given here, then it's correct.

[Ahmad Saleem]

All browsers are matching Chrome Canary 119, Firefox Nightly 120 and Safari Technology Preview 179.

NOTE: I removed -webkit- prefix from JSFiddle to test on Firefox.

Marking this as 'RESOLVED CONFIGURATION CHANGED', please reopen if it is still reproducible.