HTMLArea 4.0

A replacement for TEXTAREA elements, © 2004-2013 Inferior-Products.com.
InteractiveTools.com, 2003-2004.

Return to the HTMLarea page, or the HTMLarea page hosted on SourceForge.

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.2//EN">
<html>

<head>
<title>Passing parameters to JavaScript code</title>
<link rel="stylesheet" href="custom.css" />
</head>

<body>
<h1>Passing parameters to JavaScript code</h1>

Sometimes we need to pass parameters to some JavaScript function that we
wrote ourselves. But sometimes it's simply more convenient to include the
parameter not in the function call, but in the affected HTML elements.
Usually, all JavaScript calls affect some element, right?

Well, here's an original way to do it. Or at least, I think it's
original.

<h2>But first...</h2>

... an example. Why would I need such thing? I have a JS function that
is called on <code>BODY</code> <code>onload</code> handler. This function
tries to retrieve the element with the ID "conttoc" and, if present, it will
<a href="toc.epl" title="Automatic TOC generation">generate an index</a>.
The problem is, this function exists in some external JavaScript library
that it's loaded in page. I only needed to pass the parameter from one page.
Thus, it makes sense to pass the parameter from the HTML code on
that page, not to affect the others.

The first idea that came to me was to use some attribute, like "id" or
"class". But "id" was locked already, it had to be "conttoc". Use
"class"? It's not elegant. what if I really wanted to give it a class, at some point?

So I thought: what are the HTML elements that do not affect the page
rendering in any way? Well, comments. I mean, comments, HTML
comments. You know, like <code>&lt;!-- this is a comment --&gt;</code>.

Though comments do not normally affect the way browser renders the page,
they are still parsed and are part of the DOM, as well as any other node.
But this mean that we can access comments from JavaScript code, just like we
access any other element, right? Which means that they can affect
the way that page finally appears ;-)

The main part was the idea. The code is simple ;-) Suppose we have the
following HTML code:

<pre class="code">&lt;div id=&quot;conttoc&quot;&gt;&lt;/div&gt;</pre>

and our function checks for the presence an element having the ID
"conttoc", and generates a table of contents into it. Our code will also
check if the "conttoc" element's first child is a comment node, and if so
will parse additional parameters from there, for instance, a desired prefix
for the links that are to be generated into it. Why did I need it? Because
if the page uses a <code>&lt;base&gt;</code> element to specify the default
link prefix, then links like "#gen1" generated by the <a href="toc.epl">toc
generator</a> will not point to that same page as they should, but to the
page reffered from <code>&lt;base&gt;</code>.

So the HTML would now look like this:

<pre class="code">&lt;div id=&quot;conttoc&quot;&gt;&lt;!-- base:link/prefix.html --&gt;&lt;/div&gt;</pre>

And our TOC generation function does something like this:

<pre class="code">var element = getElementById(&quot;conttoc&quot;);
if (element.firstChild &amp;&amp; element.firstChild.nodeType == 8) {
 // 8 means Node.COMMENT_NODE. We're using numeric values
 // because IE6 does not support constant names.
 var parameters = element.firstChild.data;
 // at this point &quot;parameters&quot; contains base:link/prefix.html
 // ...
}</pre>

So we retrieved the value passed to the script from the HTML code. This
was the goal of this article.

<hr />
<address><a href="https://sourceforge.net/users/sf_chris">SF_chris</a></address>
 Last modified on 2013-07-29 18:24:48


</body>
</html>

submit