Last Comment Bug 57882 - List markers (bullets) render inside adjacent float edge (implement float-displace property)
: List markers (bullets) render inside adjacent float edge (implement float-dis...
Status: NEW
[Hixie-P2]
: css-moz, css1, css3, testcase
Product: Core
Classification: Components
Component: Layout: Floats (show other bugs)
: Trunk
: All All
: P3 normal with 41 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://us.imdb.com/birthday/IMDB-Ten-...
: 35666 60192 60593 65473 104900 112232 112913 113521 117179 118174 122033 128425 129965 131683 131861 137883 157583 160117 163474 165759 173533 188780 199110 199747 203270 206006 208885 209197 222108 222246 226538 246682 263555 283632 299402 300635 303216 327590 377421 542739 823046 (view as bug list)
Depends on:
Blocks: html4.01 158464 188780
  Show dependency treegraph
 
Reported: 2000-10-24 15:13 PDT by Eric Vaandering (no email)
Modified: 2015-07-28 10:19 PDT (History)
71 users (show)
asa: blocking1.3-
dbaron: blocking1.8rc1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Simplified testcase from url (431 bytes, text/html)
2000-10-25 06:04 PDT, Conor Lennon
no flags Details
Another Simplified test case (319 bytes, text/html)
2002-04-16 20:36 PDT, Matthew Walker
no flags Details
Sample HTML which demonstrates the problem (2.14 KB, text/html)
2005-07-05 05:40 PDT, Pete
no flags Details
Another test case (3.11 KB, text/html)
2014-06-25 14:52 PDT, Julian D. A. Wiseman
no flags Details

Description Eric Vaandering (no email) 2000-10-24 15:13:00 PDT
In this page there are three images and a bunch of text (including an ordered
list) that appear to share a <TD> element. The numbering for the ordered list
ends up superimposed on the images.
Comment 1 Conor Lennon 2000-10-25 06:03:44 PDT
Seeing in WinNT as well.
The problem also appears for unordered lists.
Comment 2 Conor Lennon 2000-10-25 06:04:37 PDT
Created attachment 17953 [details]
Simplified testcase from url
Comment 3 James Lariviere 2000-10-30 12:14:45 PST
Looked for dup but could not find one.

Marking NEW, OS ALL, changing summary because this rendering problem is for both
ordered and unordered lists.

I see described results in win build 2000102920.

It seems like Mozilla renders the content of each list item up against the table
cell edge.  Then renders the list numbers (or bullets) to the left of the list
item content.  This of course means that it now looks like it is inside the table.
Comment 4 James Lariviere 2000-10-30 12:28:37 PST
Really changing summary. Sorry for the SPAM!

Old summary:Ordered list goes too far to left
Comment 5 Hixie (not reading bugmail) 2000-10-30 16:15:36 PST
GRRRRRRRRR -moz-float-edge strikes again!
Comment 6 buster 2000-10-31 09:40:41 PST
yep, we'll have to take care of this post NS6 RTM.  Marking future.
Comment 7 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-11-15 11:06:00 PST
*** Bug 60192 has been marked as a duplicate of this bug. ***
Comment 8 Conor Lennon 2001-06-29 07:54:24 PDT
Is this going to be looked at any time soon?
Comment 9 Hixie (not reading bugmail) 2001-06-30 10:36:43 PDT
Unlikely. It's not a priority for most of the people currently working on layout.
Comment 10 Kevin McCluskey (gone) 2001-10-04 16:28:56 PDT
Build reassigning Buster's bugs to Marc.
Comment 11 Mats Palmgren (:mats) 2001-11-28 14:16:09 PST
*** Bug 112232 has been marked as a duplicate of this bug. ***
Comment 12 Chris Petersen 2001-12-13 19:30:53 PST
*** Bug 113521 has been marked as a duplicate of this bug. ***
Comment 13 Mats Palmgren (:mats) 2001-12-29 17:05:21 PST
*** Bug 117179 has been marked as a duplicate of this bug. ***
Comment 14 Mats Palmgren (:mats) 2001-12-31 18:24:23 PST
*** Bug 104900 has been marked as a duplicate of this bug. ***
Comment 15 Mats Palmgren (:mats) 2001-12-31 18:27:37 PST
*** Bug 112913 has been marked as a duplicate of this bug. ***
Comment 16 Boris Zbarsky [:bz] 2002-01-04 21:17:30 PST
*** Bug 118174 has been marked as a duplicate of this bug. ***
Comment 17 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-01-05 06:57:16 PST
*** Bug 65473 has been marked as a duplicate of this bug. ***
Comment 18 Mats Palmgren (:mats) 2002-01-27 11:12:02 PST
*** Bug 122033 has been marked as a duplicate of this bug. ***
Comment 19 Kevin McCluskey (gone) 2002-02-06 13:56:57 PST
Reassigning to Alex
Comment 20 Eric Vaandering (no email) 2002-02-06 20:06:39 PST
Isn't this an html4 bug rather than all these css keywords? The testcase uses no
css.
Comment 21 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-02-06 20:10:27 PST
No.  Nothing in the html4 spec says that our behavior is wrong, since HTML 4
doesn't describe layout.

Anyway, this is just a regression of bug 802.  (I feel like I've said the same
thing on 2 or 3 other bugs, but I can't find them.)
Comment 22 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-02-06 20:13:32 PST
*** Bug 60593 has been marked as a duplicate of this bug. ***
Comment 23 Kevin McCluskey (gone) 2002-02-18 13:14:46 PST
Moving to Moz1.1. Engineers are overloaded with higher priority bugs.
Comment 24 Mats Palmgren (:mats) 2002-03-02 16:35:22 PST
*** Bug 128425 has been marked as a duplicate of this bug. ***
Comment 25 Tuukka Tolvanen (sp3000) 2002-03-18 03:51:19 PST
*** Bug 131683 has been marked as a duplicate of this bug. ***
Comment 26 Boris Zbarsky [:bz] 2002-03-18 18:26:37 PST
*** Bug 131861 has been marked as a duplicate of this bug. ***
Comment 27 Amarendra Hanumanula 2002-03-26 15:52:19 PST
*** Bug 129965 has been marked as a duplicate of this bug. ***
Comment 28 Boris Zbarsky [:bz] 2002-04-16 20:29:05 PDT
*** Bug 137883 has been marked as a duplicate of this bug. ***
Comment 29 Matthew Walker 2002-04-16 20:36:25 PDT
Created attachment 79568 [details]
Another Simplified test case

No images in this test case.
Comment 30 Vaclav Dvorak 2002-06-19 17:24:30 PDT
Seeing so many duplicates, I'm surprised that this is "not a priority". :-)
Anyway, I have a question. In the following HTML, the second DIV's border is
drawn over the whole width of the page, overwriting the left-floated DIV (the
texts don't overlap, though). Is this the same bug, a different bug, or is this
the correct behaviour? I suspect it is correct, but in that case, is there a way
to make a DIV that behaves more like a table, i.e. stays on the right of the
left float?
The code:
<html><body>
<div style="float: left; border: 1px solid black">left floated div</div>
<div style="border: 3px solid red">framed div</div>
</body></html>
Comment 31 Boris Zbarsky [:bz] 2002-06-19 17:31:32 PDT
That behavior is correct... You likely want to set the width on the floater
(that's required by the CSS2 spec anyway) and then set a left margin on the div.
Comment 32 Greg K. 2002-07-11 20:16:25 PDT
Reconfirmed using FizzillaCFM/2002070913. Setting Platform=All.
Comment 33 Boris Zbarsky [:bz] 2002-07-16 01:26:36 PDT
*** Bug 157583 has been marked as a duplicate of this bug. ***
Comment 34 Boris Zbarsky [:bz] 2002-07-30 22:14:45 PDT
*** Bug 160117 has been marked as a duplicate of this bug. ***
Comment 35 Zibi Braniecki [:gandalf][:zibi] 2002-08-19 12:27:06 PDT
Can owner change Target Milestone???
When this bug will be fixed?
Comment 36 Kai Lahmann (is there, where MNG is) 2002-08-19 14:00:50 PDT
*** Bug 163474 has been marked as a duplicate of this bug. ***
Comment 37 Alexandru Savulov 2002-08-20 10:48:02 PDT
sorry folks, hope we can schedule this one for fixing soon.
Comment 38 Boris Zbarsky [:bz] 2002-08-31 03:23:37 PDT
*** Bug 165759 has been marked as a duplicate of this bug. ***
Comment 39 Mats Palmgren (:mats) 2002-10-09 15:14:31 PDT
*** Bug 173533 has been marked as a duplicate of this bug. ***
Comment 40 Vaclav Dvorak 2003-02-10 19:46:55 PST
Requesting flag blocking1.3. While I certainly appreciate new features like spam
detection, Midas, link prefetching and what have you, I humbly think it's far
more important to fix long standing, serious bugs in the very core of the
browser: HTML rendering. Thank you.
Comment 41 Boris Zbarsky [:bz] 2003-02-10 23:54:01 PST
Fixing major things in the core layout engine (like this one) is not something
that happens at the _end_ of the milestone.  Changes like this happen in the
alpha stage.
Comment 42 Eric A. Meyer (dead account) 2003-02-11 06:39:27 PST
This bug should actually be marked WONTFIX, as it isn't a bug; in CSS2, markers
aren't part of the content and so don't get "shoved over" by floats.  At least,
that was the situation last time I checked, unless somebody errata'ed things out
from under me.  This could morph into or spawn a new bug for implementing
'-moz-float-displace' (based on
http://www.w3.org/TR/css3-box/#the-float-displace) and then that could be thrown
into the UA style sheet to (maybe) give authors what they want.
Comment 43 Zibi Braniecki [:gandalf][:zibi] 2003-02-12 05:51:36 PST
You're abstractive right... But practicaly wrong. At now we have huge amount of
web pages, and part of them have this "bug".

I cannot imagine any situation when any web author would like to create
something like Mozilla's proper behaviour (both testcases). I'm almost sure that
wherever it's used, if it looks like Mozilla's render this it's unproper.

I think that we need to fix this and our behaviour should be same as Opera and IE.
Comment 44 Licinio Alves 2003-02-12 07:08:49 PST
IE 6.x also has this problem.  With IE (and Mozilla), left aligning an image
than having an unordered list to the right of it is not displayed properly.  IE
overlays the image over the bullets of the list items, making it less noticable,
whereas Mozilla overlays the bullets on the image making it more noticable. 
Neither case is really acceptible.
Comment 45 Eric A. Meyer (dead account) 2003-02-12 07:39:28 PST
I agree that there should be a way to silently handle these cases, which is why
I bought up -moz-float-displace as a subject for this bug, or a new one.  That
way we could put into the UA style sheets (or maybe just quirks.css):

   ul, ol, dl {-moz-float-displace: indent;}

...and then bullets wouldn't overlap with images (if I understand float-displace
correctly).

Alternatively, authors could add right margins to their leftward floats, which
will push away the content and thus push out the bullets.  For example:

   img.figure {float: left; margin-right: 1em;}

That should also do what authors want, without needing any new to be
implemented, and offers the advantage of letting them have some control over how
far the list items will be pushed from the float.  It only helps authors who
know to do it, of course, but I could probably find the time to write a technote
on the subject.  That seems like a good idea anyway, since IE6 is now doing
roughly the same thing Gecko is doing.
Comment 46 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-02-12 07:44:41 PST
We already implemented -moz-float-edge (an earlier proposal for handling the
same thing) to fix bug 802, but that seems to have regressed.
Comment 47 Vaclav Dvorak 2003-02-15 20:23:59 PST
I think that plain HTML without any style should always render sensibly, which
now isn't the case with <img align=left><ol><li>text. But it seems there's no
argument about that.

However, there is another thing I'd like to point out. Eric, the margin-right
solution on floats doesn't really work properly: although it does push text to
the right (and thus also the list markers, though indirectly), it also pushes
normal, non-list-item text, which may not be wanted. Also, the left
margin/padding that list items normally have is lost.

Is there really no way to correctly handle this in CSS2? :-o If IE6 shows the
same behaviour, what would be the way to solve this for IE (since I doubt it
will support CSS3 in the next ten years, judging by the fact that it still
hasn't even started on CSS2)? Okay, so this isn't a webdesigners' forum or IE
support, ;-) but I'd suppose that IE has a solution that we can imitate?
Comment 48 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-03-25 06:44:14 PST
*** Bug 199110 has been marked as a duplicate of this bug. ***
Comment 49 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-03-25 06:44:35 PST
->Layout:Floats.
Comment 50 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-03-28 19:36:58 PST
*** Bug 199747 has been marked as a duplicate of this bug. ***
Comment 51 Boris Zbarsky [:bz] 2003-04-24 19:22:40 PDT
*** Bug 203270 has been marked as a duplicate of this bug. ***
Comment 52 Stefan [:stefanh] 2003-05-16 17:58:26 PDT
*** Bug 206006 has been marked as a duplicate of this bug. ***
Comment 53 Bill Mason 2003-06-10 01:42:39 PDT
*** Bug 208885 has been marked as a duplicate of this bug. ***
Comment 54 Bill Mason 2003-06-12 13:43:57 PDT
*** Bug 209197 has been marked as a duplicate of this bug. ***
Comment 55 Mats Palmgren (:mats) 2003-10-14 07:08:04 PDT
*** Bug 222108 has been marked as a duplicate of this bug. ***
Comment 56 Boris Zbarsky [:bz] 2003-10-15 10:16:22 PDT
*** Bug 222246 has been marked as a duplicate of this bug. ***
Comment 57 Boris Zbarsky [:bz] 2003-11-22 14:15:41 PST
*** Bug 226538 has been marked as a duplicate of this bug. ***
Comment 58 David E. Ross 2003-11-22 15:02:27 PST
Another test page is at <http://www.rossde.com/test.html>.  This uses monospace
fonts to help show character, margin, and padding alignments.  

Note that this bug affects lists when there is an adjacent block with style {
float: left } (as shown in my suggested test page).  Thus, this bug does not
merely relate to lists adjacent to tables or images.  

The list markers encroach into the right margin of the adjacent left-floated
block.  The margin could be increased to prevent this (as stated in the middle
of comment #45).  However, the alignment of the list items is still wrong
relative to the alignment of elements before and after the list.  

A workaround involving setting the left margin of the list and list items is not
valid because the author would not have assurance that the list would actually
appear to the right of a left-floated block on all platforms with all browsers.   

29 other bugs have been closed as duplicates of this one.  It's time to fix it.   
Comment 59 Vaclav Dvorak 2004-03-06 13:53:36 PST
bug@annevankesteren.nl, why did you remove the URL? I still see the problem
manifested on exactly that page with Mozilla build 2004021709. Don't you?
Comment 60 David E. Ross 2004-03-06 18:12:08 PST
Reference my comment #58:  I have moved my test page to
<http://www.rossde.com/test/test.html>.  
Comment 61 Asa Dotzler [:asa] 2004-04-13 12:06:25 PDT
*** Bug 188780 has been marked as a duplicate of this bug. ***
Comment 62 Rainer Bielefeld 2004-05-12 04:57:12 PDT
Added Myself to CC
Comment 63 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-06-14 12:00:11 PDT
*** Bug 246682 has been marked as a duplicate of this bug. ***
Comment 64 Bill Mason 2004-10-09 00:47:29 PDT
*** Bug 263555 has been marked as a duplicate of this bug. ***
Comment 65 Boris Zbarsky [:bz] 2005-02-27 15:07:59 PST
*** Bug 283632 has been marked as a duplicate of this bug. ***
Comment 66 Uri Bernstein (Google) 2005-07-02 02:53:37 PDT
*** Bug 299402 has been marked as a duplicate of this bug. ***
Comment 67 Pete 2005-07-05 05:40:28 PDT
Created attachment 188301 [details]
Sample HTML which demonstrates the problem

Example of floating left table with list alongside (which is rendered
incorrectly), and right floating table with list alongside (which is rendered
correctly).
Comment 68 David E. Ross 2005-07-07 18:17:59 PDT
As I pointed out in comment #58, this problem is not limited to tables adjacent
to lists.  It occurs with other block elements adjacent to lists.  

In comment #60, I updated the link for a test case that doesn't use tables.  
Comment 69 shadowstrike32 2005-07-15 08:42:04 PDT
*** Bug 300635 has been marked as a duplicate of this bug. ***
Comment 70 O. Atsushi (Torisugari) 2005-08-03 03:38:43 PDT
*** Bug 303216 has been marked as a duplicate of this bug. ***
Comment 71 Jesus Cea 2005-10-15 14:15:48 PDT
I see this bug still alive. Long time since year 2000 :-).

I suppose this issue is too late for 1.5 release, but perhaps 1.5.1 could solve
this long-lived bug.

Hope so :).
Comment 72 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-10-15 15:43:27 PDT
This is the kind of thing that has a good bit of risk and needs to be fixed well
in advance of the release that will contain the fix.  It's also not going to be
fixed in a security release.
Comment 73 Kelly Price 2006-01-29 09:43:58 PST
It's almost Feburary 2006.  Six months for a bug to be alive.  What happened?  Guy with the can of Raid never came back after going on a supply run?
Comment 74 Jesus Cea 2006-01-30 14:54:52 PST
I read time ago, somewhere, that the bug needed some deep changes in the Gecko rendering engine, so they where a bit dangerour for the 1.5 release.

With the gecko 1.9 branch currently open and release set well into 2007 (the Firefox 3 relase), this issue should be revisited.

I suppose we need to raise awareness about this issue. I already voted for it. All of you should do it also. And some chatting in a high profile web/blog could help a lot, also :-p

Soliciting the block status for Gecko 1.9. Hope never die :).
Comment 75 Jesus Cea 2006-01-30 14:55:10 PST
I read time ago, somewhere, that the bug needed some deep changes in the Gecko rendering engine, so they where a bit dangerour for the 1.5 release.

With the gecko 1.9 branch currently open and release set well into 2007 (the Firefox 3 release), this issue should be revisited.

I suppose we need to raise awareness about this issue. I already voted for it. All of you should do it also. And some chatting in a high profile web/blog could help a lot, also :-p

Soliciting the block status for Gecko 1.9. Hope never die :).
Comment 76 Zibi Braniecki [:gandalf][:zibi] 2006-01-30 15:07:42 PST
Stop adding useless comments. This bug is open so we KNOW that the problem exists.
There is no tested patch (there is no patch at all), so as long as you're not going to set a bounty for this bug, or fix it by yourself, or at least provide usefull feedback, please, consider not commenting it anymore.
Comment 77 Uri Bernstein (Google) 2006-02-17 12:58:06 PST
*** Bug 327590 has been marked as a duplicate of this bug. ***
Comment 78 Dave Townsend [:mossop] 2007-04-13 11:37:07 PDT
*** Bug 377421 has been marked as a duplicate of this bug. ***
Comment 79 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2008-02-10 21:31:55 PST
For what it's worth, I think the regression was a result of bug 35666 moving the -moz-float-edge declaration from ul/ol to li.
Comment 80 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2008-06-11 11:51:46 PDT
We've changed the way list items are handled in Firefox 3:  see bug 413840 and also followup bugs like bug 427370, bug 416732, bug 428810.  Implementing float-displace is somewhat orthogonal, though.  So this is partly fixed, I suppose.
Comment 81 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-01-28 21:27:56 PST
*** Bug 542739 has been marked as a duplicate of this bug. ***
Comment 82 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-01-28 21:28:59 PST
Also see my comments on float-displace here:
http://lists.w3.org/Archives/Public/www-style/2008Feb/thread.html#msg116
Comment 83 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-01-29 13:42:47 PST
*** Bug 35666 has been marked as a duplicate of this bug. ***
Comment 84 David E. Ross 2011-09-23 19:33:55 PDT
Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 SeaMonkey/2.3.3

This is still a problem in Gecko 6.0.2.  The test page I cited in comment #58 still shows bullets (for a UL list) right on the edge of the adjacent box and numbers (for an OL list) inside the adjacent box.  This is for adjacent boxes to the left of the lists.
Comment 85 Julian D. A. Wiseman 2014-06-25 14:37:08 PDT
As this bug causes grief for one of the pages on my website, I made a simple test page in HTML 4.01 Transitional. 
http://www.jdawiseman.com/papers/bugs/20140625_firefox_ul.html 
http://www.jdawiseman.com/papers/bugs/20140625_firefox_ul.png 

OS X Mavericks 10.9.3 with lots of memory; Firefox 30.0.
Comment 86 Julian D. A. Wiseman 2014-06-25 14:52:41 PDT
Created attachment 8446168 [details]
Another test case
Comment 87 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2015-07-28 10:19:16 PDT
*** Bug 823046 has been marked as a duplicate of this bug. ***

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