Here are some of the posts that you may find useful.
I've digged deep in the archives to bring them to top of the water again :)

1. ajax and charset conversion issues
   
   If you write ajax applications and your pages are encoded in a non-UTF character set,
   you will most probably find yourself in need of a conversion mechanism so that the data you send to server is encoded properly without damaging native characters.
   
   
2. how to run linux without risking your hard-drive
   
   It's my first serious attempt to dive into the *nix world and hence I wanted to make the transition as painless as possible.
   
   Browsing the web I found that the easiest and harmless combination would be using a virtual machine. This way, I would not be creating a physical linux partition. Hence less risk on my side.
   
   
3. window.onload is soooo 90's
   
   I am working on a client-heavy ajax application and the more responsive I manage to make it; the better. Making the application load as fast as possible is a must-have goal for me.
   
   As you know, when DOM content loads and becomes readily available you can execute additional initialization scripts to lazy-initialize and organize the page.
   
   
4. Friends of your friend are most probably your friends
   
   The idea is simple. It applies to online social networks (6 degrees of seperation principle).
   So I thought why not apply it to links? Since I generally like my friends' friends, similarly, my second order links will be most probably the links that I like.
   

Hope you find them useful.

Cheers.

 bu yaziyi sevdin mi?  hemen una ekle!

If you've read my Modal Dialog enhanced article; you may wonder the reason why I obsinately insist on not using an IFRAME to stop the bleed through when a layer moves over a HTML Select element and I use SPANs instead.

I have received several e-mails asking the reason behind it. And since the method I propose in the article is much complicated than simply using and IFRAME, you are right in wondering the reason why.

I have several considerations most of which are philosophical in nature rather than practical.

