Thank you very much for the update...
1. Initial SRC attribute value for IFRAME
The current URL for SRC defines current cross-domain security policy
for the given pages. Because of that it is not allowed to skip this
attribute even if IFRAME will be used only for dynamically generated
content. A failure to do so will lead to IFRAME run-time scripting
access block. It was true at least for NN4.x/IE4.x/IE5.x
AFAICT at least IE 6.x and Firefox 2.x do allow to skip SRC attribute:
in such case it is being automatically set to the virtual about:blank
page. Anyone is free to use this added convenience but I humbly stay
on the old path. First of all I don't like to torture an engine
without an explicit necessity - even if it is allowed by engine
makers. Secondly a number of spyware and hijacking exploits are using
about: internal URI scheme and the common habit to set about:blank as
the browser's home and/or startup page; therefore many anti-spyware
and anti-hijacking tools are implementing special treatment for
windows and (i)frames with about:blank address up to blocking such
content completely or by blocking scripted access to them. In summary
anyone is free to relay on SRC being set automatically and working
properly: but this option is not considered and not advised by myself.
This way for iframes used as containers for dynamic content - and not
to display physical documents - still initial SRC attribute is always
being set and pointing to a physical document located in the same
domain and subdomain as the mother page to compile with the cross-
domain security requirements.
Such document should be some minimalistic blank HTML document. The
exact suggested content could be:
<html><head><title></title></head><body bgcolor="#FFFFFF"><p> </
p></body></html>
See:
http://www.russiancourses.org/tmp/blank.html
It is based two practical considerations:
1) A document with no content at all in its body section confuses
Firefox if switched to designMode: the initial cursor position will be
set to the upper-right corner as if dir would be right-to-left, but it
gets corrected with the first typed symbol. Obviously it looks very
confusing for end-users. Therefore we are using a paragraph with non-
breaking space in it to fix this behavior.
2) By default IFRAME in Firefox is transparent and in IE is opaque.
That means that the content behind IFRAME will be visible in Firefox.
It may be what you want but most of the time it is not. This is why we
are explicitly setting bgcolor for body.
A note for purists if they are wondering why do not use CSS background-
color instead and stay Strict? First of all it is textually longer and
we want to be as short as possible; and the last but not the least:
hey, we are prepearing to work with IFRAMEs so what Strict are you
talking about? IFRAMEs are not a part of Strict DTD.
2. IFRAME as an editable container
In all samples blank.html assumed to have the exact content as
suggested in the section 1.
All methods are tested on Windows XP SP2 with
Internet Explorer 6.0
Internet Explorer 7.0
Mozilla Firefox 2.0.0.13
Opera 9.26
Safari 3.0.4
A note for purists: DTDs from W3C are missing ONLOAD attribute for
IFRAME in all HTML DTDs. It is a simple typo to disregard: any browser
ever implemented IFRAME also supports documented on MSDN onload event
handler. At the same time W3C Validator will obviously complain.
Either disregard it or use document.write in SCRIPT block to insert
your iframes. Here I am using the first decision.
Option 1 : We just need an empty IFRAME with editing mode being turned
on by default.
<iframe
name="doc01"
src="blank.html"
onload="
(function(){
var name = 'doc01';
try {
var doc = self.frames[name].document;}
catch (SecurityException) {
/*NOP*/}
if ((doc) && ('designMode' in doc)) {
doc.designMode = 'on';
}
})();"></iframe>
Add as reasonably many IFRAMEs as you need: just don't forget to
change "name" and var b\name in each block.
See:
http://www.russiancourses.org/tmp/Option1.html
Option 2 : We need to load a document into IFRAME with editing mode
being turned on by default.
Same as Option 1, just use the right src value. Same domain security
rule applies of course, so you can do it only with documents from the
same domain and the same subdomain.
See:
http://www.russiancourses.org/tmp/Option2.html
Option 3. We need to load a document into IFRAME with editing mode
being turned on by default. SRC attribute cannot be hardcoded and it
will set on page load. In the sample it is assumed that some of
preliminary loaded scripts has function getUrlForIframe that takes
string argument with the name of iframe and returns src value for that
iframe.
Unfortunately I couldn't find a solution for this option. The sample
code seemingly works for a single iframe, but after that no other
script block is being executed. The function is being executed without
runtime errors as window.alert shows, but any other script is simply
disregarded. The most weird behavior - or maybe I am missing something
obvious. Any feedback is highly appreciated.
See:
http://www.russiancourses.org/tmp/Option3.html
Option 4. We need an IFRAME with editing mode being turned on by
default and pre-filled wth some content generated by script.
In the sample it is assumed that some of preliminary loaded scripts
has function getContentForIframe that takes string argument with the
name of iframe and returns HTML code to write into iframe. The only
cross-browser reliable solution I know is to split the task between
IFRAME and SCRIPT blocks. Anything else leads to unhandled race
condition and to "too many recursions" runtime error.
<iframe
name="doc01"
src="blank.html"></iframe
><script>
var name = 'doc01';
var doc = self.frames[name].document;
if (doc) {
doc.open('text/html','replace');
doc.write(getContentForIframe(name));
doc.close();
if ('designMode' in doc) {
doc.designMode = 'on';
}}
</script>
See:
http://www.russiancourses.org/tmp/Option4.html- Hide quoted text -
- Show quoted text -
to use "this" or "getElementById"