Well, I have been kind of absent from the blog lately and that is for several reasons. One is that I have been waiting for some news that would determine my direction as a professional developer. The other is that I have re-acquired a passion for chess. So, between work at the office, watching chess videos, playing chess with my PDA and watching all seven seasons of Star Trek Deep Space 9, I haven't had much time for blogging.

Also, when you think about it, the last period of my programming life has been in some sort of a limbo: switched from ASP.Net to WPF, then to ASP.Net again (while being promised it would be temporary), then back to WPF (but in a mere executive position). Meanwhile, Microsoft didn't do much to help me, and thus saw their profits plummet. Well, maybe it was a coincidence, but what if it wasn't?

I am complaining about Microsoft because I was so sold into the whole WPF/Silverlight concept, while I was totally getting fed up with web work. Yet WPF is slow, with no clear development pathway when using it, while Silverlight is essentially something else, supported by only a few platforms, and I haven't even gotten around to use it yet. And now the Internet Explorer 9/Windows 8 duo come in force placing Javascript and HTML5 in the forefront again. Check out this cool ArsTechnica blog post about Microsoft's (re)new(ed) direction.

All of this, plus the mysterious news I have been waiting for that I won't detail (don't want to jinx it :-S), but which could throw me back into the web world, plus the insanity with the mobile everything that has only one common point: web. Add to it the not too enthusiastic reaction of my blog readers when starting talking about WPF. So the world either wants web or I just have been spouting one stupid thing after another and blew my readers away.

All these shining signs pointing me towards web development also say that I should be relearning web dev with ASP.Net MVC, getting serious about Javascript, relearning HTML in its 5th incarnation and finally making some sense of CSS. Exciting and crazy at the same time. Am I getting too old for this shit or am I ready for the challenge? We'll just have to see, won't we?

I personally think that the IE8 developer tools are better than Firebug, but let's face it: Firebug was first. Besides, Firebug has also a completely javascript version called Firebug lite that you can inject into any page. Well, you might say, as a developer it is a nice tool, but how can I, the Internet surfer, use this in any page? And the answer is: the favorites links!

It all started from this brilliant post: Bookmark to inject FireBug Light into Internet Explorer. that showed how you can create a specific URL file, add it to the Favorites folder of your Windows user and then use it on any page. Elegant it may be, but it's lazy. It only works on pages that have loaded jQuery. So I did the version that works with simple javascript.

Then I realized that, since I like the Internet Explorer tools better, this is useless for me. How cool would it be to have Firebug lite on Chrome, which has yet to provide a decent developer tool. And it's even easier! Here is how you do it.

For Internet Explorer, follow the steps described in the ElegantCode post but use generic javascript: create a file called Firebug.url containing

[DOC_FirebugUI] 
ORIGURL=about:blank 
[{000214A0-0000-0000-C000-000000000046}] 
Prop3=19,2 
[InternetShortcut] 
URL=javascript:var script=document.createElement('script'); script.type='text/javascript'; script.src='https://getfirebug.com/firebug-lite.js';document.getElementsByTagName('body')[0].appendChild(script); void(0);
IDList= 
IconFile=http://getfirebug.com/img/favicon.ico 
IconIndex=1

then save it in the user's c:\Documents and Settings\{UserName}\Favorites folder.

For Chrome, you only right click on the bookmarks bar, choose Add Page, then enter the url in the file above:

javascript:var script=document.createElement('script'); script.type='text/javascript'; script.src='https://getfirebug.com/firebug-lite.js';document.getElementsByTagName('body')[0].appendChild(script); void(0);

And that is it. Click on the link in any of the said browsers and a small icon will appear in the bottom-right corner. Click on it and voila: Firebug! Of course, one can install the Firebug extension, which is actually also a javascript link, albeit really weird, but I think this is more clear and user friendly.

I didn't know about this until today, but the technique itself is so simple that it must have worked on every browser from the first introduction of the :visited CSS selector. Think about it: in your site you have a css style that colors the visited links with a specific color. Then you place in your page a list of links to other sites (maybe in a hidden container). Using Javascript, you inquire the computed style for each of the links. Taadaa! You now know the links in your list that the visitor has recently visited.

You can download a PHP demo of the technique from here. Ain't this neat?

Update: I since found another interesting article, showing how a site could (on certain browsers that are not Internet Explorer >:) )see if you are logged on to another. Here is the link.

Wow, long title. The problem, however, is simple: when adding an inline Javascript script block that changes the window.location or window.location.href properties, FireFox and Chrome do not retain the original URL of the page in the browser history. The Back button doesn't work correctly.

Going to the Mozilla page for developers I find that both redirect methods are equivalent to location.assign(url) which implicitly sets the url in the browser history chain, as opposed to location.replace(url) which doesn't affect the history and just replaces the current URL. So I get to use one method and get the behaviour of the other!

Enough said. Long story short, the behaviour was not reproduced if the same script was being loaded in a button click event. That means it is another of those annoying Gecko page load completed issues.

The solution? Instead of location=url; use setTimeout(function() { location=url; },1);. I know, really ugly and stupid. If you find a better solution to cause a redirect from javascript, please let me know.

I have been working on a jQuery based control library for a few months and today I replaced the embedded 1.3.2 version with the 1.4.2 version. I immediately noticed an increase in performance. Before, the profilers were screaming at the CLASS function, immediately followed by css. Now, the CLASS function seems to work 10 times faster. Some resizing script that I was using and was kind of sluggish now behaved all perky. I personally believe John Resig did some good things in the new 1.4 jQuery release.

Also, trying to optimize javascript code and having attended a Javascript training recently, I reached some conclusions that I want to formalize and place in a blog post, but just in case I don't find the resources, here are some quick pointers:

• Javascript has function scope and closure support, which means that a variable defined in a function will be accessed faster than one that is outside or global, also that any function you create inside another function remembers all the variables declared in that scope. You should declare local variables in init functions and also declare local functions that use those variables, essentially guaranteeing faster access and that no one will overwrite them accidentally. Also, cache in this way the global variables and functions that are commonly used, like document
• Cache the jQuery objects, not the elements. Not only it reduces the overhead of recreating them, but they "track" the underlying elements even if one removes/adds/modifies them.
• Use the context format find method of the jQuery selector to get to child controls.
• There are a lot of free profiling tools for javascript: dynaTrace Ajax is pretty cool, but also tools like the IE8 developer toolbar profiler or the famous Firebug and its many addons. You should use a profiler to understand where your bottlenecks are, they might not be where you expect them to be.
• Redrawing the DOM elements is an expensive operation and changing the style of an element has many side effects. You should check if the value you wish to change in the style of an element is not already set. For example jQuery has the outerWidth and outerHeight functions that should return the same sizes as the value you pass to width and height (at least for divs with overflow not 'visible')

Here is some code that demonstrates the above rules:

