3655 - (frameborder) frameborder="0" on <frame> leaves white strip instead of removing border

Status: RESOLVED INVALID

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

Description

[glynn]

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.

Comment 1

[karnaze (gone)]

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

Comment 2

[glynn]

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?

Comment 3

[sujay]

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

Comment 4

[karnaze (gone)]

Moving to M7

Comment 5

[karnaze (gone)]

Moving to M9.

Comment 6

[karnaze (gone)]

Reassigning frameset/iframe bugs to Eric.

Comment 7

[Eric Pollmann]

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.

Comment 8

[Eric Pollmann]

Attachment: Frame contents.

Comment 9

[Eric Pollmann]

Attachment: Test case

Comment 10

[Eric Pollmann]

Moving non-critical bugs out.

Comment 11

[Eric Pollmann]

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.

Comment 12

[ekrock's old account (dead)]

Cosmetic and not fatal. Moving to M17.

Comment 13

[Eric Pollmann]

*** Bug 22631 has been marked as a duplicate of this bug. ***

Comment 14

[ekrock's old account (dead)]

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Comment 15

[Eric Pollmann]

Rescheduling

Comment 16

[Chris Petersen]

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.

Comment 17

[leger]

Putting on [nsbeta2-] radar. Not critical to beta2.  Setting on nsbeta3 radar.

Comment 18

[Kevin Puetz]

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

[Eric Pollmann]

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.

Comment 20

[Kevin McCluskey (gone)]

Marking nsbeta3-

Comment 21

[Mats Palmgren (inactive)]

*** Bug 47727 has been marked as a duplicate of this bug. ***

Comment 22

[Jerry Baker]

Adding HTML4 keyword.

Comment 23

[Jerry Baker]

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

Comment 24

[Kevin McCluskey (gone)]

Marking rtm-.

Comment 25

[ekrock's old account (dead)]

Nominating for nsbeta1 as a standards-compliance bug we'd like to get right if
possible for that release.

Comment 26

[Stephan Niemz]

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

Comment 27

[Ken Snider]

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

[E.T.]

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

Comment 29

[Kevin McCluskey (gone)]

Bulk reassignin HTML FRAME/IFRAME bugs to Eric.

Comment 30

[Wolf-Dietrich Moeller]

*** Bug 121083 has been marked as a duplicate of this bug. ***

Comment 31

[Kevin McCluskey (gone)]

Bulk re-assigning all of Eric's HTMLFrame bugs to John.

Comment 32

[Hugo Kortschak]

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

[rubydoo123]

removing myself from the cc list

Comment 34

[Ng Sheaufeng]

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.

Comment 35

[Boris Zbarsky [:bzbarsky]]

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

Comment 36

[Ng Sheaufeng]

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

Comment 37

[John Keiser (jkeiser)]

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.

Comment 38

[Stefan Huszics]

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

Comment 39

[Boris Zbarsky [:bzbarsky]]

> 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

[Stefan Huszics]

> 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 =)

Comment 41

[Kevin McCluskey (gone)]

nsbeta1-. Engineers are overloaded with higher priority bugs.

Comment 42

[Jerry Baker]

Mass removing self from CC list.

Comment 43

[Jerry Baker]

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

Comment 44

[Zac Jacobson]

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

[Daniel Bratell]

That is bug 147883.

Comment 46

[ratman]

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

[Stefan Huszics]

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

Comment 48

[ratman]

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

[Stefan Huszics]

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

Comment 50

[Boris 'pi' Piwinger]

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

pi

Comment 51

[Ken Snider]

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

Comment 52

[Mike Dailey]

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?

Comment 53

[Boris Zbarsky [:bzbarsky]]

Yes.  see bug 147883

Comment 54

[Christopher M. Casey]

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?

Comment 55

[Boris Zbarsky [:bzbarsky]]

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.

Comment 56

[Hixie (not reading bugmail)]

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

Comment 57

[Boris Zbarsky [:bzbarsky]]

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

[ratman]

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.

Comment 59

[Boris Zbarsky [:bzbarsky]]

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

Comment 60

[Ken Snider]

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?

Comment 61

[Boris Zbarsky [:bzbarsky]]

"border=0" goes on the frameset, not the individual frames...  It does nothing I
can discern when placed on frames.

Comment 62

[Hixie (not reading bugmail)]

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

Comment 63

[Christopher M. Casey]

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?

Comment 64

[Boris Zbarsky [:bzbarsky]]

Don't use 1.1.  Use a recent build.  The border code was touched somewhat since
1.1 (like a lot).

Comment 65

[Christopher M. Casey]

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

[Boris 'pi' Piwinger]

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

Comment 67

[Hixie (not reading bugmail)]

Strictly valid HTML wouldn't use frames at all.

Comment 68

[Boris 'pi' Piwinger]

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

Comment 69

[Hixie (not reading bugmail)]

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

Comment 70

[Boris Zbarsky [:bzbarsky]]

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?

Comment 71

[Boris Zbarsky [:bzbarsky]]

<frameset frameborder="1">
  <frame frameborder="0">
  <frame frameborder="0">
</frameset>

What's the expected rendering?

Comment 72

[Christopher M. Casey]

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

Comment 73

[Christopher M. Casey]

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

[Stefan Huszics]

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

Comment 75

[Jo Hermans]

*** Bug 168474 has been marked as a duplicate of this bug. ***

Comment 76

[Boris Zbarsky [:bzbarsky]]

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

Comment 77

[mike]

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

Comment 78

[volatile]

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

[Frank Jiranek]

In Mozilla 1.2 this bug must be fixed!

Comment 80

[Stefan Huszics]

> 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

[Frank Jiranek]

Stefan Huszics:

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

This Bug was fixed in 1.2 !

Sorry :)

Comment 82

[Boris Zbarsky [:bzbarsky]]

No it was not.

Comment 83

[Daniel Clemente]

Linux 2003020805; the bug isn't fixed yet

Comment 84

[John Keiser (jkeiser)]

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

[Bill Mason]

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

Comment 86

[Jerry Baker]

Adding XHTML keyword since XHTML 1.0 framesets do not work properly either.

Comment 87

[Steve VanSlyck]

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

Comment 88

[Steve VanSlyck]

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.

Comment 89

[David Rettig]

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

Comment 90

[Steve VanSlyck]

Comment #88 was resolved by upgrade to 1.5.

Comment 91

[Alex Hosking]

Is this a particully hard bug to fix?

Comment 92

[Aaron Kaluszka]

*** Bug 247655 has been marked as a duplicate of this bug. ***

Comment 93

[Christian 'CeeJay' Jensen]

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

[Anne (:annevk)]

I suggest WONTFIX. Frames are not used that many anymore and it seems not a lot
of people have problem with Mozilla's behavior.

Comment 95

[Vidar Haarr (not reading bugmail)]

(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

[Anne (:annevk)]

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.

Comment 97

[[e-mail]]

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

[Steve VanSlyck]

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.

Comment 99

[Jacek Piskozub]

> 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

[Steve VanSlyck]

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

Comment 101

[Anne (:annevk)]

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.

Comment 102

[Jerry Baker]

> 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

[Stefan Huszics]

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

[Aaron Kaluszka]

Restoring pertinent info.

Comment 105

[Frank Wein [:mcsmurf]]

*** Bug 268880 has been marked as a duplicate of this bug. ***

Comment 106

[Anne (:annevk)]

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

Comment 107

[Patrick Dark]

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

Comment 108

[Gábor Stefanik]

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

[Gábor Stefanik]

Attachment: 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.)

Comment 111

[Michał Gołębiowski-Owczarek [:mgol]]

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

[Gábor Stefanik]

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.

Comment 113

[Michał Gołębiowski-Owczarek [:mgol]]

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

[Frankie]

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

[Frankie]

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

[Frankie]

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

Everyone have a happy 2016.

Comment 117

[Jerry Baker]

(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

[Patrick Dark]

(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

[Jacek Piskozub]

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

[Jerry Baker]

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

[Jerry Baker]

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

Comment 122

[Patrick Dark]

(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

[David Bruant]

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

Comment 124

[Karl Dubost💡 :karlcow]

Attachment: Capture d’écran 2021-11-18 à 13.52.51.png

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>

Comment 125

[Karl Dubost💡 :karlcow]

Attachment: edge Blink Canary / Firefox Nightly Gecko / Safari Tech Preview WebKit

better tests

Comment 126

[Karl Dubost💡 :karlcow]

• Safari Webkit: https://bugs.webkit.org/show_bug.cgi?id=21697
• Firefox Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=3655
• Chrome Blink: https://bugs.chromium.org/p/chromium/issues/detail?id=1063767