no margin around floated images and spans (and probably other inlines)

VERIFIED FIXED in mozilla0.8

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
17 years ago
15 years ago

People

(Reporter: Miloslaw Smyk, Assigned: Marc Attinasi)

Tracking

({compat, testcase, top100})

Trunk
mozilla0.8
x86
All
compat, testcase, top100
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: QUIRK -- minor issue, causes potential std comp problems, URL)

Attachments

(9 attachments)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.17 i686)
BuildID:    2000102608

In the page at http://amiga.com.pl/ all other browsers add a small transparent
gap around images of posters faces. It is especially evident between right edge
of the images and left edge of the news' text. In Mozilla, there is no gap.

Reproducible: Always
Steps to Reproduce:
1. Just visit http://amiga.com.pl and take a look


Expected Results:  I think there should be a gap, as all other browsers do this.

Comment 1

17 years ago
Created attachment 18566 [details]
Testcase

Comment 2

17 years ago
Confirming bug, build 2000-11-02-04 on Windows NT4 sp6.
Floating images has a margin in older browsers.
IE5 and Communicator 4.75 has a 3px margin. Opera 4.02 has a 2px margin.

Adding the following to html.css seems to fix it:

img[align] {
  margin: 3px;
}
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp, patch, testcase

Comment 3

17 years ago
Created attachment 18762 [details]
Testcase #2

Comment 4

17 years ago
It's only horizontal aligns that should have a margin. Here is a better patch:

img[align=left], img[align=right] {
	margin-left: 3px;
	margin-right: 3px;
}
Please triage.
Assignee: clayton → joki
Marc, it seems like you have done most changes in html.css so I am giving this
to you...
Assignee: joki → attinasi
We used to have this in our html.css (check lxr) -- why did we remove it?
I would guess it's because it made width:100% fail (since CSS doesn't include
the margin in the width).
Keywords: 4xp → compat
QA Contact: petersen → ian
(Assignee)

Comment 8

17 years ago
Hmm. I'm not sure which is better, the margin or the width:100% correctness.

Could this qualify as a quirk? Ian, do you know if the HTML spec indicate that
there should be a margin, or is this just a compatibility issue?

I'm agnostic on this one: I can easily add the rule, but how important is it?
HTML says nothing about it, personally I would not check it in and if we do it
would be strictly a quirk mode thing. This doesn't seem to affect any major
sites does it? And the workaround is pretty simple (use CSS)...
Whiteboard: WONTFIX ? -- minor issue, causes potential std comp problems
(Assignee)

Comment 10

17 years ago
If Netscape4 and IE put the margin in then we probably want to as well, but it
would be nice to know if this is really something that is relied upon widely on
the net. Any other sites that exhibit this?

Accepting for now, but might be a WONTFIX in the end.
Status: NEW → ASSIGNED
15 minutes of surfing and I found 5 sites having this problem, 1 top100.

1. http://www.segfault.org/
2. http://www.zdnet.com/zdnn/ (the images in the "Commentary" column)
3. http://internetworld.idg.se/ (image left of "Testa dig själv")
4. (top100) http://www.amazon.com (image left of "Visit our British store") 
5. http://www.fool.com/ (first 3 images under the search form have align=right)

I am sure I have seen this at other sites too.
Ian said: causes potential std comp problems
How come, if this is fixed with a rule in quirk.css? and also, floating images
with a percentage based width must be extremely unusual...

Updated

17 years ago
Keywords: top100
(Assignee)

Comment 12

17 years ago
Thanks, Mats. I'll add this to Quirk mode.
Whiteboard: WONTFIX ? -- minor issue, causes potential std comp problems → QUIRK -- minor issue, causes potential std comp problems
Target Milestone: --- → mozilla0.8
(Assignee)

Comment 13

17 years ago
Created attachment 22059 [details] [diff] [review]
Patch to quirk.css to give a margin to floated images
(Assignee)

Comment 14

17 years ago
One issue with the patch: it only takes care of images floated with the align
attribute. If the image is floated with css using a rule like
'img.foo { float: left; }'
then it needs to get the margin too. Actually, Nav4 gives the CSS-case twice the
margin of the align case, but IE makes them have the same margin, which seems
more reasonable.

I think we need to fix this such that we provide the margin like IE does it, in
Quirks mode only of course.
(Assignee)

Comment 15

17 years ago
Created attachment 22092 [details]
testcase showing a floated image using the align attribute and CSS float property
(Assignee)

Comment 16

17 years ago
Created attachment 22093 [details]
Image for testcase
(Assignee)

Comment 17

17 years ago
Created attachment 22094 [details]
Testcase again with images this time. Ignore previous testcase, sorry.
(Assignee)

Comment 18

17 years ago
This looks like a general problem with margins on floated inlines in Quirks mode.

I left-floated a span and put some text next to it: Mozill aapplies no implicit
margin, whereas IE puts a 3px margin, just like it does for images.

cc'ing buster for his thoughts: should we provide a margin on floated inlines in
Quirks mode?
(Assignee)

Comment 19

17 years ago
Created attachment 22110 [details]
Testcase with floated span and floated image: no margins
(Assignee)

Updated

17 years ago
Summary: no gap between right edge of faces images and left edge of texts → no margin around floated imanges and spans (and probably other inlines)
Marc: If the author is using CSS in the first place, then we should not bother
doing any 'magic' with margins. Since they are setting the 'float' property they
quite clearly can also set the 'margin' property.

Hence I think a fix that only did things for the HTML case would be best, IF we
do this at all.

Issues I have with the patch: Do we really want a left margin on images floated
left? Or only a right margin? Should the rule really be two separate rules?
Also, please use a syntax like the rest of the file for the comments, "(b=" not
" (bug " and prefix the header with "Quirk: ". Consistency makes the file look 
more professional. :-)
(Assignee)

Comment 21

17 years ago
I'm in agreement with you, Ian, about limiting the quirk to the non-CSS case. It
is bothersome though that IE and Nav both apply margin-magic to CSS-floated
inlines, but it has not been show to be a very important quirk (i.e. no top100
sites exhibiting bad layout).

Also, I went ahead and changed the new rules to provide the margin only to the
side the image is floated to (2 rules now) and I updated the formatting as you
suggested - IMNSHO the Quirk: designation is redundant, since the file is
quirk.css. A header indicating that these are quirk rules anyway would be
sufficient, but I like consistency too ;)
(Assignee)

Comment 22

17 years ago
Created attachment 22269 [details] [diff] [review]
Updated patch
(Assignee)

Comment 23

17 years ago
Created attachment 22270 [details] [diff] [review]
Updated patch: --- just shoot me now please ;)
Marc: The reason I used the "Quirk:" prefix is to clearly signal the start of
a set of rules that deal with a particular quirk, as opposed to comments on the
individual rules. This is only an issue wit the first two quirks in the file at
the moment though.

r=hixie for http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22270
(Assignee)

Comment 25

17 years ago
*** Bug 55762 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 26

17 years ago
Fix checked in: quirk.css

Thanks to Mats Palmgren for the rule suggestion!
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Assignee)

Comment 27

17 years ago
Fixed summary type - that is all ;)
Summary: no margin around floated imanges and spans (and probably other inlines) → no margin around floated images and spans (and probably other inlines)
v per testcases
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.