Two months after putting 1.6.0 RC0 out in the wild, we’ve fixed a handful of bugs and made some changes to the Class and Event APIs in response to your feedback. We’ve also addressed a long-standing issue with the Hash class. These changes are now available for download in our second release candidate, Prototype 1.6.0 RC1. Keep reading for a detailed description of the changes, some of which are incompatible with previous versions of Prototype.

Changes to the Class API

The changes to the class API introduced in [7833] are a result of feedback we’ve gotten from 1.6.0_rc0, and of numerous lengthy internal debates. Our goal was to improve the clarity of the API as well as pave the way for features that may make their way into future versions of Prototype.

To that end, we’ve eliminated the Class.extend and Class.mixin methods, improved the Class.create syntax, and changed the way you add methods to existing classes. The API is still backwards-compatible with all pre-1.6 versions of Prototype. We haven’t changed the way inheritance works, and you still access superclass methods using the special $super argument.

The biggest change is that all classes (as in the objects returned by Class.create(), not instances of those objects) now have a method named “addMethods.” This method takes a single argument, an object whose properties become instance methods and properties for all instances of the class.

For example, in 1.6.0_rc0, where you’d write:

var Foo = Class.create();
Class.extend(Foo, { /* instance methods */ });

We’ve changed this so you now write:

var Foo = Class.create();
Foo.addMethods({ /* instance methods */ });

As in 1.6.0_rc0, you can still add instance methods directly from Class.create:

var Foo = Class.create({ /* instance methods */ });

Also unchanged from 1.6.0_rc0, you can inherit from a superclass by passing the class as the first argument to Class.create (and you can optionally specify instance methods afterwards):

var Bar = Class.create(Foo);
var Baz = Class.create(Foo, { /* instance methods */ });

Internally, Prototype calls addMethods on the newly created class to add instance methods passed to Class.create.

Finally, we’ve modified Class.create to take a variable number of arguments, so you can now specify multiple collections of instance methods to add to the class, in order. This is useful for adding mixins to the class before defining your own methods:

var Bar = Class.create(Foo, Enumerable, SomeMixin, { /* instance methods */ });
var Baz = Class.create(Enumerable, { /* instance methods */ });

Hop to our “Learn” section for a full-length tutorial on classes and inheritance in Prototype.

Changes to the Event API

A small but important change was made to custom events in [7835]: all custom event names must now include a namespace. This is our solution to the problem of custom event names conflicting with non-standard native DOM events, such as “mousewheel” and “DOMMouseScroll.”

Prior to this change, Prototype treated only the event names present in the Event.DOMEvents array as native DOM events. Now, Prototype looks for the presence of the namespace delimiter—a single colon—to determine whether you’re observing a custom event or a native event.

You’ll need to update any code that uses 1.6.0_rc0’s “contentloaded” event to use its new name, “dom:loaded.” You’ll also need to give namespaces to any other custom events you may be firing or observing. We suggest using singular nouns for namespaces, and past-tense verbs for the event names (e.g. “effect:queued”, “widget:activated”, and so on).

We also fixed a minor annoyance for users still using inline event handling in their code: they were unable to stop event propagation with Event.stop(e) in IE because the event object was not extended. Now, Event.stop and Event.element extend the given event object automatically and work as expected even with inline event handling. Note that inline event handlers are still strongly discouraged; you should upgrade your code to use Event.observe or Element#observe methods, where possible.

Complete rewrite of the Hash class

Backwards compatibility change – Although it serves the same purpose as before, the new version of Hash is not compatible with the Hash class in previous versions of Prototype.

Hash properties are now hidden away in a private store to prevent the risk of collision with Hash’s instance and mixed-in methods. This means that properties of the hash can no longer be set, accessed or deleted directly; you must use the Hash#get(key), Hash#set(key, value) and Hash#unset(key) instance methods instead. To illustrate:

var myhash = new Hash();

// old API  -->  new API
myhash.name = "Bob";  -->  myhash.set('name', 'Bob');
myhash.name;          -->  myhash.get('name');
delete myhash.name;   -->  myhash.unset('name');

