Why we should avoid iframe?

[howa]

Since it is part fo the standard, why I always heard that we should
avoid iframe?

any comments?

thanks.

[=?iso-8859-1?Q?Kim_Andr=E9_Aker=F8?=]

Re: Why we should avoid iframe?

howa wrote:

Since it is part fo the standard, why I always heard that we should
avoid iframe?
>
any comments?
>
thanks.

Depends which standard you're referring to. The <iframeelemen t only
exists in HTML 4.01 Loose, and in XHTML 1.0 Transitional and Frameset.

The part about avoiding <iframereally applies to all uses of frames.
There are, for the most part, better ways to include shared content
than using frames (including <iframe>).

--
Kim André Akerø
- kimandre@NOSPAM betadome.com
(remove NOSPAM to contact me directly)

[Darin McGrew]

Re: Why we should avoid iframe?

howa wrote:

>Since it is part fo the standard, why I always heard that we should
>avoid iframe?

Kim André Akerø <kimandre@NOSPA Mbetadome.comwr ote:

The part about avoiding <iframereally applies to all uses of frames.
There are, for the most part, better ways to include shared content
than using frames (including <iframe>).

Exactly. None of the problems with frames listed in the FAQ* have anything
to do with browser support or whether frames are part of any given
specification, and all are equally applicable to inline frames.

And some of us find that disabling inline frames (at least for unknown,
untrusted sites) is an effective way to reduce annoying ads and other
stupid web tricks.

* http://www.htmlhelp.com/faq/html/fra...frame-problems
--
Darin McGrew, mcgrew@stanford alumni.org, http://www.rahul.net/mcgrew/
Web Design Group, darin@htmlhelp. com, http://www.HTMLHelp.com/

"Do not look where you fell, but where you slipped." - African Proverb

[Andy Dingley]

Re: Why we should avoid iframe?

On 24 May, 08:08, howa <howac...@gmail .comwrote:

Since it is part fo the standard, why I always heard that we should
avoid iframe?

Why do you need an <iframe? Is there a better way of doing it ?
I'd generally avoid it in favour of something better, but I wouldn't
rule it out altogether.


As a minor issue, <iframeisn't in all of the doctypes. This is no
reason to not use <iframe>, but if you're going to use it anyway, at
least choose a doctype for which it's valid.


There are several potential reasons that you might use <iframe>, some
better than others.

* To wrap some changing content up in a constant menu structure
(typical frame usage)

* To statically include boilerplate text

* For AJAX-like purposes involving HTML data sources rather than XML
(e.g. screen-scraping from HTML pages)


The first of these is perhaps the most commonplace. It has the great
advantage (like all frames techniques) of simplicity, and the
disadvantage of many small drawbacks. Overall, it's best avoided. In
practice, it's worth knowing about and still worth using if you don't
have the time / needs / skills to build something better.

It's particularly useful if you have a client-side "report viewing"
page with a single embedded report that's chosen from a list on the
container page (just as an example). Trivial HTML coding gives you a
selectable list or reports that appear in-line on the same page. It's
particularly useful if it's a set of _files_ that you're viewing here,
rather than documents from a web server (so you don't have the option
to use server-side coding). I have dozens of these myself, reporting
on the current status of our many products. Python scripts and XSLT
generate the report pages and the index page, then they're linked by
an <iframe>. Moving this to a web server would be a problem (for other
reasons), so it suits me to just keep them on the filesystem. If
they're only there as static files, I'm restricted in the techniques I
can use, but <iframestill works.


The second is really a "poor man's SSI". Avoid this. Avoid this
strongly, in favour of real SSI. Any competent hosting offers SSI, so
use it (or move to hosting that does allow it).

My current project uses a vast numbe of legacy <iframe>s, as a poor
substitute for JSP tag libraries. This separates "technical web
coders" from "applicatio n coders" who each work on separate files.
It's arguably better than having everyone dive into one large and
uncontrollable shared file, but the real solution would be a neat use
of tag libraries, not this client-side aggregation of page sections.


The third is interesting. AJAX is widely popular now, but the "X" in
AJAX stands for XML not HTML and so it's impossible to use this
technique with a non-XML HTML page, or a non well-formed XHTML page.
XmlHttpRequest et al only work for parsing XML documents. The work-
around is to use an <iframeand to dynamically load new content into
it with client-side JavaScript. The <iframe(and the browser) act as
your HTML parser. The <iframecan of course be hidden from display,
just used from program code.


<iframealso has efficiency issues, as it represents two HHTTP
requests to assemble a page that can probably be supplied through just
one (if assembled server-side first). That's a very minor point though
- any typical page will have a great many separate requests
regardless, <iframe>s are one of the last places to start counting and
optimising these away.

[Scott Bryce]

Re: Why we should avoid iframe?

Andy Dingley wrote:

AJAX is widely popular now, but the "X" in
AJAX stands for XML not HTML and so it's impossible to use this
technique with a non-XML HTML page, or a non well-formed XHTML page.

I wrote an AJAX chat that uses no XML or XHTML. The data passed to the
web page does not have to be XML. It can be anything that Javascript can
parse into valid HTML (or XHTML, depending on your DocType).

[howa]

Re: Why we should avoid iframe?

On 5 25 , 4 59 , Andy Dingley <ding...@codesm iths.comwrote:

On 24 May, 08:08, howa <howac...@gmail .comwrote:
>

Since it is part fo the standard, why I always heard that we should
avoid iframe?

>
Why do you need an <iframe? Is there a better way of doing it ?
I'd generally avoid it in favour of something better, but I wouldn't
rule it out altogether.
>

there are two strong reasons:

1. solve the cross-domain problem
2. make the original page cachabale

[Andy Dingley]

Re: Why we should avoid iframe?

On 25 May, 15:38, Scott Bryce <sbr...@scottbr yce.comwrote:

I wrote an AJAX chat that uses no XML or XHTML.

So is that AJAX, or "AJAX-like asynchronous JavaScript using an
alternative parser"? Purely a terminology point.

The data passed to the web page does not have to be XML.

It does if you're going to use XMLHttpRequest with it. If you don't,
then you can use anything you can build a parser for. For HTML, that
may well be an <iframe>.