The bulleted list items in column two are positioned too far to the left.

In the 10-8 build, the bulleted list in the second column does not appear at all, and there are extra bullets in the first (floated) column at the end of the first UL and the beginning of the second UL.‰

Also, for multiple line LI's, each line is getting a bullet. Somehow I didn't notice this before. It could have something to do with the problem. ‰

The behavior varies depending on minor changes in the page. Look at the URL above and also the following, and look at each with the window wide and with it narrow (you have to reload when you change the window size, see bug # 1060): http://www.fas.harvard.edu/~dbaron/tests/nglayout/index_1015_1.html http://www.fas.harvard.edu/~dbaron/tests/nglayout/index_1015_2.html (The _2 should be the same as my homepage now, but the homepage may change and this will not. The _1 is the spanish version of my homepage ... I've started to mess around with multilanguage stuff, and I copied it after I made the changes and realized that the old version had different bugs.) The bugs that appear are generally the following: - Extra bullets for later lines within a LI (some of the time) - Double bullets (vertically) due to strange things - extra bullets at the end of the list‰

All three of the above effects are being caused by the bullets from the unfloated text being moved over way to the right (much more than the original bug report) so that they are in line with the bullets in the floated column. This should have been obvious to me, but wasn't before. See the test case http://www.fas.harvard.edu/~dbaron/tests/nglayout/dbull.html‰

As of the 10-30 build, there are now stripes of blank (blue) area being displayed to the left of all the H2's on the right side. The bullets thing still isn't fixed either.‰

Oh... and this may be related to the fact that the links in the floating text cannot be clicked on, and moving the mouse over them doesn't do anything...‰

The bullet positioning issue is actually not a bug, as I noted in bug 1413. However, I am leaving this bug open in case you want to deal with any compatibility issues, although I recommend against it, because it's too complicated to do without messing up other stuff. Other issues in this page are treated in bugs 1060 1277 1413 1583.

I modified the page and therefore changed the URL to a backup (for you) of the old version. The positioning of the bullets, according to the CSS spec, is not a bug, but... Other issues on this page, FYI, are handled in bugs 803, 1060, 1122, 1206, 1277, 1413, 1580, and 1583, although some of those are now closed.

Setting all current Open/Normal to M4.

This is also a problem for this URL: http://www.ozemail.com.au/~lineup/surfchat/test.html

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

I think you can see the same bug at http://developer.netscape.com/js/javascript.html

A variation: at this URL, bullets appear *below* the text they apply to: http://deveLOPer.netscape.com/docs/examples/javascript/browser_type.html

ekrock's second comment is unrelated, and I filed it separately as bug 5688. I don't see anything wrong with the page he gives in his first comment.

Changed title from "Bullets positioned incorrectly" to "bullets positioned strangely around floats"

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

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

Darn, and I spent all that time narrowing it down to a small test case and it's just a DUP... :-)

Finally, this bug is fixed. I've implemented support for "float-edge" and use it in UL/OL/MENU/DIR elements. :-)

With the Sept 23rd build, this problem appears to be fixed.

BTW, what is 'float-edge' and what does it do? It doesn't seem to appear in any of the recent CSS3 WDs, and Kipp mentioned it three months ago...

It's new for CSS3 I think. Kind of like 'box-sizing'

I'd kinda guessed it was new, not being in the CSS1 and 2 specs and all -- I was just wondering what it did! ;-) 'box-sizing' is mentioned in the UI draft, but the WG have not yet released any documents related to the box model, so we haven't yet seen any 'float-edge' properties defined anywhere.

This fix has regressed. The new bug is bug 57882.