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


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

Adding section into page

Started byDr J R Stockton <reply1700@merlyn.demon.co.uk.invalid>
First post2017-01-21 23:36 +0000
Last post2017-01-23 08:50 -0800
Articles 16 — 7 participants

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


Contents

  Adding section into page Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> - 2017-01-21 23:36 +0000
    Re: Adding section into page "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-01-22 00:47 +0100
    Re: Adding section into page Doc O'Leary  <droleary@2015usenet1.subsume.com> - 2017-01-22 15:38 +0000
      Re: Adding section into page Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> - 2017-01-23 23:39 +0000
        Re: Adding section into page "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-01-23 17:37 -0800
          Re: Adding section into page "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-01-23 17:38 -0800
        Re: Adding section into page Doc O'Leary  <droleary@2015usenet1.subsume.com> - 2017-01-24 02:54 +0000
          Re: Adding section into page Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2017-01-24 21:33 +0100
        Re: Adding section into page Dr J R Stockton <J.R.Stockton@physics.org> - 2017-01-25 14:30 -0800
          Re: Adding section into page "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-01-25 17:51 -0800
            Re: Adding section into page Dr J R Stockton <J.R.Stockton@physics.org> - 2017-01-26 04:17 -0800
              Re: Adding section into page "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-01-26 14:16 +0100
                Re: Adding section into page Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> - 2017-01-27 22:33 +0000
              Re: Adding section into page "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-01-27 06:34 -0800
    Re: Adding section into page "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-01-22 10:52 -0800
      Re: Adding section into page Ram Tobolski <ramtob@gmail.com> - 2017-01-23 08:50 -0800

#32245 — Adding section into page

FromDr J R Stockton <reply1700@merlyn.demon.co.uk.invalid>
Date2017-01-21 23:36 +0000
SubjectAdding section into page
Message-ID<BJhJnbcqB$gYFwL8@invalid.uk.co.demon.merlyn.invalid>
I have some HTML pages and some HTML sub-pages.  The sub-pages can be
read independently by me as author, but their purpose is to be
incorporated variously into the pages at or shortly after page-load time.

At present, because I know how, I have been reading the sub-pages into
Iframes constructed in HTML, and manually setting the value of the
height of each Iframe.  And I have been setting some of the individual
heights by using code like

  setTimeout('Fram.style.height = Fram.contentDocument.documentElement.scrollHeight+"px"', Wate)

for each instance, but it is cumbersome and inelegant.
Using   Fram.onload   would presumably be better.

How should it be done nowadays, for current and recent systems?
Is there something better than an Iframe?
An in-line HTML Include, for example?

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

[toc] | [next] | [standalone]


#32246

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2017-01-22 00:47 +0100
Message-ID<XnsA7058040239Eeejj99@194.109.6.166>
In reply to#32245
Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> wrote on 22 Jan
2017 in comp.lang.javascript: 

> I have some HTML pages and some HTML sub-pages.  The sub-pages can be
> read independently by me as author, but their purpose is to be
> incorporated variously into the pages at or shortly after page-load
> time. 
> 
> At present, because I know how, I have been reading the sub-pages into
> Iframes constructed in HTML, and manually setting the value of the
> height of each Iframe.  And I have been setting some of the individual
> heights by using code like
> 
>   setTimeout('Fram.style.height =
>   Fram.contentDocument.documentElement.scrollHeight+"px"', Wate) 
> 
> for each instance, but it is cumbersome and inelegant.
> Using   Fram.onload   would presumably be better.
> 
> How should it be done nowadays, for current and recent systems?
> Is there something better than an Iframe?
> An in-line HTML Include, for example?

Use serverside includes.


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

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


#32253

FromDoc O'Leary <droleary@2015usenet1.subsume.com>
Date2017-01-22 15:38 +0000
Message-ID<o62jm4$kks$1@dont-email.me>
In reply to#32245
For your reference, records indicate that 
Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> wrote:

> I have some HTML pages and some HTML sub-pages.  The sub-pages can be
> read independently by me as author, but their purpose is to be
> incorporated variously into the pages at or shortly after page-load time.

I wanted to do something similar for my blog (impossiblystupid.com).  
What I ended up doing was still using an iframe to load the other pages, 
but then taking the desired elements from the contentDocument and moving 
them to a “local” layout in the DOM.

-- 
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

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


#32282

FromDr J R Stockton <reply1700@merlyn.demon.co.uk.invalid>
Date2017-01-23 23:39 +0000
Message-ID<kC3wFKr3QphYFwHG@invalid.uk.co.demon.merlyn.invalid>
In reply to#32253
In comp.lang.javascript message <o62jm4$kks$1@dont-email.me>, Sun, 22
Jan 2017 15:38:45, Doc O'Leary <droleary@2015usenet1.subsume.com>
posted:

>For your reference, records indicate that
>Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> wrote:
>
>> I have some HTML pages and some HTML sub-pages.  The sub-pages can be
>> read independently by me as author, but their purpose is to be
>> incorporated variously into the pages at or shortly after page-load time.
>
>I wanted to do something similar for my blog (impossiblystupid.com).
>What I ended up doing was still using an iframe to load the other pages,
>but then taking the desired elements from the contentDocument and moving
>them to a “local” layout in the DOM.

Thanks for all replies.

This is a local application, mainly run from directly from the local
hard disc, although it should also be usable when run from a Web server.


My present idea is to write, in the HTML of a page wherever an insertion
is to appear,
        <div class=HTM id=filename>Fail 263</div> ,
which initially should have the effect of <br> .
I will then include in the <body onload="..."> string 'Includer();'.
I will then, in the communal file loaded by
        <script type="text/javascript" src="inc-cmmn.js"></script> ,
write a function Includer which will
        Scan the as-loaded page for elements of class HTM and
          for each of them, El, use DOM methods to do
            Create in var Ifr an invisible Iframe
            Do Ifr.onload = XXX ;
            Do Ifr.src=El.id + "htm" .
Function XXX will get the body of the content of Ifr and move it into
the document as a DOM sub-tree within the aforesaid div element instead
of "Fail 263", then exit.

Something like that might serve, if it can be made to work.


ASIDE : can code executed from within a script element in the body of a
        page obtain a reference to the script element itself or to an
        adjacent element in the DOM tree, or similar?


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

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


#32284

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2017-01-23 17:37 -0800
Message-ID<1956ce83-02d4-4386-8b54-6eacb0ceef3a@googlegroups.com>
In reply to#32282
Dr J R Stockton wrote:
> 
> ASIDE : can code executed from within a script element in the body of a
>         page obtain a reference to the script element itself or to an
>         adjacent element in the DOM tree, or similar?


document.currentScript should suffice:

<https://developer.mozilla.org/en-US/docs/Web/API/Document/currentScript>

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


#32285

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2017-01-23 17:38 -0800
Message-ID<1955628f-81e6-4b54-b56f-1b3613c56030@googlegroups.com>
In reply to#32284
On Monday, January 23, 2017 at 7:37:43 PM UTC-6, Michael Haufe (TNO) wrote:
> Dr J R Stockton wrote:
> > 
> > ASIDE : can code executed from within a script element in the body of a
> >         page obtain a reference to the script element itself or to an
> >         adjacent element in the DOM tree, or similar?
> 
> 
> document.currentScript should suffice:
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/Document/currentScript>

I spoke too soon and forgot about IE...


   var currentScript = document.currentScript || (function() {
      var scripts = document.getElementsByTagName('script');
      return scripts[scripts.length - 1];
    })();

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


#32286

FromDoc O'Leary <droleary@2015usenet1.subsume.com>
Date2017-01-24 02:54 +0000
Message-ID<o66fl1$oro$1@dont-email.me>
In reply to#32282
For your reference, records indicate that 
Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> wrote:

> ASIDE : can code executed from within a script element in the body of a
>         page obtain a reference to the script element itself or to an
>         adjacent element in the DOM tree, or similar?

document.currentScript will get you the element of the currently 
executing script.

-- 
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

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


#32309

FromCezary Tomczyk <cezary.tomczyk@gmail.com>
Date2017-01-24 21:33 +0100
Message-ID<o68dn3$odj$1@csiph.com>
In reply to#32286
On 24/01/2017 03:54, Doc O'Leary wrote:
> For your reference, records indicate that
> Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> wrote:
>
>> ASIDE : can code executed from within a script element in the body of a
>>         page obtain a reference to the script element itself or to an
>>         adjacent element in the DOM tree, or similar?
>
> document.currentScript will get you the element of the currently
> executing script.

With some exceptions based on 
http://caniuse.com/#search=document.currentScript

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/
https://www.aslint.org/ - Accessibility linting tool

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


#32347

FromDr J R Stockton <J.R.Stockton@physics.org>
Date2017-01-25 14:30 -0800
Message-ID<927fba05-644b-4fae-a2e7-d956b09e4324@googlegroups.com>
In reply to#32282
On Monday, January 23, 2017 at 11:45:49 PM UTC, Dr J R Stockton wrote:

> Function XXX will get the body of the content of Ifr and move it into
> the document as a DOM sub-tree within the aforesaid div element instead
> of "Fail 263", then exit.
> 
> Something like that might serve, if it can be made to work.

The rest of the job I can do, since for that I can use parts of other
pages of mine, adjusted.

For the moment, in lieu of function XXX, I load a static IFRAME
with src file, written in HTML.  Then I use

function MoveIframeContent() {
  var SRC = document.getElementById("Ifr")
  var Branch = SRC.contentDocument.body
  var Unto = document.getElementById("filename")
  Unto.appendChild(Branch) // OK for test
  }

to *transfer* the content of the IFRAME to a static DIV,
appendChild being the first helpful method that came to mind.

It works in Firefox and in MSIE, but not in Opera Chrome
and Vivaldi, in which no transfer occurs.  It might
work in those three if I were using a Web server
rather than reading files directly from disc, which
is how the HTML will mostly be used.  I should have
remembered that the same applies to my local links checker -
evidently it is because of over-zealous misapplication of
the Same Origin Policy.  I assume that I cannot work round
that using only script on the importing page.

So, perhaps, 

  <iframe style="width:100%;"
    src="rhubarb.htm" onload="Procrustes(this)">
    Fail 547
    </iframe>

with something like
  function Procrustes(Ifr) {
    Ifr.style.height = Ifr.contentDocument.documentElement.scrollHeight+"px"
    }

Comment?  In Windows XP pro sp3, it works in Firefox 50.1.0
and MS IE 8, but does not re-size in Chrome 49.0 or Opera 36.
Can that be remedied (I suspect not)?

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

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


#32350

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2017-01-25 17:51 -0800
Message-ID<a21ab072-0975-4fbb-ba84-85870a016bbd@googlegroups.com>
In reply to#32347
On Wednesday, January 25, 2017 at 4:30:14 PM UTC-6, Dr J R Stockton wrote:
> On Monday, January 23, 2017 at 11:45:49 PM UTC, Dr J R Stockton wrote:
> 
> > Function XXX will get the body of the content of Ifr and move it into
> > the document as a DOM sub-tree within the aforesaid div element instead
> > of "Fail 263", then exit.
> > 
> > Something like that might serve, if it can be made to work.
> 
> The rest of the job I can do, since for that I can use parts of other
> pages of mine, adjusted.
> 
> For the moment, in lieu of function XXX, I load a static IFRAME
> with src file, written in HTML.  Then I use
> 
> function MoveIframeContent() {
>   var SRC = document.getElementById("Ifr")
>   var Branch = SRC.contentDocument.body
>   var Unto = document.getElementById("filename")
>   Unto.appendChild(Branch) // OK for test
>   }
> 
> to *transfer* the content of the IFRAME to a static DIV,
> appendChild being the first helpful method that came to mind.
> 
> It works in Firefox and in MSIE, but not in Opera Chrome
> and Vivaldi, in which no transfer occurs.  It might
> work in those three if I were using a Web server
> rather than reading files directly from disc, which
> is how the HTML will mostly be used.  I should have
> remembered that the same applies to my local links checker -
> evidently it is because of over-zealous misapplication of
> the Same Origin Policy.  I assume that I cannot work round
> that using only script on the importing page.
> 
> So, perhaps, 
> 
>   <iframe style="width:100%;"
>     src="rhubarb.htm" onload="Procrustes(this)">
>     Fail 547
>     </iframe>
> 
> with something like
>   function Procrustes(Ifr) {
>     Ifr.style.height = Ifr.contentDocument.documentElement.scrollHeight+"px"
>     }
> 
> Comment?  In Windows XP pro sp3, it works in Firefox 50.1.0
> and MS IE 8, but does not re-size in Chrome 49.0 or Opera 36.
> Can that be remedied (I suspect not)?

Was my earlier solution not appropriate?

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


#32355

FromDr J R Stockton <J.R.Stockton@physics.org>
Date2017-01-26 04:17 -0800
Message-ID<07446f51-fee3-4c36-bce8-8c3cba04a3b5@googlegroups.com>
In reply to#32350
On Thursday, January 26, 2017 at 1:51:20 AM UTC, Michael Haufe (TNO) wrote:
 
> Was my earlier solution not appropriate?

That will be the article linking to <http://codepen.io/mlhaufe/pen/EZmRXL> .

It appeared to require use of the Internet at page display time.

The page _must_ work, in WinXP, Win7, and Win10, and with any GUI browser
or O.S. that I may have, and hopefully on any system that can display an
HTML Web page.

It _must_ work on a computer that has NO Internet access, and also as an
ordinary Web page.

However, the re-sizing is a convenience; I can size the Iframes automatically
with Procrustes on my favourite browser, and on other browsers it is acceptable
to have the size only about right, since the Iframe can have a scroll-bar.


In WinXP sp3 with Firefox, and in Win10 with Edge, I cannot observe that your
Codepen page actually resizes any Iframes.


- - - - 

In that local page, I have

 <iframe ID=JRSO src="johnonly.htm"
  style="width:100%; height: 452ex; background:#DFF; margin-top: 1ex;">
  </iframe>

Now johnonly.htm has private stuff, and therefore the batch file which
transfers my files to elsewhere may include
    copy X:\not-john.htm Y:\johnonly.htm
and not-john.htm contains little but, in script,

    this.parent.document.getElementById('JRSO').style.display = 'none'

That vanishes the Iframe in some browsers.  Can it be improved, perhaps by removing the Iframe from the DOM tree?  Maybe not this ...

    this.parentNode.removeChild(this) ?????


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

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


#32356

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2017-01-26 14:16 +0100
Message-ID<XnsA709912539A35eejj99@194.109.6.166>
In reply to#32355
Dr J R Stockton <J.R.Stockton@physics.org> wrote on 26 Jan 2017 in
comp.lang.javascript: 

> It _must_ work on a computer that has NO Internet access, and also as an
> ordinary Web page.
> 
> However, the re-sizing is a convenience; I can size the Iframes
> automatically with Procrustes on my favourite browser, and on other
> browsers it is acceptable to have the size only about right, since the
> Iframe can have a scroll-bar. 
> 
> 
> In WinXP sp3 with Firefox, and in Win10 with Edge, I cannot observe that
> your Codepen page actually resizes any Iframes.

Could you redefine your Q?

If it means you want to execution-time concatenate text-files to a .html 
file, there are some excellent ideas here:

<http://superuser.com/questions/111825/a-command-line-or-batch-cmd-to-
concatenate-multiple-files>

So you could make a batch or a cscript command that starts executing the 
finished product.

===========

Earlier I thought it was just about executing multiple js-files, 
and could act like this:

<script src="myscript1.js"></script>
<script src="myscript2.js"></script>
<script src="myscript3.js"></script>


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

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


#32391

FromDr J R Stockton <reply1700@merlyn.demon.co.uk.invalid>
Date2017-01-27 22:33 +0000
Message-ID<sp2CfCQ8q8iYFwMT@invalid.uk.co.demon.merlyn.invalid>
In reply to#32356
In comp.lang.javascript message <XnsA709912539A35eejj99@194.109.6.166>,
Thu, 26 Jan 2017 14:16:06, Evertjan. <exxjxw.hannivoort@inter.nl.net>
posted:

>If it means you want to execution-time concatenate text-files to a .html
>file, there are some excellent ideas here:
>
><http://superuser.com/questions/111825/a-command-line-or-batch-cmd-to-concatenate-multiple-files>
>
>So you could make a batch or a cscript command that starts executing the
>finished product.

No.

Having "local" pages which, whenever edited, are [partially] copied by
CScript JavaScript to provide the distributable page set would of course
work, but I'm trying to avoid the necessary effort.

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

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


#32382

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2017-01-27 06:34 -0800
Message-ID<c15ac816-24fc-43e2-a530-862e00118117@googlegroups.com>
In reply to#32355
On Thursday, January 26, 2017 at 6:18:03 AM UTC-6, Dr J R Stockton wrote:
> On Thursday, January 26, 2017 at 1:51:20 AM UTC, Michael Haufe (TNO) wrote:
>  
> > Was my earlier solution not appropriate?
> 
> That will be the article linking to <http://codepen.io/mlhaufe/pen/EZmRXL> .
> 
> It appeared to require use of the Internet at page display time.

For a remote url, yes

> The page _must_ work, in WinXP, Win7, and Win10, and with any GUI browser
> or O.S. that I may have, and hopefully on any system that can display an
> HTML Web page.

My example supports IE10+ If you want to support older browsers then change the responseType to 'text' and set the innerHTML appropriately 

> It _must_ work on a computer that has NO Internet access, and also as an
> ordinary Web page.

XHR will work on relative paths

> However, the re-sizing is a convenience; I can size the Iframes automatically
> with Procrustes on my favourite browser, and on other browsers it is acceptable
> to have the size only about right, since the Iframe can have a scroll-bar.

And unnecessary with an approach like the above

> In WinXP sp3 with Firefox, and in Win10 with Edge, I cannot observe that your
> Codepen page actually resizes any Iframes.

Given that it doesn't use or depend on <iframe /> that's no surprise

> In that local page, I have
> 
>  <iframe ID=JRSO src="johnonly.htm"
>   style="width:100%; height: 452ex; background:#DFF; margin-top: 1ex;">
>   </iframe>
> 
> Now johnonly.htm has private stuff, and therefore the batch file which
> transfers my files to elsewhere may include
>     copy X:\not-john.htm Y:\johnonly.htm
> and not-john.htm contains little but, in script,
> 
>     this.parent.document.getElementById('JRSO').style.display = 'none'
> 
> That vanishes the Iframe in some browsers.  Can it be improved, perhaps by removing the Iframe from the DOM tree?  Maybe not this ...
> 
>     this.parentNode.removeChild(this) ?????

Or... don't use an iframe to include your html

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


#32255

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2017-01-22 10:52 -0800
Message-ID<66a60035-77ff-4b45-9673-ce694522bc86@googlegroups.com>
In reply to#32245
Dr J R Stockton wrote:
> I have some HTML pages and some HTML sub-pages.  The sub-pages can be
> read independently by me as author, but their purpose is to be
> incorporated variously into the pages at or shortly after page-load time.
> 
> At present, because I know how, I have been reading the sub-pages into
> Iframes constructed in HTML, and manually setting the value of the
> height of each Iframe.  And I have been setting some of the individual
> heights by using code like
> 
>   setTimeout('Fram.style.height = Fram.contentDocument.documentElement.scrollHeight+"px"', Wate)
> 
> for each instance, but it is cumbersome and inelegant.
> Using   Fram.onload   would presumably be better.
> 
> How should it be done nowadays, for current and recent systems?
> Is there something better than an Iframe?
> An in-line HTML Include, for example?

Sadly this is still a pain in the client.

There is/was HTML imports [1] but Mozilla [2] and others [3] have decided to not go in that direction. Primarily due to the incompatibility and duplication with ES6 imports.

An alternative for a client based solution would be an XHR Request with the new responseType="document".

I threw together a quick example of usage here:

<http://codepen.io/mlhaufe/pen/EZmRXL>

Code below:

HTML
*****
<div data-x-src="http://example.com"></div>

<div data-x-src="http://example.org"></div>

<div data-x-src="http://example.net"></div>

CSS
*****

div {
  width: 640px;
  height: 120px;
  border:1px solid black;
  margin-bottom: 1em;
  overflow: auto;
}

JS
*****
function qsa(s,ctx){
  return Array.from((ctx||document).querySelectorAll(s))
}

function loadSource(container){
  var src = container.getAttribute('data-x-src')
  var xhr = new XMLHttpRequest();
  xhr.open('GET', src, true);
  xhr.responseType = 'document';
  xhr.onload = function(e) {
    var doc = e.target.response;
    container.innerHTML = doc.body.innerHTML
  }
  xhr.send();
}

qsa('[data-x-src]').forEach(loadSource)

**************

Polyfill as required for your audience.


[1] <http://w3c.github.io/webcomponents/spec/imports/#link-type-import>
[2] <https://hacks.mozilla.org/2014/12/mozilla-and-web-components/>
[3] <http://caniuse.com/#feat=imports>

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


#32270

FromRam Tobolski <ramtob@gmail.com>
Date2017-01-23 08:50 -0800
Message-ID<ce27641d-e071-4723-856e-19e7ce2b8927@googlegroups.com>
In reply to#32255
+1

[toc] | [prev] | [standalone]


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


csiph-web