iframe confusion
Nick Theodorakis
http://www.geocities.com/stjohnsroch/schedule.html
(toward the bottom).
and as a guide, I've been looking at Jukka's and the WDG site for help:
http://www.malibutelecom.com/yucca/html/iframe.html
http://www.htmlhelp.com/reference/html40/special/iframe.html
Anyhoo, I've got a line of "alternate content" within the
<iframe></iframe>that directs non-iframers to the same content.
On WinIE5, I get the iframe ok. On NS4.x, I get the alternate content. But
when I checked it on MacIE5, I got both the ifame _and_ the alternate
content dispalyed below it.
By trial and error, I found that was because the alternate content and the
iframe were both surrounded by <p></p>, eg:
<p><iframe src="foobar"...><p>yada yada...</p></iframe></p>
(note: that validates fine)
Apparently (I think) MacIE5 sees the next <p>, and closes the first one,
thus breaking the alternate content out of the iframe.
It looks like I can fix it by changing the "outer" <p></p> tag to <div></div>.
The reason I put those around the <iframe> is because I read that it is an
inline element and that it would be helpful for positioning to surround it
with a block level element. The alternate content was also surrounded by
a block-level tag for styling in non-iframe browsers.
So now I'm confused: If <iframe> is inline, why can it contain block-level
elements for the alternate content?
And if <iframe> capable browsers are supposed to ignore the alternate
content, why did MacIE5 behave the way it did? Was it my mistake, its
mistake, or just another valid way to interpret an ambiguous spec?
Nick
--
Nick Theodorakis
nicholas_t...@urmc.rochester.edu
http://www.stjohnsroch.org/
Bodidily
message news:eb077.4465$ar1....@www.newsranger.com...
> I've been experimenting with an iframe, e.g.:
> http://www.geocities.com/stjohnsroch/schedule.html
> (toward the bottom).
>
> and as a guide, I've been looking at Jukka's and the WDG site for help:
>
> http://www.malibutelecom.com/yucca/html/iframe.html
> http://www.htmlhelp.com/reference/html40/special/iframe.html
>
Good good....
> Anyhoo, I've got a line of "alternate content" within the
> <iframe></iframe>that directs non-iframers to the same content.
>
Does <noframe></noframe> work in this situation?
> On WinIE5, I get the iframe ok. On NS4.x, I get the alternate content. But
> when I checked it on MacIE5, I got both the ifame _and_ the alternate
> content dispalyed below it.
>
> By trial and error, I found that was because the alternate content and the
> iframe were both surrounded by <p></p>, eg:
> <p><iframe src="foobar"...><p>yada yada...</p></iframe></p>
>
> (note: that validates fine)
>
> Apparently (I think) MacIE5 sees the next <p>, and closes the first one,
> thus breaking the alternate content out of the iframe.
>
> It looks like I can fix it by changing the "outer" <p></p> tag to
<div></div>.
> The reason I put those around the <iframe> is because I read that it is an
> inline element and that it would be helpful for positioning to surround it
> with a block level element.
This is true.
> The alternate content was also surrounded by
> a block-level tag for styling in non-iframe browsers.
>
> So now I'm confused: If <iframe> is inline, why can it contain block-level
> elements for the alternate content?
An Iframe is a form of frame (hence the cunning name) This means what is
displayed in the I-Frame is essentially a new page, and can contain as many
inline and block level elements as you want.
> And if <iframe> capable browsers are supposed to ignore the alternate
> content, why did MacIE5 behave the way it did? Was it my mistake, its
> mistake, or just another valid way to interpret an ambiguous spec?
>
Because its on a Mac. Try here....
http://www.htmlhelp.com/faq/html/all.html#page-inconsistent
--
Bod
===============================
More Lives than you may have hoped
depend on your personal fitness
Nick Theodorakis
>
>"Nick Theodorakis" <nicholas_t...@urmc.rochester.edu> wrote
[...]
>
>> Anyhoo, I've got a line of "alternate content" within the
>> <iframe></iframe>that directs non-iframers to the same content.
>>
>Does <noframe></noframe> work in this situation?
If you mean something like this:
<p><iframe src="foobar"><noframes><p>yada
yada</p></noframes></iframe>
then that doesn't prevent MacIE5 form breaking the alternate content out
of the iframe.
I fixed it by changing the "outer" <p></p> to <div></div>, cf:
http://www.geocities.com/stjohnsroch/schedule.html
(with <p></p> surrounding the iframe
with
http://www.geocities.com/stjohnsroch/schedule1.html
(<div></div> surrounding the iframe)
[...]
>
>> And if <iframe> capable browsers are supposed to ignore the alternate
>> content, why did MacIE5 behave the way it did? Was it my mistake, its
>> mistake, or just another valid way to interpret an ambiguous spec?
>>
>
>Because its on a Mac. Try here....
>http://www.htmlhelp.com/faq/html/all.html#page-inconsistent
>
OK, but out of these three possibilities (quoted from that page:)
"First, you may have some incorrect HTML. ..."
"Second, you may have valid HTML that different browsers interpret
differently...."
"Other possibilities are a bug in one or the other browser,..."
Which is it? a bug or a different interpretation (the markup validates)?
Thanks for your input.
Bodidily
http://hotwired.lycos.com/webmonkey/reference/browser_chart/index.html
shows differences between browsers and OS's.
Try this for more stuff on browser versions and how to beat them!
http://hotwired.lycos.com/webmonkey/authoring/browsers/
Jukka K. Korpela
> - - on MacIE5, I got both the ifame _and_
> the alternate content dispalyed below it.
>
> By trial and error, I found that was because the alternate content
> and the iframe were both surrounded by <p></p>, eg:
> <p><iframe src="foobar"...><p>yada yada...</p></iframe></p>
An interesting (an annoying) bug. I've added a note on it into my
document on IFRAME, though currently only to the working version at
http://www.cs.tut.fi/~jkorpela/html/iframe.html
> Apparently (I think) MacIE5 sees the next <p>, and closes the first
> one, thus breaking the alternate content out of the iframe.
Sounds very probable, especially since you describe that the bug vanishes
if you substitute div markup for the outer p markup. The browsers
"parser" (tag soup processor) assumably gets into wrong mode, in some
fancy way.
> The reason I put those around the <iframe> is because I
> read that it is an inline element and that it would be helpful for
> positioning to surround it with a block level element.
Yes, and additionally you would need to put any inline element inside
some block element if you wish to comply with Strict rules.
> So now I'm confused: If <iframe> is inline, why can it contain
> block-level elements for the alternate content?
A good question, which I think you mostly answered above. :-) Note that
it often makes sense to put a copy of the entire BODY content of the
iframed document into the IFRAME element, or otherwise have a long and
complicated piece of a document as the alternate content, and naturally
it should thus be possible to use block-level elements there.
So why is IFRAME inline? A good question too. Perhaps partly because it
is very similar to OBJECT which in turn is intended to be, in part, a
generalization of the IMG element, which is inline. Being an inline
element has some benefits, e.g. allowing the author write just such
elements in succession, expecting browsers to display them side by side
if there is enough horizontal space, and one above another otherwise.
> And if <iframe> capable browsers are supposed to ignore the alternate
> content, why did MacIE5 behave the way it did? Was it my mistake, its
> mistake, or just another valid way to interpret an ambiguous spec?
Its mistake, definitely.
Note that the specifications treat IFRAME differently from INS and DEL,
which "may serve as either block-level or inline elements (but not
both)". There's an explicit requirement (in prose, not in the DTD) that
the INS and DEL elements must not contain block-level content when these
elements behave as inline elements (whatever that actually means!):
http://www.w3.org/TR/html401/struct/text.html#edef-del
There's no corresponding rule for IFRAME, so the intent obviously was to
allow block level markup inside IFRAME even when the IFRAME itself
appears inside inline markup.
--
Yucca, http://www.malibutelecom.com/yucca/
alias http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.malibutelecom.com/yucca/www.html
Nick Theodorakis
> Nick Theodorakis <nicholas_t...@urmc.rochester.edu> wrote:
>
> > - - on MacIE5, I got both the ifame _and_
> > the alternate content dispalyed below it.
> >
> > By trial and error, I found that was because the alternate content
> > and the iframe were both surrounded by <p></p>, eg:
> > <p><iframe src="foobar"...><p>yada yada...</p></iframe></p>
>
> An interesting (an annoying) bug. I've added a note on it into my
> document on IFRAME, though currently only to the working version at
> http://www.cs.tut.fi/~jkorpela/html/iframe.html
>
> > Apparently (I think) MacIE5 sees the next <p>, and closes the first
> > one, thus breaking the alternate content out of the iframe.
>
> Sounds very probable, especially since you describe that the bug vanishes
> if you substitute div markup for the outer p markup. The browsers
> "parser" (tag soup processor) assumably gets into wrong mode, in some
> fancy way.
[Excuse the lateness of the reply; I didn't see your post on my
newsreader, but I found it on google.]
To follow up, I tried several combinations of <p></p> and <div></div>
(and a few other block-level elements) as containers for <iframe> and
alternate content to see how MacIE5 treated them. Here are the
results:
(1) When <p></p> is used as the container for <iframe>, the presence
any block-level element that I tried (<p>, <div>, <h1>, even
<blockquote>) around the alternate content caused the alternate to be
displayed below the <iframe> when viewed by MacIE5.
(2)Using <div></div> as the container for <iframe> caused no such
problem in MacIE5; in each case the alternate content was properly
"hidden" by the <iframe>, even when <div></div> was used as the
container for the alternate content.
Accordingly, I would recommend that authors using alternate content in
an <iframe> should use <div></div> instead of <p></p> as the
block-level container for the <iframe> if they don't want the
alternate content to be displayed by MacIE5.
(Is there a place to which I should report this?)
Thanks for the discussion.
Nick