TextArea prototype and event listeners

Csaba Gabor · Apr 8, 2006

Is there any way in Mozilla/Firefox to add an event listener to all
textarea elements? Something along the lines of
HTMLTextAreaElement.prototype.onkeydown = function() {alert('mom');}
only it should work, too.

Or is my only solution to loop through each one and use
..addEventListener? And then trap for any DOM modifiactions in case new
ones are created.

Thanks,
Csaba Gabor from Vienna

VK · Apr 8, 2006

Csaba said:
Is there any way in Mozilla/Firefox to add an event listener to all
textarea elements?

Yes, now it is possible for Gesko browsers too, because they support
behaviors:

<html>
<head>
<title>Behavior</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
body {
font: 1em Verdana, sans-serif;
color: #000000;
background-color: #FFFFFF}
form fieldset textarea {
-moz-binding: url(behavior.xml#KeyListener);
/* behavior: url() counterpair for IE left for you */
font: 1em monotype;
}
</style>
</head>

<body

<form action=""
<fieldset><legend>Demo</legend
<textarea name="ta001" cols="50" rows="5"></textarea><br
<textarea name="ta002" cols="50" rows="5"></textarea
</fieldset
</form
</body>

</html>

// behavior.xml

<?xml version="1.0"?>
<bindings xmlns="http://www.mozilla.org/xbl">
<binding id="KeyListener">
<handlers type="text/javascript">
<handler event="keypress" attachto="element">
window.alert(event.which);
</handler>
</handlers>
</binding>
</bindings>

VK · Apr 8, 2006

VK said:
-moz-binding: url(behavior.xml#KeyListener);
/* behavior: url() counterpair for IE left for you */

said "a" say "b"

Here is the full code:

// HTML

<html>
<head>
<title>Behavior</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
body {
font: 1em Verdana, sans-serif;
color: #000000;
background-color: #FFFFFF}
form fieldset textarea {
-moz-binding: url(behavior.xml#KeyListener);
behavior: url(behavior.htc);
font: 1em monotype;
}
</style>
</head>

<body

<form action=""
<fieldset><legend>Demo</legend
<textarea name="ta001" cols="50" rows="5"></textarea><br
<textarea name="ta002" cols="50" rows="5"></textarea
</fieldset
</form
</body>

</html>

// behavior.xml (for Gecko)
<?xml version="1.0"?>
<bindings xmlns="http://www.mozilla.org/xbl">
<binding id="KeyListener">
<handlers type="text/javascript">
<handler event="keypress" attachto="element">
window.alert(event.which);
</handler>
</handlers>
</binding>
</bindings>

// behavior.htc (for IE)
<public:attach event="onkeypress" onevent="KeyListener()" />
<script type="text/Jscript">
function KeyListener() {
window.alert(event.keyCode);
}
</script>

As you can see Mozilla team decided to squeeze behaviors into
pseudo-XML syntax, so the difference between bindings and behaviors may
look spooky on the first look. But you can see that the difference is
really in the used "envelope". Internally it is the same conventional
scripting in both cases - lesser any worries about feature detection
and fall back, because each block is guaranteed to be called by the
intended UA.

Csaba Gabor · Apr 8, 2006

VK said:
said "a" say "b"

Here is the full code:

// HTML

<html>
<head>
<title>Behavior</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
body {
font: 1em Verdana, sans-serif;
color: #000000;
background-color: #FFFFFF}
form fieldset textarea {
-moz-binding: url(behavior.xml#KeyListener);
behavior: url(behavior.htc);
font: 1em monotype;
}
</style>
</head>

<body
</html>

// behavior.xml (for Gecko)
<?xml version="1.0"?>
<bindings xmlns="http://www.mozilla.org/xbl">
<binding id="KeyListener">
<handlers type="text/javascript">
<handler event="keypress" attachto="element">
window.alert(event.which);
</handler>
</handlers>
</binding>
</bindings>

// behavior.htc (for IE)
<public:attach event="onkeypress" onevent="KeyListener()" />
<script type="text/Jscript">
function KeyListener() {
window.alert(event.keyCode);
}
</script>

As you can see Mozilla team decided to squeeze behaviors into
pseudo-XML syntax, so the difference between bindings and behaviors may
look spooky on the first look. But you can see that the difference is
really in the used "envelope". Internally it is the same conventional
scripting in both cases - lesser any worries about feature detection
and fall back, because each block is guaranteed to be called by the
intended UA.

This is fabulous VK, thanks for a very clear, working example.

I have just one issue with it, which is the same thing that bugs me
about IE's approach with the .htc files. I HATE extra files and extra
hits to the server. My immediate goal is to make this work with a
GreaseMonkey script, so it would be VERY useful to have everything in
one file. Unfortunately, I haven't been able to figure out how to make
your example work this way. The problem point is, I think, that '#' in
the url, which just smacks of poor spec design.

Here's what I thought to do: whether I use the CSS version or
document.addBinding(...), a url needs to be specified. So, I thought
to use data: protocol. If I take all the newlines and extra spaces out
of your behavior.xml file and put
data:text/xml,file_content_goes_here_without_trailing_hash_part
into Firefox's location bar, then Firefox is happy with that. However,
this does not fly when I try to insert it into the style sheet.
Indeed, why should it? - the parser goes along reading characters
thinking it's got xml data and then *pow* it hits that invalid #
character. Somehow, it should know that it's got to the end of the
data section. Encoding the # as %23 did not help (nor did putting an
end of file, %19, before it). Same thing goes for trying it as
data:text/html

Evidently in version 2 of xbl, the # will not be required. See
http://www.mozilla.org/projects/xbl/xbl2.html#interpretation1
vs. version 1 at:
http://www.mozilla.org/projects/xbl/xbl.html#attach-css

Can you think of any other approaches for a one file solution till
then?

Csaba

VK · Apr 8, 2006

Csaba said:
I have just one issue with it, which is the same thing that bugs me
about IE's approach with the .htc files. I HATE extra files and extra
hits to the server. My immediate goal is to make this work with a
GreaseMonkey script, so it would be VERY useful to have everything in
one file. Unfortunately, I haven't been able to figure out how to make
your example work this way.

Sorry, I should mention it myself. The hash (#) usage in Gecko bindings
is rather "creative": it doesn't point to (and has no relation to) a
HTML anchor. It points to an id'entified block in the binding file.
This way you can have as many blocks as you want:

<?xml version="1.0"?>
<bindings xmlns="http://www.mozilla.org/xbl">
<binding id="KeyListener">
<handlers type="text/javascript">
<handler event="keypress" attachto="element">
window.alert(event.which);
</handler>
</handlers>
</binding>
<binding id="Welcomer">
<handlers type="text/javascript">
<handler event="keypress" attachto="element">
window.alert('Welcome to Gecko bindings!');
</handler>
</handlers>
</binding>
</bindings>

.... and in your style declarations then:
-moz-binding: url(behavior.xml#KeyListener);
or
-moz-binding: url(behavior.xml#Welcomer);
or both

Overall you may think of any block (KeyListener, Welcomer etc) as an
object constructor. So nothing prevent you to add any amount of needed
code in any clock.

Also it seems to be the old evangelism question of what is better: an
all-in-one file or small reusable chunks one can combine in the needed
way client-side. Actually both behavior models are made holding the
latter for the true. But if you like all-in-one better, then here is
the way.

VK · Apr 8, 2006

VK said:
Sorry, I should mention it myself. The hash (#) usage in Gecko bindings
is rather "creative": it doesn't point to (and has no relation to) a
HTML anchor. It points to an id'entified block in the binding file.
This way you can have as many blocks as you want:

Yet another clarification

Behaviors (aka bindings) are not a kind of WebService or something like
that. I mean if you declare -moz-binding:
url(behavior.xml#KeyListener), it does not mean that the server returns
only KeyListener block. The entire behavior.xml file will be read and
cached in the regular way (unless specially prevented), so next call to
this file will go to the cache, not to the server.

VK · Apr 8, 2006

Csaba said:
Evidently in version 2 of xbl, the # will not be required. See
http://www.mozilla.org/projects/xbl/xbl2.html#interpretation1
vs. version 1 at:
http://www.mozilla.org/projects/xbl/xbl.html#attach-css

Can you think of any other approaches for a one file solution till
then?

Sorry, ignore my two follow-up posts then. I admit I did not get your
question right. I also admit I never used the monkey, so the internal
purpose and mechanics of what you are doing is not totally clear to me.
I guess it is about redefining automatically any loaded page, something
like magicFunction in Opera?

Any way, the task is to place the entire binding's code in url(data)? I
never thought about such twist, but must be some way I guess, just give
me some time

P.S. And yes, I am not happy neither with the hash misuse in XBL 1.0,
you may conclude it from my previous post. To use # in such way -
thusly treat an XML element with id as an anchor - it is too much of
creativity for my taste. I'm glad to hear that Mozilla seems realized
this too.

Csaba Gabor · Apr 9, 2006

VK said:
Sorry, ignore my two follow-up posts then. I admit I did not get your
question right. I also admit I never used the monkey, so the internal
purpose and mechanics of what you are doing is not totally clear to me.
I guess it is about redefining automatically any loaded page, something
like magicFunction in Opera?

GreaseMonkey (GM) allows one to inject arbitrary javascript code into
every (including i/frames) page (that meets certain user specified
criteria) that FF loads. This allows one to customize pages because
this javascript can rewrite the DOM, adding or removing elements, or
simply altering them.

In my case, I wish to alter the behaviour of every single textarea that
I encounter. Each GM script lives in a single file in a special FF
directory. More than one file is really quite awkward. So it makes
sense to get everything into one file. As far as having the behaviour
definition in one long data url, I can always encode a nicer looking
string and stuff it in.

Any way, the task is to place the entire binding's code in url(data)? I
never thought about such twist, but must be some way I guess, just give
me some time

So if you can figure out a way to get around that ugly #, my hat is off
to you.

Csaba

VK · Apr 9, 2006

Csaba said:
So if you can figure out a way to get around that ugly #, my hat is off
to you.

I guess you can keep your hat on. :-(

Here is the deal: XBL URI is not just a source file one could replace
by url(data). It is a pointer to a specific place in a specific file
pointed by that URI. url(data) simply doesn't have this part of URI
mechanics implemented, so no way.

Unfortunately in your particular case (GreeseMonkey) you have to stick
to the ancient way:
var ta = document.getElementsByTagName('TEXTAREA');
for (blah) {blah-blah}

I do not consider this as a default of XBL: it is not a requirement for
a technology to be implementable over url(data) - though could be nice
maybe.

Problems with using event handlers for button and textarea input	1	Nov 29, 2021
cloneNode and iterating event listeners	2	Apr 24, 2006
JavaScript errors trying to add event listeners for onclick() using DOM and AJAX	0	Oct 29, 2007
JavaScript error trying to add event listeners using DOM and AJAX	0	Oct 29, 2007
Safari Textarea and Events	3	Apr 2, 2007
Textarea challenge: caret pos, resultant text	0	Apr 4, 2006
Prototype 1.6--Somebody Stop These People	6	Dec 24, 2009
David Mark's Essential Javascript Tips - Volume #8 - Tip #47E -Attaching and Detaching Event Listene	1	Dec 15, 2011

TextArea prototype and event listeners

Csaba Gabor

VK

VK

Csaba Gabor

VK

VK

VK

Csaba Gabor

VK

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads