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

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

Instead of iframe onload?

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

Contents

  Instead of iframe onload? Dr J R Stockton <J.R.Stockton@physics.org> - 2017-05-18 05:40 -0700
    Re: Instead of iframe onload? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-05-18 15:07 +0200
      Re: Instead of iframe onload? Dr J R Stockton <J.R.Stockton@physics.org> - 2017-05-18 08:11 -0700
        Re: Instead of iframe onload? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-05-18 18:09 +0200
          Re: Instead of iframe onload? Andrew Poulos <ap_prog@hotmail.com> - 2017-05-19 12:36 +1000
            Re: Instead of iframe onload? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-05-19 09:15 +0200
              Re: Instead of iframe onload? Andrew Poulos <ap_prog@hotmail.com> - 2017-05-19 18:12 +1000
                Re: Instead of iframe onload? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-05-19 11:47 +0200
    Re: Instead of iframe onload? Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2017-05-19 02:44 -0700
    Re: Instead of iframe onload? Martin Honnen <martin.honnen@gmx.de> - 2017-05-19 15:25 +0200
      Re: Instead of iframe onload? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-19 18:11 +0200
      Re: Instead of iframe onload? Dr J R Stockton <J.R.Stockton@physics.org> - 2017-05-19 14:30 -0700
        Instead of <iframe onload=... Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> - 2017-05-20 22:15 +0100
          Re: Instead of <iframe onload=... Stefan Weiss <krewecherl@gmail.com> - 2017-05-21 02:10 +0200
            Re: Instead of <iframe onload=... Dr J R Stockton <J.R.Stockton@physics.org> - 2017-05-21 11:46 -0700
              Re: Instead of <iframe onload=... Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> - 2017-05-24 23:18 +0100
            Re: Instead of <iframe onload=... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-21 23:22 +0200
              Re: Instead of <iframe onload=... Stefan Weiss <krewecherl@gmail.com> - 2017-05-22 00:39 +0200
                Re: Instead of <iframe onload=... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-22 01:38 +0200
                  Re: Instead of <iframe onload=... Stefan Weiss <krewecherl@gmail.com> - 2017-05-22 02:19 +0200
                    Re: Instead of <iframe onload=... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-22 02:35 +0200
                      Re: Instead of <iframe onload=... Stefan Weiss <krewecherl@gmail.com> - 2017-05-22 12:54 +0200
                        Re: Instead of <iframe onload=... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-22 15:37 +0200
                          Re: Instead of <iframe onload=... Stefan Weiss <krewecherl@gmail.com> - 2017-05-22 18:23 +0200
                            Re: Instead of <iframe onload=... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-23 14:15 +0200
                              Re: Instead of <iframe onload=... Stefan Weiss <krewecherl@gmail.com> - 2017-05-23 15:56 +0200
                                Re: Instead of <iframe onload=... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-23 18:41 +0200
          Re: Instead of <iframe onload=... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-22 03:27 +0200

Page 1 of 2  [1] 2  Next page →

#33342 — Instead of iframe onload?

I use such as

 <iframe src="someHTML.htm" onload="Procrustes(this)"></iframe>

to adjust the height of the iframe to fit the displayed
content from page someHTML.htm ; it works in my Firefoxes.

BUT
  (1) I've not tested it on all browsers,
  (2) If someHTML.htm contains a similar construction,
      the 'outer' iframe resizes wrongly, for an obvious
      reason,
  (3) Validators & testers dislike iframe ... onload.

Is there a better method, acceptable to at least to
validator.w3.org, known to all reasonable browsers
including Firefox esr 52.1.1 (32 bit), and free of
unforeseen evils?  If so, please explain.

I have seen method ondatasetcomplete in Wikipedia.


-- 
  (c) John Stockton, near London, UK.  Using Google, no spell-check. |
 Mail: J.R.""""""""@physics.org                                      |

[toc] | [next] | [standalone]

#33344

Dr J R Stockton <J.R.Stockton@physics.org> wrote on 18 May 2017 in 
comp.lang.javascript:

> I use such as
> 
>  <iframe src="someHTML.htm" onload="Procrustes(this)"></iframe>
> 
> to adjust the height of the iframe to fit the displayed
> content from page someHTML.htm ; it works in my Firefoxes.
> 
> BUT
>   (1) I've not tested it on all browsers,
>   (2) If someHTML.htm contains a similar construction,
>       the 'outer' iframe resizes wrongly, for an obvious
>       reason,
>   (3) Validators & testers dislike iframe ... onload.
> 
> Is there a better method, acceptable to at least to
> validator.w3.org, known to all reasonable browsers
> including Firefox esr 52.1.1 (32 bit),

If it is from your own website, use serverside includes.

I use them often, as they can add temporary sections, are on/off switchable 
by serverside if/then code and give a better [over]view of the main file 
source. Each hes its own outer <div> where the id matches the name of the 
file [#thisFile] and the internal css has all declarations starting with 
#thisFile. And you can place the files to be included out of external reach.

main file in the <body>:

<!-- #include virtual ="/../inc/June2017.asp"-->
<!-- #include virtual ="/../inc/July2017.asp"-->

and the file June2017.asp:

<% if now<#2017/07/01# then %>
... css and html code here ...
<% end if %>

They love to be part of a display:flex; construct.

> and free of unforeseen evils? 

How could one ever be able to forsee "unforeseen evils",
or even more so the absense thereof?

> If so, please explain.

Impossible.

> I have seen method ondatasetcomplete in Wikipedia.

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

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

#33345

On Thursday, May 18, 2017 at 2:08:15 PM UTC+1, Evertjan. wrote:
> Dr J R Stockton <...> wrote on 18 May 2017 in 
> comp.lang.javascript:


> If it is from your own website, use serverside includes.

That is not possible.
It needs to work on pages distributed by slippernet.


> > and free of unforeseen evils? 
> 
> How could one ever be able to forsee "unforeseen evils",
> or even more so the absense thereof?


Foresee, absence.  "Unforeseen" refers to the situation at
the time of writing, when only the author has seen the message.
One must distinguish between "foreseen" and "foreseeable".  The
most annoying evils are those which were foreseeable but not
foreseen.

-- 
  (c) John Stockton, near London, UK.  Using Google, no spell-check. | 
 Mail: J.R.""""""""@physics.org                                      | 

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

#33346

Dr J R Stockton <J.R.Stockton@physics.org> wrote on 18 May 2017 in 
comp.lang.javascript:

>> > and free of unforeseen evils? 
>> 
>> How could one ever be able to forsee "unforeseen evils",
>> or even more so the absense thereof?
> 
> Foresee, absence.  "Unforeseen" refers to the situation at
> the time of writing, when only the author has seen the message.
> One must distinguish between "foreseen" and "foreseeable".  The
> most annoying evils are those which were foreseeable but not
> foreseen.

True in itself, however, you mis the negative "free of" here.

Being free of unforeseen evils can never be ascertained,
except in hindsight.

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

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

#33348

On 19/05/2017 2:09 AM, Evertjan. wrote:
> Dr J R Stockton <J.R.Stockton@physics.org> wrote on 18 May 2017 in
> comp.lang.javascript:
> 
>>>> and free of unforeseen evils?
>>>
>>> How could one ever be able to foresee "unforeseen evils",
>>> or even more so the absence thereof?
>>
>> Foresee, absence.  "Unforeseen" refers to the situation at
>> the time of writing, when only the author has seen the message.
>> One must distinguish between "foreseen" and "foreseeable".  The
>> most annoying evils are those which were foreseeable but not
>> foreseen.
> 
> True in itself, however, you miss the negative "free of" here.
> 
> Being free of unforeseen evils can never be ascertained,
> except in hindsight.

If no unforeseen evil happened then in the past the future would've been 
free of unforeseen evils!

Andrew Poulos

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

#33349

Andrew Poulos <ap_prog@hotmail.com> wrote on 19 May 2017 in 
comp.lang.javascript:

>> Being free of unforeseen evils can never be ascertained,
>> except in hindsight.
> 
> If no unforeseen evil happened then in the past the future would've been 
> free of unforeseen evils!

Indeed, but that just means asking to acertain that there will be none in 
that same future is pointless.

Well pointless up to a point. 
At least it gives us something to discuss, it seems.

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

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

#33350

On 19/05/2017 5:15 PM, Evertjan. wrote:
> Andrew Poulos <ap_prog@hotmail.com> wrote on 19 May 2017 in
> comp.lang.javascript:
> 
>>> Being free of unforeseen evils can never be ascertained,
>>> except in hindsight.
>>
>> If no unforeseen evil happened then in the past the future would've been
>> free of unforeseen evils!
> 
> Indeed, but that just means asking to ascertain that there will be none in
> that same future is pointless.
> 
> Well pointless up to a point.
> At least it gives us something to discuss, it seems.
> 

Unless if something unexpectedly evil happened and we didn't see it. So 
an unforeseen evil happened and we just haven't notice it yet - it would 
be pre-unforeseen :-)

Andrew Poulos

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

#33352

Andrew Poulos <ap_prog@hotmail.com> wrote on 19 May 2017 in 
comp.lang.javascript:

> Unless if something unexpectedly evil happened and we didn't see it. So 
> an unforeseen evil happened and we just haven't notice it yet - it would 
> be pre-unforeseen :-)

I am not sure that evil even exists, except as a social construct,
just as the existance of an unforseeable future is pure speculation.

Reality is difficult enough to grasp.

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

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

#33351

Dr J R Stockton  wrote:
> I use such as
> 
>  <iframe src="someHTML.htm" onload="Procrustes(this)"></iframe>
> 
> to adjust the height of the iframe to fit the displayed
> content from page someHTML.htm ; it works in my Firefoxes.
> 
> BUT
>   (1) I've not tested it on all browsers,
>   (2) If someHTML.htm contains a similar construction,
>       the 'outer' iframe resizes wrongly, for an obvious
>       reason,
>   (3) Validators & testers dislike iframe ... onload.
> 
> Is there a better method, acceptable to at least to
> validator.w3.org, known to all reasonable browsers
> including Firefox esr 52.1.1 (32 bit), and free of
> unforeseen evils?  If so, please explain.

Perhaps using Ajax to load the content within a div, combined with CORS [1] headers to allow access to cross-origin responses.

[1] <https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS>
 
--
Joao Rodrigues

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

#33353

On 18.05.2017 14:40, Dr J R Stockton wrote:
> I use such as
> 
>   <iframe src="someHTML.htm" onload="Procrustes(this)"></iframe>
> 
> to adjust the height of the iframe to fit the displayed
> content from page someHTML.htm ; it works in my Firefoxes.
> 
> BUT
>    (1) I've not tested it on all browsers,
>    (2) If someHTML.htm contains a similar construction,
>        the 'outer' iframe resizes wrongly, for an obvious
>        reason,
>    (3) Validators & testers dislike iframe ... onload.
> 
> Is there a better method, acceptable to at least to
> validator.w3.org, 


I think HTML5 and HTML5.1 do allow the "onload" event handler attribute 
on most elements 
(https://www.w3.org/TR/html5/dom.html#global-attributes) and I don't 
have any problems at https://validator.w3.org/nu/#textarea to validate e.g.

<!DOCTYPE html>
<html lang="en">
<head>
<title>iframe onload test</title>
</head>
<body>
<section>
<h1>test</h1>
<iframe src="http://example.com/" 
onload="console.log(event.type);"></iframe>
</section>
</body>
</html>

so I am not sure why you think that validators dislike the onload 
attribute, at least you haven't told us which document standard you target.

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

#33355

Martin Honnen wrote:

> On 18.05.2017 14:40, Dr J R Stockton wrote:
>> I use such as
>> 
>>   <iframe src="someHTML.htm" onload="Procrustes(this)"></iframe>
>> 
>> to adjust the height of the iframe to fit the displayed
>> content from page someHTML.htm ; it works in my Firefoxes.
>> 
>> BUT
>>    (1) I've not tested it on all browsers,
>>    (2) If someHTML.htm contains a similar construction,
>>        the 'outer' iframe resizes wrongly, for an obvious
>>        reason,
>>    (3) Validators & testers dislike iframe ... onload.
>> 
>> Is there a better method, acceptable to at least to
>> validator.w3.org,
> 
> I think HTML5 and HTML5.1 do allow the "onload" event handler attribute
> on most elements
> (https://www.w3.org/TR/html5/dom.html#global-attributes) and I don't
> have any problems at https://validator.w3.org/nu/#textarea to validate
> […]

Also, any problems with validators can be circumvented by scripting event 
listeners at the appropriate time:

  iframeRef.onload = function () {
    Procrustes(this);
  };

BTW, quite an interesting name for a function :)  [For those who are 
unaware: Procrustes was the Greek mythological villain who ran a less 
expensive hostel just outside ancient Athens that made his visitor victims 
fit exactly into his bed by either stretching them or sawing off their 
limbs.  He was one of the three villains famously killed by Athens’ hero 
Theseus (who is partly historical) using their own methods against them when 
he traveled to meet his natural father, Aigeus, King of Athens (only that 
Theseus beheaded the tall Procrustes instead).  (I listened to the myth of 
Theseus, beautifully told by Austrian writer Michael Köhlmeier, a few days 
ago.)]

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#33356

On Friday, May 19, 2017 at 2:25:22 PM UTC+1, Martin Honnen wrote:
> On 18.05.2017 14:40, Dr J R Stockton wrote:
> > I use such as
> > 
> >   <iframe src="someHTML.htm" onload="Procrustes(this)"></iframe>
> > 
> > to adjust the height of the iframe to fit the displayed
> > content from page someHTML.htm ; it works in my Firefoxes.
> > 
> > BUT
> >    (1) I've not tested it on all browsers,
> >    (2) If someHTML.htm contains a similar construction,
> >        the 'outer' iframe resizes wrongly, for an obvious
> >        reason,
> >    (3) Validators & testers dislike iframe ... onload.
> > 
> > Is there a better method, acceptable to at least to
> > validator.w3.org, 
> 
> 
> I think HTML5 and HTML5.1 do allow the "onload" event handler attribute 
> on most elements 
> (https://www.w3.org/TR/html5/dom.html#global-attributes) and I don't 
> have any problems at https://validator.w3.org/nu/#textarea to validate e.g.
> 
> <!DOCTYPE html>
> <html lang="en">
> <head>
> <title>iframe onload test</title>
> </head>
> <body>
> <section>
> <h1>test</h1>
> <iframe src="http://example.com/" 
> onload="console.log(event.type);"></iframe>
> </section>
> </body>
> </html>
> 
> so I am not sure why you think that validators dislike the onload 
> attribute, at least you haven't told us which document standard you target.

Alas, no! my pages start with :-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
&
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
 "http://www.w3.org/TR/html4/strict.dtd">

I also have a batch file with other minor checkers in it; it
which also has a call to an old copy of TIDY (as a checker)
and a call to an old local links checker which I once wrote
in Pascal and compiled in Delphi.

I have tended to start pages with strict.dtd and change to loose.dtd
 when strict.dtd reports baffling faults; loose.dtd generally
 reports things which I should have remembered were wrong.  So,
 for me, <!DOCTYPE HTML> is impractical.

Perhaps I should put, in a general include file, something like

function Elasticate(Sauce, DefaultHeight) {
  // code to insert into DOM at this point ...
  // make iframe
  // iframe onload = Procrustes (this, DefaultHeight)
  .. iframe src = Sauce
  // end DOM code
  }

and put in the HTML of the pages something like

<script ...> Elasticate("pagelet.htm", 45) </script>


"Procrustes" also occurs in the works of LVCN : Google
 for   Niven Procrustes   to approach details.

-- 
  (c) John Stockton, near London, UK.  Using Google, no spell-check. |
 Mail: J.R.""""""""@physics.org                                      |

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

#33357 — Instead of <iframe onload=...

In comp.lang.javascript message <b06552ca-cd04-4314-8dea-76a7630b4058@go
oglegroups.com>, Fri, 19 May 2017 14:30:08, Dr J R Stockton
<J.R.Stockton@physics.org> posted:

By the way, method ondatasetcomplete was not found useful.

>Perhaps I should put, in a general include file, something like
>
>function Elasticate(Sauce, DefaultHeight) {
>  // code to insert into DOM at this point ...
>  // make iframe
>  // iframe onload = Procrustes (this, DefaultHeight)
>  .. iframe src = Sauce
>  // end DOM code
>  }
>
>and put in the HTML of the pages something like
>
><script ...> Elasticate("pagelet.htm", 45) </script>


I am now putting. for example,

  <script type="text/javascript"> Ink("$compost.htm", 69) </script>

in the HTML pages, and have added the following in a commonly-included
script file.


function Ink(Sauce, DefaultHeight) { var Fram
  // code to create and insert iFrame into DOM where called ...
  Fram = document.createElement("iframe")
  Fram.style.border = "2px solid red"
  Fram.style.width = "100%"
  Fram.style.margin = "0.5ex 0"
  Fram.style.background = "#FFE"
  Fram.onload = Inky(Fram, DefaultHeight)
  document.body.appendChild(Fram)
  Fram.src = Sauce }

function Inky(Ifr, ExHi) {
  // Autosize works in Firefox and MS IE (Edge?), else use ExHi
  setTimeout(function() { Procrustes(Ifr, ExHi) } , 500) }

function Procrustes(Ifr, ExHi) { var Ht
  try { Ht = Ifr.contentDocument.documentElement.scrollHeight }
    catch(e) { Ht = 0 }
  Ht = (Ht==0 ? ExHi + "ex" : Ht + "px") // ; alert(Ht)
  Ifr.style.height = Ht }


The setTimeout appeared necessary for the frame height needed to be
discoverable by Procrustes; perhaps there is a better way.

Sometimes, an iFrame appears further down the document than intended,
when two are adjacent.

Alas, iFrame has a minimum height.

That got rid of almost all of the iFrame onloads; a couple of special
cases needed a minor addition to the above code.

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Merlyn Web Site <                       > - FAQish topics, acronyms, & links.

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

#33358 — Re: Instead of <iframe onload=...

Dr J R Stockton wrote:
> The setTimeout appeared necessary for the frame height needed to be
> discoverable by Procrustes; perhaps there is a better way.

I haven't tested any of this, but even if it turns out to be necessary for
some reason, 500 ms *after* the load event seems a bit excessive. It's not
that I can't wait for half a second, I just really dislike elements jumping
around on a page.

> Sometimes, an iFrame appears further down the document than intended,
> when two are adjacent.
> 
> Alas, iFrame has a minimum height.

They do not; even iframes with 0px height are possible.
Use display:block.

- stefan

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

#33359 — Re: Instead of <iframe onload=...

On Sunday, May 21, 2017 at 1:10:10 AM UTC+1, Stefan Weiss wrote:
> Dr J R Stockton wrote:
> > The setTimeout appeared necessary for the frame height needed to be
> > discoverable by Procrustes; perhaps there is a better way.
> 
> I haven't tested any of this, but even if it turns out to be necessary for
> some reason, 500 ms *after* the load event seems a bit excessive. It's not
> that I can't wait for half a second, I just really dislike elements jumping
> around on a page.

Perhaps the onload event is fired when all of the file has actually
arrived, rather than when it has been sufficiently processed for its
height to be known.  I will test shorter intervals; but, as I am
using it, the jumping is not annoying.  _At_present_, an inadequate
interval leaves the iframe short ...

Another problem occurred when the file in the self-adjusting frame
contained a self-adjusting frame.  That was easily avoided when I
noticed that the inner material did not need to be framed (certain
site "design" rationalisations have been done since that material
was originated); un-framing it meant that no frame would be
shorter than the size of <iframe></iframe>.

> > Sometimes, an iFrame appears further down the document than intended,
> > when two are adjacent.
> > 
> > Alas, iFrame has a minimum height.
> 
> They do not; even iframes with 0px height are possible.
> Use display:block.

While writing the above, it occurred to me that it would be easy
to set the size of the infant iframe to the value of DefaultHeight
provided, and adjust it later if the right height becomes known.
Then, for readers whose browser window is a sensible number of em
units wide, jumping will be replaced by minor hopping.

Thanks.

-- 
  (c) John Stockton, near London, UK.  Using Google, no spell-check. |
 Mail: J.R.""""""""@physics.org                                      |

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

#33404 — Re: Instead of <iframe onload=...

In comp.lang.javascript message <2c839093-3b07-40fc-9cda-7ffd9f92faa9@go
oglegroups.com>, Sun, 21 May 2017 11:46:39, Dr J R Stockton
<J.R.Stockton@physics.org> posted:

> ...

>While writing the above, it occurred to me that it would be easy
>to set the size of the infant iframe to the value of DefaultHeight
>provided, and adjust it later if the right height becomes known.
>Then, for readers whose browser window is a sensible number of em
>units wide, jumping will be replaced by minor hopping.


Yes.  But I have at last realised that this JavaScript re-sizing can
never work under all necessary circumstances.

I want the pages to display well when read (or copied) from a transfer
USB memory stick, using an ordinary PC with only what Windows supplies,
though maybe using another browser instead.  And I'd rather not rely on
it having a UK keyboard, or a keyboard driver that matches the keyboard.

Therefore I cannot rely on using
        Iframe.contentDocument.documentElement.scrollHeight
because when reading from a local drive Chrome, at least, considers that
to be forbidden by the Same Origin Policy.

Therefore I intend, as author, to continue using Firefox, in which the
Same Origin Policy is more sensibly implemented, with "Iframe includes"
and "contentDocument", but with the Iframe height initially being set to
an initially suitable amount.  Provided that the refusal of
contentDocument is silently trapped, that version will be non-ideal but
distributable.

And I have it in mind to write a pre-processor, in Windows Script Host
JavaScript, which will read file ????WXYZ.HTM, read and insert the
includes that it contains, recursively, and write file ????WXYZ.$HTM;
the (MS-DOS Batch) transfer program can easily be persuaded to omit the
"$".

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Merlyn Web Site <                       > - FAQish topics, acronyms, & links.

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

#33360 — Re: Instead of <iframe onload=...

Stefan Weiss wrote:

> Dr J R Stockton wrote:
>> The setTimeout appeared necessary for the frame height needed to be
>> discoverable by Procrustes; perhaps there is a better way.
> 
> I haven't tested any of this, but even if it turns out to be necessary for
> some reason, 500 ms *after* the load event seems a bit excessive. It's not
> that I can't wait for half a second, I just really dislike elements
> jumping around on a page.

I would like to know the layout engine that requires this timeout in the 
first place.
 
>> Sometimes, an iFrame appears further down the document than intended,
>> when two are adjacent.
>> 
>> Alas, iFrame has a minimum height.
> 
> They do not; even iframes with 0px height are possible.

Correct.

> Use display:block.

Unnecessary.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#33361 — Re: Instead of <iframe onload=...

Thomas 'PointedEars' Lahn wrote:
>>> Sometimes, an iFrame appears further down the document than intended,
>>> when two are adjacent.
>>>
>>> Alas, iFrame has a minimum height.
>>
>> They do not; even iframes with 0px height are possible.
> 
> Correct.
> 
>> Use display:block.
> 
> Unnecessary.

For the height of the iframe itself, yes, but the OP also wrote "Sometimes,
an iFrame appears further down the document than intended, when two are
adjacent". Block display can be used to fix that.

- stefan

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

#33362 — Re: Instead of <iframe onload=...

Stefan Weiss wrote:

> Thomas 'PointedEars' Lahn wrote:
>>>> Sometimes, an iFrame appears further down the document than intended,
>>>> when two are adjacent.
>>> Use display:block.
> […] Block display can be used to fix that.

How did you get that idea?

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#33363 — Re: Instead of <iframe onload=...

Thomas 'PointedEars' Lahn wrote:
>>>> Use display:block.
>> […] Block display can be used to fix that.
> 
> How did you get that idea?

That's really none of your business.


- stefan

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web