You should also be aware of other changes to the Hash API:

  • The $H(object) shortcut is now completely equivalent to new Hash(object). Both always return a new object, regardless of whether the argument was an Object or another Hash.
  • Hash#merge returns a new Hash instead of modifying the Hash it’s called on.
  • Hash#update is a destructive version of Hash#merge that modifies the Hash it’s called on.
  • Hash#clone returns a new, cloned instance of Hash.
  • Hash#toObject that returns a copy of the Hash’s inner Object.
  • Hash.toQueryString is now an alias of Object.toQueryString. (Hash.toQueryString is deprecated and will be removed in a future version of Prototype.)
  • Hash#remove has been removed in favor of Hash#unset.
  • Hash.toJSON has been removed in favor of Object.toJSON or the Hash#toJSON instance method.

Other changes and deprecations in this release

  • Element#wrap now returns the newly created wrapper element instead of the element being wrapped.
  • document.getElementsByClassName and Element#getElementsByClassName are now deprecated, since native implementations of these methods return a live NodeList, while we can only return a static Array. Please use $$ or Element#select instead. Example: 
    document.getElementsByClassName('foo')  -->  $$('.foo')
element.getElementsByClassName('foo')   -->  element.select('.foo')

We’ve fixed 19 bugs since 1.6.0_rc0; see the CHANGELOG for full details.

Download, Report Bugs, and Get Help

Thanks to the many contributors who made this release possible! Barring any heinous bugs, RC1 will be our last release candidate, and you can expect the final version of 1.6.0 to land in early November.

Comments

  1. Michael #

    Thanks a lot for such a great lib.

    Will events like mouse(enter|leave|wheel) make it into the final?

    October 16th, 2007 @ 06:35 PM
  2. Sam Stephenson #

    Hi Michael- At this time we don’t have any plans to normalize mouseenter/mouseleave/mousewheel events in 1.6.0. However, the new event API should make it easy for 3rd party scripts to observe these browser-specific events and translate them into custom events.

    October 16th, 2007 @ 08:57 PM
  3. Justin Meyer #

    Looks good, but what was the reasoning for changing the Hash class? Was it solely due to collisions? Or is there something more interesting in mind?

    October 17th, 2007 @ 12:51 AM
  4. Alex #

    Does this still work?

    document.observe(“contentloaded”, function() { //ello? });

    October 17th, 2007 @ 02:01 AM
  5. Alex Egg #

    I guess I missed the namespaced part:

    document.observe(“dom:loaded”, function()

    October 17th, 2007 @ 02:20 AM
  6. arty #

    Hello.

    I’m a great fan of Prototype library. I’m thankful for your hard work.

    But I just hate this change: myhash.name = “Bob”; —> myhash.set(‘name’, ‘Bob’); “Welcome to Java world” it says to me.

    Looks like this makes me stick to 1.5.1.1 or try to roll my own from old Hash and new other parts in SVN repo.

    Please reconsider!

    October 17th, 2007 @ 02:46 AM
  7. Edd Couchman #
    For those of you using scriptaculous 1.8.0_pre1, line 221 of effects.js should be changed from: 
    Class.mixin(Effect.ScopedQueue, Enumerable);
    to: 
    Effect.ScopedQueue.addMethods(Enumerable);

    I have submitted this to scriptaculous.

    October 17th, 2007 @ 03:51 AM
  8. Daniel #

    Is there a way to concat two hashes with the new syntax? like myhash.join(anotherHash)?

    October 17th, 2007 @ 04:00 AM
  9. Michael #

    Oops, I used to pass hashes to Template’s evaluate() and now everything stopped working. any clues, please?

    October 17th, 2007 @ 04:20 AM
  10. Werner Wachsmann #

    Hi Michael,

    use Hash.toObject to pass the hash object to Template’s evaluate(). 
    
var objHash = new Hash();
objHash.set('hello', 'world');
objHash.set('my', 'hash');
console.dir( objHash.toObject() );
    October 17th, 2007 @ 06:16 AM
  11. advanced #

    Thanks for the heads up Edd, I might’ve missed that. Looking Good Sam!

    October 17th, 2007 @ 06:18 AM
  12. advanced #

    actually.. string “mixin” not founr in 1.8.0_pre1

    October 17th, 2007 @ 06:30 AM
  13. Mislav #

    @Edd, that’s great. Thanks.

    Daniel: @var result = myhash.merge(anotherHash)

    @Michael: that’s a regression, I will fix it shortly.

    Justin, arty: The change was just due to collisions, there are no benefits other than making Hashes key-safe. We'd also like to have @hash.key = value, but in JavaScript that simply can’t work if you want to have methods on the object also, and we do. You can easily revert to the old behavior, though; just follow the instructions from my blog post. This is a proof-of-concept, I don’t really recommend it (for obvious reasons).

    October 17th, 2007 @ 06:38 AM
  14. Mislav #

    Ah, “at”-signs were interpreted incorrectly in my previous comment. Just ignore them.

    October 17th, 2007 @ 06:43 AM
  15. Kniaź #

    Michael. You should use Hash#toObject before passing hash to Template#evaluate().

    Changes look nice. I love the real OOP-style (Java-style sb said), so changes in Hash API are fine for me :-) But I wonder why Hash#remove() was removed (sic!). Is this backwards incompatibility really necessary? Couldn’t unset() and remove() coexist?

    October 17th, 2007 @ 06:51 AM
  16. Kniaź #

    Sorry for my duplicate answer for Micheal’s question. I’ve started to write it about hour ago and in the middle had to go out. Didn’t notice all those answers :-)

    October 17th, 2007 @ 07:00 AM
  17. Mislav #

    Kniaź: No problem, wanting to help is always positive. We will definitely solve the Template issue, until then be sure to call “toObject()” when passing Hash data to your templates.

    October 17th, 2007 @ 07:37 AM
  18. arty #

    Mislav, thanks! I thought of this too and decided that it may break too much of internals. However I’ll give it a try after release.

    Now I start preparing myself to abandon Hash and use only plain js objects until I need .each() or like.

    Thanks to all developers for $H(obj) not extending obj itself! : )

    October 17th, 2007 @ 07:51 AM
  19. Luis Fernando Planella Gonzalez #

    The Hash changes are really show stoppers!!! I know there’s a semantic flaw by not knowing whether a hash property is a key / value pair or an object property, but that breaks too much code (at least on my case). I use Hashes a lot, and it’s not just a simple search / replace to adequate those changes. I know the temptation for improvements is big, but backward compatibility should be a basic principle!!! Please, reconsider!!!

    Besides that, all other changes since 1.5.x are great! Congratulations!

    October 17th, 2007 @ 08:30 AM
  20. Mislav #

    Luis-

    This is a major release we are speaking of, and APIs usually change in major releases. If you don’t want to change your old code you might scroll up to see one of my comments mentioning a blog post. I don’t really recommend it, though; it’s better to be safe with current Hash and getters/setters.

    October 17th, 2007 @ 08:51 AM
  21. Zuzmic #

    Hmm , it seems that new Element(‘div’, { opacity: 0.5}); not working now

    October 17th, 2007 @ 09:06 AM
  22. Mislav #

    Zuzmic: you might want to smack yourself on the head first and write new Element(‘div’).setStyle({ opacity: 0.5}) :)

    October 17th, 2007 @ 09:19 AM
  23. mhw #

    Mislav -

    Excellent writeup on the class/inheritance structure of 1.6—thanks for taking the time to put that together!

    I had one question about it, though. It says:

    “When you inherit from Pirate, the class methods are not inherited. This feature may be added in future versions of Prototype. Until then, copy the methods manually, but not like this:”

    