/* set an element to be of the same size as another element */
function sameSize(base,target) {
  // jQuery and cache
  base=$(base);
  target=$(target);
  // local variable will be remembered 
  // and accessed faster
  var lastSize={
    width:-1,
    height:-1
  };
  // local function will be private and also accessed faster
  function checkSize() {
    // get the outer size of the base element
    var baseSize={
      width:base.outerWidth(),
      height:base.outerHeight()
    };
    // compare it with lastSize
    // do nothing if this size was handled before
    // use the !== inequality for extra speed (no type conversion)
    if (baseSize.width!==lastSize.width
      ||baseSize.height!==lastSize.height) {
      // get both the declared and real size of the target element
      var targetSize={
        declaredWidth:target.css('width'),
        declaredHeight:target.css('height'),
        width:target.outerWidth(),
        height:target.outerHeight()
      };
      // only change the size (and thus fire all sorts of events
      // and layout refreshes) only if the size is not already
      // declared as such or simply the same for other reasons
      // like 100% layout in a common container
      if ((targetSize.width!==baseSize.width
          &&targetSize.declaredWidth!=baseSize.width+'px')
        ||(targetSize.height!==baseSize.height
          &&targetSize.declaredHeight!=baseSize.height+'px') {
            // Javascript object notation comes in handy
            // when using the css jQuery function
            target.css(baseSize);
          }
      // cache the handled size
      lastSize=baseSize;
    }
  }
  // bind the function to any event you want to
  // since it will only do anything if the size actually
  // needs changing
  base.bind('resize',checkSize);
  $(window).bind('resize',checkSize);
  setInterval(checkSize,1000);
}

/* faster getElementById */
// use a local anonymous function as a closure
(function(){
  // cache the document in a private local variable
  var d=document;
  byId=function(id) {
    return d.getElementById(id);
  };
  // a lot more code might come here, all using byId and accessing
  // it faster since it is local to the closure
})();
/* you might think that this doesn't do much if no other code
in the closure, since byId would be a global function and just as
slow to be accessed, but remember that you only need to find the
function once, while document.getElementById needs to find document,
and then getElementById. And document is a large object. */

/* find the tables inside a div using the context syntax */
var div=$('#myDiv');
var childTables=$('table',div);

You have an HTML element with two or more classes in the class name, something like "class1 class2" (separated by space and not by comma as some sites wrongly suggest) and some of the rules in the two classes overlap. What is order in which rules are read and do they overwrite other rules that are already in place?

I made a test HTML and I noticed that the rules in class2 overwrote the ones in class1, but since I had asked the wrong question, I had the wrong answer. If I changed the class name to "class2 class1" the result was the same!

It appears that the rules in CSS classes that overlap are overwritten based on their order in the document and latest win, overwriting the previous. In other words, if class1 would be defined later than class2, then its properties would overwrite class2's. The order of classes in a class name is complete without relevance!

There is one spiny issue when trying to move a html source from inline to CSS styling and that is the parameters of the table: cellspacing and cellpadding in particular.

From my tests it appears that cellpadding is overwritten by the CSS styling (the first time I ever see an inline attribute being overridden by CSS), however cellspacing does not. In order to remove the default cellspacing, use border-collapse:collapse on the table.

In order to set the table cellspacing through CSS, use the border of the td elements. Unfortunately, it doesn't work with transparent color, so you must set it to the color of the background. No luck if the background is an image. Margin on the cells doesn't work. Who uses cell spacing, anyway? Non Internet Explorer browsers have a table property called border-spacing, but it only works for some DOCTYPEs even in other browsers, so it's not reliable.

To set the table cell padding through CSS, just use the padding property of the cells. As I said earlier, it overrides the cellpadding property of the table.

So, in order to set 5px cell spacing and 5px cell padding through CSS, use this:

 body {
  background-color:white; /* use the same color for the border of cells */
 }
 table {
  border-collapse:collapse; /* remove default cellspacing */
  border-spacing:5px; /* it works on some browsers on some DOCTYPEs */
 }
 td {
  padding:5px; /* cell padding */
  border:5px solid white; /* cell spacing */
 }

You should set the padding as a general rule for all the TDs on the page. CSS classes like

table.MyClass td { padding:1px }

will affect all cells in all child tables! The more general the CSS selector, the easier will be to avoid overwriting some of your normal settings. For example, the CSS rule above would override

.myTD { padding-right:3px; }

because it is more specific.

Internet Explorer added something called expression to CSS, something purists have booed at for mingling javascript and CSS. Well, boo back! I happen to like stuff that can solve problems. If I were at Microsoft I would create an entire subset of javascript and css functionality. But hey, that's just me.

Anyway, I have decided to use expression to run an initialize function on newly created elements. It would work like this:

initialize:expression(window.initializeElement?initializeElement(this):null);

This CSS bit tells Internet Explorer (and none of the other browsers) that the initialize style property should get the value of the initializeElement function every time the browser refreshes the layout of the element. In the function itself I would do something like this:

function initializeElement(elem) {
  if (!elem.style.initialize) {
    doSomethingWith(elem);
  }
  return true;
}

This basically executes doSomethingWith on each element matched by the CSS rule and only once.

Good theory, but in practice it was terribly slow and, after a while, it managed to kill Internet Explorer with a strange System.AccessViolationException: Attempted to read or write protected memory error.

What happened? The slowness, I gathered after a while, was caused by the function doSomethingWith because it changed the style of the element. That meant that the css rule was being applied again before the function ended and returned true. Changing things to:

function initializeElement(elem) {
  if (!elem.style.initialize) {
    elem.style.initialize=true;
    doSomethingWith(elem);   
  }
  return true;
}

fixed it.

The error that killed Internet Explorer was even stranger. After a while I narrowed it down to using jQuery. I have no idea what it did, probably trying to access computedStyle or something like that. The thing is that changing an $(elem).height() with elem.offsetHeight solved it.

I've encountered this situations a couple of times, what happends is that, at the end of the body of the document or of a major element like a form or a page wide div, sometimes (I haven't really been able to reproduce it at will) hidden elements start having height. This includes hidden divs and spans and even script elements. It seems to be happening mostly on Internet Explorer, but the behaviour has reportedly also been found on Opera and even Chrome.

For a specific example, I had this page with a lot of script tags at the end of the form element. Curiously, only when some spans with display:none were added at the end of the body element the problem would become evident as the height of the page would increase by 12px and a vertical scrollbar would appear. I also encountered the issue when I moved, via script, the calendar popup div for a datetime editor at the end of the body element to solve a positioning issue. Both were happening in "quirks mode" because I am forced to use a HTML 4.01 Transitional doctype.

To me it seems that the browser considers that script tags have no layout, so there is no problem to put them all one above the other in that extra 12px bit, but it does consider it needs to reserve that 12px space. Well, does it have layout or doesn't it?

I looked on the web for people with similar problems and I have encountered very few that actually tackled it. Here is one example of a solution from the Perishable Press blog: Prevent JavaScript Elements from Breaking Page Layout when Following Yahoo Performance Tip #6: Place Scripts at the Bottom.

For short, the solution in the above link is to place all the scripts at the end of the page, but inside a hidden div element. If you have access to all the layout, that is a great solution. However, I found that I could not use it, since the scripts were not added by me and I had no control over their placements. So I found an alternative solution, after noticing that the extra size would dissappear if the popup div of a control was shown.

Well, my solution is quite obvious: if there are issues with hidden and script elements placed at the end of the page, then why not try to add an element at the end of the page and thus make hidden elements NOT be at the end? :)

A short jQuery script did it for me:

$('script').each(function() { 
if ($(this).height()>0 && !$('form').children(':last').is('div.scrollFix'))
  $(this).parent().append('<div style=\'position:absolute;background:transparent;width:0px;height:0px;line-height:0px;font-size:1px;\' class=\'scrollFix\' />'); 
});

or, in normal Javascript:

var scripts=document.getElementsByTagName('script');
for (var i=0; i<scripts.length; i++) {
  var script=scripts[i];
  var parent=script.parentNode;
  var lastChild;
  if (parent&&parent.childNodes.length>0)
    lastChild=parent.childNodes[parent.childNodes.length-1];
  var isFixed=(lastChild&&lastChild.tagName&&lastChild.tagName.toLowerCase()=='div'&&lastChild.className=='scrollFix');
  if (script.offsetHeight>0&&!isFixed) {
    var div=document.createElement('<div style=\'position:absolute;background:transparent;width:0px;height:0px;line-height:0px;font-size:1px;\' class=\'scrollFix\' />');
    parent.appendChild(div);
  }
}

The script is improved by actually scanning the last element of the parent element for the hidden div so that it doesn't add a zillion divs, one for each script tag. However, it doesn't cover the situation where other elements, rather than the script elements, cause the problem. However, the principle remains sound.

A very informative article, one that examines the differences of CSS interpretation between versions of Internet Explorer (and ignores any other browser), appeared yesterday in Smashing Magazine. Since I found it very informative, I am blogging the link to it: CSS Differences in Internet Explorer 6, 7 and 8.

I had this situation where in Internet Explorer, in quirks mode, I would open a dropdown calendar (so showing an absolutely positioned element that was until then hidden) and the scrollHeight of the entire page would increase by a magical 19px.

This was caused by a fix for another problem, where the displayed calendar would not position itself under the text input element where it should have positioned, so I made it so that the displayed calendar would be the last child of the body element. This way it would always show in the correct position, but displaying this situation when elements were trying to fit in the height of the page.

I could not find the cause other than a problem in the Internet Explorer render engine, but I did find a fix. Instead of placing it at the end of the body element, place it at the beginning. With jQuery that simply translates into:

if (!elem.parent().is('body')) $('body').prepend(elem);

Notice my use of prepend instead of append.

Today I've updated my computer with the latest patches from Microsoft and then, starting a project, I noticed that it didn't look right in Internet Explorer 8. For example a table with an empty td of width 1px looked as if having 4px. Setting it to 2px or above made it look of having 2px or whatever value I had chosen. I have solved the situation by adding content to the td in question (a simple  ), but before today I have not had this problem.

Update: This blog post was previously called "Microsoft updates breaking changes?" but in the meanwhile I have determined what the problem was. It was the zoom! I had my IE set to 75% zoom. That caused the weird behaviours and appearance.

The solution is still working, but the problem should be rephrased as "Why do the widths of td elements behave strangely when setting smaller zoom in Internet Explorer?".

Just for kicks I tried duplicating the problem using the zoom:75% style setting on body and, even if it looked bad too, it was a completely different behaviour.

Usually this happends in IE, but it may happen in a various other situations, given that Internet Explorer is famously bad, but also has to fight with all the backward compatibility and that new "innovative" browsers are on the way.

Let me make this easy: if it's a weird sixteen pixels difference (or somewhere around 16) then you probably are in one of these situations:

