the meaning of life, the universe and everything

Yes, it is a common problem.

I receive mails continiously telling that selects are bleeding through sardalya's DraggableLayer. Thanks everyone for their feedback by the way.

It is a rendering issue, the browser renders those selects on top of anything else.

My first trial was to remove selects while dragging and re-show them when dropping.
It was the pseudo pop up, where I tried a concept similar for the first time.
But what I see is people hate this kind of usage (i.e. selects appearing and dissappearing)

So I have a brand new idea: I'll add some method (like transformCombos(blnValue) )
When one uses

var lyr=new LayerObject("elemID");
lyr.transformCombos();

the layer will hide the selects and show alternate divs/spans when it is visible (i.e. visible and not-collapsed) and it will show the actual selects otherwise.

Moreover the property will be true by default for ToolTip and DropDownMenu. I have to think more about it. Just a starting idea.

Someone offered using IFRAMEs. Yes, IFRAMES do work. But I don't want using them as a part of my solution. What if a browser X comes and says that 'my selects are preciousss, they will be rendered even on top of an IFRAME' ".

I don't like using frames... any kind of frames.

Did you know that CSS3 specs (which is still under development) has a lot of interesting recommendations such as drop shadows, fancy rounded corners for your boxes etc.

One recommendation that currently interests me, which is currently being implemented by Mozilla-family and IE (in a non-standard manner), is the opacity feature. To give opacity support in IE and moz a simple style definition is adequate like;

.opaque{filter:alpha(opacity=85);opacity:.85;}
.opaque2{filter:alpha(opacity=75);opacity:.75;}

Where .opaque will be 85 per cent opaque where .opaque2 will be 75 per cent opaque (more transparent)

I plan to integrate this to sardalya's DraggableLayer so that when dragging a layer it seems transparent and when dropping it back it restores its opacity.

However if you plan to use it be aware that your "valid CSS" badge of honor will be gone. That is not a big thing imo.

I believe that if you do what you do and you know the risks and cosequences of your action, and if your action creates a better "cross-browser" user experience, you may close your eye and slightly deviate from the standards.

Take for example suckerfish dropdown menus. Since IE does not suppor :hover pseudoclass correctly, the author uses a tiny little script to make it work just as the same in IE/js-enabled
(okay, the market penetration of IE may be an important factor behind this decision but the decision helps create the same user experience in all modern browsers)

Or another case: Assume you are coding and XHTML compliant web page using .Net platform (using Visual studio .net 2003 -- not 2005) . Your web form will be something like.

[form name="FrmPage" id="FrmPage" method="post"]
[input name="__VIEWSTATE" type="hidden" value="...some crap..."]

That's not valid XHTML. You may apply a response filter on the server side and re-format the output into a valid form (and there are people that do this)

[form id="FrmPage" method="post"] *note there is no name attribute
[div][input name="__VIEWSTATE" type="hidden" value="...the same crap..."][/div]
*the hidden input is enclosed in a container.


But is it worth consuming your CPU power and writing a custom filter just to be purely standards blind? Yes its standards blindness, not standards compatibility. We are blindly adhering to the declared standard without using, our genuine property of being an intelligent creture: our judgement.

At times like this I stand back a few meters from my monitor and re-evaluate my action.

In the new design of sarmal, I plan to put something like below in the footer under my copyright disclaimer:

"This page is valid xhtml, valid css and at least w3ai-a accessible with intentional exceptions."

Moral of the story:

Don't let a machine do a man's job. I mean of course go validate your code. It is the first step in creating a coherent, accessible and future-oriented web site. However, don't build a blind faith to it. The W3C validator cannot decide, it cannot judge between apropriate and inapropriate.

In short use your feelings and your judgement. You will mostly find the right path.

May the force be with you :)

# posted by Volkan Ozcelik : 8:06 AM  0 comments   

I realized that I am browsing, harvesting, archiving thousands of web pages daily. Then a project popped up in my mind. What if I collect those links, write short summaries to them (and site snapshots may be) and display a tiny portion of them randomly?

I am currently mindmapping on various details of the issue. One critical point is how I can evaluate "best of best".
I think I'll devise an algorithm which will create score based on a weighted average of
overall site topology (generated by a mapping tool such as link checker pro), my subjective judgement and other's subjective judgement(initially each click/view will be counted as a vote
after that a more complex rating mechanisim may be generated.)

Just an idea... it may transform to an entirely different concept in the future, who knows.

This is a follow-up of my prior post on memory leakage.

