Last Comment Bug 54696 - Move -moz-float-edge declaration to quirk.css
: Move -moz-float-edge declaration to quirk.css
Status: RESOLVED FIXED
: css1
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla1.9beta4
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
:
Mentors:
Depends on: 413840
Blocks: 56362 143162
  Show dependency treegraph
 
Reported: 2000-09-29 10:53 PDT by David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
Modified: 2008-02-11 23:04 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch #1 (1.79 KB, patch)
2005-02-13 09:13 PST, Anne (:annevk)
bzbarsky: superreview-
Details | Diff | Review

Description David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-09-29 10:53:49 PDT
There's a rule in html.css (with selector |li|) containing the rule
|-moz-float-edge: margin-box|.  I think this should be moved to quirk.css so
that its strange effects don't hit standards mode.  (see bug 54644)
Comment 1 Pierre Saslawsky 2000-09-29 15:01:28 PDT
Ian, David: I'll be glad to get approvals and check that in for you if you attach 
a testcase.
Comment 2 Hixie (not reading bugmail) 2000-09-29 18:42:21 PDT
Created attachment 15808 [details]
Test case showing one reason why -moz-float-edge sucks

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=15808
Comment 3 Hixie (not reading bugmail) 2001-02-12 16:36:57 PST
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
Comment 4 Christopher Hoess (gone) 2001-09-07 13:18:36 PDT
Has this happened?  Is it happening?  Has it been postponed until floats aren't 
as broken?
Comment 5 Pierre Saslawsky 2001-09-07 16:21:43 PDT
Ian & Dbaron: The attached testcase may show why -moz-float-edge sucks (although, 
on the same topic, bug 54644 was closed as Invalid on [2000-11-09 17:52]) but it 
surely doesn't show why the 'LI {-moz-float-edge: margin-box}' declaration should 
be moved from html.css to quirk.css.  Why don't we simply remove it?
Comment 6 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2001-09-07 16:28:46 PDT
Well, it was there for bug 802, except bug 65473 makes me wonder how well that
fix actually worked.
Comment 7 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2001-09-07 16:29:19 PDT
CSS3 will hopefully describe better ways of handling this stuff -- there's a bit
in the current CSS3 box model working draft.
Comment 8 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-06-19 21:07:52 PDT
Assigning pierre's remaining Style System-related bugs to myself.
Comment 9 Hixie (not reading bugmail) 2003-04-10 06:37:10 PDT
dbaron: this would be an easy fix if you still want to do it (I'm apathetic; the
quirky behaviour is as bad as the standard behaviour...).
Comment 10 David A. Madore 2003-05-08 07:29:13 PDT
Well, if everyone else is apathetic, I'd rather the standard were followed.  I
just filed bug 204869 which turned out to be a dup of bug 143162.

Incidentally, is there a doc for -moz-float-edge somewhere (or something
resembling a doc) apart from the source?  What are the possible values?
content-box and margin-box?
Comment 11 Anne (:annevk) 2005-02-13 09:13:11 PST
Created attachment 174231 [details] [diff] [review]
patch #1

Ian, something like this? Or do you want the rule for the HR element to move as
well?
Comment 12 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-13 19:48:45 PST
I don't really understand the issues involved in list-and-float interaction well
enough to review this quickly (I could maybe do it if forced, but there are
better reviewers for this).
Comment 13 Hixie (not reading bugmail) 2005-02-14 03:37:29 PST
This shouldn't be done before we implement the 'float-displace' and
'indent-edge-reset' properties.

   http://www.w3.org/Style/Group/css3-src/css3-box/#float-displace
   http://www.w3.org/Style/Group/css3-src/css3-box/#indent-edge-reset

...otherwise we'll just go from one bad behaviour (non-compliant) to another bad
behaviour (albeit currently compliant) to yet another behaviour (compliant
again) by which time authors will have insulted us for changing our behaviour
too often and gone elsewhere.
Comment 14 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-20 22:43:58 PST
Comment on attachment 174231 [details] [diff] [review]
patch #1

sr- per Ian's comments
Comment 15 Gérard Talbot 2005-04-11 09:55:48 PDT
Removing css1 keyword and adding css-moz keyword
Comment 16 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-04-11 23:28:33 PDT
(In reply to comment #15)
> Removing css1 keyword and adding css-moz keyword

...which is, of course, incorrect, since the presence of the declaration means
we're not conforming to CSS1.  Furthermore, the bug has nothing to do with the
behavior of -moz-float-edge.
Comment 17 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2008-02-10 18:39:07 PST
I basically did this (except removed it from quirks mode too) in bug 413840.  Although now comment 13 is giving me second thoughts; the new behavior really is pretty bad too, and by matching other browsers on it we'd basically be preventing it from ever changing in the future.
Comment 18 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2008-02-10 21:23:38 PST
... but our old behavior was equally bad, since we had -moz-float-edge on li, not ul, so the bullets overlapped before the patch as well.  So I think we're better off now, although we probably should implement float-displace.

In any case, I think this is fixed.

Note You need to log in before you can comment on or make changes to this bug.