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 2 of 2 — ← Prev page 1 [2]

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

Stefan Weiss wrote:

> 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.

Am I to understand that you are not willing to substantiate your statement?

-- 
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]

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

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

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

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

Stefan Weiss wrote:

> 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.

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>

-- 
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]

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

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

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

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

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?

-- 
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]

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

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

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

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

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.

-- 
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]

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

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
    };
  }());
 
-- 
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] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web