IE's problem is not 100% related to circular references (using circular references just makes the issue more apparent) It has more to do with usage of closures.

There is more on MSDN to describe the ie leak patterns.

If you do not know what closures are, I recommend an excellent web page describing them. They are excellent pieces to use, but can be very harmful if you use them improperly. Nevertheless closures are a powerful construct. Better keep them in your inventory.

Let us begin with a sample non-leaking code (non-cross-browser)

[html]
[head]
[meta http-equiv="refresh" content="1;" /]
[script type="text/javascript"]
window.onload=function(evt){

var obj=document.getElementById("my-element");

obj.attachEvent("onclick",fn_handler);

/*in order to observe the leakage*/
obj.bigString=new Array(1000).join(new Array(200).join("XXXXX"));

};//onload

function fn_handler(evt){
alert("hello world!");
}
[/script]
[/head]
[body]
[div id="my-element"]cccc[/div]
[/body]
[/html]



The assignment of obj.bigString will not affect anything because it will be deallocated as soon as window.onload function exits.

Now let us create a closure and see how things change:

[html]
[head]
[meta http-equiv="refresh" content="1;" /]
[script type="text/javascript"]
window.onload=function(evt){
var obj=document.getElementById("my-element");

obj.attachEvent("onclick",fn_handler);

/*the closure*/
var fn_handler=function(evt){
alert("hello world!");
};

/*in order to observe the leakage*/
obj.bigString=new Array(1000).join(new Array(200).join("XXXXX"));
};//onload
[/script]
[/head]
[body]
[div id="my-element"]cccc[/div]
[/body]
[/html]



Here the DOM node ("my-element") is referencing the closure (fn_handler) through its onclick attribute.

OTOH the obj variance that is within the scope of the closure (fn_handler) is referencing the DOM node ("my-element").

A la circular reference!

Since the JScript garbage collector is a mark and sweep GC, you may think that it should handle circular references. And in fact it does. However this circular refernce is between DOM and JS worlds and DOM and JS have separate garbage collectors. So they cannot cleanup memory in situations like this.

Microsoft admits IE's leak and says:

"Don't use closures unless you really need closure semantics. In most cases, non-nested functions are the right way to go"

I don't agree with them. If something is useful, but their impementation is buggy, why should I need to avoid using it. The bug has to be fixed not avoided.

So you have several choices at hand:

1. You don't care and pray that your application doesn't blow up.
2. Write your own garbage collection mechanism (not as difficult as it sounds)
3. Don't use closures.

So my humble advice is, use closures (they are extremely useful) but know the consequences of it and handle them accordingly.

One simple approach is to write a closure that unloads all the events, does does other necessary cleanup and unloads itself as a final step.

Some compatibility results for onbeforeunload:

Opera 8 -> *it does not work*
IE -> works okay
Moz -> works okay
Saf and the rest-> not tested

Here is what ppk says about Opera' onunload:

"In Opera load and unload do not fire when the user uses Back or Forward to enter or leave a page, or when the user closes the window."

... onload support of opera is similar. Again PPK says:

"Opera itself says this is the correct way to handle onload. Although this may be true, it will certainly cause compatibility problems. "

Here is another quote from someone else:

"IE4+/Win, Mozilla 1.7a+, Netscape 7.2+, and Firefox support onbeforeunload"

At least Safari fully supports onunload event. I am not sure whether it supports onbeforeunload, and if it does whether it supports it correctly.

Having seen that Opera does not have the memory leak problem at all, the onunload fix is basically for ie and moz. In short, I think I'll stick with onunload.

Or better use a switch like:

var g_bul_fired=false;
window.onbeforeunload=function(evt){
g_bul_fired=true;
... cleanup ...
};
window.onunload=function(evt){
if(!g_bul_fired){
... cleanup ...
}
};

As you may already know, creating closures in IE may generate memory leaks:

"The Internet Explorer web browser (verified on versions 4 to 6 (6 is current at
the time of writing)) has a fault in its garbage collection system that prevents
it from garbage collecting ECMAScript and some host objects if those host
objects form part of a "circular" reference. The host objects in question are
any DOM Nodes (including the document object and its descendants) and ActiveX
objects. If a circular reference is formed including one or more of them, then
none of the objects involved will be freed until the browser is closed down, and
the memory that they consume will be unavailable to the system until that
happens. "

says Jim Ley.

And Laurens proposes a solution for it: http://laurens.vd.oever.nl/weblog/items2005/closures/

After examining the code, I thought, that much lines of code was kinda over-complication of the problem.