var Captain = Class.create(Pirate, {});
// this is wrong!
Object.extend(Captain, Pirate);

    What is the preferred nomenclature?

    Thanks again!

    October 17th, 2007 @ 09:36 AM
  24. Mislav #

    Zuzmic: on the other hand, that may not work in IE. Better insert it in the document before setting opacity.

    mhw: This might work, but I haven’t tested. This snippet has to appear before you define those classes, then you will be able to do this: Captain.inheritClassMethods();

    October 17th, 2007 @ 10:38 AM
  25. Woil #

    The changes to hash are understandable but as arty said above, “Welcome to Java world.” In review of the code it appears that the hash now uses an internal object for getting and setting values. Because javascript doesn’t have protected members, this is easily accessed from outside code.

    
var h = new Hash();
h.set('name', 'Bob'); 
alert(h._object.name);     //Bob
h._object.name = 'Joe';
alert(h._object.name);     //Joe
alert(h.get('name'));      //Joe

    Is this a bad practice? It might be easier to rewrite existing hash code with this style than with get() and set().

    October 17th, 2007 @ 12:56 PM
  26. Woil #

    For Michael and others, the mouseenter and mouseleave events are implemented in ticket #8354. As I use these events in a number of places I went ahead and implemented them in the current rc1 edge.

    http://dev.rubyonrails.org/attachment/ticket/8354/event_mouseenter_106rc1.patch

    I would to see them implemented, or to see a good explanation of the recommended way to implement them without hacking the source.

    October 17th, 2007 @ 01:48 PM
  27. Mike Rumble #

    I can see how the changes to Hash might affect some people – it certainly isn’t going to be as straight forward as slapping a copy if 1.6 over the top of 1.5 and hoping for the best.

    However people are missing the point a little bit, for the first thing which struck me when I saw the proposed move to the get and set methods for Hash was how it opens up the possibility for pseudo getters and setters.

    Consider the following Pastie which subclasses Hash and adds basic observers to a Class:

    http://pastie.caboo.se/108294

    This example is rather simple but this could lead to a nice alternative to custom events on elements where you want to observe changes to properties in your class instances.

    Nice work Team Prototype!

    October 17th, 2007 @ 05:43 PM
  28. Mislav #

    Woil: Tobie wanted to get true privacy for that object, but it would require jumping through hoops. I like it exposed, on the other hand, because I can access it in subclasses.

    It’s definitely bad practice to access that object directly in app code. The underscore (“pseudo-privacy”) is an indicator of that.

    Mike Rumble: nice demonstration! I’m pleased to see that at least somebody started to notice benefits of this approach.

    BTW, you must be registered to the (Freenode) services before talking to Pastie bot. After that, just say hi to Pastie in public (“pastie: hi”).

    October 17th, 2007 @ 06:42 PM
  29. Tobie Langel #

    Woil: _object is a (pseudo) private property, so you really shouldn’t access it directly as It could very well turn truly private in an upcoming release.

    I know getters and setters are not the sexiest, but they are the only reliable solution to a trustworthy implementation of Hash.

    Note that when you have more than one property to set at the same time, Hash#update is your friend:

    
