35666 - [FLOAT] problem with bullets

Status: RESOLVED DUPLICATE of bug 57882

(Core :: Layout, defect, P3)

Description

[buster]

split off from bug 24101.  That bug is specifically about how floats are 
laid out inside a container that is too narrow to contain them.

This bug is about how bullets can overlap floats in some circumstances.

Comment 1

[John Morrison]

Attachment: testcase; from 24101, but adjusted to work with "new" html.css rules

Comment 2

[John Morrison]

Attachment: testcase; like above but uses DIV instead of TABLE for floats (i.e., simpler)

Comment 3

[ekrock's old account (dead)]

Consider for FUTUREing. If the container's too small to contain all the floats, 
it's guaranteed to look **** anyway, yes?

Comment 4

[John Morrison]

I leave the question of whether this is a candidate for future up to 
buster|ekrock, based on whether this is too much of an edge case (balanced 
against the cost/risk to fix it). 

However, I think Eric misinterpreted my brief summary: There is plenty of room 
to place the floaters and content within this container; the problem is just an 
edge case where the next potential block in the flow is placed in a space that 
is too narrow -- i.e., it should be dropped below the left-float, not pulled up 
to the RHS of the left-float.

Comment 5

[Hixie (not reading bugmail)]

This can be solved very, very simply, actually.

There is a bug in html.css. Currently, it says:

   ul, menu, dir {
     display: block;
       /*...*/
     float-edge: margin-box;
   }

   ol {
     display: block;
       /*...*/
     float-edge: margin-box;
   }

   li {
     display: list-item;
   }

It *should*, IMHO, read:

   ul, menu, dir {
     display: block;
       /*...*/
   }

   ol {
     display: block;
       /*...*/
   }

   li {
     display: list-item;
     float-edge: margin-box;
   }

...that is, the " float-edge: margin-box; " declaration should be in the LI rule
not in the UL, OL, DIR, MENU rules. That will make LIs wrap around floats so 
that bullets appear on the sensible side, and will make the UL obey CSS1 rules 
of not taking floats into account.

Unfortunately, that means that 'float-edge' is a flawed property. Try the
test case I will attach shortly to see what I mean. David, should this be
brought up to the WG's attention?

cc'ing various people who may know more.

Comment 6

[Hixie (not reading bugmail)]

Attachment: testcase, shows solution and why we need to contact WG.

Comment 7

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 8

[Marc Attinasi]

Denying approval for beta3.

Comment 9

[ekrock's old account (dead)]

Note: my understanding is that we've been waiting for a long time for the WG for 
a response on this issue and that we haven't received one. If that's the case, 
we need to move forward and do what we believe to be The Right Thing whenever 
resources allow (which is currently slated to be Future)--lack of response by a 
WG can't become a blocking factor on delivering the product.

Comment 10

[Pierre Saslawsky]

ekrock: I don't think the issue was ever brought up to the WG (which is something 
that David and Ian can do directly now).

There is another bug, that I commented on and probably assigned to buster, about 
floats and lists where I recommended following the interpretation from MacIE5 
because (1) it seemed more natural and (2) if needed, our current interpretation 
could be obtained through standard css rules. I can't remember the bug number 
though...

Comment 11

[Hixie (not reading bugmail)]

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

Comment 12

[Hixie (not reading bugmail)]

Bug 48806 had a great testcase:
   http://bugzilla.mozilla.org/showattachment.cgi?attach_id=12846

Clearing nsbeta3- to trigger reevaluation. We have a quick fix for this. It is 
not perfect, but it is a lot better than what we do now. Let's get than in at
least. (We can get the proper fix in when we work on all the floater bugs.)

Comment 13

[Hixie (not reading bugmail)]

Taking bug; I have it fixed in my html.css.

Comment 14

[Hixie (not reading bugmail)]

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

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Is this related to bug 48869 ? It was marked Invalid but I'm not sure I agree...

Comment 16

[Hixie (not reading bugmail)]

No this has no relation to bug 48869.

Comment 17

[lchiang]

per PDT team:  PDT agrees with Marc's statement on 8/7 "Denying approval for
beta3"

Marking this bug P5 priority.  If you disagree, please give a reasoning per
PDT's P1 criteria and state a user impact.  Thanks.

Comment 18

[Hixie (not reading bugmail)]

PDT: Please stop changing my priority field. The priority field is to be touched
only by the assignee per mozilla.org policy.

Reasoning why this should be PDTP2: I have fixed it, it fixes standard 
compliance bugs, and it is low risk.

Comment 19

[clayton]

Ian, priority fields are being touched by PDT for bugs nominated for commercial 
release.  Mozilla is most certainly entitled to fix in the Mozilla tree once 
Netscape branches.  Sorry we're at odds here, this will be history next thursday 
after the branch.

Comment 20

[Hixie (not reading bugmail)]

Apologies if my previous comment sounded a bit strong; I did not want to make
it sound like I was disrespecting the work that the PDT do.


The bug: This bug will _not_ be history once we branch. This, being a generic 
standards compliance bug (P3 per the PDT criteria as I read it) is going to 
cause problems for as long as Netscape 6.0 is on the market (at least 6 months,
probably much longer considering how slowly people upgrade). Without this bug
fixed, placing a UL near a float immediately causes the UL to change size so 
that it does not go under the float. For example:

   * this is item 1 this is item 1 this is +-------------------------------+ 
     item 1 this is item 1 this is item 1  |  IMAGE FLOAT                  |
   * this is item 2 this is item 2 this is |                               |
     item 2 this is item 2 this is item 2  +-------------------------------+
     this is item 2 this is item 2 this is 
     item 2                                
   * this is item 3 this is item 3 this is 
     item 3 this is item 3 this is item 3

With the fix for this bug, only one of the list items is so constrained. Thus,
we are making it very hard for web authors to use floats and lists together for
as long as our product is on the market.

The fix has been available since early June. It is a three line change. It has
been tested thoroughly (I have checked the change with the top100, our CSS 
tests, our HTML tests, and some other ad hoc testing). It is low risk. 

I understand that the PDT check-in guidelines are designed to focus engineers
so that resources are spent fixing the most important bugs. However, the time
for development has already been spent (before I was hired) and the time for 
testing the fix has already been spent (during my free time). The fix is low 
risk, so it is unlikely to cause regressions. If it does, then since the fix is
very simple, it would be very easy to back it out. The extra time spent QAing 
this change will be zero, since QA will be running _all_ the CSS tests anyway,
regardless of whether this is checked in or not.

The PDT guidelines are also intended to reduce the risk of regressions. However,
this bug is well understood, and the code exercised by this fix is already being
exercised in much so the same way (we are merely swapping LI for UL and OL).

So: Given the above, why would the fix not be checked in?


The priority field: Per mozilla.org policy the priority field is "utilized by 
the programmers/engineers to prioritized [sic] their work to be done".
   http://bugzilla.mozilla.org/bug_status.html#priority
I currently have 26 bugs assigned to me, covering various tasks such as fixing
bugs in the 'mozbot' IRC bot, some MathML testing that I need to complete, and
a few meta bugs that are awaiting resolution. I use the priority field to
categorise these bugs into separate groups. Moving a bug assigned to me to 'P5'
is equivalent to saying "there is no work to do here". Eqivalently, I use 'P1'
to mark some of my bugs as having the most impact on the product. By marking 
this bug 'P5' you are saying that CSS standards compliance is less important 
than adding a Channel Logging module to mozbot (bug 16226). I do not believe 
this is what you intended.

Changing the priority field on bugs assigned to me reduces my productivity by
a considerable amount. I do not imagine this is what you are trying to do 
either. Please use the whiteboard field to mark the PDT-priority level, as
was intended. Please?

Comment 21

[Pierre Saslawsky]

PDT, please approve. This is typically the kind of job we hired Ian for: I don't 
think someone else would have seen the long-term effects of not fixing the 
problem.

Comment 22

[Blake Ross]

fixed with ian's *.css checkin, i believed

Comment 23

[Hixie (not reading bugmail)]

blake: No, this was NOT fixed. Did you check that it worked? If so, you should
have marked it WORKSFORME, not FIXED, anyway.

This _cannot_ be fixed since the CSS WG has yet to decide what the correct
behaviour should be, and our current behaviour isn't likely to be defined as 
correct at all.

Comment 24

[Hixie (not reading bugmail)]

Anyway: Pierre checked in (on my behalf) a temporary fix for this, which
allievates the problem, but does not fix it.

Reassigning to Layout to work out what the correct fix should be. Taking QA
since we need to contact the WG.

Comment 25

[karnaze (gone)]

Reassigning to Buster.

Comment 26

[Hixie (not reading bugmail)]

The issue was raised in the W3C and the relevant working groups (CSS and XSL:FO)
are looking at it. A solution was proposed and is currently going through the 
usual committee munging processes. It involves adding two new properties. This
bug is therefore blocked at the moment unless we want to implement experimental
versions to see if they are suitable.

Comment 27

[Artem Saveliev]

Attachment: Another testcase?

Comment 28

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Ian, any progress in the CSSWG on this?

Comment 30

[Boris Zbarsky [:bzbarsky]]

.

Comment 31

[Hixie (not reading bugmail)]

Yeah, look in CSS3 Lists for how to do it. CSS3 Box will have more detailed stuff.

Comment 32

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm not sure what this bug is still about.  I think bug 57882 more clearly covers the reason we need to implement float-displace.

But, for what it's worth, I removed the -moz-float-edge declaration in bug 413840 -- since I think it was made largely useless by this bug, which moved it from ul/ol to li, thus making the bullets overlap the floats again.  (Or was the list indent coming from margin on li back then?  I don't think it ever came from styles on li.)