Since I am ill; for the time being, I am spending my whole weekend at home and to reduce the boredom I wanted to propose another solution.

I created several test cases to see how the modern browsers handle the memory leakage problem:

I use four seperate HTML files.

But before starting, you may want to download the entire project (366Kb) along with png and gif images and test files. However use them with caution. I do not take any responsibility if your system crashes, your favorite browser hangs, an earthquake strikes your pc whatsoever.

I've slightly modified Laurens' HTML. I have two test cases:

Here is the HTML for IE .
And HTML For Mozilla-based browsers.

As you may see from the code, the pages refresh themselves every 1 second to demonstrate the leak scenario.

I've tested the "ie test case" in IE, the "mozilla test case" in mozilla.

I've tested both test cases in Opera since it can behave like IE
or like Mozilla (i.e. it can handle both attachEvent and addEventListener)

The CPU utilization and memory graphs are as follows:

Internet Explorer

1. click to view the image.

2. after closing the browser.

You can clearly see the ramp out there.

Mozilla FireFox

1. click to view the image.

2. after closing the browser.

As you can see, mozilla shows a ramp as well. Although IE's ramp is steeper, mozilla also has memory leak problems. Besides mozilla exhibits an exceptionally high CPU utilization (which shows that its not as good as IE in Array operations and String manipulation.

Opera

I think I'm gonna change my browser preference. Opera (8) was the best of all those browsers both in terms of CPU utilization and memory stability.

1. Here is opera using attachEvent.

2. Opera using addEventListener.

No memory leak, no inefficiency in CPU usage. Opera simply rocks!

I did not test it in Netscape because it either uses IE's or Mozilla's rendering engine. So the results would not be worth examining.

Having seen the leakage issue here is my solution for it:

just add the bold line for IE and you are done.

window.onload=function(evt){
...
/*Make sure we see the leak*/
element.bigString = new Array(1000).join(new Array(200).join("XXXXX"));
/*schedule for cleanup*/
window.onunload=function(){ element.detachEvent("onclick",fnc); };
...
}

And for mozilla the fix is similar:

window.onload=function(evt){
...
/*Make sure we see the leak*/
element.bigString = new Array(1000).join(new Array(200).join("XXXXX"));
/*schedule for cleanup*/
window.onunload=function(){element.removeEventListener("click", fnc, false); };
...
};

One line of code and you are done.

If you want something cross-browser, you may try sardalya's EventHandler object (which is in some revision, but the current version works okay none the less.), which utilizes an EventRegistry and unloads the registered events so that you do not need to write the unload code yourself.

And here are the screens after the fix

1. internet explorer after applying the fix.

2. mozilla after applying the fix.

3. Opera after applying the fix. (attachEvent version)

4. Opera after applying the fix. (addEventListener version)

Look ma! No ramps in memory usage! Not difficult huh?

* * *

And here are those three browsers' rankings according to the test results.

garbage collection:

Opera -> gold medal
Mozila -> silver medal (the memory leak ramp was hardly recognizable)
IE -> disqualified (sorry for that)

String & Array Manipulation:

IE -> gold medal.
Opera -> Silver medal (very close to IE but IE eats 1-2% lesser CPU and seems more stable)
Mozilla -> disqualified (sorry good friend, 90% CPU utilization on the average, whereas others use around 8-10% of CPU.)

Overall Memory Usage (in fixed mode):

IE -> gold medal
Opera -> silver medal
Mozilla -> bronze medal

Of course you should keep in mind that I am using a W2K Server box, so it may use memory more efficiently in MS-friendly apps.

That much talk for today,
Hope it helps someone.

Cheers!

After mostly finishing the Editor. I started the re-design of sarmal.

The key concepts will be:

1. A fluid layout.
2. Standards-compatibility, Usability, Accessibility (the magnificient trio)
3. em-based fonts (former design was on a pixel-perfect basis)
4. a "what's new" section.
5. a cleaner navigation and focus on content.

After all those; I will finalize things in my local development environment, and republish the site. Currently sardalya has a newer version with important add-ons, bug fixes and optimizations. However I am not able to publish it until I finish the design and test of rest of my local site (there are some js/css errors around).

Following the republish, I think I will focus on the backoffice. The first thing in my ming is to create an article generation module.

After discussing about encoding in thelist, I thought that it would be nice to share the two methods that I use to convert to and from server encoding and database encoding:

public static string ServerStringToResponseString(string value){
 return Encoding.GetEncoding(setting.DatabaseCodePage).GetString(
  Encoding.GetEncoding(setting.DataReadCodePage).GetBytes(value)
 );
}

