Bug 3655 (frameborder)

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




Layout: HTML Frames
19 years ago
a year ago


(Reporter: glynn, Unassigned)


({html4, testcase, xhtml})

html4, testcase, xhtml
Dependency tree / graph
Bug Flags:
blocking1.4b -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [HTML4-16.2.2] please read comment 76, URL)


(3 attachments)



19 years ago
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:
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.


18 years ago
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 1

18 years ago
Sorry, this is the way Nav4.5 does it. If you want the space of the border to go
away, use border=0 also.


18 years ago

Comment 2

18 years ago
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?


18 years ago
Resolution: INVALID → ---
Whiteboard: reopened, should support standard not old behavior here

Comment 3

18 years ago
Chris, re-assigning some of Greg's old bugs to you.


18 years ago
Target Milestone: M7

Comment 4

18 years ago
Moving to M7

Comment 5

18 years ago
Moving to M9.


18 years ago
Assignee: karnaze → pollmann

Comment 6

18 years ago
Reassigning frameset/iframe bugs to Eric.


18 years ago
OS: Windows 98 → All
Whiteboard: reopened, should support standard not old behavior here → [TESTCASE]

Comment 7

18 years ago
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

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.

Comment 8

18 years ago
Created attachment 662 [details]
Frame contents.

Comment 9

18 years ago
Created attachment 663 [details]
Test case


18 years ago

Comment 10

18 years ago
Moving non-critical bugs out.

Comment 11

18 years ago
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.

Comment 13

18 years ago
*** 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


18 years ago
Whiteboard: [TESTCASE]

Comment 15

17 years ago
Target Milestone: M17 → M20

Comment 16

17 years ago
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

Comment 17

17 years ago
Putting on [nsbeta2-] radar. Not critical to beta2.  Setting on nsbeta3 radar.
Keywords: nsbeta3
Whiteboard: [nsbeta2-]

Comment 18

17 years ago
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.

Comment 19

17 years ago
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. ***

Comment 22

17 years ago
Adding HTML4 keyword.
Keywords: html4

Comment 23

17 years ago
Ugh. Sorry for the spam. One day we'll get a Bugzilla pref to add yourself to 
the CC: on all bugs commented on.


17 years ago
Blocks: 7954


17 years ago
No longer blocks: 7954


17 years ago
Keywords: rtm
Marking rtm-.
Whiteboard: [nsbeta2-][nsbeta3-] → [rtm-][nsbeta2-][nsbeta3-]


17 years ago
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.

Comment 26

17 years ago
*** Bug 63696 has been marked as a duplicate of this bug. ***

Comment 27

16 years ago
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.

Comment 28

16 years ago
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


16 years ago
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

Comment 32

15 years ago
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.

Comment 33

15 years ago
removing myself from the cc list

Comment 34

15 years ago
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.


15 years ago
Keywords: mozilla1.0, nsbeta1

Comment 36

15 years ago
> 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

Comment 38

15 years ago
>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.

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.

Comment 40

15 years ago
> 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: nsbeta1 → nsbeta1-

Comment 42

15 years ago
Mass removing self from CC list.

Comment 43

15 years ago
Now I feel sumb because I have to add back. Sorry for the spam.

Comment 44

15 years ago
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?

Comment 45

15 years ago
That is bug 147883.

Comment 46

15 years ago
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.

Comment 47

15 years ago
>  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"
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<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" />
Frames are not working in your Browser.

Comment 48

15 years ago
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.

Comment 49

15 years ago
> 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]


15 years ago
Blocks: 158464


15 years ago
Keywords: mozilla1.1

Comment 50

15 years ago
Looks like bug 147883 is a dupe. Fpr some reason, nobody reacted to this
suggestion there.


Comment 51

15 years ago
*** Bug 147883 has been marked as a duplicate of this bug. ***

Comment 52

15 years ago
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?
Yes.  see bug 147883

Comment 54

15 years ago
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
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?

Comment 58

15 years ago
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
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

> 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.

