Closed Bug 5610 Opened 26 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.