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