I always get a sinking feeling when Prototype starts to change. Sam (who maintains the project) is checking fixes for the next release today and Justin Palmer (encytemedia.com) is posting things that he’s seeing get checked in as it happens. On the one hand, the next version offers some nice improvements (thus far, there may be even more changes to come), but on the other, it’s stuff I’ve got to go dig into and incorporate into my work…

via ajaxian:
Justin Palmer has updated us with a bunch of recent Prototype updates including:

• Chainability: A bunch of methods now return their first arg so we can change together methods

  $('sidebar').addClassName('selected').show();
  $('sweet').observe('click', function(e) {
      console.log("%s was clicked", Event.element(e));
  }).setStyle({color: 'red'});

• Form and Form.Element methods mixed in to $ and $$
• Shorter syntax for Event Observing:
  $('element').observe('click', function(e) { alert(e); });
• Backwards Compatability: Element.toggle, Element.show, and Element.hide no longer take an arbitrary number of arguments
• Add serialization and observation support for input type=search
• Simulate non-GET/POST requests by POSTing with a _method parameter set to the actual verb
• Make Element.update() handle TABLE-related elements with the DOM API because of IE’s missing .innerHTML property on them
• and many more.

I just found this Encytemedia post on Prototype inheratance that’s totally worth the read. Additionally, at the end he (Justin Palmer) points to Dean Edward’s Base script that provides an interesting alternative.

…All that has since changed. Thanks to the persuasion of The Javascript MacGyver, Sam replaced the Object.prototype bits in favor of Object.extend and Object.inspect. With this decision, however Prototype’s inheritance scheme can be messy, and it’s certainly hard to read if you don’t spend time trying to really figure out what’s going on.

Here’s a chunk of code I use when I’m writing javascript to let me pepper my code with debug statements and not worry about crashing browsers without the firebug functionality (like safary, which has it’s own console.log syntax and will crash if it encounters firebug formated statements): Read the rest of this entry »

Brandon S. writes: The first release candidate of IE version 7 came out today…
And then on ajaxian:
The IE Team has posted more details on the IE7 CSS changes so we can all get prepared:

We are currently locking down IE7 for shipping and I wanted to give an update on the CSS work that went into IE7. Chris originally outlined our plans for IE7, and we listened to a lot of feedback (blog, connect database, conferences, our WASP partnership etc.) to help us address the most grievous bugs and prioritize which features to put in for IE7. I like to thank especially the contributors on this blog for their participation. Your feedback made a difference in deciding what issues to address.

We understand that we are far from being done and we know we have still a lot of work ahead of us. IE 7 is a stepping stone in our effort to improve our standards compliance (especially around CSS). As an example, in the platform we did not focus on any proprietary properties – though we may try out new features in the future using the official ms- prefix, following the CSS extension mechanism. We also work very closely with the W3C CSS working group (which I am a member of) to help clarify assumptions in our implementation and drive clarifications into the spec. I really like to thank everyone who helped us here.

In all, we made over 200 behavior changes (bug fixes or new features) under strict mode to improve CSS2.1 compliance. All this work (with the exception of transparent PNGs) has been done under the switch only, since all changes required behavioral updates to be more in line what the CSS spec specifies. To preserve application compatibility we will not make any behavioral changes to ‘quirks mode’ as it has been established since IE6.

Read about the many changes that have been made.

Now, what was I just saying?

via Ajaxian:

Cody Swann was working on a web application that was using the Dynamic Script Pattern, which Dojo has excellent support for, but Prototype didn’t.

Cody then extended Prototype to support ScriptSrcTransport similarly to how Dojo does it.

The code below support the Simple, Polling and JSONP and JSON Callbacks described in the Dojo book.