Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: IFRAME Trouble with firefox

  1. #1
    Join Date
    Mar 2005
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default IFRAME Trouble with firefox

    Ok, I'm now bald because I've pulled out all my hair and can't figure out my problem!!! Any help you can anyone can offer would be great. The page I'm speaking about can be found at:

    www.heromythmusic.com

    The issue is, in IE, the page displays as it should, with an IFRAME inside a graphic layout. All is well, page loads from the IFRAME as it should. However, in Mozilla FireFox, the IFRAME loads nothing, and there is just a black area (the background color) where the IFRAME should be displaying the "news.php" page.

    What's worse, if you check out:

    THIS LINK

    The IFRAME works fine in FireFox. OH, by the way, ITS THE EXACT SAME CODE!!!!! It works in one page, and not in the other!!!! I really can't figure out whats going on here. Could anyone help me out with this extremely wierd problem! Thanks in advance.

    Greg

  2. #2
    Join Date
    Dec 2004
    Location
    UK
    Posts
    2,358
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by gregerly
    I have a few questions. I think they're worth considering seriously.

    • Why are you serving well-formed XHTML as HTML?
    • Why are you using a modern mark-up language to produce something that could have been written with HTML 3.2?
    • Do you have a particular reason for providing no alternative content for any of your images, even those that have have obvious alternatives?
    • You are aware that not everyone browses with a 1008x702 pixel viewport, aren't you? Users hate having to scroll horizontally.
    The issue is, in IE, the page displays as it should [...]
    When IE displays things "properly" but other user agents don't, it's a fair bet that IE is wrong. Though neither IE nor Firefox is wrong in this case, this is something worth considering in the future.

    However, in Mozilla FireFox, the IFRAME loads nothing, and there is just a black area (the background color) where the IFRAME should be displaying the "news.php" page.
    Firefox loads the content perfectly fine, and displays it quite reasonably.

    THIS LINK

    [...] OH, by the way, ITS THE EXACT SAME CODE!!!!!
    No, it isn't. The style sheet for the first document specifies a black background colour and a black foreground colour (I don't think I need to mention that that's an incredibly stupid thing to do, do I?). The second document uses the default style sheet which, in most user agents in their default configuration, will use black text on a white background.

    In both cases, the background colour for the iframe is the default - transparent - hence your disappearing text.

    Mike

  3. #3
    Join Date
    Mar 2005
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    wow do I feel stupid. I'm still not sure I understand what exactly is happening though. The page that I'm loading into the IFRAME is white with black text. Why is the page turning black? I agree with everything you said in your post though. I know fixed width designs bite, but this is the clients vision, not mine. I really appreciate you taking the time to look this over and figure out what was going wrong. I just assumed that the page wasn't loaded. Could you clarify for me what you meant by "serving proper XHTML as HTML"? Anyways, thank again for the help.

    Greg

  4. #4
    Join Date
    Dec 2004
    Location
    UK
    Posts
    2,358
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by gregerly
    wow do I feel stupid.
    It's a relatively simple mistake to make, but easily avoidable. For a start, do not rely on defaults. If you want a particular colour combination, specify it, even if it seems like the user agent uses it already. Whilst that might be true with a user agent in it's default configuration, some people fiddle with their settings.

    Consider for instance that rather than staring at white backgrounds, a user sets their colour scheme to have an off-white background to reduce strain on their eyes. If you rely on a default white, your page could look pretty stupid. Worse still, what if you choose a foreground colour - again, based on a white background - that is similar to a user's default background colour? Instead of just looking wrong, the text will be completely unreadable.

    This also leads to another rule: if you specify one colour (background or foreground), you must specify the other. Similarly, if you use background images, you must specify a suitable colour replacement in case the image isn't shown.

    I'm still not sure I understand what exactly is happening though. The page that I'm loading into the IFRAME is white with black text.
    You're missing the point: it's isn't white on black, it's some default combination. Firefox doesn't actually specify a default background colour for any element. It uses the suggested default, transparent. The default white you see is the colour of the containing window which documents are rendered into. The only default colour specified is the foreground colour, which is black.

    What you do is state that the containing page has a black background, and you leave everything else to the default transparent. That's usually fine as everything else will be stacked on top, allowing the black to show through. However, the background colour of your iframe and it's content is also transparent, so these too also allow the black background of the containing page to show through. If you want the iframe page to be white on black, specify that explicitly with a CSS rule:

    Code:
    body {
      background-color: white;
      color: black;
    }
    Could you clarify for me what you meant by "serving proper XHTML as HTML"? Anyways, thank again for the help.
    The mark-up you've produced is obviously XHTML. However, user agents don't look at the file contents to determine what's been sent[1] - they look at what the server tells them it sent via the Content-Type header. Currently, that's text/html on your server. A meta element (useless to user agents, by the way) also says the same thing.

    When a user agent is told that it's getting HTML, it will take the server's word for it and treat the content as HTML. In other words, every user agent on the planet[2] will look at your neat XHTML and say, "What the feck is this? This is some badly written HTML!" At which point, it will proceed to slurp it up as if it were tag soup. Well done! Now what was the point of all that effort?

    At the present moment, serving XHTML as XHTML (sending a application/xhtml+xml MIME type) isn't feasible. Internet Explorer has no idea what XHTML is and will just ask users if they want to download the file. Older user agents will do the same thing. Unless you're using content negotiation - sending XHTML to those that say they can handle it, and HTML to everything else - XHTML really is just a waste of your time. HTML will be around for a very long time yet, and there's no reason why you can't produce well-formed HTML[3].

    If Microsoft end up supporting XHTML soon, then it might be worth worrying about migration. Even then, you'd still need content negotiation for those left using earlier IE versions, and other XHTML-ignorant user agents. But for the moment, just stick to HTML.

    Mike


    [1] Actually, IE does now and then, but IE is broken. In fact, this behaviour has led to some of its nasty vulnerabilities. The HTTP specification says to use the Content-Type header for a reason, but no. Microsoft always knows best...

    [2] Well, within reason. Some user agents may not error-correct documents, but such agents are pretty much useless on the Web now due to the sheer volume of badly written crap.

    [3] Nonsense about "XHTML is stricter" is just that. HTML is, and always was, a mark-up language with strict rules. It's just that the popularisation of the Web led to people authoring documents when they had no idea what they were doing. That in turn led to these clueless people teaching other clueless people how to do clueless things. Browser vendors had little choice but to produce software that could adapt to the result.

  5. #5
    Join Date
    Mar 2005
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    mwinter

    This is a really eye opening post for me. I really want to let you know how much I appreciate you time to explain this to me. I use Dreamweaver, mostly in the coding enviornment PHP, mysql, that kind of stuff, so the layout stuff I'm still learning. I can specify when I begin a new document wether or not to make the document XHTML (and I've heard from alot of people that XHTML is the way to go). So most of the handing coding I do I try to make XHTML compliant. Again, I thank you for your time.

    Greg

  6. #6
    Join Date
    Dec 2004
    Location
    UK
    Posts
    2,358
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by gregerly
    I've heard from alot of people that XHTML is the way to go
    When any new technology comes out (and to be honest, XHTML isn't that new - five years old, now) lots of people scramble to try and use it without considering what they're doing. It's a case of, "Ooh! Brand new. It must be good!"

    Don't get me wrong, I'm all for the principle of XHTML. It enforces well-formedness (though not validity - two different things) which a surprisingly large number of site fail to achieve, despite being incredibly simple. It also aims for semantic mark-up (that means no tables-for-layout), which is quicker and easier to parse. Unfortunately, the former benefit is only useful if all XHTML user agents do what the specification states: refuse to parse malformed mark-up. If something as forgiving, and widely-used, as IE enters the XHTML market, XHTML will be just like HTML only failures will be more catastrophic for those using conforming user agents.

    So most of the handing coding I do I try to make XHTML compliant.
    You can continue to do the same thing with HTML. I think the only thing you'd need to drop is the slash on empty elements. That is,

    Code:
    <input ...>
    not
    Code:
    <input ... />
    The other fairly clear change is the removal of the XML declaration (<?xml ... ?>), and using a HTML DOCTYPE declaration rather than a XHTML one.

    Mike

  7. #7
    Join Date
    Feb 2008
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Same problem different noob

    Hi Mike,

    I have the same problem as Greg had, I am using an iframe on a page of a new website i am building for a friend which is supposed to display the page news.html with a white background and black text as the news.html page is set too, as with gregs problem IE displays the page as i want it to look but FF displays the iframe with a black background and black text (you can see it if highlighted) so i took your advice about setting the foreground color of the page to white i the css so that the iframe would not display transparent however the problem hasnt change? this is the css code for the body of all my pages:

    /* Body */
    body {background-color: black;
    color: white;}

    Here is the code for the iframe in the page:

    <iframe
    src="news.html" height="380" width="600">
    </iframe>

    and finaly here is the news.html body code:

    <body background color="white">

    sorry i cant give you a link to the page as it is only hosted on my uni's server and due to copyright issues no content on the server can be viewed externally.

    Could you give me a little help so i can sort this out please.

    Thanks in advance,

    Joe.

  8. #8
    Join Date
    Mar 2005
    Location
    SE PA USA
    Posts
    29,070
    Thanks
    44
    Thanked 3,216 Times in 3,178 Posts
    Blog Entries
    12

    Default

    Mike's not around any longer.

    Code:
    <body background color="white">
    Is meaningless to most browsers. Those that would do anything with it would set the text color to white. This would be better:

    Code:
    <body style="background-color:white;">
    and should accomplish your aim. If you need more help:

    Please post a link to the page on your site that contains the problematic code so we can check it out.
    - John
    ________________________

    Show Additional Thanks: International Rescue Committee - Donate or: The Ocean Conservancy - Donate or: PayPal - Donate

  9. #9
    Join Date
    Jan 2011
    Posts
    2
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Talking My Solution on reload Iframe

    <iframe name="myframe" width="100%" frameborder="no" height="1400px" scrolling="no" src="yourpage.html" >
    </iframe>

    Code above won't work if we click on firefox reload button.

    Try to use this code on <body>. but first, delete the src="yourpage.html" code on your iframe.

    <body onload="parent.myframe.location='yourpage.html'>

    It's work even we navigate to another iframe link then press the reload button on firefox.

    The problem is..., that unload body code will conflict with another javascript such as "tool tip", but it's okay if u not use that such javascript on your site (tool tip). kwokwowkowk

    But if u must put that code..., this is my solution :

    I use javascript tool tip code on my site that contain window.onload = initTip; on <head></head>, but conflict with <body onload="parent.myframe.location='yourpage.html'">.

    1. delete window.onload = initTip; on <head> segment.
    2. add initTip; together with parent.myframe.location='yourpage.html'.
    3. don't forget to put () behind initTip.

    <body onload = "initTip(); parent.myframe.location='yourpage.html'">

  10. #10
    Join Date
    Mar 2011
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Hi guys,
    I came across this forum because I have similar trouble with a iframe that I have added to my website saltoweb.biz. I found this frame on facebook and thought it would be a nice add on to the site. So I copied the code and placed it on my site just like advised.
    The content displays great on ie and for some weird reason it also showed in firefox. Today I wrote another post on the facebook page facebook.com/saltointernational, which is supposed to feed the content of the frame.
    The update is shown in ie but now in firefox I only see a white box!??

    Anybody how can help me to solve this mystery?

    I have to say that I am not a programmer, only hacking around a little more in "trial and error mode" - so please explain it to me like for dummies

    Thanks a lot
    Last edited by jscheuer1; 03-19-2011 at 12:04 PM. Reason: remove hotlinks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •