Whta's the Story with document.createElement('iframe') in IE?

V

vunet

It is recommended by some sources I found to create IFrames in IE
using
document.createElement('<iframe src="#">')
instead of document.createElement('iframe').
Why and what browser versions to use it? IE5 or IE6?
Thanks
 
H

Henry

It is recommended by some sources I found to create
IFrames in IE using
document.createElement('<iframe src="#">')
instead of document.createElement('iframe').
Why

The generally quality of browser issue analysis is extremely poor and
may things get suggested as workarounds for issues that have never
been pinned down or understood by the people making those suggestions.
and what browser versions to use it? IE5 or IE6?

There is no reason to use it at all, at the very least (and certainly)
from IE 6.
 
V

vunet

There is no reason to use it at all, at the very least (and certainly)
from IE 6.

It's not what I've seen around. In fact there was a case where I was
submitting form to remote IFRAME. That never worked for IE6 until I
used the syntax above to fix it, because the was no possible
communication with that IFRAME using IE6.
But are you saying that this workaround could be without the fix I
explain? Also, here is another link where iframe is created like so:
document.createElement('<iframe src="#">')

http://developer.apple.com/internet/webcontent/iframe.html

Thanks
 
T

Thomas 'PointedEars' Lahn

vunet said:
[Henry wrote:]
There is no reason to use it at all, at the very least (and certainly)
from IE 6.

It's not what I've seen around. In fact there was a case where I was
submitting form to remote IFRAME. That never worked for IE6 until I
used the syntax above to fix it, because the was no possible
communication with that IFRAME using IE6.
But are you saying that this workaround could be without the fix I
explain?

User agents based on MSHTML 5.0 and later support this method of W3C DOM
Level 1+ as it was specified. There is no workaround necessary at all.
Also, here is another link where iframe is created like so:
document.createElement('<iframe src="#">')

http://developer.apple.com/internet/webcontent/iframe.html

So we should eat sh*t because a million flies -- and especially the big,
noisy ones -- cannot be wrong?

Please trim, but do not remove, GG's default attribution line.


PointedEars
 
V

vunet

vunet said:
[Henry wrote:]
There is no reason to use it at all, at the very least (and certainly)
from IE 6.
It's not what I've seen around. In fact there was a case where I was
submitting form to remote IFRAME. That never worked for IE6 until I
used the syntax above to fix it, because the was no possible
communication with that IFRAME using IE6.
But are you saying that this workaround could be without the fix I
explain?

User agents based on MSHTML 5.0 and later support this method of W3C DOM
Level 1+ as it was specified.  There is no workaround necessary at all.
Also, here is another link where iframe is created like so:
document.createElement('<iframe src="#">')

So we should eat sh*t because a million flies -- and especially the big,
noisy ones -- cannot be wrong?

Please trim, but do not remove, GG's default attribution line.

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

OK, so I understand you do not agree with that workaround but if it
was used and it did fix the problem, then what is your better and
correct (!) suggestion to handle those situations?
 
H

Henry

On Sep 9, 11:26 am, Thomas 'PointedEars' Lahn wrote:
OK, so I understand you do not agree with that workaround
but if it was used and it did fix the problem,

Which problem?
then what is your better and correct (!) suggestion
to handle those situations?

There is no reason for not using the DOM standard element creation
method for IFRAMEs in any (reasonably) DOM standard browser (and IE
6+).

But if you are challenging people to produce better solutions to
problems you need to state what the problem is that is supposed to be
addressed by the solution, else you are just waiting everyone's time.
 
H

Henry

It's not what I've seen around.

So what? If you look you will be able to find someone on the Internet
telling you anything and everything.
In fact there was a case where I was submitting form to
remote IFRAME. That never worked for IE6 until I used
the syntax above to fix it, because the was no possible
communication with that IFRAME using IE6.

What does "no possible communication" mean? You see what I man about
the quality of analysis? Communicating, in the sense of reading object
properties, executing contained scripts and so on, is entirely
possible in IE 6, I do it all the time.
But are you saying that this workaround could be without
the fix I explain?

You did not explain anything, and you have not stated what it is that
is supposed to be worked around.
Also, here is another link where iframe is created like so:
document.createElement('<iframe src="#">')

http://developer.apple.com/internet/webcontent/iframe.html

<quote cite="http://developer.apple.com/internet/webcontent/
iframe.html">
Sadly, referencing the IFRAME's document object is no simple
task, since IE5, IE5.5, IE6, and NS6 all provide different
ways to access it. ...
</quote>

IE 5, 6 and 7, all Netscape 6+/Mozilla/Firefox/Gecko, Opera, Safari,
and quite a list of other browsers all provide a single consistent and
reliable method of accessing the documents contained in IFRAMEs. If
the author of that page is not aware of that fact then it is not
surprising that he/she has wondered off into a world of stupid
workarounds and UA branching code to try and mitigate for their
evident ignorance. It happens all the time, but that does not make
following a good idea.
 
V

vunet

So what? If you look you will be able to find someone on the Internet
telling you anything and everything.


What does "no possible communication" mean? You see what I man about
the quality of analysis? Communicating, in the sense of reading object
properties, executing contained scripts and so on, is entirely
possible in IE 6, I do it all the time.


You did not explain anything, and you have not stated what it is that
is supposed to be worked around.



<quote cite="http://developer.apple.com/internet/webcontent/
iframe.html">
Sadly, referencing the IFRAME's document object is no simple
task, since IE5, IE5.5, IE6, and NS6 all provide different
ways to access it. ...
</quote>

IE 5, 6 and 7, all Netscape 6+/Mozilla/Firefox/Gecko, Opera, Safari,
and quite a list of other browsers all provide a single consistent and
reliable method of accessing the documents contained in IFRAMEs. If
the author of that page is not aware of that fact then it is not
surprising that he/she has wondered off into a world of stupid
workarounds and UA branching code to try and mitigate for their
evident ignorance. It happens all the time, but that does not make
following a good idea.

With my original question I was hoping to hear what experts think if
they are familiar with what I am asking.
This went the wrong way, so let me state the problem I personally had.
I created a mechanism to upload images keeping the user on one page.
The form would submit image files into dynamically created IFRAME. I
developed this in Firefox but when I started testing IE6 form was not
able to submit to my hidden IFRAME: it did not see it... This form's
target was IFRAME's name.
When I did some research I discovered that if I create IFRAME like
this for IE6 (document.createElement('<iframe src="#">')) then it
would work for me and it did.
That's why I am wondering why it happened and is it something I should
be better off using for IE6 or less?
Thanks
 
T

Thomas 'PointedEars' Lahn

vunet said:
I created a mechanism to upload images keeping the user on one page.
The form would submit image files into dynamically created IFRAME. I
developed this in Firefox but when I started testing IE6 form was not
able to submit to my hidden IFRAME: it did not see it... This form's
target was IFRAME's name.
When I did some research I discovered that if I create IFRAME like
this for IE6 (document.createElement('<iframe src="#">')) then it
would work for me and it did.

Talk is cheap. Show me the code.
-- Linus Torvalds
That's why I am wondering why it happened and is it something I should
be better off using for IE6 or less?

You are asking all the wrong questions.
<http://catb.org/~esr/faqs/smart-questions.html>

Again, please trim your quotes.


PointedEars
 
L

Laurent vilday

vunet :
It is recommended by some sources I found to create IFrames in IE

What sources ?
using document.createElement('<iframe src="#">')
instead of document.createElement('iframe').

Are you sure it is the "src" attribute the problem ? This is not the
issue I am aware of.
<http://msdn.microsoft.com/en-us/library/ms536389.aspx>
<quote>
Attributes can be included with the sTag as long as the entire string
is valid HTML. To include the NAME attribute at run time on objects
created with the createElement method, use the sTag .
</quote>

This code will *not* "work" in IE6 or IE7, but will in IE8b2

<a href="http://www.google.fr" target="myIframe">link</a>
<script type="text/javascript">
var iframe = document.createElement('iframe');
iframe.name = 'myIframe';
document.body.appendChild(iframe);
</script>

This code will "work" in IE6 and IE7, but will *not* in IE8b2

<a href="http://www.google.fr" target="myIframe">link</a>
<script type="text/javascript">
var iframe = document.createElement('<iframe name="myIframe">');
iframe.name = 'myIframe';
document.body.appendChild(iframe);
</script>

As you can see (once tested), the issue IE6 can encounter is related to
the name attribute of the newly created element, I have tested with your
src workaround and I can't find any other issue than the "name" one.

So, are you really sure about the src="#" workaround ?
 
H

Henry

On Sep 9, 5:17 pm, vunet wrote:
With my original question I was hoping to hear what experts
think if they are familiar with what I am asking.

When you get round to asking a question that can be answered you might
get an answer.
This went the wrong way, so let me state the problem I
personally had.

The problem, or the symptoms of a problem that you never managed to
pin down?
I created a mechanism to upload images keeping the user on
one page. The form would submit image files into dynamically
created IFRAME. I developed this in Firefox but when I started
testing IE6 form was not able to submit to my hidden IFRAME:
Symptom!

it did not see it...

You mean a form with a TARGET attribute did not (POST) submit in such
a way that the response was received as the new contents of an IFRAME
with a corresponding NAME attribute?

I POST forms to dynamically created named/IDed IFRAMEs in IE 6+ all
the time, so your inability to do so certainly does not indicate that
it is impossible.
This form's target was IFRAME's name.

But was it? The balance of probability is that you attempted to use -
setAttribute - to set the NAME attribute, and that has never worked
well on IE (for any elements).
When I did some research I discovered that if I create
IFRAME like this for IE6
(document.createElement('<iframe src="#">')) then it
would work for me and it did.

I think there should be a name attribute in that mark-up, but still it
is not needed.
That's why I am wondering why it happened and is it something
I should be better off using for IE6 or less?

If you want to know why some script did not work then you should show
that script. Describing it only goes so far, and usually leaves the
impression that some programmer error has been made but is not going
to be recognised by the programmer responsible and so will never be
included in any description.
 
H

Henry

On Sep 9, 6:04 pm, Laurent vilday wrote:
This code will *not* "work" in IE6 or IE7, but will in IE8b2

<a href="http://www.google.fr" target="myIframe">link</a>
<script type="text/javascript">
var iframe = document.createElement('iframe');
iframe.name = 'myIframe';
document.body.appendChild(iframe);
</script>
<snip>

How are you defining "*not* work" in that case? The code, when pasted
into a simple HTML page, produces the IFRAME just fine in IE 6, and
that is pretty much all it has been coded to do.

(The handling of name attributes is pretty much an irrelevance if you
never attempt to do anything that relates to them.)
 
L

Laurent vilday

Henry a écrit :
On Sep 9, 6:04 pm, Laurent vilday wrote:

<snip>

How are you defining "*not* work" in that case? The code, when pasted
into a simple HTML page, produces the IFRAME just fine in IE 6, and
that is pretty much all it has been coded to do.

Well, I though it was obvious to reproduce but you are right it needs
more explanation to understand what needs to be done to reproduce the
problem.

1) Browse the HTML code
2) Click on the link

For IE6 and 7, the iframe appears correctly on the document, but the
(The handling of name attributes is pretty much an irrelevance if you
never attempt to do anything that relates to them.)

Pff, I really though it was obvious for anyone reading the html,
especially from clj readers since this *name* issue in dynamically
created element is far (*very* far) from being a new thing.

There is a link to a target (myIframe) and there is a dynamically
created iframe with a dynamic name attribute (myIframe), don't you see
something relevant ?

Anyway I'm so bored of playing games here, EOD.
 
L

Laurent vilday

Henry a écrit :
On Sep 9, 5:17 pm, vunet wrote:


When you get round to asking a question that can be answered you might
get an answer.

Oh come on ! Do you really need to be another PointedEars ?
You mean a form with a TARGET attribute did not (POST) submit in such
a way that the response was received as the new contents of an IFRAME
with a corresponding NAME attribute?

I POST forms to dynamically created named/IDed IFRAMEs in IE 6+ all
the time, so your inability to do so certainly does not indicate that
it is impossible.

LOL, really without any IE6/IE7 hack ? I doubt it. No, sorry, I have no
doubt, I *know* by experience it is a lie.

Read *very* carefully this document :
<http://msdn.microsoft.com/en-us/library/ms536389.aspx>
<quote>
Attributes can be included with the sTag as long as the entire string is
valid HTML. To include the NAME attribute at run time on objects created
with the createElement method, use the sTag .
</quote>

In IE6 and IE7, if you have to use the name attribute of a dynamic
element inserted into the document, you *must* declare the name
attribute of the element when calling document.createElement(). After is
too late.

in IE6 and IE7 :
var input = document.createElement('<input name="myInput">');
var iframe = document.createElement('<iframe name="myIframe">');

Anywhere else :
var input = document.createElement('input');
input.name = 'myInput';
var iframe = document.createElement('iframe');
iframe.name = 'myIframe';

Period.
 
V

vunet

In IE6 and IE7, if you have to use the name attribute of a dynamic
element inserted into the document, you *must* declare the name
attribute of the element when calling document.createElement(). After is
too late.

in IE6 and IE7 :
var input = document.createElement('<input name="myInput">');
var iframe = document.createElement('<iframe name="myIframe">');

Anywhere else :
var input = document.createElement('input');
input.name = 'myInput';
var iframe = document.createElement('iframe');
iframe.name = 'myIframe';

Is this the answer I was looking for? Thanks Laurent, I've been
through all this dirt from other 'experts' but finally got what I
need.
 
T

Thomas 'PointedEars' Lahn

vunet said:
In IE6 and IE7, if you have to use the name attribute of a dynamic
element inserted into the document, you *must* declare the name
attribute of the element when calling document.createElement(). After
is too late.
[...]
Is this the answer I was looking for?

You have failed to provide a proper question in the first place!

This was a lucky guess and does not mean that you did anything OK here.
Thanks Laurent, I've been through all this dirt from other 'experts' but
finally got what I need.

Yeah, so why don't you FOAD now?


Score adjusted

PointedEars
 
S

slebetman

(The handling of name attributes is pretty much an irrelevance if you
never attempt to do anything that relates to them.)

It is relevant because the code DOES ATTEMPT TO DO SOMETHING WITH THE
IFRAME NAME. You just failed to read this bit:
^^^^^^^^^^
 
T

The Magpie

vunet said:
With my original question I was hoping to hear what experts think if
they are familiar with what I am asking.
Experts are suggesting that using <iframe> is basically a bad idea
unless you have some over-riding reason that you need to use it. In
virtually all cases, there will be no such reason.
 
H

Henry

Laurent said:
Henry a écrit :

Oh come on ! Do you really need to be another PointedEars ?

You may not appreciate how the discipline of asking a decent question
promotes both understanding and eliciting worthwhile answers, but it
looks like you might get a lesson in that today.
LOL, really without any IE6/IE7 hack ?

That depends on what you consider an IE hack. The code I use works
fine on a very wide range of browsers including IE 6+ and does not
branch at all. It does take one action that is necessary to get it
working properly for IE, but that action is harmless to other
browsers.
I doubt it. No, sorry, I have no
doubt, I *know* by experience it is a lie.

So you *know* it is a lie? We will see.
<snip>

Microsoft's browser documentation is notoriously unreliable. And
they certainly are not (and never have been) a source for
cross-browser coding advice.
In IE6 and IE7, if you have to use the name attribute of a
dynamic element inserted into the document, you *must*
declare the name attribute of the element when calling
document.createElement(). After is too late.

There is no "must" about it.
in IE6 and IE7 :
var input = document.createElement('<input name="myInput">');
var iframe = document.createElement('<iframe name="myIframe">');

Anywhere else :
var input = document.createElement('input');
input.name = 'myInput';

This is successful in IE. The created input element is functional
and will be successfully submitted as a name/value pair with the
containing form. Here the issue with name attributes is only that
form controls created in this way are not then available as
members of the document, FORM element or its - elements -
collection using their names, but there are ways around that.
(The exception being <input type="radio">, which use name
attributes as part of their mechanism and so are problematic on
IE).
var iframe = document.createElement('iframe');
iframe.name = 'myIframe';

Period.

When properly analysed, to the point of precisely pinning down the
cause and effect relationship that results in the issue, the
critical factor is that when an IFRAME element is created on IE
without a name being provided in the creation process (the call
to - createElement -) the window object that corresponds with the
IFRAME is not given a - name - property, and subsequent setting
of the - name - property of the IFRAME object or its NAME
attribute (with setAttribute) does not have the side effect of
setting the - name - attribute of the window object.

Having pinned that down the solution is simple; it is to directly
assign to the - name - property of the window object, either just
before targeting it with links or form submission, or following
the IFRAMEs insertion into the document. E.G.:-

<html>
<head>
<title></title>
</head>
<body>
<a href="http://www.google.com/"
target="myIframe"
onclick="frames[this.target].name = this.target">link</a>
<script type="text/javascript">
var iframe = document.createElement('iframe');
iframe.id = iframe.name = 'myIframe';
document.body.appendChild(iframe);
</script>
</body>
</html>

- and/or:-

<html>
<head>
<title></title>
</head>
<body>
<a href="http://www.google.com/"
target="myIframe"
onclick="frames[this.target].name = this.target">link</a>
<script type="text/javascript">
var iframe = document.createElement('iframe');
iframe.id = iframe.name = 'myIframe';
document.body.appendChild(iframe);
frames['myIframe'].name = 'myIframe';
</script>
</body>
</html>

And those work fine on IE, many other browsers (the scriptable ones
that support dynamic DOM standard IFRAME creation) and does not
need to test and branch, while only using the standard call to -
createElement -. The window - name - setting operations are harmless
on the browsers that do not need them, and so it is easier/quicker
to just do it rather than trying to perform some test to see if it
is necessary, though the test is simple as prior to the assignment
the IE window object has no name. The same solution applies in
precisely the same way to form submission.

But of course your experience tells you that that is all a lie,
doesn't it? Period.
 
H

Henry

Is this the answer I was looking for? Thanks Laurent, I've
been through all this dirt from other 'experts' but finally
got what I need.

If you were only interested in listening to the answer you wanted to
hear, rather than learning the truth, why did you ask the question in
the first place? You knew the answer you wanted to hear from the
outset, so you were just wasting everyone's time asking the question
in a forum that would rather promote understanding stupid mystical
incantations.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,999
Messages
2,570,243
Members
46,836
Latest member
login dogas

Latest Threads

Top