• scrollbars - that you may not see, but they are there. I've just met this issue with a table of 100 percent width placed in a div of 100 percent width and it happened in IE8!
• line-height - this is usually with Internet Explorer 6 or less, divs that are 16px in height when they have no content and have a specified lower height
• font-size - also something from the older browsers

I have this very precise requirement I am working on: a collapsable panel that has rounded corners of fixed size and a background image or a gradient, both needed to stretch with the panel, which would be vertically resizable by javascript. Also, the HTML 4.01 Transitional DocType will be used on pages. The only respite given is that the solution should work only on Internet Explorer.

I have first tried some jQuery alternatives, but I am not happy with them. Even if the rounded corners would have been what I was looking for (and they were not), the background stretching is a difficult feat to master in HTML. Even so I have cropped up something that takes the entire content of the panel and relatively positions it over an absolutely positioned image that is then stretched by javascript to its needed dimensions. However, all this relative and absolute positioning requires a lot of event driven javascript (when the events themselves are not really there, so I must also create new browser events!) and it has been shown to break either layout or functionality like the one for collapse.

Enter VML, an obscure web technology from Microsoft that has a RoundRect object that can have a fill of an image OR a gradient, stretched to the full size of the element. Can you see it? I was already planning the blog entry, detailing the masterful ASP.Net control that would change the world of web development forever.

Back to real life now. First of all, the RoundRect element does have an arcSize property that determines the percentual size of the rounded rectangle. By percentual, I mean that resizing the element would lead to larger corners. I don't need that. Another nice surprize was that I can't either read or write the arcSize property from Javascript, it throws an error. People have complained about it before and their solution was to disconnect the element from the DOM, change the arcSize, then add it back into the DOM. It didn't work for me.

After wasting about half a day with this, I concluded that the RoundRect was a lost cause. Enter Shape! A Shape is a VML element that can take any shape determined by a path. The path has interesting primitives like qx and qy which mean "draw an arc to this position". It appears that a Shape can easily take the place of the RoundRect. What was even nicer, the path attribute could be changed at will by javascript.

<v:shape strokecolor="blue" strokeweight="1" coordorigin="0 0" coordsize="203 103" style="width:200px;height:100px"
path="m 2,0 l 198,0 qx 200,2 l 200,98 qy 198,100 l 2,100 qx 0,98 l 0,2 qy 2,0 e"></v:shape>

The code above is a 2 pixel rounded corner rectangle of size 200 by 100. To add a stretched background image or gradient, a v:fill element must be added as a child of the shape and you are done!

I was extatic, finally having solved the problem that had haunted me for days, until I noticed that, unless I specify the width in pixels, the shape would behave really strange. I was commited not only to a panel that needed to be defined as percentual or expanding with the content, but also to HTML 4.01 Transitional DOCTYPE. In this particular situation, placing two shapes in a table, let's say, even if the table size was specified or, indeed, the sizes of the TD elements, in percentages or pixels, the shape would just expand to its maximum possible width.

I got stuck here. The control worked perfectly when the width was specified in pixels. Anything else just throws a big wrench into the works and makes it wanna go boom. In a fit of anger, I just replaced the obsolete doctype with the modern XHTML 1.1 one. And it worked, but only on Internet Explorer 8, not any of the previous versions of the browser.

Therefore my only option now is to either abandon the technology completely or to convince people to change the DocType for all their legacy pages. How fun is that?!

And before you write the usual crappy "Microsoft sucks! Internet Explorer sucks!", try giving me a solution for my request that would at least work in another browser. Was it so difficult to recognize the need for a stretched background image and custom shaped containers ?!

I was having real trouble with an html menu. Every time I would move the mouse over an item, a large gray area would appear over the screen. This only happened on Internet Explorer 7, not Internet Explorer 8 or any other browser. When I changed the Doctype from XHTML to HTML I reproduced the error on IE8 as well.

Strangely enough, when I first found the source of the problem, a border of 899px , I thought it was a browser javascript incompatibility. How could it be differently? The CSS was mine and the JS was not. Obviously it was their fault. However, after reproducing the problem in IE8, I could use the more advanced developer tools available and I realised that the strange border width was not part of the element style, but the CSS class style itself. It was there, the interpreted style for my menu control class: border: 899px;.

I rechecked the CSS and I found the actual problem: no hash in front of the colors! So the browser found something like D8C89A instead of #D8C89A, did a weird parse on it, got 899, then considered it a size in pixels!

Hopefully, someone will read this and save themselves a lot of grief and time.