Summary: | LI element loses its bullet in multi-column mode | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Doeke Zanstra <doekman> | ||||
Component: | CSS | Assignee: | gur.trio | ||||
Status: | RESOLVED CONFIGURATION CHANGED | ||||||
Severity: | Normal | CC: | ahmad.saleem792, ap, commit-queue, craiga, darin, dbates, esprehn+autocc, glenn, gur.trio, hyatt, info, jackalmage, koivisto, kondapallykalyan, laszlo.gombos, mitz, robin, simon.fraser, tabatkins, tonikitoo, webkit.org, yutak, zalan | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Mac (PowerPC) | ||||||
OS: | OS X 10.4 | ||||||
URL: | http://zanstra.com/x/webkit/li-colcount.html | ||||||
Attachments: |
|
Description
Doeke Zanstra
2008-12-31 00:42:18 PST
also ordered list numerals, and according to Bug 38835 list-style-image images too https://bugs.webkit.org/show_bug.cgi?id=38835 Workaround: list-style-position: inside; (Webkit default is presumably outside) (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. 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.
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. Changed Comment 0 test case in following fiddle: https://jsfiddle.net/fgax1to4/ Safari 16.5.1 is matching with Chrome Canary 117. 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. 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. 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. |