[FLOAT] problem with bullets

RESOLVED DUPLICATE of bug 57882

Status

()

Core
Layout
P3
normal
RESOLVED DUPLICATE of bug 57882
18 years ago
8 years ago

People

(Reporter: buster, Unassigned)

Tracking

(Blocks: 1 bug, {css1, css3, testcase})

Trunk
Future
css1, css3, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P4])

Attachments

(4 attachments)

(Reporter)

Description

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

Updated

18 years ago
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → M17

Comment 1

18 years ago
Created attachment 7536 [details]
testcase; from 24101, but adjusted to work with "new" html.css rules

Comment 2

18 years ago
Created attachment 7537 [details]
testcase; like above but uses DIV instead of TABLE for floats (i.e., simpler)
Consider for FUTUREing. If the container's too small to contain all the floats, 
it's guaranteed to look **** anyway, yes?

Comment 4

17 years ago
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.
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.
Keywords: css1, css3, testcase
Hardware: PC → All
Summary: [FLOAT] problem with bullets → [html.css] [FLOAT] problem with bullets
Whiteboard: have fix (but it is suboptimal -- need to contact WG)
Created attachment 9832 [details]
testcase, shows solution and why we need to contact WG.

Updated

17 years ago
Keywords: nsbeta2, nsbeta3

Comment 7

17 years ago
Putting on [nsbeta2-] radar. Not critical to beta2. 
Whiteboard: have fix (but it is suboptimal -- need to contact WG) → [nsbeta2-] have fix (but it is suboptimal -- need to contact WG)

Comment 8

17 years ago
Denying approval for beta3.
Whiteboard: [nsbeta2-] have fix (but it is suboptimal -- need to contact WG) → [nsbeta2-] [nsbeta3-] have fix (but it is suboptimal -- need to contact WG)
Target Milestone: M17 → Future
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

17 years ago
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...
*** Bug 48806 has been marked as a duplicate of this bug. ***
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.)
QA Contact: petersen → py8ieh=bugzilla
Whiteboard: [nsbeta2-] [nsbeta3-] have fix (but it is suboptimal -- need to contact WG) → [nsbeta2-] have fix (but it is suboptimal -- need to contact WG)
Keywords: patch
Taking bug; I have it fixed in my html.css.
Assignee: buster → py8ieh=bugzilla
Status: ASSIGNED → NEW
Keywords: patch
Priority: P2 → P1
QA Contact: py8ieh=bugzilla → chrisd
Whiteboard: [nsbeta2-] have fix (but it is suboptimal -- need to contact WG) → [nsbeta2-] [have fix] (but it is suboptimal -- need to contact WG)
Target Milestone: Future → M18
*** Bug 22774 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta2-] [have fix] (but it is suboptimal -- need to contact WG) → [nsbeta2-] [nsbeta3+] [have fix] (but it is suboptimal -- need to contact WG)
Is this related to bug 48869 ? It was marked Invalid but I'm not sure I agree...
Depends on: 3935
No this has no relation to bug 48869.
Status: NEW → ASSIGNED

Comment 17

17 years ago
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.
Priority: P1 → P5
Whiteboard: [nsbeta2-] [nsbeta3+] [have fix] (but it is suboptimal -- need to contact WG) → [nsbeta2-] [nsbeta3+] [PDTP5] [have fix] (but it is suboptimal -- need to contact WG)
No longer depends on: 3935
Blocks: 6625
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.
Priority: P5 → P1

Comment 19

17 years ago
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.
Priority: P1 → P5
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?
Priority: P5 → P1
Whiteboard: [nsbeta2-] [nsbeta3+] [PDTP5] [have fix] (but it is suboptimal -- need to contact WG) → [nsbeta2-] [nsbeta3+] [PDTP5] [FIX IN HAND] (but it is suboptimal -- need to contact WG)

Comment 21

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

17 years ago
fixed with ian's *.css checkin, i believed
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Keywords: nsbeta2, nsbeta3
Resolution: FIXED → ---
Whiteboard: [nsbeta2-] [nsbeta3+] [PDTP5] [FIX IN HAND] (but it is suboptimal -- need to contact WG) → (but it is suboptimal -- need to contact WG)
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.
Assignee: py8ieh=bugzilla → clayton
Status: REOPENED → NEW
QA Contact: chrisd → petersen
Priority: P1 → P3
QA Contact: petersen → py8ieh=bugzilla
Summary: [html.css] [FLOAT] problem with bullets → [FLOAT] problem with bullets
Target Milestone: M18 → Future

Comment 25

17 years ago
Reassigning to Buster.
Assignee: clayton → buster
Blocks: 78094
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.
Keywords: mozilla1.2
Whiteboard: (but it is suboptimal -- need to contact WG) → [Hixie-P5] BLOCKED: waiting on WG

Comment 27

16 years ago
Created attachment 48801 [details]
Another testcase?
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Ian, any progress in the CSSWG on this?
.
Assignee: attinasi → ian
Yeah, look in CSS3 Lists for how to do it. CSS3 Box will have more detailed stuff.
Assignee: ian → other
Whiteboard: [Hixie-P5] BLOCKED: waiting on WG → [Hixie-P4]
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.)
Assignee: layout → nobody
QA Contact: ian → layout
Status: NEW → RESOLVED
Last Resolved: 17 years ago8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 57882
You need to log in before you can comment on or make changes to this bug.