471,594 Members | 2,655 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,594 software developers and data experts.

TextArea prototype and event listeners

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

Apr 8 '06 #1
8 5394
VK

Csaba Gabor wrote:
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>

Apr 8 '06 #2
VK

VK wrote:
-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.

Apr 8 '06 #3
VK wrote:
VK wrote:
-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.


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_p art
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/...nterpretation1
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

Apr 8 '06 #4
VK

Csaba Gabor wrote:
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.

Apr 8 '06 #5
VK

VK wrote:
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.

Apr 8 '06 #6
VK

Csaba Gabor wrote:
Evidently in version 2 of xbl, the # will not be required. See
http://www.mozilla.org/projects/xbl/...nterpretation1
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.

Apr 8 '06 #7
VK wrote:
Csaba Gabor wrote:
Evidently in version 2 of xbl, the # will not be required. See
http://www.mozilla.org/projects/xbl/...nterpretation1
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?


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

Apr 9 '06 #8
VK

Csaba Gabor wrote:
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.

Apr 9 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Amir Hardon | last post: by
reply views Thread by Kamilche | last post: by
1 post views Thread by Marek Murin | last post: by
4 posts views Thread by reggiestyles | last post: by
2 posts views Thread by meyousikmann | last post: by
56 posts views Thread by ashore | last post: by
reply views Thread by XIAOLAOHU | last post: by
reply views Thread by Anwar ali | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.