Open Bug 57882 Opened 24 years ago Updated 2 years ago

List markers (bullets) render inside adjacent float edge (implement float-displace property)

Categories

(Core :: Layout: Floats, defect, P3)

Product:
Core
Component:
Layout: Floats
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: ewv, Unassigned)

References

(
URL
)

Details

(4 keywords, Whiteboard: [Hixie-P2])

Attachments

(4 files)

Simplified testcase from url
(deleted), text/html
Details
Another Simplified test case
(deleted), text/html
Details
Sample HTML which demonstrates the problem
(deleted), text/html
Details
Another test case
(deleted), text/html
Details
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.
Seeing in WinNT as well. The problem also appears for unordered lists.
Attached file Simplified testcase from url (deleted) —
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: correctness, testcase
OS: Linux → All
Really changing summary. Sorry for the SPAM! Old summary:Ordered list goes too far to left
Summary: Ordered list goes too far to left → Ordered and Unordered list bullets render inside previous table edge
GRRRRRRRRR -moz-float-edge strikes again!
Assignee: clayton → buster
Blocks: html4.01
Keywords: css-moz, css1
Summary: Ordered and Unordered list bullets render inside previous table edge → List markers render inside adjacent float edge
yep, we'll have to take care of this post NS6 RTM. Marking future.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 60192 has been marked as a duplicate of this bug. ***
Target Milestone: Future → mozilla1.0
Is this going to be looked at any time soon?
Unlikely. It's not a priority for most of the people currently working on layout.
Keywords: css3
Whiteboard: [Hixie-P2]
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Status: ASSIGNED → NEW
*** Bug 112232 has been marked as a duplicate of this bug. ***
*** Bug 113521 has been marked as a duplicate of this bug. ***
*** Bug 117179 has been marked as a duplicate of this bug. ***
*** Bug 104900 has been marked as a duplicate of this bug. ***
*** Bug 112913 has been marked as a duplicate of this bug. ***
*** Bug 118174 has been marked as a duplicate of this bug. ***
*** Bug 65473 has been marked as a duplicate of this bug. ***
*** Bug 122033 has been marked as a duplicate of this bug. ***
Reassigning to Alex
Assignee: attinasi → alexsavulov
Isn't this an html4 bug rather than all these css keywords? The testcase uses no css.
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.)
*** Bug 60593 has been marked as a duplicate of this bug. ***
Moving to Moz1.1. Engineers are overloaded with higher priority bugs.
Target Milestone: mozilla1.0 → mozilla1.1
*** Bug 128425 has been marked as a duplicate of this bug. ***
*** Bug 131683 has been marked as a duplicate of this bug. ***
*** Bug 131861 has been marked as a duplicate of this bug. ***
*** Bug 129965 has been marked as a duplicate of this bug. ***
*** Bug 137883 has been marked as a duplicate of this bug. ***
Attached file Another Simplified test case (deleted) —
No images in this test case.
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>
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.
Reconfirmed using FizzillaCFM/2002070913. Setting Platform=All.
Hardware: PC → All
*** Bug 157583 has been marked as a duplicate of this bug. ***
Blocks: 158464
*** Bug 160117 has been marked as a duplicate of this bug. ***
Can owner change Target Milestone??? When this bug will be fixed?
*** Bug 163474 has been marked as a duplicate of this bug. ***
sorry folks, hope we can schedule this one for fixing soon.
Target Milestone: mozilla1.1alpha → mozilla1.3alpha
*** Bug 165759 has been marked as a duplicate of this bug. ***
*** Bug 173533 has been marked as a duplicate of this bug. ***
Blocks: 188780
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.
Flags: blocking1.3?
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.
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.
Flags: blocking1.3? → blocking1.3-
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.
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.
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.
We already implemented -moz-float-edge (an earlier proposal for handling the same thing) to fix bug 802, but that seems to have regressed.
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?
Component: Layout → Layout: Floats
*** Bug 199110 has been marked as a duplicate of this bug. ***
->Layout:Floats.
Assignee: alexsavulov → float
QA Contact: petersen → ian
*** Bug 199747 has been marked as a duplicate of this bug. ***
*** Bug 203270 has been marked as a duplicate of this bug. ***
*** Bug 206006 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.3alpha → ---
*** Bug 208885 has been marked as a duplicate of this bug. ***
*** Bug 209197 has been marked as a duplicate of this bug. ***
Target Milestone: --- → Future
*** Bug 222108 has been marked as a duplicate of this bug. ***
*** Bug 222246 has been marked as a duplicate of this bug. ***
*** Bug 226538 has been marked as a duplicate of this bug. ***
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.
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?
URL: http://us.imdb.com/birthday/IMDB-Ten-...
Reference my comment #58: I have moved my test page to <http://www.rossde.com/test/test.html>.
*** Bug 188780 has been marked as a duplicate of this bug. ***
Added Myself to CC
*** Bug 246682 has been marked as a duplicate of this bug. ***
*** Bug 263555 has been marked as a duplicate of this bug. ***
*** Bug 283632 has been marked as a duplicate of this bug. ***
*** Bug 299402 has been marked as a duplicate of this bug. ***
Example of floating left table with list alongside (which is rendered incorrectly), and right floating table with list alongside (which is rendered correctly).
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.
*** Bug 300635 has been marked as a duplicate of this bug. ***
*** Bug 303216 has been marked as a duplicate of this bug. ***
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 :).
Flags: blocking1.8rc1?
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.
Flags: blocking1.8rc1? → blocking1.8rc1-
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?
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 :).
Flags: blocking1.9a1?
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 :).
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.
Flags: blocking1.9a1?
*** Bug 327590 has been marked as a duplicate of this bug. ***
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.
Summary: List markers render inside adjacent float edge → List markers (bullets) render inside adjacent float edge (implement float-displace property)
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.
Assignee: layout.floats → nobody
QA Contact: ian → layout.floats
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.
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.
Attached file Another test case (deleted) —
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 41 duplicates, 40 votes and 70 CCs.
:TYLin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(aethanyc)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(aethanyc)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: