Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Instead of iframe onload?

61 views
Skip to first unread message

Dr J R Stockton

unread,
May 18, 2017, 8:40:19 AM5/18/17
to
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 |

Evertjan.

unread,
May 18, 2017, 9:08:15 AM5/18/17
to
Dr J R Stockton <J.R.St...@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)

Dr J R Stockton

unread,
May 18, 2017, 11:12:01 AM5/18/17
to
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.

Evertjan.

unread,
May 18, 2017, 12:09:40 PM5/18/17
to
Dr J R Stockton <J.R.St...@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.

Andrew Poulos

unread,
May 18, 2017, 10:36:56 PM5/18/17
to
On 19/05/2017 2:09 AM, Evertjan. wrote:
> Dr J R Stockton <J.R.St...@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

Evertjan.

unread,
May 19, 2017, 3:15:14 AM5/19/17
to
Andrew Poulos <ap_...@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.

Andrew Poulos

unread,
May 19, 2017, 4:12:34 AM5/19/17
to
On 19/05/2017 5:15 PM, Evertjan. wrote:
> Andrew Poulos <ap_...@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

Joao Rodrigues

unread,
May 19, 2017, 5:44:59 AM5/19/17
to
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

Evertjan.

unread,
May 19, 2017, 5:47:49 AM5/19/17
to
Andrew Poulos <ap_...@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.

Martin Honnen

unread,
May 19, 2017, 9:25:22 AM5/19/17
to
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.

Thomas 'PointedEars' Lahn

unread,
May 19, 2017, 12:11:37 PM5/19/17
to
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.

Dr J R Stockton

unread,
May 19, 2017, 5:30:14 PM5/19/17
to
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.

Dr J R Stockton

unread,
May 20, 2017, 6:47:10 PM5/20/17
to
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.St...@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.


Stefan Weiss

unread,
May 20, 2017, 8:10:10 PM5/20/17
to
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

Dr J R Stockton

unread,
May 21, 2017, 2:46:45 PM5/21/17
to
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.

Thomas 'PointedEars' Lahn

unread,
May 21, 2017, 5:22:28 PM5/21/17
to
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.

Stefan Weiss

unread,
May 21, 2017, 6:40:00 PM5/21/17
to
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

Thomas 'PointedEars' Lahn

unread,
May 21, 2017, 7:38:09 PM5/21/17
to
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?

Stefan Weiss

unread,
May 21, 2017, 8:19:26 PM5/21/17
to
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

Thomas 'PointedEars' Lahn

unread,
May 21, 2017, 8:35:31 PM5/21/17
to
Am I to understand that you are not willing to substantiate your statement?

Thomas 'PointedEars' Lahn

unread,
May 21, 2017, 9:27:38 PM5/21/17
to
Dr J R Stockton wrote:

> function Ink(Sauce, DefaultHeight) { var Fram
> […]
> Fram.onload = Inky(Fram, DefaultHeight)
^^^^^
> […]
> function Inky(Ifr, ExHi) {
> // Autosize works in Firefox and MS IE (Edge?), else use ExHi
> setTimeout(function() { Procrustes(Ifr, ExHi) } , 500) }

[Unusual, highly questionable code style aside:]

JFTR, this is a common mistake. This way the function Inky() would be
called *before* the assignment to the “onload” property, and the “onload”
property would be assigned the “undefined” value when either the “null”
value or a reference to a Function instance is expected. Such an assignment
would result in a runtime error in earlier versions of Internet Explorer;
later versions might have a setter for that property to ignore it and to
keep the default “null” property value.

It is therefore unsurprising to me that the timeout delay would have to be
set that high (500 ms) as calling Inky() does _not_ correspond with loading
the iframe document.

Perhaps the following was sought for instead:

iframe.onload = function () {
inky(this, defaultHeight);
};

However, usually one would wrap the iframe object into a custom object with
appropriate initialization and methods instead of global functions (OOP:
encapsulation, information hiding). For example (quick hack):

/* @namespace */
var JRS = (function () {
"use strict";

/* @constructor */
function _IframeWidget (target, source)
{
if (!(this instanceof _IframeWidget))
{
return new _IframeWidget(target, source);
}

this.target = target || document.createElement("iframe");

Object.assign(this.target.style, {
border: "2px solid red",
width: "100%",
margin: "0.5ex 0",
background: "#FFE"
});

this.target.onload = function () {
this.procrustes();
}.bind(this);

if (!target) document.body.appendChild(this.target);

this.target.src = source;
}

Object.assign(_IFrameWidget.prototype, {
/* @memberOf JRS.IFrameWidget.prototype */
defaultHeight: …,

procrustes: function (exHi) {
// … this.target.contentDocument …
}
});

Object.defineProperty(_IFrameWidget.prototype, "constructor", {
/* @memberOf JRS.IFrameWidget.prototype */
value: _IFrameWidget
});

return {
/* @memberOf JRS */
IframeWidget: _IFrameWidget
};
}());

Stefan Weiss

unread,
May 22, 2017, 6:54:21 AM5/22/17
to
Thomas 'PointedEars' Lahn wrote:
>>>> […] Block display can be used to fix that.
>>> How did you get that idea?
>>
>> That's really none of your business.
>
> Am I to understand that you are not willing to substantiate your statement?

If you have a different opinion or concrete criticism just post it, and I
will probably reply, but I'm not wasting my time answering silly questions.


- stefan

Thomas 'PointedEars' Lahn

unread,
May 22, 2017, 9:37:27 AM5/22/17
to
I do not think that demanding a rationale for someone’s contention is silly,
particularly if technical matters are concerned.

However, I think that you are committing the fallacy of shifting the burden
of proof, and that the evasion that apparently is to facilitate it could be
characterized as being silly.

See also: <https://yourlogicalfallacyis.com/burden-of-proof>

Stefan Weiss

unread,
May 22, 2017, 12:23:59 PM5/22/17
to
Thomas 'PointedEars' Lahn wrote:
>> If you have a different opinion or concrete criticism just post it, and I
>> will probably reply, but I'm not wasting my time answering silly
>> questions.
>
> I do not think that demanding a rationale for someone’s contention is silly,
> particularly if technical matters are concerned.
>
> However, I think that you are committing the fallacy of shifting the burden
> of proof, and that the evasion that apparently is to facilitate it could be
> characterized as being silly.

I'm not playing this game with you. You don't want to say what exactly it is
you're disagreeing with, fine by me. Go and find someone else to annoy.


- stefan

Thomas 'PointedEars' Lahn

unread,
May 23, 2017, 8:15:11 AM5/23/17
to
Stefan Weiss wrote:

> Thomas 'PointedEars' Lahn wrote:
>>> If you have a different opinion or concrete criticism just post it, and
>>> I will probably reply, but I'm not wasting my time answering silly
>>> questions.
>>
>> I do not think that demanding a rationale for someone’s contention is
>> silly, particularly if technical matters are concerned.
>>
>> However, I think that you are committing the fallacy of shifting the
>> burden of proof, and that the evasion that apparently is to facilitate it
>> could be characterized as being silly.
>
> I'm not playing this game with you.

This is not a game. It my the attempt to have a constructive discussion
which you that *you* are rejecting.

> You don't want to say what exactly it is you're disagreeing with,

No, because *you* made the claim; *you* carry the burden of proof. This
is a core principle of a *constructive* discussion, and I find it hard to
understand why you find that so hard to understand.

> fine by me. Go and find someone else to annoy.

Ask yourself this: If you have a *valid* reason for making that suggestion,
why are you not just laying it out? Why are you *annoyed* if you are asked
about it?

Thomas 'PointedEars' Lahn

unread,
May 23, 2017, 8:15:33 AM5/23/17
to
Stefan Weiss wrote:

> Thomas 'PointedEars' Lahn wrote:
>>> If you have a different opinion or concrete criticism just post it, and
>>> I will probably reply, but I'm not wasting my time answering silly
>>> questions.
>>
>> I do not think that demanding a rationale for someone’s contention is
>> silly, particularly if technical matters are concerned.
>>
>> However, I think that you are committing the fallacy of shifting the
>> burden of proof, and that the evasion that apparently is to facilitate it
>> could be characterized as being silly.
>
> I'm not playing this game with you.

This is not a game. It is my attempt to have a *constructive* discussion
which you that *you* are *rejecting*.

> You don't want to say what exactly it is you're disagreeing with,

No, because *you* made the claim; *you* carry the burden of proof. This
is a core principle of a *constructive* discussion, and I find it hard to
understand why you find that so hard to understand.

> fine by me. Go and find someone else to annoy.

Ask yourself this: If you have a *valid* reason for making that suggestion,
why are you not just laying it out? Why are you *annoyed* if you are asked
about it?

Stefan Weiss

unread,
May 23, 2017, 9:56:27 AM5/23/17
to
Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>>> If you have a different opinion or concrete criticism just post it, and
>>>> I will probably reply, but I'm not wasting my time answering silly
>>>> questions.
>>>
>>> I do not think that demanding a rationale for someone’s contention is
>>> silly, particularly if technical matters are concerned.
>>>
>>> However, I think that you are committing the fallacy of shifting the
>>> burden of proof, and that the evasion that apparently is to facilitate it
>>> could be characterized as being silly.
>>
>> I'm not playing this game with you.
>
> This is not a game. It is my attempt to have a *constructive* discussion
> which you that *you* are *rejecting*.

Sheesh, calm down. If it means so much to you, I'll play along.

>> You don't want to say what exactly it is you're disagreeing with,
>
> No, because *you* made the claim; *you* carry the burden of proof. This
> is a core principle of a *constructive* discussion, and I find it hard to
> understand why you find that so hard to understand.

This is how this thread presents itself to me (paraphrased):

JS: (A) Sometimes, an iFrame appears further down the document than
intended, when two are adjacent.
(B) iFrame has a minimum height

SW: (C) No minimum height for iframes.
(D) Use display:block.

TL: C is right, D is unnecessary.

SW: D actually refers to A and can fix it.

TL: Wrooong, but I'm not telling why.

SW: Not playing with you.

TL: Please?

SW: No.

TL: Pretty please?

SW: No.

TL: But this is really serious, you must provide proof!

If this is not how you wanted your posts to come across, you should work on
your communication skills.

I think it's ridiculous to try and transform a thread about a minor display
problem into a formal academic argument and demand rigorous logical proof.
But since you seem really invested in this, I'll indulge you in the hope
that you'll finally stop bugging me.

I only have to find one single situation where (D) solves (A). Neither of us
knows anything about the original markup involved, so here's something simple:

<!DOCTYPE html>
<html>
<head>
<title>PointyFrames</title>
<style>
* { box-sizing: border-box }
div {
border: 6px solid blue;
width: 150px;
}
iframe {
/*display: block;*/
border: 6px solid red;
width: 100%;
}
</style>
</head>
<body>
<div>
<iframe src="about:blank"></iframe>
<iframe src="about:blank"></iframe>
</div>
</body>
</html>

Without display:block, there is vertical space between the iframes; with
display:block, the space disappears. QED.

This is not an uncommon situation in web design, which is why I suggested
display:block as a possible solution even without having seen the source
document. There are several other ways to solve it, but that's irrelevant.

>> fine by me. Go and find someone else to annoy.
>
> Ask yourself this: If you have a *valid* reason for making that suggestion,
> why are you not just laying it out? Why are you *annoyed* if you are asked
> about it?

The paraphrased summary above should make it clear to you why I'm getting a
little annoyed. You demand all kinds of "proofs" from people in this group,
but you rarely volunteer information on your own. You won't even say what
you're taking issue with, instead you post disparaging and cryptic comments
like "Nonsense" or "You don't know what you're talking about" or "How did
you get that idea". Then you swoop in and *demand* proofs and pretend that
you're interested in a constructive discussion, rather than showing off and
criticizing others. I have seen this from you so many times that I have to
assume it's your little game. If this is not a game, then it's probably a
symptom.


- stefan

Thomas 'PointedEars' Lahn

unread,
May 23, 2017, 12:41:41 PM5/23/17
to
Stefan Weiss wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> You don't want to say what exactly it is you're disagreeing with,
>> No, because *you* made the claim; *you* carry the burden of proof. This
>> is a core principle of a *constructive* discussion, and I find it hard to
>> understand why you find that so hard to understand.
>
> This is how this thread presents itself to me (paraphrased):
>
> JS: (A) Sometimes, an iFrame appears further down the document than
^^^^^^
> intended, when two are adjacent.
^^^^^^^^
> (B) iFrame has a minimum height
>
> SW: (C) No minimum height for iframes.
> (D) Use display:block.
>
> TL: C is right, D is unnecessary.
>
> SW: D actually refers to A and can fix it.
>
> TL: Wrooong, but I'm not telling why.

Straw man. That is _not_ what I said in that follow-up. Not even remotely.

> I only have to find one single situation where (D) solves (A).

Before one suggests a solution D for a problem A, one must first properly
identify the problem A. Otherwise D can fall short of solving A and can
even introduce more problems.

From your answer one can see that you assume that problem A is that there
are *consecutive* *iframe elements in the source code* *formatted to 100 %
width* so that they are vertically arranged. For that case I concur:
Setting “display: block” on those iframe elements (setting it on the first
iframe element suffices) apparently solves the problem of *vertical* spacing
between the “IFrames” (if the margins are 0) *and* has no obvious side
effects.

But the OP said “adjacent iFrame”; that can be interpreted in other ways,
too.

I still think the most straightforward interpretation here is the
*rendering*, _not_ the source code. Because the OP was referring to
“adjacent IFrames”, not “consecutive iframe elements”.

So it would be equally possible that the “IFrames” are supposed to appear
*next to each other* and that this sometimes does not happen. Setting
“display: block” on any iframe element then has the disadvantage that the
iframes are arranged vertically, which might not be what is wanted.

There is a general solution that addresses both interpretations:
Set “display: block” *and* “float: left”. One might even need to set the
“width” property explicitly.


I can see now that the OP sets “width: 100%” on some of their dynamically
inserted iframes. This gives support to, but does not necessitate, your
interpretation that *all* iframes are to be arranged vertically, and your
idea that “display: block” would solve the spacing problem without side
effect.

Dr J R Stockton

unread,
May 24, 2017, 6:42:42 PM5/24/17
to
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.St...@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
"$".
0 new messages