• First of all; the ugly IFRAME hack (which most of the DHTML and AJAX API's prefer to use) is a non-semantic usage of the IFRAME element.
  The legitimate usage of the IFRAME is to provide external data; such as a disclaimer or a web service.
  
  
• Introducing a non-semantic element (with or without JavaScript) does not eliminate the fact that it is used in a semantically incorrect fashion.
  
  
• May be in the future IFRAMEs wil behave differenly and allow bleed-through, who knows.
  
  However spans will always behave as intended because I use them in a semantically correct way: They are used to wrap text around. And this usage is a supplementary method to enhance user experience; not an ugly hack that utilizes the user agent's render characteristics.
  
  
• Yet another reason; people may tend to browse frame support disabled. Or their user agents may not have frame support at all (and old browser, or a PDA for instance).
  I know, that's equally true for JavaScript, but who really turns JavaScript off anyway?
  
  
• From my testings, IFRAME hack only works in IE5.5 and above (it may be a concern for some people; but I don't think it's a big deal).
  
  
• Activex, Java, Flash etc.. is another story. If you would like to implement the third method; you can replace them with a static alternative (an image or text may be). But I admit that's a bit overkill.
  

As per the good news; you don't need IFRAME masking in IE7. It's no longer necessary.

...

I'd like to stress once more that it is not a bad idea. There are tons of DHTML tooltips, menus etc. around using the IFRAME hack. It's just me being a little picky.

May the source be with you!

 bu yaziyi sevdin mi?  hemen una ekle!

I've listed my most-frequently-used FireFox Extensions.
Hope that you find them useful:

1. All in one SideBar

All in one sidebar enables you to quickly access, organize, update, activate/passivate your extensions. Highly inspired from Opera web browser's sidebar.

You can also access your history, bookmarks, recent downloads, themes, JavaScript Console and Page Properties with just this very side bar.

I highly recommend you try it, if you haven't already done so:

2. Colorzilla

It assists web developers and graphic designers with color related tasks - both basic and advanced.

With ColorZilla you can get a color reading from any point in your browser, quickly
adjust this color and paste it into another program. You can Zoom the page you are viewing and
measure distances between any two points on the page.

Colorzilla is available for download here.

3. Dictionary Search

I am not a native English speaker. Although most of the time I can deduce the meaning of words from the general structure of the sentence; I often wonder the exact meaning of the word
(yeah I'm curious) and Dictionary Search is a great time-saver for me.

4. FireBug

I don't know how I had been developing AJAX applications without FireBug.

Some fun features of FireBug include;

• Logging for web pages
  
  No more 'alert("debug:" + myvar);' s in the source.
  Firebug logs them for you without interrupting the process.
  
  
• JavaScript debugging
  
  You can stop JS execution, add breakpoints, step in, step out from the methods.
  It's no different than using your favorite IDE's debugger.
  
  alert( "I will never ever use alerts for debugging again" );
  
  
• Errors at your fingertips
  
  FireBug adds a little icon to the Firefox status bar which tells you if your page is busted.
  No more digging through the muddy pile of errors in the JavaScript Console window.
  
  
• CSS / DOM inspector
  
  Elements and styles and events, oh my goodness. This can't be true. I can inspect anything on the page with my mouse. Morever I can change attributes, attach new events; modify/override JS methods! Unbelievable!
  
  
• JavaScript comamnd line
  
  To inspect and alter variables and state date.
  Sing with me:
  

  "No more alert debugging."

  
  
• Ajax Request Spy
  
  Logs all your XMLHttpRequests along with post data and header information on-the-fly.
  
  If you are developing (or you plan to develop) AJAX Web Applications; this feature is a must-have for you.
  

You can download FireBug from Joe Hewitt's web site.

5. FireFTP

Forget about your bloated FTP client. And meet FireFTP.

I assure you; you won't look for an alternative once you get used to it.

6. Web Developer Toolbar

A must-have for any Web Developer / Designer.

You had better use it to understand how an invaluable toolbar it is for the web developer.

7. Session Saver

Although FireFox is an excellent browser; it may crash once in a while.

If you are in the middle of a research with a zillion of tabs open (see the next list item);
then session saver is actually your life-saver. It saves all open sessions before the crash
occurs and loads them back when you re-launch Firefox.

8. TabMixPlus

If you are like me, a zillon tabs open side by side; then TabMixPlus is just the tool for you.

9. EditCSS

As its name implies, with EditCSS you are able to edit your site's CSS files on-the-fly and observe the changes immediately.

Edit CSS is available for download here.

10. Total Validator

The Total Validator Firefox extension provides one-click validation for HTML, Accessibility, Dead Links and more...

Total Validator is a complementary tool for standardistas out there.

I say "complementary" on purpose; because as you all know automated accessibility
checks don't mean much and the developer is responsible for passing each checkpoint manually.

BONUS

If have followed up to this point then you deserve a bonus don't you?

11. Noia Theme

Tired of the default Firefox look? Then install noia extreme theme. You'll be amazed how it changes look and feel of your Firefox.


... May the source be with you!

 bu yaziyi sevdin mi?  hemen una ekle!

Mozilla Leak Monitor extension says that sardalya's _.chain method leaks if you decide to attach the event explicitly bypassing the EventRegistry.

In the core of sardalya , at times, I explicitly bypass EventRegistry attachment if (and only if) I am 100% sure that the code would not leak (no closures, no expando properties etc...).

The author of the plugin also confirms my action:

Some of these leaks are things that are clearly bugs in the extension (such as registering observers with the observer service forever) and some are things that arguably shouldn't leak (at varying argument strengths).

Although some of those leaks may be real. Most of those leaks are due to a bug in the extension (or FF1.5 or both).

Currently there is a lot of buzz around in blogs and forums telling;

... and also XYZ Framework Leaks, I've installed the Firefox Leak Monitor plugin and oh my goodness; every single site I visit is leaking! gmail is leaking, dojo is leaking, prototype is leaking.

Hey look! sardalya leaks as well.

I am in need to write this blog post; because I've received a pile of e-mails telling that the current version of sardalya has leaks in it. Thank you everyone for your feedback. I very much appreciate them and use your comments and suggestions as a means to improve, enhance and re-shape sardalya.

...Coming back to the leak issue. Well I (think that I) have adequate knowledge on what causes a JavaScript memory leak, in what circumstances the memory leaks etc... I've even written an article about it. And I am pretty (99.999%) sure that the former version of sardalya does not leak.

To keep the long story short I've converted expressions like

_.chain(document,"mousemove",
this._onMouseMove,true);

to

_.chain(document,"mousemove",
this._onMouseMove);

in the current version of sardalya.

I think this is a better approach (whether there is an actual leak or not) because

• First of all it is a defensive coding practice. Better be safe than sorry.
  
  
• Secondly reclaiming memory as soon as possible in window unload, instead of leaving the decision to the garbage collector will positively affect performance.
  

There is a caveat though: If there is an excessive amount of event registration going on the page; the internal array that holds pointers to event handlers in the EventRegistry object may increase in size and this will result in a slightly increased amount of memory consumption (a.ka. a pseudo leak)

But I guesstimate that this pseudo leak won't be recognizable in practical situations.

And yes I've released a new version of sardalya (2.2.5). It has some minor fixes and this leak issue implemented.

 bu yaziyi sevdin mi?  hemen una ekle!