Created attachment 450389 [details] simple testcase If I set overflow of a list-item to anything except 'visible', the marker box is never rendered. Note that this bug is about overflow applied to list items, not on list item containers like ul or ol where we have enough bugs about. In the case of list-style-position: outside, the marker has apparently never been rendered in Gecko history. In the case of list-style-position: inside, there is a regression. I don't have a smaller range for that than Firefox 3.0 worked, 3.6 up to current nightlies don't work. Currently CSS 2.1 defines > 'overflow' on the element does not clip the marker box. See http://www.w3.org/TR/CSS2/generate.html#propdef-list-style-position
We're not even creating the bullet frame in those cases (which is why the "inside" case is broken too).
OK, that regressed when we stopped inheriting the display:list-item into the scrolledframe in bug 456484.
Created attachment 450441 [details] [diff] [review] Fix the regression I'm really not sure how to make the scrollframe not clip the bullet (or how that would even behave... when scrolling presumably the bullet would need to be _outside_ the scrollframe?). We should spin that off into a separate bug.
Though I should note that neither webkit nor presto implement the outside bullet behavior, so either it's a recent spec change or it's seriously at risk.
(In reply to comment #4) > Though I should note that neither webkit nor presto implement the outside > bullet behavior, so either it's a recent spec change or it's seriously at risk. The definition was added between the 19 July 2007 and 23 April 2009 CRs. IE doesn't implement that behaviour either (I was about to file a bug over there). However, if I got a list with a lot of content in each list-item, and I clip that using overflow, I'd still expect the bullets to render. There seems to be no other way that doesn't require additional code.
Right; I understand why the spec's proposed behavior is desirable. It just happens to be a huge pain to implement given the other constraints the spec places on list bullets (like inheriting various properties from the list, for example!).
Yeah, I thought so.. I still think the spec shouldn't change. Else we probably cut off a path we'd like to go in the future. But for now the implementation would be low priority. Hmm, thinking of Level 3 Lists out of interest. Can we estimate whether the implementation of a ::marker pseudo-element (or whatever it will end up with) would ease the difficulty of this problem?
Not really. We effectively have an internal pseudo-element for the bullet already.
Comment on attachment 450441 [details] [diff] [review] Fix the regression Hmm, I wonder if this will fail if you have -moz-column set on the list-item? Maybe we should check the primary frame of the frame's element?
I considered that, but was worried about table pseudo stuff. I guess that shouldn't be an issue, though.... OK, I'll do that. And add a test for the column case (though how columns are supposed to interact with bullets... <sigh>).
> Hmm, I wonder if this will fail if you have -moz-column set on the list-item? Yes, indeed. I'll add a test for that.
But we can't use the primary frame, because in SetInitialChildList (which is where this code is) that's not set yet.
Created attachment 450570 [details] [diff] [review] Like so?
Comment on attachment 450570 [details] [diff] [review] Like so? This works, but only because an outer table frame can't appear here (since table frames can't be NS_DISPLAY_LIST_ITEM). You might want to mention that in a comment.
> You might want to mention that in a comment. Done.
Pushed http://hg.mozilla.org/mozilla-central/rev/574993ec2aee Filed bug 571564 on outside markers.