Last Comment Bug 36854 - [LIST]if list-style-position is inside, bullet takes own line
: [LIST]if list-style-position is inside, bullet takes own line
Status: NEW
Should double check with CSS WG?? [ns...
: css1, testcase
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
-- normal with 20 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
: 59863 (view as bug list)
Depends on:
Blocks: 230504
  Show dependency treegraph
Reported: 2000-04-22 21:16 PDT by Gwyn Judd
Modified: 2015-06-07 20:26 PDT (History)
26 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

test case illustrating the behaviour (701 bytes, text/html)
2000-04-22 21:17 PDT, Gwyn Judd
no flags Details
testcase showing more general CSS1 problem (212 bytes, text/html)
2000-06-16 23:13 PDT, David Baron :dbaron: ⌚️UTC-8
no flags Details
Testcase to show CSS bug when using list-style-position:inside (2.40 KB, text/html)
2013-02-07 17:02 PST, Ryan Foster
no flags Details

Description User image Gwyn Judd 2000-04-22 21:16:01 PDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 ppc; en-US; m15)
BuildID:    2000041919

When you have an <H3> tag inside a <LI> tag the text is displayed on the next
line eg:

<LI><H3>This text should be displayed on the same line as the bullet point but
it isn't</H3></LI>

Netscape 4.7 displays it correctly on the same machine. The above URL is on my
home computer which isn't up all the time so I am attaching the same file below.
Comment 1 User image Gwyn Judd 2000-04-22 21:17:15 PDT
Created attachment 7866 [details]
test case illustrating the behaviour
Comment 2 User image troy 2000-04-22 21:52:09 PDT
Reassigning to buster because it's a block problem
Comment 3 User image Blake Ross 2000-04-22 22:07:25 PDT
seen also on 2000042208, win98.  confirming and removing "(and possibly 
others)" from summary so it's visible in its entirety from the Bugzilla just keep in mind that this might also be occurring with tags other 
than <H3>.  