Comment 60

15 years ago
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:

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.)
Last Resolved: 18 years ago15 years ago
Resolution: --- → WORKSFORME

Comment 63

15 years ago
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).

Comment 65

15 years ago
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...

Comment 66

15 years ago
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.

Strictly valid HTML wouldn't use frames at all.

Comment 68

15 years ago
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.

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


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:

Alias: frameborder
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">

What's the expected rendering?

Comment 72

15 years ago
<frameset frameborder="1">
  <frame frameborder="0">
  <frame frameborder="0">

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

Comment 73

15 years ago
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.

Comment 74

15 years ago
<frameset frameborder="1">
  <frame frameborder="0">
  <frame frameborder="0">

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

Comment 75

15 years ago
*** 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

  <frame frameborder="0">
    <frame frameborder="0">
    <frame frameborder="0">

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...

Comment 77

15 years ago
frameborder="0" in the frameset tag removes the borders, this is however not
correct according to w3c HTML spec

Comment 78

15 years ago
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>

Comment 79

15 years ago
In Mozilla 1.2 this bug must be fixed!


15 years ago
Keywords: mozilla1.0, mozilla1.1

Comment 80

15 years ago
> 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. :)

Comment 81

15 years ago
Stefan Huszics:

OK - it was my fault :-(
I wanted to say:

This Bug was fixed in 1.2 !

Sorry :)
No it was not.

Comment 83

15 years ago
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.

Comment 85

14 years ago
*** Bug 198545 has been marked as a duplicate of this bug. ***

Comment 86

14 years ago
Adding XHTML keyword since XHTML 1.0 framesets do not work properly either.
Keywords: xhtml

Comment 87

14 years ago
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  ;)   ).


14 years ago
Flags: blocking1.4b?

Comment 88

14 years ago
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.


14 years ago
Flags: blocking1.4b? → blocking1.4b-


14 years ago
Summary: frameborder="0" doesn't remove borders on frames → frameborder="0" on <frame> leaves white strip instead of removing border

Comment 89

14 years ago
Seems to be affecting all images in XHTML rendering.  Puts a 6-8 pixel border on
the top and bottom of image

Comment 90

14 years ago
Comment #88 was resolved by upgrade to 1.5.

Comment 91

14 years ago
Is this a particully hard bug to fix?

Comment 92

13 years ago
*** 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 ?

Comment 94

13 years ago
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
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.

Comment 96

13 years ago
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. 

Comment 98

13 years ago
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

Comment 99

13 years ago
> 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 :-)

Comment 100

13 years ago
A. Sorry about the basefont thing; I'm not a programmer just a complainer, er, 
bug reporter.
2. What spam?

Comment 101

13 years ago
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

Comment 102

13 years ago
> 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.

Comment 103

13 years ago
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).

Comment 104

13 years ago
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. ***

Comment 106

12 years ago
*** Bug 289397 has been marked as a duplicate of this bug. ***

Comment 107

11 years ago
Could this not be solved by simply following the suggestion in CSS 2.1?

�*) 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:


Comment 108

10 years ago
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.

Comment 109

10 years ago
Created attachment 269123 [details]
Picture of how it could be done (left: HTML, right: XHTML)

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.)
Duplicate of this bug: 414300
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...

Comment 112

9 years ago
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.

Comment 114

2 years ago
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?

Comment 115

2 years ago
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.

Comment 116

a year ago
Gecko displays the testcases identically to WebKit & Blink, and "web standards" is no longer a significant concern for frameborder.

Everyone have a happy 2016.
Last Resolved: 15 years agoa year ago
Resolution: --- → INVALID

Comment 117

a year ago
(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.

Comment 118

a year ago
(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.

Comment 119

a year ago
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.

Comment 120

a year ago
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.

Comment 121

a year ago
I checked. The frameset element is not deprecated. It appears in the HTML5 specification.


Comment 122

a year ago
(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.

Comment 123

a year ago
(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.
You need to log in before you can comment on or make changes to this bug.