Last Comment Bug 571564 - outside list marker not drawn when overflow is not visible
: outside list marker not drawn when overflow is not visible
Status: NEW
:
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://bugzilla.mozilla.org/attachme...
Depends on:
Blocks: css2.1-tests
  Show dependency treegraph
 
Reported: 2010-06-11 12:27 PDT by Boris Zbarsky [:bz] (Out June 25-July 6)
Modified: 2013-11-11 13:07 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test HTML to show this bug (779 bytes, text/html)
2010-08-06 00:37 PDT, Zhang Weiwu
no flags Details

Description Boris Zbarsky [:bz] (Out June 25-July 6) 2010-06-11 12:27:17 PDT
The problem is that the scrollframe clips it.  The rendering the spec calls for means putting the marker _outside_ the scrollframe but inheriting from stuff in the scrollframe.  So effectively an out-of-flow.  Maybe we should implement it that way?

Side note:  webkit, presto, IE8 all have the same behavior as us right now.  IE9 might not, though.
Comment 1 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-06-13 16:41:05 PDT
I think this is remarkably low priority.
Comment 2 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-06-13 17:57:39 PDT
Can we change the spec to say that the marker just gets hidden in that case?  IT doesn't seem worth implementing.
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-06-13 19:09:13 PDT
> Can we change the spec to say that the marker just gets hidden in that case? 

We could, I'd think, though it does lead to somewhat unfortunate rendering of lists with non-overflow-visible items...  From an authoring perspective, showing the marker really is preferable.  fantasai claimed IE9 may be changing behavior here; no idea about other UAs' plans.
Comment 4 Zhang Weiwu 2010-08-06 00:37:17 PDT
Created attachment 463444 [details]
Test HTML to show this bug

Hello. I am trying to help to demonstrate by a test case. Please kindly check if the test case is addressing this issue.

With the test HTML file:

- it shows the bullet is clipped off with overflow:hidden using Firefox 3.6.3 (Ubuntu 10.04) and Firefox 3.5.11 (Mac OS). 
- the bullet is not clipped off with overflow:hidden using Firefox 3.0.5 (OpenSUSE 11.1)

It is difficult for me to understand why the bullet is clipped off (Fx>3.5) anyway even when list-style-position: inside, which should put the bullet within view-port.
Comment 5 Zhang Weiwu 2010-08-06 01:28:13 PDT
As said on the test HTML comment, changing list-style-position to inside does not make marker show up for Fx > 3.5. This behavior is verified on multiple computers here. In such case i would not think remarkably low priority, because the mentioned competitor browsers would render the marker in case of list-style-position: inside

In fact we have a production website with this behavior /only/ happen on Firefox.
Comment 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-08-06 04:40:12 PDT
The list-style-inside issue is not this bug, as you can tell from the summary, which explicitly talks about _outside_ list markers.  Inside list markers were fixed in bug 571281.
Comment 7 Gérard Talbot 2012-12-27 20:33:29 PST
"
outside
    (...) In CSS 2.1, a UA may hide the marker if the element's 'overflow' is other than 'visible'.
"
http://www.w3.org/TR/CSS21/generate.html#propdef-list-style-position

The "may" word makes this optional for CSS 2.1.

Closest test I could find is with 'overflow: auto':
http://test.csswg.org/suites/css2.1/latest/html4/list-style-position-004.htm

and, right now, no browser (IE9, IE10, Chrome 24.0.1290.1, Opera 12.50, Safari 6.0.2) display the bullet anyway.
Comment 8 Gérard Talbot 2013-11-11 13:07:19 PST
Setting platform to All and operating system to All

Note You need to log in before you can comment on or make changes to this bug.