Closed Bug 36854 Opened 24 years ago Closed 3 years ago

[LIST]if list-style-position is inside, bullet takes own line


(Core :: Layout: Block and Inline, defect)

Not set





(Reporter: b.judd, Unassigned)


(Blocks 1 open bug, )


(Keywords: css1, testcase, Whiteboard: Should double check with CSS WG?? [nsbeta3-][CSS1-5.6.5])


(3 files)

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.
Reassigning to buster because it's a block problem
Assignee: troy → buster
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 :)...
Ever confirmed: true
OS: Linux → All
Hardware: Macintosh → All
Summary: <H3> tags (and possibly others) inside <LI> tags displayed on next line → <H3> tags inside <LI> tags displayed on next line
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).
Well, you learn something new every day.  Sorry 'bout that :)  In any case, 
it's still on all platforms/OS's
Target Milestone: --- → M18
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M18 → M19
Priority: P3 → P2
Priority: P2 → P1
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?
Keywords: css1, nsbeta3
Summary: <H3> tags inside <LI> tags displayed on next line → [LIST]if list-style-position is inside, bullet takes own line
Whiteboard: Should double check with CSS WG??
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?
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...
cc eric...
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.
No, it means we have to change everything for 'list-style-position: outside'.
QA Contact: petersen → chrisd
Denied beta3: not our most critical problem at this time...
Whiteboard: Should double check with CSS WG?? → Should double check with CSS WG?? [nsbeta3-]
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.
Priority: P1 → P2
Target Milestone: M19 → Future
*** Bug 59863 has been marked as a duplicate of this bug. ***
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.
Keywords: testcase
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...
QA Contact: chrisd → ian
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Whiteboard: Should double check with CSS WG?? [nsbeta3-] → Should double check with CSS WG?? [nsbeta3-][CSS1-5.6.5]
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
Priority: P2 → --
Target Milestone: Future → ---
Blocks: 230504
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."
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline
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.
Attachment #711606 - Attachment mime type: text/plain → text/html
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?
Still not solved...
Still there in 29.0.1. That’s sad.
What is needed to prioritize this issue?
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?"
Flags: needinfo?(smontagu)
Flags: needinfo?(jfkthame)
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.)
Flags: needinfo?(jfkthame)
Echoing comment 28
Flags: needinfo?(smontagu)
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,

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!
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!
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!
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.
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.
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.

This bug is invalid. The rendering in Firefox and Chrome is the same, and agrees with the spec which says:

The marker box is generated by the ::marker pseudo-element of a list item as the list item’s first child ...

(Safari renders it differently though - filed bug

Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.