public static string ResponseStringToServerString(string value) {
 return Encoding.GetEncoding(setting.DataReadCodePage).GetString(
  Encoding.GetEncoding(setting.DatabaseCodePage).GetBytes(value)
 );
}

Hope it helps someone.

I've finished version 1.0.1 of the Editor.

I think the Editor is a too generic name for a DOM editor. So I'll give it a new name which will sorta create a brand for it. Currently DOMEditor comes into my mind. Not that creative but better than "Editor" anyways.

you may want to read the updated article.

This is one further step in my article creator module that I'll use in sarmal's back end.

Well, I realize that blogs are the best place to write TODO lists. I have a local TODO database app using MySQL at home, but blogging is better and fun.

Some other ideas for the editor:

MOSTLY DONE.
WILL NOT CURENTLY IMPLEMENT THE SPLIT AND MERGE/SPLIT STUFF AND LIST TABLE ETC. MAY BE LATER...

1. Add tips and help definitions:
   1.1. Don't use extra spaces and don't press enter.
   1.2. If you need to press enter consider creating a new paragraph.
   1.3. Splitting a node to its words and joining several nodes together is a useful tool.
   1.4. Did not implement nested tags because it's not that necessary (may be it'll be done in the next version)
   1.5. Did not implement lists / tables etc. One can live without them (may be in next version)
2. split to words will work like this:
   lorem ipsum dolor.
   [lorem ][ipsum ][dolor.]
3. add drag support:
   CopyCatLayer extends DraggableLayer
   
   lyr._source
   lyr._destination
   
   (shiftctrlalt)-dragging onto a node of the same type will swap the nodes.
   dragging onto a node will move the source node just before the destination node.
   

In one of my recent blog entries I mentioned the excellent and free JavaScript editor JEdit which is an add-on to Eclipse IDE.

Since I cannot use it with visual studio dot net IDE to edit my aspx and js files of my web projects I merged the workspaces of two IDEs.

That is I pointed C:\Inetpub to Eclipse as a workspace. This way Eclipse sees all my wwwroot and when I edit a js file with it, it is immediately reflected to the visual studio web project.

May be it is madness. But JEdit is a real time-saver for coding JavaScript so imho it's worth the effort.

Since I am adding new links and modules. I think I need a design review as well.

http://www.sarmal.com/

- Too many curls and gradients and the layout is not liquid.
- I think I can utilize the space better and neater.
- the layout currently barely fits 800*600. can be better adjusted.
- the LHS links are too big. (plus they had better be an ul instead of div and anchor combinations.
- the CSS is bloated.
- the google ads do not fit right in the layout.

Overall, I need some simplicity and freshness. I'll re-design the site, after I finish up with the article Editor. But before doing all that redesign, comes the design of my portfolio & personal web page which is down (for re-design) for more than 3 months.

A new version of sardalya is emerging:

After several optimizations, the code is better organized. Moreover I examined a more consistent behavior and a far better CPU utilization when Dragging layers.

So what's new in the new version:

1. Static object are now accessed via their name so instead of calling
   
   new EventHandler().addEventListener
   
   you simply call
   
   EventHandler.addEventListener
   
2. Entire code reviewed line-by-line. Parts of it are optimized. Unnecessary parts are removed.
   
3. Three or four tiny bugs that were hiding under the carpet were killed (the code is debugged I mean :) )
   
4. Two new objects are added: WindowObject and DOMManager.
   
5. We now have a Article Editor which is a case study by itself.
   
6. Instead of global control variables we now have controller objects: DraggableLayerController, CollapseManagerController and PreloaderController.
   
7. And much more that I cannot remember.

Just wait for the new release and see the difference.

After finisihing with sardalya I plan to continue developing the Editor as I promised.

After some brainstorming here are the things that I plan to implement. Just writing down them so that I won't forget later:

Methods to add:

-split : split a textual node in the middle to two equivalent text nodes.
-splitToWords : as its name implies.
- union -> combine 2+ nodes. First union inline ones. Then block level ones.
- add a link -> easy.
- surround to add nested tags
test surround( em ) -> em strong test strong* em*
-add image (possibly with the help of some ajax lookup)

I'd like to thank everyone for their special attention on the rich content editor. Your mails gave me motivation to enhance the editor further.

Though I will first review and optimze sardalya before diving into the Editor.

The Editor is almost complete. I have a few things to add but currently it works anyway.

You may find an article at:
http://www.codeproject.com/useritems/DOMEditor.asp

I've written the article with the Editor :)

I will add it to sardalya, but I have to code review sardalya before doing any add on to it.
Else things will get pretty messy.

After reading here and there and everywhere about encoding, localization, globalization etc. here are my final findings:

• In .net Strings do not consist of simpe byte arrays, but it is a unicode-aware char array. To be more specific: Internally, .NET applications use UTF-16 Unicode encoding for string data.
  
• If no encoding is specified, then platform's default encoding is used by default (of course) which may be different than your local encoding.
  
• The byte array extracted from a String explicitly (str.getBytes("iso-8859-1") returns a different byte array than str.getBytes("iso-8859-9"))
  
• When you convert a byte array to a String using encoding E, the bytes are mapped to what is called "unicode code points". So if you convert a byte[], that is extracted from an iso-8859-9 encoded String, to a iso-8859-1 encoded String, some characters might show up as question marks (?) or boxes. These are valid data but they are not printable on the screen. And yes the data is there. Just you cannot see it. This is because the iso-8859-1 encoding scheme does not have a mapping for those code points.
  
• Some Encoding translations (such as ISO8859_1 and ISO8859_9) are reversible. Here is a quote:
  
  "Not all encoders assume a one-to-one relationship between byte values and character values. To ensure a reliable translation, do not rely on the default locale encoder. Explicitly specify an encoder that uses a reversible translation."
  
• Let us explain it with a use-case:
  (Sorry for my laziness: the code is java-ish, not c#. Although what's important is the concept here)
  
  

  aString = aStream.toString("ISO8859_1");
  /*
   * assume that the stream is iso8859_9 encoded
   * but we convert it to an ISO8859_1 encoded String.
   */
  aByteArray = aString.getBytes("ISO8859_1");
  /*
   * These bytes belong to an iso8859_9 encoded stream and
   * we have now recoverd them since iso8859_1 
   * encoding is reversible.
   * (from the above quote)
   */
  
  

  
  

  Thus you can be sure that; when we create a String out of aByteArray
  using ISO8859_9 encoding; we will get our original String without any loss.

  
  

  Though this issue might not be apparent if the program was not tested under a non-western locale.
  

Side Note:
There is another issue called "round trip compatibility". That is when you convert a String from encoding A to encoding B and then back to encoding A you get your original String without any loss. Round-trip compatibility is not strictly related to the reversibility issue explained above but it's also another concept to consider when you try to internationalize your application.

As a final remark;

There ain't no such thing as 'plain text'.

Cheers for now.

References:

• http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4296969
  incorrect behavior of several character converters.
• http://www.i18nguy.com/unicode/codepages.html
  codepages at the push button.
• http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemtextencodingclassconverttopic2.asp
  Encoding.Convert method.
• http://www.simultrans.com/seminars/seminar199808.htm
  SimulTrans localization seminar: Demiystifying Unicode.
• Java(tm) Development Kit - JDK(tm) 1.1.7 Software README
• http://www.joelonsoftware.com/articles/Unicode.html
  The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• http://www.cl.cam.ac.uk/~mgk25/unicode.html
  UTF-8 and Unicode FAQ for Unix/Linux

The magnificient trio (me, my love and mügü) visited the remaining buildings of The 9th International Istanbul Biennial.

This part was more interesting than the previous one.

The most interesting of all wat the artwork of Y.Z. Kami, who is best known "for his portraits of humble, unremarkable people with compact and acute gazes".

For the Biennial, Kami photographed scenes from Konya during "Mavlid" (the celebration of Prophet Mohammed's birthday).

And there were his sculptures all around the floor.

I cannot exatly tell about the artwork. You have to see it for yourself. There were stone circles with various sizes on the entire floor.

Just quoting a passage so that you may have a feeling of what it looks like.

"In Kami's sculptural installation, Sufi philosophy is echoed by the circular orbit of the alabaster stones, each one painstakingly preapared and inscribed with verses from Mevlana's The Book of Shams-e Tabrizi.The scultpture evokes, in one sweep, Kami's Persian heritage, the stonework in Seljukid, religious architecture in Central Asia and the ornamental aesthetics of that region that have been fundamental to his practice for the last ten years."

---

As a side note: point is to man, and circle (or sphere) is to God in Sufi philosophy. Not only in Sufi school but also in many ecsoteric schools (in ancient Greece and ancient Egypt, --hypotetically speaking: in Mu and Atlantis, may be--) the usage the same symbolism to express god-human-god, point-sphere-point relationship is worth thinking.

That's for today.
Cheers!