Also changing OS and Platform to ALL (the former combination of Macintosh and 
Linux didn't make much sense anyways :)...
Comment 4 User image Gwyn Judd 2000-04-22 22:28:23 PDT
not quite...actually I run linux on my G3 powermac so it makes more sense than
you would think :). In this case setting it as Linux on macintosh is the closest
I can get (which you see from the "ppc" in the User-Agent).
Comment 5 User image Blake Ross 2000-04-22 22:34:05 PDT
Well, you learn something new every day.  Sorry 'bout that :)  In any case, 
it's still on all platforms/OS's
Comment 6 User image buster 2000-06-01 14:21:01 PDT
redistributing bugs across future milestones, sorry for the spam
Comment 7 User image David Baron :dbaron: ⌚️UTC-8 2000-06-16 23:10:25 PDT
This actually seems to be a major CSS1 compliance issue, because of the way we 
implement LI that are not within UL.  If 'list-style-position' is 'inside' we 
are supposed to put the list marker inside the first inline box of the box with 
display list-item.  I assume this means that we should not generate an inline 
box unless there are none - that the inline box may be within a child.  (This is 
the way it works for 'list-style-position:outside'.

What's happening here is that we're creating a line-box for just the bullet.

Ian:  Is everything I said correct?
Comment 8 User image David Baron :dbaron: ⌚️UTC-8 2000-06-16 23:13:42 PDT
Created attachment 10301 [details]
testcase showing more general CSS1 problem
Comment 9 User image Hixie (not reading bugmail) 2000-07-23 18:47:01 PDT
David: I don't know, CSS2 says "inside: The marker box IS the first inline box 
in the principal block box, after which the element's content flows."
(emphasis mine) -- This could be interpreted both ways?
Comment 10 User image David Baron :dbaron: ⌚️UTC-8 2000-07-23 20:50:45 PDT
I know it can be interpreted both ways (create a line box in the 'list-item'
block vs. use the first line box that exists).  However, one of them (the first)
breaks lots of existing pages, so therefore it must be the second.  That's my
first rule for resolving blatant ambiguities in CSS...
Comment 11 User image Blake Ross 2000-07-24 05:32:21 PDT
cc eric...
Comment 12 User image Hixie (not reading bugmail) 2000-07-24 17:00:02 PDT
David: Yeah, but the other one means we don't have to change anything, thus
we ship sooner... that's my first criteria. ;-)

However, our current behaviour has no other advantages. Thus I agree that it is
a bug.
Comment 13 User image David Baron :dbaron: ⌚️UTC-8 2000-07-24 17:20:13 PDT
No, it means we have to change everything for 'list-style-position: outside'.
Comment 14 User image Marc Attinasi 2000-08-07 10:24:38 PDT
Denied beta3: not our most critical problem at this time...
Comment 15 User image buster 2000-10-03 23:09:19 PDT
This bug only effects <LI> that are not immediate children of a list <UL> or
<OL> for example.  So this is not a P1. Downgrading to P2. The author has a
straightforward workaround:  wrap the proper list type around the list items.
Supporting malformed documents isn't a top priority for the next few weeks, and
the risk to fix would be moderate, so marking Future.
Comment 16 User image David Baron :dbaron: ⌚️UTC-8 2000-11-15 07:50:20 PST
*** Bug 59863 has been marked as a duplicate of this bug. ***
Comment 17 User image Hixie (not reading bugmail) 2000-12-11 16:17:20 PST
Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that
do not have the "testcase" keyword and yet have an attachement with the word
"test" in the description field. Apologies for any mistakes.
Comment 18 User image Hixie (not reading bugmail) 2001-02-12 16:32:02 PST
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
Comment 19 User image Kevin McCluskey (gone) 2001-10-04 16:31:47 PDT
Build reassigning Buster's bugs to Marc.
Comment 20 User image Boris Zbarsky [:bz] (still a bit busy) 2003-04-20 11:23:25 PDT
Comment 21 User image listy 2006-06-06 04:46:16 PDT
There is a description in a CSS 2.0 recommendation: which tell us that Gecko behaviour is faulty.

"Most block-level elements in CSS generate one principal block box. In this section, we discuss two CSS mechanisms that cause an element to generate two boxes: one principal block box (for the element's content) and one separate marker box (for decoration such as a bullet, image, or number). The marker box may be positioned inside or outside the principal box. Unlike :before and :after content, the marker box does not affect the position of the principal box, whatever the positioning scheme."
Comment 22 User image Ryan Foster 2013-02-07 17:02:28 PST
Created attachment 711606 [details]
Testcase to show CSS bug when using list-style-position:inside

I ran into this problem today using Firefox 18.0.2 when I discovered that menus (using A tags set to display:block inside LI tags) which worked as I expected in Chrome 24.0.1312.57 did not display the same way in Firefox 18.0.2.  After some searching, I found a Stack Overflow question ( that pointed me to this bug report.  I've created a detailed testcase with explanations and sections that are labeled in an effort to clearly demonstrate the behavior described in this bug report.  Is this at all helpful?

Regarding the whiteboard note "Should double check with CSS WG??", it's a shame we couldn't get Daniel Glazman or someone else to check during the recent CSS WG meeting from Feb 4-6.
Comment 23 User image Valter Vicente 2013-11-18 06:37:27 PST
I've just run across this same problem developing for a new website. The Stack Overflow question that Ryan Foster showed is exactly the kind of issue I'm having right now. Hasn't it been solved since 2000?
Comment 24 User image Dragomir 2014-02-11 07:09:06 PST
Still not solved...
Comment 25 User image gurdiga 2014-05-23 20:23:46 PDT
Still there in 29.0.1. That’s sad.
Comment 26 User image Jens O. Meiert 2014-09-16 04:13:56 PDT
What is needed to prioritize this issue?
Comment 27 User image Elbart 2014-11-01 01:06:19 PDT
14 and a half years...

comment 21 mentioned CSS2, here's (I think) the final wording:

Note the attached image.

Firefox doesn't look like this one bit with "list-style-position:inside" when heading-tags are involved. "outside" is fine.

Another realworld-example:
Scroll down to "TL;DR?"
Comment 28 User image Jonathan Kew (:jfkthame) 2014-11-01 08:01:25 PDT
Not sure why I've been ni?'d here; this isn't something I've worked on, or particularly know about. Clearing flag. (If there's a specific question for me, ask it; but I don't see one here.)
Comment 29 User image Simon Montagu :smontagu 2014-11-19 01:37:30 PST
Echoing comment 28
Comment 30 User image Pablo Rodríguez 2014-12-15 10:37:51 PST
I think that summary should be something similar to "inside list items containing block elements add new lines".

BTW, shouldn’t the product be CSS?

The problem can be shown with this sample:

<style type="text/css">
ul li { list-style: inside disc; }
ul.x li { list-style-position: inside; }
ul.y li { list-style-position: inside; list-style-type: disc; }
ul.z li { list-style: inside; list-style-type: disc; }
ul.a li { list-style: inside; list-style: disc; }
ul.b li { list-style-position: inside; list-style: disc; }


<li><p>Not working.</p></li>

<ul class="x">
<li><p>Not working.</p></li>

<ul class="y">
<li><p>Not working.</p></li>

<ul class="z">
<li><p>Not working.</p></li>

<ul class="a">

<ul class="b">

For some strange reason, when list-style or list-style-position contains the "inside" value, Firefox needs a different list-style attribution with one of the values from list-style-type defined in list-style. These values in list-style-type will not work.

Would it be possible to update the product and the summary with a more accurate description, so that this bug could be fixed soon?

Many thanks for your help,

Comment 31 User image Pablo Rodríguez 2014-12-29 13:28:24 PST
Hi there,

this report is almost 15 years old. It has P1 priority. Sorry, I’m not sure whether this is the highest, but nobody is working on it. 

It is not related to CSS1 only. It is related to CSS2 also (and I guess CSS3 [I haven’t checked it]).

Sorry, I cannot code. So I cannot contribute myself a patch (programming code is all Greek to me).

I think the bug pattern is clear (see the sample above).

Would it be possible that this bug could be fixed before its report turns 15yo?

Many thanks for your work and best wishes for 2015!
Comment 32 User image RaduM 2015-02-17 07:15:42 PST
Just ran into this problem today. It's allmost 15 years since this problem was reported. My mind is boggled on how such a ting can still remain a bug after all these years. Mozilla, this is more important than all your webRTC, HTML5 compliance and Flash replacement stuff. Fix it! It will make headlines when you do!
Comment 33 User image Kyle McNutt 2015-04-14 16:24:54 PDT
I ran into this today as well!

I would like to take a crack at fixing this bug with the limited open time in my schedule. If someone could please point me in the right direction at least in code then I would greatly appreciate it! Otherwise wish me luck!
Comment 34 User image David Baron :dbaron: ⌚️UTC-8 2015-04-14 16:33:44 PDT
We currently construct the bullet in nsBlockFrame::SetInitialChildList (in layout/generic/nsBlockFrame.cpp).  In order to fix this, we'd need to end up putting the bullet in an entirely different frame (but only when one is available), but still displaying it as though it were related to the 'display: list-item' frame.

Getting the tree construction right requires adding logic to deal with what happens if that child goes away, for example.  (It might move to a different child or back to the parent.)  It also needs to deal with content being inserted in the parent that means the bullet should now be in a line of the parent.  Getting this all right is a decent amount of work, and at risk of causing crashes or even security bugs if it's done wrong.

Dealing with styling probably isn't that hard, though, although I might be missing something.
Comment 35 User image Kyle McNutt 2015-04-14 17:33:55 PDT
Hey David! Great to talk with you!

Sounds like an awesome problem! :) Thanks so much for the code files and help, someone with the kind of experience that you have on this is exactly what I need.

I didn't think this was going to be a small project, if it was I would guess that it would have been cleared up earlier than now. That being said I don't think it's something impossible, especially with correct CSS specification behavior in other browsers. 

That being said I can understand wanting to avoid something that could cause problems, as you mentioned, so if Mozilla wants to leave the behavior of bullets as is, I won't be the one to cause headaches. That being said if the issue remains open, I would like to at least take a stab at a bug fix.
Comment 36 User image David Baron :dbaron: ⌚️UTC-8 2015-04-14 18:15:01 PDT
You're welcome to work on it; I'd recommend against doing tons of work without checking in and asking whether your approach so far is good.

One other thought about handling the messy dynamic change cases -- one way to handle those, since they're likely rare, is to just conditionally destroy and rebuild more stuff than "needed" (i.e., reconstruct frames for the list-item (and thus for all of its descendants)), because the code to do that is far simpler, and the condition under which it happens is rare.  The trick is then just making sure that we don't hit that codepath too often.
Comment 37 User image erp2 2015-04-15 01:49:35 PDT Comment hidden (spam)

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