Closed
Bug 54696
Opened 24 years ago
Closed 16 years ago
Move -moz-float-edge declaration to quirk.css
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
mozilla1.9beta4
People
(Reporter: dbaron, Assigned: dbaron)
References
Details
(Keywords: css1)
Attachments
(1 file)
1.79 KB,
patch
|
bzbarsky
:
superreview-
|
Details | Diff | Splinter Review |
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•24 years ago
|
||
Ian, David: I'll be glad to get approvals and check that in for you if you attach a testcase.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [easy fix]
Target Milestone: --- → Future
Comment 3•24 years ago
|
||
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...
QA Contact: chrisd → ian
Comment 4•23 years ago
|
||
Has this happened? Is it happening? Has it been postponed until floats aren't as broken?
Comment 5•23 years ago
|
||
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?
Assignee | ||
Comment 6•23 years ago
|
||
Well, it was there for bug 802, except bug 65473 makes me wonder how well that fix actually worked.
Assignee | ||
Comment 7•23 years ago
|
||
CSS3 will hopefully describe better ways of handling this stuff -- there's a bit in the current CSS3 box model working draft.
Assignee | ||
Comment 8•22 years ago
|
||
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: ASSIGNED → NEW
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Comment 9•21 years ago
|
||
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...).
Summary: Move float-edge declaration to quirk.css → Move -moz-float-edge declaration to quirk.css
Assignee | ||
Updated•21 years ago
|
Whiteboard: [easy fix] → [easy fix][patch]
Comment 10•21 years ago
|
||
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•20 years ago
|
||
Ian, something like this? Or do you want the rule for the HR element to move as well?
Assignee: dbaron → bug
Attachment #174231 -
Flags: superreview?(bzbarsky)
Attachment #174231 -
Flags: review?(ian)
Comment 12•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
Comment on attachment 174231 [details] [diff] [review] patch #1 sr- per Ian's comments
Attachment #174231 -
Flags: superreview?(bzbarsky) → superreview-
Updated•19 years ago
|
Assignee: bug → nobody
Status: ASSIGNED → NEW
Comment 15•19 years ago
|
||
Removing css1 keyword and adding css-moz keyword
Updated•19 years ago
|
Attachment #174231 -
Flags: review?(ian)
Updated•19 years ago
|
Priority: P3 → --
Whiteboard: [easy fix][patch]
Assignee | ||
Comment 16•19 years ago
|
||
(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.
Assignee | ||
Updated•17 years ago
|
QA Contact: ian → style-system
Assignee | ||
Comment 17•16 years ago
|
||
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.
Assignee | ||
Comment 18•16 years ago
|
||
... 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.
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → dbaron
Assignee | ||
Updated•16 years ago
|
Target Milestone: Future → mozilla1.9beta4
You need to log in
before you can comment on or make changes to this bug.
Description
•