Closed Bug 3655 (frameborder) Opened 26 years ago Closed 9 years ago

frameborder="0" on <frame> leaves white strip instead of removing border

Categories

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

defect

Tracking

()

RESOLVED INVALID
Future

People

(Reporter: glynn, Unassigned)

References

()

Details

(Keywords: html4, testcase, xhtml, Whiteboard: [HTML4-16.2.2] please read comment 76)

Attachments

(5 files)

March 11 Seamonkey builds, Mac 8.5/G3, Linux 5.2, optimized, viewer March 10 win98 optimized, viewer 1. Launch Seamonkey and load test case page: slip/projects/marvin/html/frameset_frame_border.html 2. Look at frame 5 for obvious example. • Frame frameborder=0 attribute setting is not rendered properly; a frame border is still rendered when value set to "0". With "0" setting you should see a borderless frame.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
Sorry, this is the way Nav4.5 does it. If you want the space of the border to go away, use border=0 also.
Status: RESOLVED → REOPENED
Not trying to be difficult here, and I am aware of the old border=0 trick, but that goes against trying to go with standards rather than how it happened to be done in prior versions of browser(s). Shouldn't we be trying to stick with the 4.0 w3 spec rather than what was decided in the past?
Resolution: INVALID → ---
Whiteboard: reopened, should support standard not old behavior here
Chris, re-assigning some of Greg's old bugs to you.
Target Milestone: M7
Moving to M7
Moving to M9.
Assignee: karnaze → pollmann
Status: REOPENED → NEW
Reassigning frameset/iframe bugs to Eric.
Status: NEW → ASSIGNED
OS: Windows 98 → All
Whiteboard: reopened, should support standard not old behavior here → [TESTCASE]
I've attached a test case. The border is not rendered, but space is still reserved for the border. According to the spec: frameborder = 1|0 [CN] This attribute provides the user agent with information about the frame border. Possible values: 1: This value tells the user agent to draw a separator between this frame and every adjoining frame. This is the default value. 0: This value tells the user agent not to draw a separator between this frame and every adjoining frame. Note that separators may be drawn next to this frame nonetheless if specified by other frames. What we're currently doing is equivalent to rendering a border, just poorly so. I agree with Greg here, we should not leave space between the frames.
Attached file Frame contents. (deleted) —
Attached file Test case (deleted) —
Moving non-critical bugs out.
After careful consideration, I've decided that I probably won't get this bug in for M12. Currently I have nearly 50 bugs scheduled for M13, so there is a possibility that this bug may need to be moved out farther still.
Target Milestone: M13 → M17
Cosmetic and not fatal. Moving to M17.
*** Bug 22631 has been marked as a duplicate of this bug. ***
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Whiteboard: [TESTCASE]
Rescheduling
Target Milestone: M17 → M20
Marking nsbeta2 since this attribute is not working properly. I see a vertical white divider between the first and second frame. Basically a divider should not be displayed. Check out our HTML 4.0 Transitional test case on mozilla.org : http://mozilla.org/quality/browser/standards/html/frame_frameborder_0.html. This test case renders without a border or divider in Mac IE 5.
Keywords: nsbeta2
Putting on [nsbeta2-] radar. Not critical to beta2. Setting on nsbeta3 radar.
Keywords: nsbeta3
Whiteboard: [nsbeta2-]
adding myself to the Cc: I'm looking into this, but I'm not taking it on until I get a better handle on the problem.
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M20 → Future
Marking nsbeta3-
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
*** Bug 47727 has been marked as a duplicate of this bug. ***
Adding HTML4 keyword.
Keywords: html4
Ugh. Sorry for the spam. One day we'll get a Bugzilla pref to add yourself to the CC: on all bugs commented on.
Blocks: html4.01
No longer blocks: html4.01
Keywords: rtm
Marking rtm-.
Whiteboard: [nsbeta2-][nsbeta3-] → [rtm-][nsbeta2-][nsbeta3-]
QA Contact: cpratt → ianh
Keywords: nsbeta1
Nominating for nsbeta1 as a standards-compliance bug we'd like to get right if possible for that release.
*** Bug 63696 has been marked as a duplicate of this bug. ***
The big problem with this bug is it forces noncompliance as a workaround. It isn't so much that the frames are rendered incorrectly, it's that we ONLY support the correct behaviour by using a non standards-compliant rendering method (the BORDER tag in the FRAMSET element, which is not allowed). If I wanted to create an html 4.0.1 (or even XHTML 1) compliant page and have no borders between my pages, I cannot do so. Further, though one of CSS2's purposes is to eliminate frames entirely (as evidenced by the lack of frames support in XHTML 1.1), the vast majority of framed websites ARE using frames, not CSS2 as of yet.
This bug is one that keeps me from being standard compliant if I want to support mozilla. It's been there for more than 2 years. Could someone fix this??
Bulk reassignin HTML FRAME/IFRAME bugs to Eric.
Assignee: pollmann → evaughan
Status: ASSIGNED → NEW
Blocks: 104166
*** Bug 121083 has been marked as a duplicate of this bug. ***
Bulk re-assigning all of Eric's HTMLFrame bugs to John.
Assignee: eric → jkeiser
The rendering problem can be viewed on two web-sites: a) home.tiscalinet.ch/kortschak (a chess-site where I try to code 'strict' W3C HTML-code. I used the sample of the w3c.org) b) www.schachclub-rhy.ch (a chess-site where I provide 'appropriate' HTML-code) On site b) I use the attribute 'border=0' to enable a proper rendering of my frames. Notice, that the border attribute must be inserted in the FRAMESET tag.
removing myself from the cc list
Fully agreed with comment #27 & 28. Noticed this issue has been delayed and reassigned since 1999. This type of changes may be boring and not challenging for the guru's out there but shouldn't have taken such a long time to resolved for us to be compliance with the w3c standard.
> This type of changes may be boring and not challenging for the guru's out > there What created this impression? I looked into doing this once. This would need a pretty complete rewrite of how frames and framesets are reflowed, of how the frame splitters are implemented, and a few other things.
Keywords: mozilla1.0, nsbeta1
> What created this impression? Sorry, don't have sufficient understanding to know the actual bulk of work involved but let's face it, taking >3 years to correct this issue is simply unreasonable for those real experts if they really make an effort to solve it. What could be other possible conclusion? Basically Mozilla is able to render the page to the needs, but handled it non- standard way. If remember correctly, older IE have a non-standard framespacing attribute for Frameset as well but corrected when w3c recommendation is out.
Nominating something for mozilla1.0/nsbeta1 is not going to give me an extra two weeks of time before 1.0. Thus it won't get fixed either way. The time is the underlying problem, not the nomination. This is a high priority on my plate. Just not 1.0 high. And remember this is a bug, not a discussion board. Please post useful information, not complaints. If you want to know how you can help, email me and bzbarsky.
>Please post useful information, I posted in a duplicate that this ougt to be a five minute fix (for someone actually able to code, ie not me :) 1,5 year ago. Why? Because Mozilla already behaves correctly if you (for the <frameset>) add the hack attribute "border=0". Thus all that should logically need to be done is to use the same "mode" by default unless frameborder is NOT 0 on all frames. In short, "fake" border=0 behaviour when all frameborders=0. The only possible problem area I can think of is if someone uses a frameborder on some parts of a page and not on some other parts, but IME that is really really rare (usually people have frameborders "off" and some few "on" but I can't recall ever seeing a single site with some "on" and some "off"). I thus can't see why that should stop a 1.0 release with this bug fixed.
> Thus all that should logically need to be done is to use the same "mode" by > default unless frameborder is NOT 0 on all frames. Unfortunately the borders are handled by the frameset in the current code. And the border width is currently decided on _before_ any of the child frames get looked at during reflow. This could be changed, but it wouldn't be particularly simple, since you'd have to look not only at frames that are children of this frameset but also at descendants (See the testcase, for example. What if all the frames were 'frameborder=0'?) and be careful not to reflow them until you get the border widths set up and all that. The initial reflow would particularly suck, since that's where the frame objects are created and initialized and the order of initialization has to be exactly right; we've already had weird bugs in window.frames ordering when that order got changed. And as you say, that would only solve the case when every single frame has frameborder=0. In particular, the testcase attached to this bug would still fail miserably. In short, it'd be a good deal of work and not really fix anything.
> the border width is currently decided on _before_ any of the child frames get looked at during reflow. :( Never mind then. It sure is a bit annoying to have to use illegal HTML for a site only due to this, but since neighter IE nor Opera does this correctly either, I'm sure there are other lot more important bugs to fix for Moz 1.0. Keep up the good work =)
nsbeta1-. Engineers are overloaded with higher priority bugs.
Keywords: nsbeta1nsbeta1-
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Just got Build 2002052508 (win2k)... the last build I had, frameborder="0" left a space: mildly annoying. this build, frameborder="0" draws the border in that space: way more annoying. Is this not *more* broken now?
That is bug 147883.
using moz1.1a (and moz1.0) on winme. to update the current status - this issue appears to have regressed further, as now there is no way to prevent frame borders from being drawn (including the old border=0 trick) except by placing a frameborder=0 into the frameset tag (which is against standards), and no way to maintain borders only between some of the frames on a page. this seems (to me) to be a major breakage that needs to be fixed. it's kinda sad if ie 4.0 is better at standards compliance with frames than moz 1.0 is. suggestions: increase priority to p1/p2 and set a reasonable target milestone (say, moz1.2) to have all frame border issues within standards. add keywords regression and 4xp (for shame's sake). set bug 147883 as a dupe of this one.
> as now there is no way to prevent frame borders from being drawn Hm, seems to be working fine for me with 1.1. Perhaps OS specific? (I'm on Win98SE) Check if eg this code adds unwanted frameborders (it doesn't for me). The only nonstandards compliant stuff used is the border="0", which is needed anyway for the page to work in IE and Opera. <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>Frametest</title> </head> <frameset cols="100, 1*" border="0"> <!-- border="0" is a bugfix for IE, NS as well as Opera --> <frame name="nav" src="nav.html" frameborder="0" marginwidth="1" marginheight="1" scrolling="auto" /> <frame name="main" src="home.html" frameborder="0" marginwidth="1" marginheight="1" scrolling="auto" /> <noframes> <body> <p> Frames are not working in your Browser. </p> </body> </noframes> </frameset> </html>
my apologies. in my previous comment i meant to say that there is no way to remove frame borders without including either frameborder=0 or border=0 in the frameset tag, neither of which are supported by html4.0 or xhtml1.0. also, there still is no way to remove/show only some frame borders on a page. msie 4.0 is compliant on both counts.
> in my previous comment i meant to say that there is no way to remove frame borders without including either frameborder=0 or border=0 in the frameset tag, neither of which are supported by html4.0 or xhtml1.0. Yes, everybody that has read this bugthread is already well aware of this. In fact that is the very reason this bug exsists :) > msie 4.0 is compliant on both counts. Perhaps, but eg MSIE 6.0 is NOT compliant, neighter is eg Opera 6.x. This can also be read in this thread including a plausable reason for why this is (rendering speed). =)
Whiteboard: [rtm-][nsbeta2-][nsbeta3-] → [rtm-][nsbeta2-][nsbeta3-][HTML4-16.2.2]
Blocks: 158464
Keywords: mozilla1.1
Looks like bug 147883 is a dupe. Fpr some reason, nobody reacted to this suggestion there. pi
*** Bug 147883 has been marked as a duplicate of this bug. ***
Sorry guys, but this bug exists in Mozilla 1.1. I upgraded from 0.9.9 to 1.1 and all of my frames had borders, even though I had frameborder="no"/frameborder="0" and border="0" in my frame tag. I downgraded to 0.9.9 again and this problem doesn't appear. Did something break in 1.1?
Would someone please fix this. Mozilla is supposedly one of the most compliant browsers out there, and that is often touted as one if it's best features. Mozilla 1.1 does NOT comply with the HTML 4.01 spec. Why should we be forced to use nonstandard tricks to get the page to render correctly? Nobody on the Mozilla team feels this is important enough to fix? I have read that this would require a rewrite of this or that... So what? Rewrite it! This bug has existed for over 2 years! Get it fixed! I don't want to hear that IE or Opera don't do it correctly either, that doesn't make it right for Mozilla to behave incorrectly. Is anyone listening?
Adding helpwanted keyword to make the situation clear. Let me summarize the state of things: 1) This would be a big rewrite of the frame layout code. That's a large investment of time. It means someone has to pay for that time (in company money, volunteer time, or something). Obviously none of the companies contributing to this project care so far and no volunteers have expressed interest in doing this. Oh, and anyone with the knowledge to do such a rewrite is typically busy fixing bugs that really affect our interaction with real-world websites.... 2) Specifying frameborder="0" on a single frame in a frameset can lead to a situation where it's not clear how the page should be rendered and it's not clear how it should react when splitters dragged. (consider 4 frames, 2 rows and 2 cols in a single frameset. frameborder="0" on all but the top-left frame. What should the frame sizes be? What should happen as one of the two splitters is dragged?). Basically, I feel that this part of the specification is incredibly poorly thought out and not implementable in any meaningful manner. (And yes, I spent a few dozen hours at one point working on this. I hold by my statement that the spec, as written, is simply not implementable). 3) Mozilla does not even comply with the HTML 2.0 spec fully. Nor does any other browser. We're trying, but it's always a tradeoff between what we'd like to have and the constraints real life places on us (eg. I can't spend 300 development hours on this bug, because I just don't have 300 hours to spend and I have more important bugs (crashers, non-compliance to non-obsolete specifications, etc) to fix). I would much appreciate it if someone addressed point #2 and proved me wrong, I should note.
(bz: "Note that separators may be drawn next to this frame nonetheless if specified by other frames." -- HTML4:16.2.2:frameborder) Of course frames are deprecated and stylistic attributes like frameborder doubly so... People really shouldn't be using the frameborder attribute, so there's a good argument here for us to never fix this.
Whiteboard: [rtm-][nsbeta2-][nsbeta3-][HTML4-16.2.2] → [rtm-][nsbeta2-][nsbeta3-][HTML4-16.2.2] WONTFIX?
Ian, I've read that sentence. Many times. My question stands. Read my proposed scenario again... There should be something like: frame | frame ------- frame frame With just those two splitters reaching halfway, right? Where should the bottom-right frame end? What happens at the corner? Are there gaps between the top-right and bottom-right frames? Same for bottom-left and bottom-right? What if the frameset spec is cols="*,*" rows="*,*" so that the frame sizes should be equal? What happens when the vertical splitter is dragged? Does the bottom-left frame resize? If so, why? If not, why not?
i think part of the reason for the confusion on how frameborder=0 would be ideally rendered is due to the need to decide whether a frameborder=0 would supercede the default frameborder in adjacent frames, would be superceded by the default, or would be superceded only by an explicit frameborder=1 in the adjacent frame. i would say that the specifications call for the latter. this would cause none of the frame borders to be drawn in the 2x2 3-out-of-4-frameborder=0 example unless an explicit "frameborder=1" is included in the fourth frame. dragging behaviour should therefore follow based on which borders are drawn. given the nature of this bug, the status whiteboard, and the lack of a milestone target, i don't see how it's a major severity bug. however, it shouldn't be written off just because it's hard. is there a shortcut or temp hack possible to try for an interim solution - maybe allowing a frameborder=1 within a <frame> to override a frameborder=0 statement in a <frameset> and draw borders locally? this would be the inverse of the specs, but would at least allow for equivalent behaviour.
Severity: major → normal
> i would say that the specifications call for the latter. The specification says the default value of "frameborder" is "1". So having "frameborder=1" and not having a frameborder attribute at all are exactly equivalent. > dragging behaviour should therefore follow based on which borders are drawn. This tells me nothing. When I grab that vertical splitter that goes halfway down the page and drag, which frames change size? What you're suggesting is just as hard to do as the "correct" fix. No one is writing it off because it's "hard"; I'm writing it off because the spec, as written, does not admit a reasonable implementation of any sort that I can see.
In reference to comment #56, Frames are still valid even in the XHTML 1.0 Spec, via the Frameset DTD, which I wouldn't *quite* call deprecated yet, since the vast majority of websites don't even support it yet. :) My only real question is this: Since you can obtain the correct rendering of sites using the "border=0" attribute. Do the current questions regarding borders, etc. not apply to that attribute? Can we not simply import the behaviour of the "border" attribute into the "frameborder" attribute?
"border=0" goes on the frameset, not the individual frames... It does nothing I can discern when placed on frames.
Ok, here's a testcase: http://www.hixie.ch/tests/adhoc/html/frames/001.html Since we do the same as IE, and it seems sensible to me, and it is most definitely within the vagueness of the spec, WORKSFORME. If you want to reopen it, please be extremely specific about what is wrong with the way we render that testcase. Or if the problem is with some other testcase, please be very specific about that one. (We render the official URI for this bug the same as IE, give or take a few insignificant pixels.)
Status: NEW → RESOLVED
Closed: 26 years ago22 years ago
Resolution: --- → WORKSFORME
When I go to the testcase page (using Mozilla 1.1, windows 2000), I see a border on all frames (A Cross basically)! Am I the only one seeing this behavior?
Don't use 1.1. Use a recent build. The border code was touched somewhat since 1.1 (like a lot).
O.K. The newest nightly does at least erase the borderd properly... Yay! But... The sapce where the border is normally drawn still exists, this isn't as good. I know IE does something similar, but I still don't think thats right... Consider upper-right has a dark background, and lower-right has same dark background. The way it is now, an ugly white line is drawn in between, when I think there should be no discernable space...
For Ian's testcase I think there should be no border between b and d,since both have frameborder=0. But I think (and there are many vortes and dupes asking for a solution) that the key question is how to achieve the following common web site structure in *valid* HTML: A frameset where there are no borders anywehere and all frames "touch" their adjacent ones, i.e., there is no space between them. Like in the attached testcase no (white) space between middle and right frame. If this has a solution, then I would say WFM. Before that I don't think it should be RESOLVED in any way. pi
Strictly valid HTML wouldn't use frames at all.
Ian, IBTD: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN" "http://www.w3.org/TR/REC-html40/frameset.dtd"> can be used and validated. pi
Yes, but that is not strictly valid. It's using a deprecated DTD. I made a second testcase, which shows that we aren't really doing the right thing. When frameborder="0", we should be hiding the border, not just making it white. http://www.hixie.ch/tests/adhoc/html/frames/002.html REOPENing. I don't think we need to solve the problem bz was talking about, it can't be solved sensibly. However, we should try to at least, as Boris put it, "achieve ... in *valid* HTML ... a frameset where there are no borders anywhere and all frames "touch" their adjacent ones, i.e., there is no space between them". At the moment the only way to do that is using the non-standard "borders" attributes on the <frameset> elements: http://www.hixie.ch/tests/adhoc/html/frames/compat/001.html
Alias: frameborder
Status: RESOLVED → REOPENED
QA Contact: bugmail → ian
Resolution: WORKSFORME → ---
Summary: frameborder=0 attribute value not rendered properly → frameborder="0" doesn't remove borders on frames
Whiteboard: [rtm-][nsbeta2-][nsbeta3-][HTML4-16.2.2] WONTFIX? → [rtm-][nsbeta2-][nsbeta3-][HTML4-16.2.2]
So let me get this straight... the request is: If all the frames involved have frameborder="0" then don't show any borders anywhere and don't leave space for them. Is this correct?
<frameset frameborder="1"> <frame frameborder="0"> <frame frameborder="0"> </frameset> What's the expected rendering?
<frameset frameborder="1"> <frame frameborder="0"> <frame frameborder="0"> </frameset> That's not valid html. According to html 4.01 spec, there is no frameborder property of frameset. But, even so, I would say to not show any borders. I would have the individual frame settings override the frameset if such html was encountered.
This is a big offtopic, but I thought maybe someone here would be able to provide an answer. Since it's been mentioned that Frames are depricated, and indeed, seem to be removes from xhtml 1.1, excatly how is the same effect supposed to be done? I have yet to see anything that can replace the exact functionality of frames (load multiple .html pages on one screen, layout, etc)... I have seen some CSS stuff, but things like target= and such dont seem to be getting replaced. I'm just wondering if maybe someone has a guide oh how to replace frames with CSS, or whatever w3c is recommending, since I cannot find anything right now.
------ <frameset frameborder="1"> <frame frameborder="0"> <frame frameborder="0"> </frameset> What's the expected rendering? ------ Definintly not draw any borders, since the (illegal) frameborder in frameset should be ignored. ******** Since it's been mentioned that Frames are depricated, and indeed, seem to be removes from xhtml 1.1, excatly how is the same effect supposed to be done? -------- Frames where actally "removed" already in 1999 dince it's only included in the HTML 4.01 Spec as an "compability with old browsers" feature (aka deprecated). As I'm sure you are aware of you are supposed to write STRICT HTML 4.01 for v4.x+ browsers and only use transitional to add support for older browsers by adding deprecated HTML to your exsisting STRICT pages ;) Anyway, to get the functonality of <frame>s using valid strict HTML 4.01 and later, use <object type="text/html"... Of cource most browsers doesn't handle this very well yet (including Mozilla...), so if you have serverside methods at your desposal, those are preferable.
*** Bug 168474 has been marked as a duplicate of this bug. ***
OK. Here's a summary of the situation, in case someone has time to do it. I will not be able to get to this for at least a month (I'll be off the net, for one thing). Right now the border stuff is determined in nsFrameSetFrame.cpp; the function in question is nsHTMLFramesetFrame::Init(). Now the trick is that Init() is called at construction time of the frame (layout frame, not HTML frame; I hate the terminology). So it has access to the frameborder of the parent (which it inherits if its own is not specified), but does not have access to the frameborders of the child frames (again, layout frames), since those have not been constructed yet. It _does_ have access to the child content nodes, or at least would break horribly as-is if it did not. So it's all well and good until you get to trying to handle the case of <frameset> <frame frameborder="0"> <frameset> <frame frameborder="0"> <frame frameborder="0"> </frameset> </frameset> In this case we need the "computed frameborder" of the inner frameset before it know is, essentially. Oh, and slowing down this code is punishable by beating (it's already slower than it needs to be), so recursively walking for every frameset and thus walking the inner frames twice in this case is not such a great idea...
frameborder="0" in the frameset tag removes the borders, this is however not correct according to w3c HTML spec
Frameborder="0" works in the frameset object but it belongs in the frame object. I.e. <frameset cols="*,*" frameborder="0"><frame src="col1.html"><frame src="col2.html></frameset> will work but the w3c standard calls for the frameborder to go like this <frameset cols="*,*"><frame src="col1.html" frameborder="0"><frame src="col2.html frameborder="0"></frameset>
In Mozilla 1.2 this bug must be fixed!
> In Mozilla 1.2 this bug must be fixed! #1 Mozilla 1.2 final is already out. #2 This is an open source project. I'm sure your patch contributions will be gladly accepted. :)
Stefan Huszics: OK - it was my fault :-( I wanted to say: This Bug was fixed in 1.2 ! Sorry :)
No it was not.
Linux 2003020805; the bug isn't fixed yet
We could potentially modify the borders whenever children are added. It does amount to recursion, but it would make JavaScript and frames more robust.
*** Bug 198545 has been marked as a duplicate of this bug. ***
Adding XHTML keyword since XHTML 1.0 framesets do not work properly either.
Keywords: xhtml
Are they ever going to fix this? I have <frameset cols="21%,2px,*" border="0" frameborder="0"> in my index.html page and the borders are still there and still resizeable (I have every one set to be not resizeable.) See http://olr.freemason.com/mozerrors for examples (like you haven't seen enough already ;) ).
Flags: blocking1.4b?
For me, in any case, this appears to be hardware dependent. On my laptop borders on all websites are visible and resizeable no matter what code is used. On my desktops they render correctly.
Flags: blocking1.4b? → blocking1.4b-
Summary: frameborder="0" doesn't remove borders on frames → frameborder="0" on <frame> leaves white strip instead of removing border
Seems to be affecting all images in XHTML rendering. Puts a 6-8 pixel border on the top and bottom of image
Comment #88 was resolved by upgrade to 1.5.
Is this a particully hard bug to fix?
*** Bug 247655 has been marked as a duplicate of this bug. ***
This bug is still valid in Firefox 0.9 over 5 years after it was entered into bugzilla :( .. nuff whining .. I have actually noticed something .. emm odd when using the testcase that _might_ be another bug. The frameborders can be dragged by the mouse (ofcourse) , but when you drag the border between A and B or the one between C and D you misalign the image (also quite normal). Here is a task for you .. realign the image again. Observation : You CAN'T. The dragged frame seems to skip pixels and always does this when the frames are nearly aligned. Why is that ?
I suggest WONTFIX. Frames are not used that many anymore and it seems not a lot of people have problem with Mozilla's behavior.
Assignee: john → nobody
Status: REOPENED → NEW
Keywords: nsbeta1-
QA Contact: ian → core.layout.html-frames
Whiteboard: [rtm-][nsbeta2-][nsbeta3-][HTML4-16.2.2] → [rtm-][HTML4-16.2.2]
(In reply to comment #94) > I suggest WONTFIX. Frames are not used that many anymore and it seems not a lot > of people have problem with Mozilla's behavior. I respectfully disagree. You are somewhat right, frames may not be used "much" any more on most "mainstream" sites. They are, however, used in many corporate intranets and other large- and small-scale web applications.
Does this bug does any harm to their implementations? Because there are other, non-standard methods, which are often used to "collapse everything together". They work in Mozilla too. I believe something like the following on the top frameset element will do: # <frameset frameborder="0" framespacing="0" border="0"> That is by the way the *only method* to safely collapse everything together cross browser.
If Mozilla shows incorrect behavior this is a valid bug and there are no good reasons why it *should* be decided not to fix it. I do not think it would harm to leave the bug open to document the problem. Also, having an open bug will prevent many DUPes by people who would otherwise create a new bug for this.
I disagree with WONTFIX. Mozilla does not program to likes or dislikes or current practice but to the published standards. That's what sets us apart from IE/OE.
> Mozilla does not program to likes or dislikes or > current practice but to the published standards. Yes? So look what happened to the basefont bug 3875. Basefont is a legal element of HTML 4.01 standard. Sorry for the spam, of course :-)
A. Sorry about the basefont thing; I'm not a programmer just a complainer, er, bug reporter. 2. What spam?
Every time someone makes a comment people get mail (often called spam) and the bug becomes less likely to be fixed. Mozilla is not aiming for full HTML 4.01 support. Mozilla will be a XML browser with some knowledge of HTML 4.01 and the XHTML namespace. It will support CSS and some additional technologies. Therefore it isn't likely that deprecated features will be supported if it isn't really needed (it doesn't seem to be the case that sites depend on it and there is a workaround as mentioned in comment 96). So until someone creates a patch, as outlined in comment 76 it doesn't make sense to put *any* additional comments to this bug.
Whiteboard: [rtm-][HTML4-16.2.2] → please read comment 76 and 101 first
> Every time someone makes a comment people get mail (often called spam) > and the bug becomes less likely to be fixed. If the likelyhood of a bug fix is inversely proportional to the number of comments a bug report receives, that just seems like evidence of contributors and developers that are prone to temper tantrums and petty vendettas rather than any valid commentary on the reporters.
Re #102 I'm sure devs don't mind good usefull input/feedback, but quite often new posts are just repeating what has already been said and/or don't take into consideration the complexities/facts that has already been explained. That just creates background noise that the human brain subconsiosly learns to filter out. > # <frameset frameborder="0" framespacing="0" border="0"> Exactly what browser(s) need the addition of (an illegal) frameborder="0" in the frameset as a workaround? IME border="0" is enough, but mayby I missed some? PS I also agree with closing this bug would be a bad idea since there would be sure to appear dups. This is a valid bug against the latest valid HTML spec (though one of the main problems in solving it is in fact that the spec is unclear in how things should behave, so the first step would be to get a clarification in the HTML spec).
Restoring pertinent info.
Whiteboard: please read comment 76 and 101 first → [HTML4-16.2.2] please read comment 76
*** Bug 268880 has been marked as a duplicate of this bug. ***
*** Bug 289397 has been marked as a duplicate of this bug. ***
Could this not be solved by simply following the suggestion in CSS 2.1? http://www.w3.org/TR/CSS21/tables.html#propdef-border-spacing: �*) Note: user agents may also apply the 'border-spacing' property to 'frameset' elements. Which elements are 'frameset' elements is not defined by this specification and is up to the document language. For example, HTML4 defines a <FRAMESET> element, and XHTML 1.0 defines a <frameset> element. The 'border-spacing' property on a 'frameset' element can be thus used as a valid substitute for the non-standard 'framespacing' attribute.� The obvious example: frameset {border-spacing: 0;}. You still wouldn't have a solution for the HTML 4.01 frameborder attribute, but it could be a validating substitute for the current method that Mozilla supports because it could just utilize the existing functionality. A value of zero would be equivalent to 'frameborder="1"' and a value greater than zero would be equivalent to 'frameborder="0"'. // Just for reference, the framespacing attribute seems to be Microsoft's equivalent to Mozilla's frameborder attribute except with more functionality (and arguably uglier). That's documented at: http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/framespacing.asp
My idea: 1. Drop the current frame border rendering code entirely. (That is, without the rest of the solution, no frame borders at all.) 2. Base our new solution on CSS. 3. Threat frames that are not frameborder=0 as if they had CSS that makes borders appear around them. (So, a frame surrounded by other frames is essentially "border:2px halfframe oscolor", where the border style "halfframe" refers to a border style that looks like half of ur current solution, while "oscolor" refers to automatically choosing the right color according to the operating system colors. We should decide whether or not to expose these "new" options in real CSS.) 4. On frames that are *NOT* entirely surrounded by other frames (that is, frames that touch the edge of the page), skip sides that are on the edges, and draw borders on the rest of the frames. 5. If a frame that is frameborder=0 and another that is frameborder=1 are adjacent to each other, draw the half-border of the frame that should have a border as usual, and if and only if a HTML-parser is used, draw the other half of the border on the other frame. If an XML-parser is used, skip the second part of this rule as an HTML-specific style provision. 6. If two adjacent frameborder=0s are present, do the obvious thing (drawing no border on both frames). I will attach a mockup of a 3x3 frameset using these new rules later.
This is a demonstration of how it should look after the fix. (Note that the XHTML-specific "half-border" behavior is just a "fallback" in case we can't do CSS provisions at all in XHTML.)
I could understand that some functionality is not planned to be implemented, but not things like that! How am I suppose to write a *valid* HTML page that is properly displayed in Fx? And don't tell me about all those dtd workarounds. Now w3c validator claims my site is not valid - I'd like to make it valid, but then I'd have to give up with Fx compatibility... Come on, 9 years passed...
By the way, I have written a way to implement the spec more correctly/reasonably. Still noone is touching this bug, eve though the "no correct way to implement the spec" problem is mostly fixed.
A lot of time passed, so: has anything changed since 2008 so that it would ease fixing this rendering issue in Firefox 9+? Just asking, not that I use frames a lot currently.
As of late 2015: Hixie testcase 001: Google Chrome 47, Apple Safari 9, and Firefox 4x all display identically (no border between C & D). MS Explorer 11 displays no borders at all. Hixie testcase 002: Chrome, Safari & Firefox display identically (all white borders). Explorer has slightly thinner borders. Pollmann testcase: Chrome, Safari & Firefox display identically (3 gray borders, white-on-white gap between last two frames). Explorer goes completely off the rails, showing white borders on everything, and aqua page backgrounds? Nevertheless, given that none of the browsers render in the desired way, perhaps the thing that should be changed is the developers' expectation?
I think this bug should be closed. The original complaint is that people wanted to write standards-compliant HTML. A decade later, anyone who cares about validation and standards DOES NOT USE FRAMES. They are at best merely deprecated, at worst "entirely obsolete, and must not be used". Also, if somehow this bug were "fixed", Firefox would be the only major browser to render framesets that way. It would be a case of jumping off a nice solid bridge (that isn't on fire) when everyone else is staying on.
Gecko displays the testcases identically to WebKit & Blink, and "web standards" is no longer a significant concern for frameborder. Everyone have a happy 2016.
Status: NEW → RESOLVED
Closed: 22 years ago9 years ago
Resolution: --- → INVALID
(In reply to Frankie from comment #116) > Gecko displays the testcases identically to WebKit & Blink Oh, well as long as everyone else is getting it wrong too, no need to have Firefox get it right.
(In reply to Jerry Baker from comment #117) > (In reply to Frankie from comment #116) > > Gecko displays the testcases identically to WebKit & Blink > > Oh, well as long as everyone else is getting it wrong too, no need to have > Firefox get it right. The frame element -- for which the frameborder attribute addressed by this bug exists -- is defined as an "obsolete" and "non-conforming" feature in the WHATWG HTML Living Standard specification; see https://html.spec.whatwg.org/multipage/obsolete.html#non-conforming-features. That makes this bug moot since its only purpose would be to change the rendering of preexisting pages or new, post-2015 pages created with frame elements in violation of the spec. (I'll unvote for it shortly.) The spec suggests an alternative: "[e]ither use iframe [elements] and CSS instead, or use server-side includes to generate complete pages with the various invariant parts merged in". You'll lose the de facto standard drag/drop/resize behavior of frame element borders, but that can be duplicated by using JavaScript if necessary. Another alternative is to use XHTML documents in tandem with an XSLT style sheet. When used to generate complete pages client-side, this has the advantage that each page will have a unique, navigable URL instead of a single URL owned by a frame-hosting page. I think this is a better approach than what the HTML spec suggests if you're just trying to add boilerplate items like a menu, header, and footer to your content.
Patrick is right. However problems like this one, namely HTML elements which became obsolete before they have been implemented is a legacy of a much slower implementation in the old Netscape era. Another example was basefont, the hero of bug 3875.
1. Since when is whatwg a recognized standards body? 2. So Mozilla's position is that it will not render legacy Web pages correctly? That's handy.
I checked. The frameset element is not deprecated. It appears in the HTML5 specification. http://www.w3.org/TR/2014/REC-html5-20141028/rendering.html#frames-and-framesets
(In reply to Jerry Baker from comment #121) > I checked. The frameset element is not deprecated. It appears in the HTML5 > specification. > > http://www.w3.org/TR/2014/REC-html5-20141028/rendering.html#frames-and- > framesets The W3C spec you've cited says the same thing the WHATWG spec does at http://www.w3.org/TR/2014/REC-html5-20141028/obsolete.html#non-conforming-features. It, likewise, calls the frame and frameset elements "obsolete" and "non-conforming". In other words, the W3C is also behind the idea that these elements -- and therefore the frameborder attribute -- should never be used. As for the page you've cited, there's a lead-in paragraph that states "User agents are not required to present HTML documents in any particular way. However, this section provides a set of suggestions for rendering HTML documents that, if followed, are likely to lead to a user experience that closely resembles the experience intended by the documents' authors. So as to avoid confusion regarding the normativity of this section, RFC2119 terms have not been used. Instead, the term 'expected' is used to indicate behavior that will lead to this experience." See http://www.w3.org/TR/2014/REC-html5-20141028/rendering.html#rendering for that paragraph. The WHATWG spec has a corresponding paragraph at https://html.spec.whatwg.org/multipage/rendering.html#rendering. To summarize, the rendering behaviors specified at http://www.w3.org/TR/2014/REC-html5-20141028/rendering.html#frames-and-framesets and https://html.spec.whatwg.org/multipage/rendering.html#frames-and-framesets are merely suggestions, not requirements. In light of those suggestions though, I do think this bug should have been resolved "RESOLVED WONTFIX" since this bug now represents a request to implement an optional part of a spec, however the result will be the same. (I don't expect a fix because, as I indicated before, this only fixes legacy pages and specifically those that used frameborder="0" even though it didn't work in all browsers.) If you're still creating frame-based pages in violation of the specs, you can use the non-standard framespacing="0" attribute as a functional alternative. Your pages won't be standards-compliant if you're using the frame element, so I suppose it doesn't matter if a non-standards-compliant attribute is used at that point. I'd advise against it though due to navigation issues. For example, I still visit http://bmproductions.fixnum.org/index.htm?http://bmproductions.fixnum.org/wmptagplus and fragment identifiers that should normally shortcut me to a specific part of a page (like #downloads) don't work because they refer to the frame-hosting page instead of the content page.
(In reply to Jerry Baker from comment #120) > 1. Since when is whatwg a recognized standards body? The web does not start with standards. It took me a long time to understand how the web works. I did my best to try to share my understanding of the relationship between user/authors/implementors/spec writers here: https://youtu.be/7eNFQqMSxtU?t=62 And the WHATWG is probably the only standards body that functions acknowledging how the web actually works, so always creates the most accurate specs. As a web developer, it's the standard body I "recognize" and trust the most by a long shot (for the specs they cover). > 2. So Mozilla's position is that it will not render legacy Web pages correctly? For all I know, Mozilla (and all major browser makers) make backward-compatibility a top priority and is part of literally every discussion about moving the web forward. Do you have knowledge of web pages in the wild which, today, are broken by the current behavior? Can you share the links if so? Otherwise, it's just an hypothetical concern and all browsers are already busy working on concerns which have proven to be a problem in actual websites.
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core

https://html.spec.whatwg.org/multipage/rendering.html#attributes-for-embedded-content-and-images

for the suggested CSS default.

iframe[frameborder='0'], iframe[frameborder=no i] { border: none; }

frameborder="" is interpreted as 0 in WebKit and Blink.

data:text/html,<!doctype html><iframe style="height:300px;width:300px;background-color:gold;" frameborder="">foo</iframe>
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: