Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #19680 > unrolled thread

Set iframe src without default.

Back to article view | Back to comp.lang.javascript

Contents

  Set iframe src without default. Andrew Poulos <ap_prog@hotmail.com> - 2013-05-08 08:08 +1000
    Re: Set iframe src without default. "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-05-08 01:14 +0200
      Re: Set iframe src without default. Andrew Poulos <ap_prog@hotmail.com> - 2013-05-08 13:18 +1000
        Re: Set iframe src without default. "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2013-05-08 08:45 +0300
          Re: Set iframe src without default. Andrew Poulos <ap_prog@hotmail.com> - 2013-05-08 16:53 +1000
            Re: Set iframe src without default. "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2013-05-08 10:25 +0300
    Re: Set iframe src without default. "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2013-05-08 08:50 +0300
    Re: Set iframe src without default. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-08 10:25 +0200
      Re: Set iframe src without default. Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-05-09 00:12 +0200
        Re: Set iframe src without default. Christoph Becker <cmbecker69@gmx.de> - 2013-05-09 02:06 +0200
          Re: Set iframe src without default. Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-05-09 11:34 +0200
            Re: Set iframe src without default. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-12 17:46 +0200
    Re: Set iframe src without default. Stefan Weiss <krewecherl@gmail.com> - 2013-05-08 11:35 +0200
      Re: Set iframe src without default. Andrew Poulos <ap_prog@hotmail.com> - 2013-05-08 20:58 +1000
        Re: Set iframe src without default. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-08 14:33 +0200
          Re: Set iframe src without default. Andrew Poulos <ap_prog@hotmail.com> - 2013-05-09 10:10 +1000
            Re: Set iframe src without default. Tim Streater <timstreater@greenbee.net> - 2013-05-09 09:33 +0100
            Re: Set iframe src without default. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-09 12:26 +0200
        Re: Set iframe src without default. Matt McDonald <matt@fortybelow.ca> - 2013-05-08 18:52 -0400
          Re: Set iframe src without default. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-09 12:30 +0200

#19680 — Set iframe src without default.

I have a page with an iframe in it

<iframe src="blah.htm"></frame>

If javascript is enabled then at window.onload the source is changed 
depending on what's found in the hash part of the URL. If javascript is 
not enabled then users get to see 'blah.htm' - the default.

The issue that I'm having is that when the page loads 'blah.htm' often 
flashes up just before the source is changed.

If I don't set a src then the 'fails' when javascript is not enabled.

How do I keep a default src without the default flashing up before the 
src is dynamically changed?

Andrew Poulos

[toc] | [next] | [standalone]

#19682

Andrew Poulos wrote on 08 mei 2013 in comp.lang.javascript:

> I have a page with an iframe in it
> 
> <iframe src="blah.htm"></frame>
> 
> If javascript is enabled then at window.onload the source is changed 
> depending on what's found in the hash part of the URL. If javascript is 
> not enabled then users get to see 'blah.htm' - the default.
> 
> The issue that I'm having is that when the page loads 'blah.htm' often 
> flashes up just before the source is changed.
> 
> If I don't set a src then the 'fails' when javascript is not enabled.
> 
> How do I keep a default src without the default flashing up before the 
> src is dynamically changed?

If you do not like that, why do you make it that way?

It is reasonable to expect some delay, if you first load the iframe with 
the default page, and then only when the total is loaded start changing 
the iframe. There is no reason to wait for the page to be loaded to start 
testing the hash.

But as you show, the whole setup stinks, because it "prefers" noscript,
while most browsers are script enabled, so noscript should be the 
fallback.

If you must, perhaps:

<iframe id='myIframe' style='display:none;'></frame>
<noscript><iframe src='blah.htm'></frame></noscript>

and have script fill the source of the first iframe and change the 
display? 


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#19683

On 8/05/2013 9:14 AM, Evertjan. wrote:
> Andrew Poulos wrote on 08 mei 2013 in comp.lang.javascript:
>
>> I have a page with an iframe in it
>>
>> <iframe src="blah.htm"></frame>
>>
>> If javascript is enabled then at window.onload the source is changed
>> depending on what's found in the hash part of the URL. If javascript is
>> not enabled then users get to see 'blah.htm' - the default.
>>
>> The issue that I'm having is that when the page loads 'blah.htm' often
>> flashes up just before the source is changed.
>>
>> If I don't set a src then the 'fails' when javascript is not enabled.
>>
>> How do I keep a default src without the default flashing up before the
>> src is dynamically changed?
>
> If you do not like that, why do you make it that way?
>
> It is reasonable to expect some delay, if you first load the iframe with
> the default page, and then only when the total is loaded start changing
> the iframe. There is no reason to wait for the page to be loaded to start
> testing the hash.

So you're saying I should consider putting a SCRIPT element right after 
the iframe to change the iframe's src?

> But as you show, the whole setup stinks, because it "prefers" noscript,
> while most browsers are script enabled, so noscript should be the
> fallback.
>
> If you must, perhaps:
>
> <iframe id='myIframe' style='display:none;'></frame>
> <noscript><iframe src='blah.htm'></frame></noscript>
>
> and have script fill the source of the first iframe and change the
> display?

I've not used NOSCRIPT much but it appears that I can use the same ID 
for an element within the NOSCRIPT and without.

Andrew Poulos++++++++

[toc] | [prev] | [next] | [standalone]

#19684

2013-05-08 6:18, Andrew Poulos wrote:

>> If you must, perhaps:
>>
>> <iframe id='myIframe' style='display:none;'></frame>
>> <noscript><iframe src='blah.htm'></frame></noscript>
>>
>> and have script fill the source of the first iframe and change the
>> display?
>
> I've not used NOSCRIPT much but it appears that I can use the same ID
> for an element within the NOSCRIPT and without.

No, you cannot; id attribute values must be unique within a document.

Using <noscript> is generally a bad move, except perhaps in simple cases 
where its only purpose is to tell users with scripting disabled that the 
page just won't work without scripting.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#19686

On 8/05/2013 3:45 PM, Jukka K. Korpela wrote:
> 2013-05-08 6:18, Andrew Poulos wrote:
>
>>> If you must, perhaps:
>>>
>>> <iframe id='myIframe' style='display:none;'></frame>
>>> <noscript><iframe src='blah.htm'></frame></noscript>
>>>
>>> and have script fill the source of the first iframe and change the
>>> display?
>>
>> I've not used NOSCRIPT much but it appears that I can use the same ID
>> for an element within the NOSCRIPT and without.
>
> No, you cannot; id attribute values must be unique within a document.

Ok, though my debugger does not complain.

> Using <noscript> is generally a bad move, except perhaps in simple cases
> where its only purpose is to tell users with scripting disabled that the
> page just won't work without scripting.

Google says that the only "bad" thing about NOSCRIPT is if you put links 
within a NOSCRIPT element Google will treat them with suspicion. What am 
I missing?

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#19688

2013-05-08 9:53, Andrew Poulos wrote:

> Google says that the only "bad" thing about NOSCRIPT is if you put links
> within a NOSCRIPT element Google will treat them with suspicion. What am
> I missing?

HTML5 CR says:
"The noscript element is a blunt instrument. Sometimes, scripts might be 
enabled, but for some reason the page's script might fail. For this 
reason, it's generally better to avoid using noscript, and to instead 
design the script to change the page from being a scriptless page to a 
scripted page on the fly"
http://www.w3.org/TR/html5/scripting-1.html#the-noscript-element

Although changing the <iframe> element's src attribute value with a 
script means such an approach, the problem with it is, as you have 
noticed, that it changes the rendered page. This is why I suggested a 
different approach, based on resolving the issue server-side, so that 
what the browser gets is ready for display.

If you need to handle this client-side, then the question is how to 
intercept page processing as early as possible, so that when scripting 
is enabled, the <iframe> element will have the right src attribute when 
the browser starts rendering it. Here jQuery might help, see
http://stackoverflow.com/questions/4395780/difference-bw-onload-and-document-readyfunction
(Stay tuned to usual whining about jQuery, usually presented without 
giving any constructive alternative you could actually apply.)

A simpler approach, which might work well enough in practice, is to put 
the <script> element that contains code for changing the src attribute 
right after the <iframe> element.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#19685

2013-05-08 1:08, Andrew Poulos wrote:

> I have a page with an iframe in it
>
> <iframe src="blah.htm"></frame>
>
> If javascript is enabled then at window.onload the source is changed
> depending on what's found in the hash part of the URL. If javascript is
> not enabled then users get to see 'blah.htm' - the default.

This sounds like something that should be done server-side and using a 
query part rather than a fragment ("hash part"). Please explain the 
context and purpose so that various solutions to the original problem, 
rather than to the assumed approach, can be discussed.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#19691

Andrew Poulos wrote:

> I have a page with an iframe in it

There are no “pages”.  Are you using HTML, and if yes, which version?

> <iframe src="blah.htm"></frame>
> 
> If javascript is enabled

There is no “javascript”.  Which ECMAScript implementations and runtime 
environments are you targeting?

> then at window.onload the source is changed depending on what's found in
> the hash part of the URL.

There is no “hash part of the URL”.  Do you mean the URI fragment?

> If javascript is not enabled then users get to see 'blah.htm' - the 
> default.

Why does there have to be a default – why do there have to be two versions?  
If client-side script support was not present or not enabled, client-side 
script code in the *one* iframe document would simply not be executed.

> The issue that I'm having is that when the page loads 'blah.htm' often
> flashes up just before the source is changed.
> 
> If I don't set a src then the 'fails' when javascript is not enabled.
> 
> How do I keep a default src without the default flashing up before the
> src is dynamically changed?

You cannot solve this problem with client-side scripting.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#19713

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Andrew Poulos wrote:

>> the hash part of the URL.
>
> There is no “hash part of the URL”.  Do you mean the URI fragment?

~ $ curl -s http://tools.ietf.org/rfc/rfc3986.txt | grep "URI fragment"
~ $ 

-- 
This stdout intentionally left blank.

[toc] | [prev] | [next] | [standalone]

#19716

Eric Bednarz wrote:
>
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
> 
>> Andrew Poulos wrote:
> 
>>> the hash part of the URL.
>>
>> There is no “hash part of the URL”.  Do you mean the URI fragment?
> 
> ~ $ curl -s http://tools.ietf.org/rfc/rfc3986.txt | grep "URI fragment"
> ~ $ 
> 
But note RFC 3986, section 3.5:

| The fragment identifier component of a URI [...]

IOW: A URI's fragment identifier component [...]

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#19719

Christoph Becker <cmbecker69@gmx.de> writes:

> Eric Bednarz wrote:
>>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> 
>>> Andrew Poulos wrote:
>> 
>>>> the hash part of the URL.
>>>
>>> There is no “hash part of the URL”.  Do you mean the URI fragment?
>> 
>> ~ $ curl -s http://tools.ietf.org/rfc/rfc3986.txt | grep "URI fragment"
>> ~ $ 
>> 
> But note RFC 3986,

I believe I did. How is "the URI fragment" supposed to be less ambiguous
than "the hash part of the URL"?

NB:

Exhibit A
  Since there-is-no-javascript is on-topic in this group:
  window.location.hash
Exhibit B
  "A family of URIs can share the same non-hash part."
  <http://www.w3.org/TR/cooluris/#choosing>

> section 3.5:
>
> | The fragment identifier component of a URI [...]
>
> IOW: A URI's fragment identifier component [...]

Just a few IOWs more and we're there.

http://de.wikipedia.org/wiki/Stille_Post

[toc] | [prev] | [next] | [standalone]

#19737

Eric Bednarz wrote:

> Christoph Becker <cmbecker69@gmx.de> writes:
>> Eric Bednarz wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> Andrew Poulos wrote:
>>>>> the hash part of the URL.
>>>>
>>>> There is no “hash part of the URL”.  Do you mean the URI fragment?
>>> 
>>> ~ $ curl -s http://tools.ietf.org/rfc/rfc3986.txt | grep "URI fragment"
>>> ~ $
>> 
>> But note RFC 3986,
> 
> I believe I did. How is "the URI fragment" supposed to be less ambiguous
> than "the hash part of the URL"?

“fragment” is a term in an Internet standard specifying URIs/URLs; “hash 
part” is not.  Furthermore, “hash” is a rather overloaded word with regard 
to computers (ask a theoretical computer scientist, a Perl programmer, an 
ECMAScript programmer, and a Twitter user – you will get *five* different 
definitions); “fragment” rather is not.

> NB:
> 
> Exhibit A
>   Since there-is-no-javascript is on-topic in this group:
>   window.location.hash

A legacy, although perhaps soon a standardized, DOM feature whose property 
value is not well-defined (depending on the DOM implementation, can be with 
or without “#”).  If possible, parse document.URL instead.

Besides:

,-<http://www.w3.org/TR/2012/CR-html5-20121217/infrastructure.html
   #url-decomposition-idl-attributes>
| 
| o . hash [ = value ]
|   Returns the current fragment identifier in the underlying URL.
|   Can be set, to change the underlying URL's fragment identifier.

> Exhibit B
>   "A family of URIs can share the same non-hash part."
>   <http://www.w3.org/TR/cooluris/#choosing>

Informative, not normative.
 
>> section 3.5:
>>
>> | The fragment identifier component of a URI [...]
>>
>> IOW: A URI's fragment identifier component [...]
> 
> Just a few IOWs more and we're there.
> 
> http://de.wikipedia.org/wiki/Stille_Post

I do not think it is uncommon that the English genitive (“of”) is replaced 
with a compound word for brevity.  Perhaps I should have said ”URI fragment 
identifier component” (although there is a “fragment” production in the URI 
ABNF grammar, so my meaning should have been clear), but other than that you 
do not have a point.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#19692

On 2013-05-08 00:08, Andrew Poulos wrote:
> I have a page with an iframe in it
> 
> <iframe src="blah.htm"></frame>
...
> How do I keep a default src without the default flashing up before the 
> src is dynamically changed?

Why do you need a default src? Instead of changing the src when the page
loads, you could create and insert the iframe at that point.


- stefan

[toc] | [prev] | [next] | [standalone]

#19693

On 8/05/2013 7:35 PM, Stefan Weiss wrote:
> On 2013-05-08 00:08, Andrew Poulos wrote:
>> I have a page with an iframe in it
>>
>> <iframe src="blah.htm"></frame>
> ...
>> How do I keep a default src without the default flashing up before the
>> src is dynamically changed?
>
> Why do you need a default src? Instead of changing the src when the page

If javascript is not enabled then I still need at least something to 
display.

> loads, you could create and insert the iframe at that point.


Thanks, though I take JKK and PE's comments on board that the only 
"real" way to do this is server side.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#19694

Andrew Poulos wrote:

> On 8/05/2013 7:35 PM, Stefan Weiss wrote:
>> On 2013-05-08 00:08, Andrew Poulos wrote:
>>> I have a page with an iframe in it
>>>
>>> <iframe src="blah.htm"></frame>
>> ...
>>> How do I keep a default src without the default flashing up before the
>>> src is dynamically changed?
>>
>> Why do you need a default src? Instead of changing the src when the page
> 
> If javascript is not enabled then I still need at least something to
> display.
> 
>> loads, you could create and insert the iframe at that point.
> 
> Thanks, though I take JKK and PE's comments on board that the only
> "real" way to do this is server side.

You have misunderstood me at least.  A good solution to your problem is to 
have the client-side script that changes the iframe document in or included 
by the iframe document.  For you can only say for sure on the *client* side 
whether there is client-side script support, whether it is enabled, and 
whether the support is sufficient for the task – simply by executing the 
relevant code (which would contain feature tests).

Stefan's suggestion is another good idea, but apparently not applicable 
here.

There is also a third way combining both suggestions, but it might not be 
among the best ones here: You can include the iframe element displaying the 
default document (or put other content) and replace that programmatically by 
client-side (DOM) script with a new iframe element that displays another 
document.  This is the same approach you would choose if, for example, you 
wanted to include a static Google Maps map (an image) in an HTML document 
(that would work everywhere), and replace it with an interactive Google Maps 
map if possible (“progressive enhancement”).

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#19717

On 8/05/2013 10:33 PM, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>
>> On 8/05/2013 7:35 PM, Stefan Weiss wrote:
>>> On 2013-05-08 00:08, Andrew Poulos wrote:
>>>> I have a page with an iframe in it
>>>>
>>>> <iframe src="blah.htm"></frame>
>>> ...
>>>> How do I keep a default src without the default flashing up before the
>>>> src is dynamically changed?
>>>
>>> Why do you need a default src? Instead of changing the src when the page
>>
>> If javascript is not enabled then I still need at least something to
>> display.
>>
>>> loads, you could create and insert the iframe at that point.
>>
>> Thanks, though I take JKK and PE's comments on board that the only
>> "real" way to do this is server side.
>
> You have misunderstood me at least.  A good solution to your problem is to
> have the client-side script that changes the iframe document in or included
> by the iframe document.  For you can only say for sure on the *client* side
> whether there is client-side script support, whether it is enabled, and
> whether the support is sufficient for the task – simply by executing the
> relevant code (which would contain feature tests).
>
> Stefan's suggestion is another good idea, but apparently not applicable
> here.
>
> There is also a third way combining both suggestions, but it might not be
> among the best ones here: You can include the iframe element displaying the
> default document (or put other content) and replace that programmatically by
> client-side (DOM) script with a new iframe element that displays another
> document.  This is the same approach you would choose if, for example, you
> wanted to include a static Google Maps map (an image) in an HTML document
> (that would work everywhere), and replace it with an interactive Google Maps
> map if possible (“progressive enhancement”).

Is it "better" to replace one iframe with another instead of just 
changing the iframe's src?

I've tried a way that was previously suggested (dropping the noscript, 
and instead dynamically changing the src with a script element 
immediately after the iframe element in the HTML) and it seems to do 
what I need.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#19718

In article <1emdnRJN--PxdBfMnZ2dnUVZ_sqdnZ2d@westnet.com.au>,
 Andrew Poulos <ap_prog@hotmail.com> wrote:

> Is it "better" to replace one iframe with another instead of just 
> changing the iframe's src?
> 
> I've tried a way that was previously suggested (dropping the noscript, 
> and instead dynamically changing the src with a script element 
> immediately after the iframe element in the HTML) and it seems to do 
> what I need.

I have two <div>s one after the other, with an iframe in each. I need 
two because I want the sandbox attribute on one iframe but not on the 
other.

I switch between them by changing the display attribute of the <divs>, 
as in:

     div1Ptr.style.display = "block";
     div2Ptr.style.display = "none";

and vice versa. Appears to work with no problems.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#19721

Andrew Poulos wrote:

> On 8/05/2013 10:33 PM, Thomas 'PointedEars' Lahn wrote:
>> Andrew Poulos wrote:
>>> Thanks, though I take JKK and PE's comments on board that the only
>>> "real" way to do this is server side.
>>
>> You have misunderstood me at least.  A good solution to your problem is
>> to have the client-side script that changes the iframe document in or
>> included by the iframe document.  For you can only say for sure on the
>> *client* side whether there is client-side script support, whether it is
>> enabled, and whether the support is sufficient for the task – simply by
>> executing the relevant code (which would contain feature tests).
>>
>> Stefan's suggestion is another good idea, but apparently not applicable
>> here.
>>
>> There is also a third way combining both suggestions, but it might not be
>> among the best ones here: You can include the iframe element displaying
>> the default document (or put other content) and replace that
>> programmatically by client-side (DOM) script with a new iframe element
>> that displays another document.  This is the same approach you would
>> choose if, for example, you wanted to include a static Google Maps map
>> (an image) in an HTML document (that would work everywhere), and replace
>> it with an interactive Google Maps map if possible (“progressive
>> enhancement”).
> 
> Is it "better" to replace one iframe with another instead of just
> changing the iframe's src?

Depends.

> I've tried a way that was previously suggested (dropping the noscript,
> and instead dynamically changing the src with a script element
> immediately after the iframe element in the HTML) and it seems to do
> what I need.

It is inherently unreliable, though.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#19714

On Wed, 8 May 2013, Andrew Poulos wrote:

> If [JavaScript] is not enabled then I still need at least something
> to display.

I have the following suggestions to contribute:

    1. Conceal the iframe with an HTML class that utilises
    `visibility: hidden`. Perhaps you could display some alternate
    content and then hide that with a script. That is, alternate
    content such as an image would be displayed before scripting
    runs. Once scripting runs, the iframe would be displayed and
    the image would be concealed.

    2. Point the iframe to a nonexistent URI (*e.g.*,
    http://www.null.invalid). The alternate content inside of the
    iframe would therefore be displayed. Once scripting runs, the
    src property would be altered to an existing URI.

If you could further elucidate your concerns, I could provide more
ideas.

[toc] | [prev] | [next] | [standalone]

#19720

Matt McDonald wrote:

> On Wed, 8 May 2013, Andrew Poulos wrote:
>> If [JavaScript] is not enabled then I still need at least something
>> to display.
> 
> I have the following suggestions to contribute:
> 
>     1. Conceal the iframe with an HTML class that utilises
>     `visibility: hidden`. Perhaps you could display some alternate
>     content and then hide that with a script. That is, alternate
>     content such as an image would be displayed before scripting
>     runs. Once scripting runs, the iframe would be displayed and
>     the image would be concealed.

This would mean that in the worst case both image and iframe are displayed; 
that is, both image and iframe would be indexed by a search engine.  Bad 
idea.
 
>     2. Point the iframe to a nonexistent URI (*e.g.*,
>     http://www.null.invalid). The alternate content inside of the
>     iframe would therefore be displayed.

Or an error message would be displayed, and a search engine would detect a 
broken link in the HTML document.  Bad idea.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web