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

NEW
Unassigned

Status

()

Core
Layout: Floats
P3
normal
17 years ago
2 years ago

People

(Reporter: Eric Vaandering (no email), Unassigned)

Tracking

(4 keywords)

Trunk
Future
css-moz, css1, css3, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.3 -
blocking1.8rc1 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P2], URL)

Attachments

(4 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
Seeing in WinNT as well.
The problem also appears for unordered lists.

Comment 2

17 years ago
Created attachment 17953 [details]
Simplified testcase from url

Comment 3

17 years ago
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

Comment 4

17 years ago
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: 7954
Keywords: css-moz, css1
Summary: Ordered and Unordered list bullets render inside previous table edge → List markers render inside adjacent float edge

Comment 6

17 years ago
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. ***
(Reporter)

Updated

17 years ago
Target Milestone: Future → mozilla1.0
Keywords: mozilla1.0

Comment 8

16 years ago
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. ***

Comment 12

16 years ago
*** 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
(Reporter)

Comment 20

16 years ago
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. ***

Comment 27

16 years ago
*** Bug 129965 has been marked as a duplicate of this bug. ***
*** Bug 137883 has been marked as a duplicate of this bug. ***

Comment 29

16 years ago
Created attachment 79568 [details]
Another Simplified test case

No images in this test case.

Comment 30

15 years ago
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.

Comment 32

15 years ago
Reconfirmed using FizzillaCFM/2002070913. Setting Platform=All.
Hardware: PC → All
*** Bug 157583 has been marked as a duplicate of this bug. ***

Updated

15 years ago
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. ***

Comment 37

15 years ago
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

Comment 40

15 years ago
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.

Updated

15 years ago
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.

Comment 44

15 years ago
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.

Comment 47

15 years ago
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. ***

Comment 52

15 years ago
*** Bug 206006 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Target Milestone: mozilla1.3alpha → ---

Comment 53

14 years ago
*** Bug 208885 has been marked as a duplicate of this bug. ***

Comment 54

14 years ago
*** Bug 209197 has been marked as a duplicate of this bug. ***

Updated

14 years ago
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. ***

Comment 58

14 years ago
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.   

Updated

14 years ago

Comment 59

14 years ago
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

14 years ago
Reference my comment #58:  I have moved my test page to
<http://www.rossde.com/test/test.html>.  

Comment 61

14 years ago
*** Bug 188780 has been marked as a duplicate of this bug. ***

Comment 62

14 years ago
Added Myself to CC
*** Bug 246682 has been marked as a duplicate of this bug. ***

Comment 64

13 years ago
*** 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. ***

Comment 67

12 years ago
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

12 years ago
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

12 years ago
*** Bug 300635 has been marked as a duplicate of this bug. ***
*** Bug 303216 has been marked as a duplicate of this bug. ***

Comment 71

12 years ago
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-

Comment 73

12 years ago
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

12 years ago
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?

Comment 75

12 years ago
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. ***

Updated

11 years ago
Duplicate of this bug: 377421
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
Duplicate of this bug: 542739
Also see my comments on float-displace here:
http://lists.w3.org/Archives/Public/www-style/2008Feb/thread.html#msg116
Duplicate of this bug: 35666

Comment 84

6 years ago
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.
Created attachment 8446168 [details]
Another test case
Duplicate of this bug: 823046
You need to log in before you can comment on or make changes to this bug.