var h = new Hash({foo: 1});
h.update({bar: 2, baz: 3});
h.toObject();
//-> {foo: 1, bar:2 baz: 3}
    October 17th, 2007 @ 08:48 PM
  30. Ran Baron #

    This version somehow breaks drag and drop capability with scriptaculous 1.8.0_pre1 on IE. Works the same in FF but not in IE. Tested with IE6 and IE7. Any ideas?

    October 17th, 2007 @ 09:11 PM
  31. Colin #

    Prototype is looking more and more like Mootools in API, and more like dojo in size with every update!

    October 18th, 2007 @ 04:14 AM
  32. Michael Schøler #

    Error on this page:

    Mouseover on any of the right-menu categories collapses this page in ie6, and a page reload is needed to continue reading.

    October 18th, 2007 @ 05:48 AM
  33. pdan #

    It seems to me that the new Hash also creates problems when used to pass parameteres to Ajax requests – you have to use .toObject on the hash in order to make it work, or else the whole object with methods is sent :)

    October 18th, 2007 @ 07:12 AM
  34. Andrew Dupont #

    @pdan: Are you sure? If this were the case it wouldn’t have made it through the unit tests. Do you have code that exhibits this behavior, or are you just speculating?

    October 18th, 2007 @ 10:42 AM
  35. albert #

    Hi;

    where & when can i Report a bug of prototype ?

    thks, community. albert.

    October 18th, 2007 @ 12:10 PM
  36. Michael #

    Drag and drop now fails in IE with Scriptaculous 1.7.1 as well. If someone has a fix, please let us all know.

    @pdan. it works perfectly on my tests and production environment

    October 18th, 2007 @ 12:17 PM
  37. Tobie Langel #

    Albert: to submit a bug, please follow our contribute guide.

    October 18th, 2007 @ 12:49 PM
  38. PDan #

    General info: page to select products from database. JS: function fltApply(_limit) { var url = ‘EQ_selector.php’; var pars = $H({‘act’: ‘list’, ProductName’: $F(‘ProductName’)}); var myAjax = new Ajax.Updater(‘listProduse’, url, {method: ‘get’, parameters: pars}); } With this I get a: Request-URI Too Large – The requested URL’s length exceeds the capacity limit for this server. Apache Server at localhost Port 80 With .toObject everything is fine. With POST instead of GET is ok, because I can post large objects. Tested with Firefox2/Firebug to watch the comunication.

    October 18th, 2007 @ 02:59 PM
  39. PDan #

    Also a question: in 1.6.0RC0, this inside an event pointed to the element that trigered the action. in RC1 it points to the observed element. Which behaviour is the one that is right. In RC1 how can I find who trigered the action?

    October 18th, 2007 @ 03:35 PM
  40. PDan #

    About this in events, I think the right one is the one in RC1, and I found out I can use Event#target to get the element that trigered the action

    October 19th, 2007 @ 03:12 AM
  41. nicolash #

    the changes to this/Event#target with observers mentioned by PDan seems rather important to me – maybe they should be part of this article!

    October 19th, 2007 @ 03:58 AM
  42. huangam #

    I still like the Hash in Version 1.5.1.0

    October 19th, 2007 @ 11:48 PM
  43. Daniel Skinner #

    The new features are looking great.

    Will we ever see prototype making it easy to handle mousewheel events?

    October 20th, 2007 @ 05:58 AM
  44. Yellow Pages #

    I really expected to see the Hash rewrite thing. The event classes change are cool.

    Thank you very much!

    Ed

    October 22nd, 2007 @ 12:11 AM
  45. Sven #

    Thanks for this great library! One suggestion though, a timeout setting would be nice :)

    Something like:

    new Ajax.Request( ‘ajax.php’, { timeout: 5000; onTimeout: function() { // do stuff } } );

    October 23rd, 2007 @ 02:56 AM
  46. Diogo #

    Prototype 1.6 has very nice new features! congrats! I’ve just coded an edit in place component. http://www.diogopeixoto.com/2007/10/23/edit-in-place-using-prototype-160/

    October 23rd, 2007 @ 09:05 PM
  47. Burak #

    Hi,

    I am sorry, I looked from your site, and I know “Prototype framework is managed by the Trac issue tracking system on the Ruby on Rails developer site.”

    but I could not find how I can ask a question about Prototype.

    My problem is:

    I just downloaded version 1.5.1. The old version that I used in my web site (asp.net 2.0) is: 1.5.0_rc1

    I only updated the new “prototype.js” with the old one.

    I got “Stack overflow at line: 0” error when I want to open a pop-up window. (IE 7.0)

    What might be the problem. I hope you could help.

    Note: I tried also with 1.6.0 RC version. I have the same error.

    October 24th, 2007 @ 03:36 AM
  48. Tobie Langel #

    Hi Burak,

    Please kindly use the mailing list or irc for these kind of questions.

    Thank you!

    October 24th, 2007 @ 05:13 AM
  49. vectoroc #

    Перевод на русский http://vectoroc.blogspot.com/2007/10/blog-post.html

    October 24th, 2007 @ 10:04 AM
  50. Vlad!mir #

    Really great work!!!, but I have question: Prototype has a largeness enough. I think about loading of separate parts of framework using SAJAX, it is possible to save a SVN-structure of framework; It can look as: Import.js(‘base’,true); Import.js(‘dom’,true); Import.js(‘myScenario?param1=value1&param2=value2’,false); Where Import is AJAX-based object, if last parameter ‘true’ make its similar to ‘include_once’ in PHP Do I have right on the use of framework in such kind for creation of the extensions? Sorry for my English

    October 24th, 2007 @ 04:58 PM
  51. Tobie Langel #

    Vlad!mir,

    There are dependencies within the different components of Prototype which would make loading them on demand impossible or at least extremely complicated.

    Gzipped, the current version of Prototype is 28kb. And it’s cached by the browser, so I really wouldn’t bother going down that tedious route.

    However, if you do wish to pursue your endeavor, Prototype is released under an MIT-style license, which allows you to do so as long as you leave the copyright intact.

    Happy prototyping!

    October 24th, 2007 @ 05:36 PM
  52. polypus #

    So can I just drop this (along w/ the latest svn version of scriptaculous) into a fresh new rails 2.0 app and have it all run smoothly?

    thanks for the lib!

    October 24th, 2007 @ 09:52 PM
  53. Vlad!mir #

    Is it possible partial applying (papply) with Prototype framework?

    October 25th, 2007 @ 03:28 AM
  54. Denny #

    All of the recent changes are fantastic! I was using prototype 1.6.0_rc0 previously and just updated to rc1. In our environment, we have a maven plugin that compresses our javascript files. I had no issues in rc0. but now, in rc1, I’m finding that prototype is ‘breaking.’ The issue seems to be with the introduction of the $super special argument. Has anyone else had this issue come up? How can this be resolved so that we can continue to compress our prototype file?

    Thanks!

    October 26th, 2007 @ 04:44 PM
  55. choncon #

    I cant post data (with unicode) by AJAX.They become like: dí s dí

    October 26th, 2007 @ 06:46 PM
  56. Kazu Yamamoto #

    Hello,

    First of all, thank you for the great package. I’ writing this in case you don’t notice this.

    I have tested prototype.js 1.6.0RC1 with JavaScript Lint (http://www.javascriptlint.com/).

    There were no errors but there 191 warnings with the default configuration. I think some warnings (including missing semicolon, redeclaration of var value) should be removed.

    Are you planning to fix them in RC2?

    October 28th, 2007 @ 10:25 PM
  57. Sudhir #

    Hey… great work, guys… just love what you’re doing for all of us, and when i’m good enough at programming i will contribute all i can…

    but now, though, when can we expect documentation for 1.6? :D and does scriptaculous 1.7.0 break when we replace prototype 1.5 with 1.6? Think it might…

    October 29th, 2007 @ 09:59 AM
  58. Jeff #

    Why do I always have to add code to the prototype lib to prevent it from sending ‘extend’ in request headers and now in this version it is sending it as a get param also. Here is the patch I am using: - prototype-1.6.0_rc1.js 2007-10-19 09:53:49.000000000 -0500 + prototype.js 2007-10-30 11:05:03.000000000 -0500 @ -1066,6 +1066,7 @ + if ( pair.key == ‘extend’ ) return; var key = encodeURIComponent(pair.key), values = pair.value; @ -1279,8 +1280,10 @ $H(extras).each(function(pair) { headers[pair.key] = pair.value }); }

    if (values && typeof values == 'object') {

    - for (var name in headers) + for (var name in headers) { + if (name == ‘extend’) continue; this.transport.setRequestHeader(name, headers[name]); + } },

    success: function() {
    October 30th, 2007 @ 11:07 AM
  59. Colin Manning #

    I’m a great fan of 1.6 and have been implementing some pretty cool stuff with the initial release candidate. However apart from the bug fixes, I’m not sure what the benefits of the new features in RC1 are. The “addMethods” method to the Class APi seems pointless to me – I can see that an “addMethod(name, source)” would be nice to make code read better, but the implemented “addMethods” is pointless – as I would just move my existing code into a different place.

    Despite above comment, I appreciate the bug fixes and the development effort.

    All the best,

    Colin

    October 30th, 2007 @ 06:52 PM
  60. hs #

    123

    November 2nd, 2007 @ 01:36 AM
  61. 应天 #

    哈哈。。 支持。。加油哦。。 来自中国。。

    November 3rd, 2007 @ 07:37 PM
  62. Eugene Park #

    For AJAX requests, in addition to onSuccess and onFailure, how about a onTimeout method? Would like to handle network latency failures a bit differently than normal ajax failures…

    November 5th, 2007 @ 12:48 AM
  63. cfcodefans #

    Please add XMLDocument support into Prototype frame! Let us handle xml data more easier, between different Browsers!

    Please add XMLDocument support into Prototype frame! Let us handle xml data more easier, between different Browsers!

    Please add XMLDocument support into Prototype frame! Let us handle xml data more easier, between different Browsers!

    Please add XMLDocument support into Prototype frame! Let us handle xml data more easier, between different Browsers!

    November 6th, 2007 @ 09:59 PM
  64. zerox #

    I noticed that the keypress event doesn’t work properly in IE (6 & 7) when I couldn’t get keyboard navigation in the Scriptaculous Autocompleter to work. In IE the callback function isn’t fired when keys like up, down, left, right, home… are pressed. But it works normally for other keys (alpha and numeric).

    I did a quick test (yes i call it after dom was loaded) Event.observe(‘mojtest’, ‘keypress’, foo);

    It works OK with prototype 1.5.x but not with 1.6.x

    November 7th, 2007 @ 01:37 PM
  65. zerox #

    Uh.. keydown seems to be the solution. I should take a breath next time and look at the code again :).

    November 7th, 2007 @ 01:42 PM
  66. krizzl0r #

    Why are the “browser-engine/object”-checks inside and not outside? e.g. the Event.observe-method:

    currenty: ... function(...) { if (element.addEventListener) { ... } else { ... } }

    best performance: if (element.addEventListener) { ... function(...) { ... } } else { ... function(...) { ... } } this way Event.observe(...) would not check element.addEventListener for every single call.

    November 7th, 2007 @ 03:05 PM

Sorry, comments are closed for this article.

Search Blog


Search the prototype blog.

Subscribe to the blog

Categories

Akismet badge