Gwyn Judd Reporter
	Description • 24 years ago

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.

	troy
	Comment 2 • 24 years ago

Reassigning to buster because it's a block problem

	Blake Ross
	Comment 3 • 24 years ago

seen also on 2000042208, win98.  confirming and removing "(and possibly 
others)" from summary so it's visible in its entirety from the Bugzilla 
list...so 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 :)...

	Gwyn Judd Reporter
	Comment 4 • 24 years ago

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

	Blake Ross
	Comment 5 • 24 years ago

Well, you learn something new every day.  Sorry 'bout that :)  In any case, 
it's still on all platforms/OS's

	buster
	Comment 6 • 24 years ago

redistributing bugs across future milestones, sorry for the spam

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 7 • 24 years ago

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?

	Hixie (not reading bugmail)
	Comment 9 • 24 years ago

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?

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 10 • 24 years ago

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

	Blake Ross
	Comment 11 • 24 years ago

cc eric...

	Hixie (not reading bugmail)
	Comment 12 • 24 years ago

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.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 13 • 24 years ago

No, it means we have to change everything for 'list-style-position: outside'.

	Marc Attinasi
	Comment 14 • 24 years ago

Denied beta3: not our most critical problem at this time...

	buster
	Comment 15 • 24 years ago

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.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 16 • 24 years ago

*** Bug 59863 has been marked as a duplicate of this bug. ***

	Hixie (not reading bugmail)
	Comment 17 • 24 years ago

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.

	Hixie (not reading bugmail)
	Comment 18 • 24 years ago

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

	Kevin McCluskey (gone)
	Comment 19 • 23 years ago

Build reassigning Buster's bugs to Marc.

	Boris Zbarsky [:bzbarsky]
	Comment 20 • 21 years ago

.

	listy
	Comment 21 • 18 years ago

There is a description in a CSS 2.0 recommendation: http://www.w3.org/TR/CSS2/generate.html#q11 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."

	Ryan Foster
	Comment 22 • 11 years ago

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 (http://stackoverflow.com/questions/1142314/css-rendering-inconsistency-on-ul-with-firefox-being-the-odd-ball-out) 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.

	Valter Vicente
	Comment 23 • 11 years ago

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?

	Dragomir
	Comment 24 • 10 years ago

Still not solved...

	gurdiga
	Comment 25 • 10 years ago

Still there in 29.0.1. That’s sad.

	Jens O. Meiert
	Comment 26 • 10 years ago

What is needed to prioritize this issue?

	Elbart
	Comment 27 • 10 years ago

14 and a half years...

comment 21 mentioned CSS2, here's (I think) the final wording:
http://www.w3.org/TR/CSS2/generate.html#propdef-list-style-position

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: http://www.cindori.org/trim-enabler-and-yosemite/
Scroll down to "TL;DR?"

	Jonathan Kew [:jfkthame]
	Comment 28 • 10 years ago

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

	Simon Montagu :smontagu
	Comment 29 • 10 years ago

Echoing comment 28

	Pablo Rodríguez
	Comment 30 • 10 years ago

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:

<html>
<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; }

</style>
<body>

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

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

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

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

<ul class="a">
<li><p>Working.</p></li>
</ul>

<ul class="b">
<li><p>Working.</p></li>
</ul>
</body>
</html>

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,


Pablo

	Pablo Rodríguez
	Comment 31 • 9 years ago

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!

	RaduM
	Comment 32 • 9 years ago

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!

	Kyle McNutt
	Comment 33 • 9 years ago

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!

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 34 • 9 years ago

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.

	Kyle McNutt
	Comment 35 • 9 years ago

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.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 36 • 9 years ago

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.