Closed Bug 5610 Opened 25 years ago Closed 25 years ago

Extra padding below <IMG> inside of an <A>

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

defect

Tracking

()

VERIFIED DUPLICATE of bug 4677

People

(Reporter: silver, Assigned: buster)

References

()

Details

(Whiteboard: [TEST] pglendinning@cen.com)

There is a serious problem in rendering frames in Netscape (mozilla-gecko) in
comparision to IE. Please check the given link
(http://www.alton.hu/jogar/frames.html) both in IE and Netscape or Neoplanet
5.0 to see the problem. This I call serious for it makes developing site using
frames virtually impossible, for viewers can only see a damaged view of the -
originally- well positioned frames and images if they are using netscape.
Compatibility! That is the most important. Our best guess is that Netscape does
not use the given pixel values but converts them to percentages.

PLEASE DO SOMETHING! This is important for the whole internet community and
website developers!

Thanx in advance.

Bela
Severity: trivial → normal
Status: NEW → ASSIGNED
Target Milestone: M6
I started looking at the file and it seems that the frameset page is not coded
correctly. Here is the frameset breakdown:
<frameset rows="30*,400,30*" frameborder="NO" border="0" framespacing="0">
  <frame src="feher.html" MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=NO noresize>
 <frameset cols="*,600,*">
  <frame src="bal.html" MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=NO noresize>
  <frameset rows="40*,340,20*">
    <frame src="logopici.html" MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=NO
noresize>
      <frame src="main.html" MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=AUTO
noresize name="tartalom">
      <frame src="also.html" MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=NO noresize>
    </frameset>
  <frame src="csikjobb.html" MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=NO noresize>
 </frameset>
    <frame src="csiklent.html" MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=NO
noresize>
  </frameset>

In the first frameset, they have the rows set at 30*,400,30* -- what this states
is: the middle column should be 400 pixels and the remaining pixels should be
divided up between the remaining columns, however, using the * denotes that they
are supposed to be 30 times larger then the other column. The * is used to
signify a multiple. See section 16.2, Rows and Columns of the HTML 4.0 DTD for
an explanation. I would imagine the code could be rewritten to reflect the
appropriate sizing that is needed.
Moving to M8
Assignee: karnaze → pollmann
Status: ASSIGNED → NEW
Reassigning frameset/iframe bugs to Eric.
Whiteboard: [MAKINGTEST] pglendinning@cen.com
I've posted three preliminary simplified test cases at
http://www.serve.com/apg/bugzilla/5610.html, one with a horizontal frameset, one
vertical, and one with both vertical and horizontal. The frame sizing seems to
be working fine in M7(Win32) in all three cases.

This looks to be the same bug as is reported in #5833, and has been a big
problem in Netscape's browsers. If you look at the test cases in a
Communicator or Navigator 4.x and change the size of the browser window slowly,
you'll see that not only are the fixed-size frames never the right size, but
they change sizes as the main window changes.

As for the bit mentioned above about the sizes specified in the original URL
reported, I'd agree that the code is probably technically incorrect. However, I
don't know that the * notation should be interpreted as a multiple, but as a
ratio. That is, you add up all the coefficients and allocate space based on each
frame's coefficient in relation to the sum.

This would mean that 30*,400,30* would reduce down to the same thing as *,400,*,
and 40*,340,20* would be 2*,340,*. The spec isn't very clear as to whether or
not relative lengths should be reduced like this, though.

http://www.w3.org/TR/REC-html40/types.html#type-multi-length
Here's another example from me. I guess this code is so simple, that this one
cannot be the brought down to an HTML bug. This page renders fine in IE or
Neoplanet. If You open the different frames (eg. top left) in a new window (in
netscape), it works fine, so the problem is simply with frame sizes again. I
hope this helps.

http://www.alton.hu/silver/lq/index2.html
The problem that M7(Win32) has with the above URL is not related to frame
sizing, but to the fact that the framed documents are rendered with a one-pixel
margin, even though the marginheight and width are set to zero in the frameset.
For example, the topleft frame *is* 475 pixels wide, but two of those get taken
up by the left and right margins. That's why your images (whose total width is
475 pixels) end up wrapping to a second line in M7.

When I add the code "marginwidth=0 marginheight=0" to the body tags of each of
the framed documents, the wrapping problem goes away in M7(Win32). (Although,
there's some strange spacing being left between the lines of images where it
would seem they should butt up against each other. It's not really a frameset
issue, so I'll see if it's addressed in a separate bug.) I shouldn't have to do
this, however, since those values are set in the frameset. Not to mention the
fact that those are not proper attributes of the body tag, according to the
spec:

    http://www.w3.org/TR/REC-html40/struct/global.html#edef-BODY

This is completely different from -- although visually similar to -- the problem
Communicator or Navigator 4.x (and earlier for that matter) have with the
frameset. In those cases the frameset is rendered at slightly varying sizes
depending on the size of the full browser window, usually smaller than the
specified size.
Didn't make M8
Status: NEW → ASSIGNED
I checked out the examples in Gecko vs. IE 5.0 (Neoplanet uses IE 5.0's
rendering engine and will always look identical to IE for every page...)

http://www.alton.hu/jogar/frames.html
Looks the same in both browsers at all window sizes.  What's wrong here?

http://www.alton.hu/silver/lq/index2.html
Lines wrapped in Gecko, did not wrap in IE.

Then for the interesting part:

I resized down IE's window to the same size as Gecko's (let's compare apples to
apples), and found that IE wraps lines exactly like Gecko does.  When there is
not enough space to render the requested pixel width, you have the option of
either letting things slide off the right or scaling them down.  Both IE and
Gecko scale down.  This does not seem like a bug to me.

I then resized Gecko's and IE's window up to the original size IE started at.
There was a small horizontal line (2 pixels?) between the halves of the
LAquaTec' gif.  This may be a bug.  I'm still looking into the cause.
OS: Windows 98 → All
Hardware: PC → All
Whiteboard: [MAKINGTEST] pglendinning@cen.com → [TEST] pglendinning@cen.com
The vertical gap is caused by the <A> surrounding the images, when I removed or
commented out the <a>, things displayed exactly the same as IE.  I don't know
why the border=0 spec on the image isn't preventing this.
Assignee: pollmann → troy
Status: ASSIGNED → NEW
Summary: Inaccurate rendering of pixel sized frames → Extra padding below <IMG> inside of an <A>
Troy, I don't know who this should go to, but it seems like a core layout issue.
Why is there extra padding on the bottom of this an <IMG> contained in a <A>?  I
tried playing with the ua.css file, particularly the 'a:link img' spec but had
no luck.  Can you take a look?  Thanks!

I copied this test case internally, which you can modify, at:
/u/pollmann/public/work/frames/wrap/index.html

You can view it at:
http://blueviper/frames/wrap
Assignee: troy → kipp
Kipp, this is another example of <BR> and inline elements interacting to
cause excess spacing. I think it's an inline layout issue.

I thought you had another bug that was the same (and this would be a DUP), but I
can't seem to find it.

This is really the URL you want to look at:
http://blueviper.mcom.com/frames/wrap/topleft.html
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 4677 ***
Status: RESOLVED → VERIFIED
Verified Dup
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.