Now, that title doesn't much, but it's the only one I could think of, because I haven't yet determined the source of the problem. Baiscally, what happends is that there is a difference of behaviour between style included directly into the page and actually using javascript to add to the head of the page a dynamically created link element.

I have no idea what exactly is going on, but I will try to explain it based on the evidence. There was this menu control, an Infragistics Web Menu from the NetAdvantage 9.1 suite, that, given the right styling, would look exactly like what I wanted. After setting that style in a css file I decided to load it using a javascript dynamic load just in case the control would be rendered only on asynchronous postbacks. And it worked perfectly. In IE8, Chrome and FireFox. However, when tried on IE7, it exibited the strange behaviour that, on mouse over, the entire table that the menu was rendered as expanded to fill the screen and was completely blank. After extensive attempts to capture the element with Internet Developer toolbar I noticed that the border-bottom-width and border-left-with were abnormally high, like thousands of pixels.

As of now I know not the cause of this. I can tell you, though, that moving the same style from the dynamically loaded CSS into a statically loaded one or by copying that style in a style tag in the page fixed the issue. I really hope it helps someone lose less days of their lives attempting to see what is going on.

Also, if you know the cause of this, or maybe other pages reporting the same behaviour or, I dare hope, a fix, please let me know.

You know how difficult is to test a web site on the many (conflicting) versions of Internet Explorer browsers that were created. While most of us don't even bother to test for anything lower than IE 6.0, there are major differences between IE6, 7 and 8. I used to use something called MultipleIEs before that contained IE versions up to 6, but now I found something that looks even better: IE Collection, boasting IE versions up to and including Internet Explorer 8.0.

I have installed it and so far I had no major issues with it. It does seem to change some part of the default IE configuration, so take a look there after you finish installing it.

I needed a dynamic menu control for my site. So, of course, I tried to use the ASP.Net Menu control (with its many failings when following CSS standards). It was a painful failure. It didn't work in either Internet Explorer 8 or FireFox 3! That was especially strange since I had used the control in a bunch of sites and it worked back then!

Long story short:

<DynamicMenuStyle CssClass=adjustedCssIndex />

where adjustedCssIndex is a CSS class that specifies the z-index property:

.adjustedCssIndex { z-index:100; }

Long story, it seems that the control assumes there is a default z-index value set by the browsers; Bertrand Le Roy from Microsoft says as much in his blog, and discloses a patch fix.

However, as you can see in that post's comments, there is also a very simple CSS fix to all of this, by specifying the z-index.

I've spent about a day on a thing that I can only consider a FireFox bug. As a complete reverse from what I would expect from a javascript script, it worked anywhere but in FireFox! And FireFox 2.1, I haven't even installed 3.0 yet.

It concerned a simple javascript function from a third party that was supposed to get the absolute positioning of an element when clicked. I've written one myself a while ago, but it didn't work either! Here is the function that I was trying to fix:

function getPos(n) {
 var t = this, x = 0, y = 0, e, d = t.doc, r;

 n = t.get(n);

 // Use getBoundingClientRect on IE, Opera has it but it's not perfect
 if (n && isIE) {
  n = n.getBoundingClientRect();
  e = t.boxModel ? d.documentElement : d.body;
  x = t.getStyle(t.select('html')[0], 'borderWidth'); // Remove border
  x = (x == 'medium' || t.boxModel && !t.isIE6) && 2 || x;
  n.top += t.win.self != t.win.top ? 2 : 0; // IE adds some strange extra cord if used in a frameset

  return {x : n.left + e.scrollLeft - x, y : n.top + e.scrollTop - x};
 }

 r = n;
 while (r) {
  x += r.offsetLeft || 0;
  y += r.offsetTop || 0;
  r = r.offsetParent;
 }

 r = n;
 while (r) {
  // Opera 9.25 bug fix, fixed in 9.50
  if (!/^table-row|inline.*/i.test(t.getStyle(r, "display", 1))) {
   x -= r.scrollLeft || 0;
   y -= r.scrollTop || 0;
  }

  r = r.parentNode;

  if (r == d.body)
   break;
 }

 return {x : x, y : y};
}

As you see, it is a little more complex than my own, although I don't know if it works better or not.

Anyway, I found that the problem was simple enough: the element I was clicking did not have an offsetParent! Here is a forum which discusses a possible cause for it. Apparently the Gecko rendering engine that FireFox uses does not compute offsetParent, offsetTop or offsetLeft until the page has finished loading. I didn't find anything more detailed and there were just a few pages that seemed to report a problem with offsetParent null in FireFox.

I tried to solve it, but in the end I gave up. My only improvement to the script was this line:

while (r&&!r.offsetParent) {
    x+=r.offsetLeft||0;
    y+=r.offsetTop||0;
    r=r.parentNode;
};

which resulted in a more localised position, i.e. the position of the closest parent to which I could calculate a position.

In the end the problem was solved by restructuring the way the dynamic elements on the page were created, but I still couldn't find either an official cause or a way to replicate the issue in a simple, separate project. My guess is that some types of DOM manipulations while the page is loading (in other words, scripts that are just dropped on the page and not loaded in the window 'load' event which change stuff in the page element tree) lead to FireFox forgetting to compute the offset values or just even assuming that the page is never loaded.

Now, this is a stupid post. And By stupid I mean that kind of thing that if you hear about it you think "Oh, it was obvious", but if it happends to you you waste a lot of time trying to fix, then you think "Oh, it was obvious. If I blog about it I will sound stupid". Well, this kind of blog posts are the most important, I think, so here it is, sounding stupid:

I had a div, absolutely positioned and of fixed width, with a long text inside that would just not wrap! That means the div would either expand its width to accomodate my text (Internet Explorer) or bleed the text out (FireFox). Was it white-space:nowrap? No! Was it that some of the table cells that contained elements had the "noWrap" attribute? No! What the hell is going on?!

Solution and explanation: wrapping occurs only on NORMAL SPACES, not  . The text inside my div didn't really have any spaces in it, it was one continuous string of words joined by the innocent  .

I have been working on an idea, one that assumed that if you remember the content sent to an UpdatePanel, you can send only the difference next time you update it. That would mean that you could use only one UpdatePanel, maybe in the MasterPage, and update only changes, wherever they'd be and no matter how small.

However, I also assumed that if I set the innerHTML property of an HTML element, the value will remain the same. In other words that elem.innerHTML=content; implied that elem.innerHTML and content are identical at the end of the operation. But they were not! Apparently the browser (each flavour in its own way) interprets the string that you feed it then creates the element tree structure. If you query the innerHTML property, it uses the node structure to recreate it.

So comparing the value that you've fed it to the actual value of innerHTML after the operation, you see quoted attribute values, altogether removed attributes when they have the default value, uppercased keywords, changed attribute order and so on and so on. FireFox only adds quotes as far as I see, but you never know what they'll do next.

On the bright side, now that my idea had been torn to shreds by the browser implementation, I now have an answer to all those stuck up web developers that consider innerHTML unclean or unstructured and criticize the browsers for not being able to render as fast when using DOM methods. The innerHTML property is like a web service. You feed it your changes in (almost) XML format and it applies it on the browser. Since you pretty much do the same when you use any form of web request, including Ajax, you cannot complain.

A chat user asked me the other day of how does one put the tabs in the AjaxToolKit TabContainer vertically and I had no idea. I've decided to do it today and write this blog post, maybe he'll come back and he'd get the answer.

So, the request is simple: take a web site with a TabContainer in it and make it show the tabs vertically. I can only assume that the vertical tabs would go on the left and the content in the right. So I took the Internet Developer Toolbar and analysed the html output of a page with four static tabs. I added a <style> tag with CSS classes and started making changes until it worked. Unfortunately, the same setup would not work on Firefox, so I had to repeat the process using Firebug to analyse the page output. In the end this is the result:

<style>
.ajax__tab_header {
    float:left;
}
.ajax__tab_body {
    /*float:left;*/
    margin-left:220px;
}
.ajax__tab_outer {
    display:block !important;
}
.ajax__tab_tab{
    /*min-width:200px;*/
    width:200px;
    height:auto !important;
}
</style>

.

Add this on top of your page or include it in your CSS and the tabs will appear vertically.

Now for a bit of explaining.

• First of all this does not overwrite the CSS that the TabContainer loads because it is organized under a general ajax__tab_xp class like: .ajax__tab_xp .ajax__tab_header .
• Then the width of 200px is arbitrary. I used it to keep the vertical tabs at the same width. I tried using min-width first, but it won't display right in Firefox.
• Another point is about the ajax__tab_body class that I tried to set up first as float left, which would place the body div next to the tabs div, however this breaks if the body tab is wider and the content would appear underneath the tabs div. Thanks to my colleague Romeo I used the margin-left trick. 220px is enough to work in both IE and Firefox. It can be made smaller (closer to 200px)if the default IE body margin would be 0.
• The !important keyword is placed to overwrite some settings that are already set up in the original TabContainer CSS.
• Last issue: now the right panel will be truncated if it gets too large. You should control the overflow of that div, although, as far as I am concerned, my job is done

As a kind of disclaimer, I am not a CSS expert. If you know of a better way of doing this, please let me know.

I am going to quickly describe what happened in the briefing, then link to the site where all the presentation materials can be found (if I ever find it :))

The whole thing was supposed to happen at the Grand RIN hotel, but apparently the people there changed their minds suddenly leaving the briefing without a set location. In the end the brief took place at the Marriott Hotel and the MSDN people were nice enough to phone me and let me know of the change.

The conference lasted for 9 hours, with coffee and lunch breaks, and also half an hour for signing in and another 30 minutes for introduction bullshit. You know the drill if you ever went to one of such events: you sit in a chair waiting for the event to start while you are SPAMMED with video presentations of Microsoft products, then some guy comes in saying hello, presenting the people that will do the talking, then each of the people that do the talking present themselves, maybe even thank the presenter at the beginning... like a circular reference! Luckily I brought my trusted ear plugs and PDA, loaded with sci-fi and tech files.

The actual talk began at 10:00, with Petru Jucovschi presenting as well as holding the first talk, about Linq and C# 3.0. He has recently taken over from Zoltan Herczeg and he has not yet gained the necessary confidence to keep crouds interested. Luckily, the information and code were reasonably well structured and, even if I've heard them before, held me watching the whole thing.

Linq highlights:

• is new in .NET 3.0+ and it takes advantage of a lot of the other newly introduced features like anonymous types and methods, lambda expressions, expression trees, extension methods, object initializers and many others.
• it works over any object defined as IQueryable<T> or IEnumerable (although this last thing is a bit of a compromise).
• simplifies our way of working with queries, bring them closer to the .NET programming languages and from the just-in-time errors into the domain of compiler errors.
• "out of the box" it comes with support for T-Sql, Xml, Objects and Datasets, but providers can be built (easily) for anything imaginable.
• the linq queries are actually execution trees that are only run when GetEnumerator is called. This is called "deffered execution" and it means more queries can be linked and optimised before the data is actually required.
• in case you want the data for caching purposes, there are ToList and ToArray methods available

Then there were two back-to-back sessions from my favourite speaker, Ciprian Jichici, about Linq over SQL and Linq over Entities. He was slightly tired and in a hurry to catch the plain for his native lands of Timisoara, VB, but he held it through, even if he had to talk for 2.5 hours straight. He went through the manual motions of creating mappings between Linq to SQL objects and actualy database data; it wouldn't compile, but the principles were throughly explained and I have all the respect for the fact that he didn't just drag and drop everything and not explain what happened in the background.

Linq to SQL highlights:

• Linq to SQL does not replace SQL and SQL programming
• Linq to SQL supports only T-SQL 2005 and 2008 for now, but Linq providers from the other DB manufacturers are sure to come.
• Linq queries are being translated, wherever possible, to the SQL server and executed there.
• queries support filtering, grouping, ordering, and C# functions. One of the query was done with StartsWith. I don't know if that translated into SQL2005 CLR code or into a LIKE and I don't know exactly what happends with custom methods
• using simple decoration, mapping between SQL tables and C# objects can be done very easily
• Visual Studio has GUI tools to accomplish the mapping for you
• Linq to SQL can make good use of automatic properties and object initialisers and collection initialisers
• an interesting feature is the ability to tell Linq which of the "child" objects to load with a parent object. You can read a Person object and load all its phone numbers and email addresses, but not the purchases made in that name

Linq to Entities highlights:

• it does not ship with the .NET framework, but separately, probably a release version will be unveiled in the second half of this year
• it uses three XML files to map source to destination: conceptual, mapping and database. The conceptual file will hold a schema of local object, the database file will hold a schema of source objects and the mapping will describe their relationship.
• One of my questions was if I can use Linq to Entities to make a data adapter from an already existing data layer to another, using it to redesign data layer architecture. The answer was yes. I find this very interesting indeed.
• of course, GUI tools will help you do that with drag and drop operations and so on and so on
• the three level mapping allows you to create objects from more linked tables, making the internal workings of the database engine and even some of its structure irrelevant
• I do not know if you can create an object from two different sources, like SQL and an XML file
• for the moment Linq to SQL and Linq to Entities are built by different teams and they may have different approaches to similar problems

Then it was lunch time. For a classy (read expensive like crap) hotel, the service was really badly organised. The food was there, but you had to stay in long queues qith a plate in your hand to get some food, then quickly hunt for empty tables, the type you stand in front of to eat. The food was good though, although not exceptional.

Aurelian Popa was the third speaker, talking about Silverlight. Now, it may be something personal, but he brought in my mind the image of Tom Cruise, arrogant, hyperactive, a bit petty. I was half expecting him to say "show me the money!" all the time. He insisted on telling us about the great mathematician Comway who, by a silly mistake, created Conway's Life Game. If he could only spell his name right, tsk, tsk, tsk.

Anyway, technically this presentation was the most interesting to me, since it showed concepts I was not familiar with. Apparently Silverlight 1.0 is Javascript based, but Silverlight 2.0, which will be released by the half of this year, I guess, uses .NET! You can finally program the web with C#. The speed and code protection advantages are great. Silverlight 2.0 maintains the ability to manipulate Html DOM objects and let Javascript manipulate its elements.

Silverlight 2.0 highlights:

• Silverlight 2.0 comes with its own .NET compact version, independent on .NET versions on the system or even on operating system
• it is designed with compatibility in mind, cross-browser and cross-platform. One will be able to use it in Safari on Linux
• the programming can be both declarative (using XAML) and object oriented (programatic access with C# or VB)
• I asked if it was possible to manipulate the html DOM of the page and, being written in .NET, work significantly faster than the same operations in pure Javascript. The answer was yes, but since Silverlight is designed to be cross-browser, I doubt it is the whole answer. I wouldn't put it past Microsoft to make some performance optimizations for IE, though.
• Silverlight 2.0 has extra abilities: CLR, DLR (for Ruby and other dynamic languages), suport for RSS, SOAP, WCF, WPF, Generics, Ajax, all the buzzwords are there, including DRM (ugh!)

The fourth presentation was just a bore, not worth mentioning. What I thought would enlighten me with new and exciting WCF features was something long, featureless (the technical details as well as the presenter) and lingering on the description would only make me look vengeful and cruel. One must maintain apparences, after all.

WCF highlights: google for them. WCF replaces Web Services, Remoting, Microsoft Message Queue, DCOM and can communicate with any one of them.

If you don't want to read the whole thing and just go to the solution, click here.

I reached a stage in an ASP.Net project where a I needed to make some pages work faster. I used dotTrace to profile the speed of each form and I optimized the C# and SQL code as much as I could. Some pages still were very slow.

Now, I had the idea to look for Javascript profilers. Good idea, bad offer. You either end up with a makeshift implementation that hurts more than it helps, or with something commercial that you don't even like. FireFox has a few free options like FireBug or Venkman, but I didn't even like them and then the pages I was talking about were performing badly in Internet Explorer, not FireFox.

That got me thinking of the time when Firefox managed to quickly select all the items in a <select> element, while on Internet Explorer it scrolled to each item when selecting it, slowing the process tremendously. I then solved that issue by setting the select style.display to none, selecting all the items, then restoring the display. It worked instantly.

Can you guess where I am going with this?

Most ASP.Net applications have a MasterPage now. Even most other types of sites employ a template for all the pages in a web application, with the changing page content set in a div or some other container. My solution is simple and easy to apply to the entire project:

Step 1. Set the style.display for the page content container to "none".
Step 2. Add a function to the window.onload event to restore the style.display.

Now what will happen is that the content will be displayed in the hidden div, all javascript functions that create, move, change elements in the content will work really fast, as Internet Explorer will not refresh the visual content in the middle of the execution, then show the hidden div.

A more elegant solution would have been to disable the visual refresh of the element while the changes are taking place, then enable it again, but I don't think one can do that in Javascript.

This fix can be applied to pages in FireFox as well, although I don't know if it speeds anything significantly. The overall effect will be like the one in Internet Explorer table display. You will see the page appear suddenly, rather than see each row appear while the table is loaded. This might be nice or not nice, depending on personal taste.

Another cool idea would be to hide the div and replace it with a "Page loading" div or image. That would look even cooler.

Here is the code for the restoration of display. In my own project I just set the div to style="display:none", although it might be more elegant to also hide it using Javascript for the off chance that someone might view the site in lynx or has Javascript disabled.

function addEvent(elm, evType, fn, useCapture)
// addEvent and removeEvent
// cross-browser event handling for IE5+, NS6 and Mozilla
// By Scott Andrew
{
if (elm.addEventListener){
elm.addEventListener(evType, fn, useCapture);
return true;
} else if (elm.attachEvent){
var r = elm.attachEvent("on"+evType, fn);
return r;
} else {
alert("Handler could not be removed");
}
} 

function initMasterPage() {
document.getElementById('contenuti').style.display='';
}

addEvent(window,'load',initMasterPage);

Apparently, the innerText property of Javascript elements is not available for FireFox or other browsers other than Internet Explorer. FireFox exposes something similar, but with the name textContent. Why would any one of these two butt-heads learn from the other and cooperate for the common good?

The functionality of this property is to expose the inner content of an element minus any html tags. With something like <div><span class="red">Red text<span></div> the div innerText/textContent property returns "Red text". It could also work when setting, stripping tags from the content before setting innerHTML, although it seems that for both implementations setting innerText or textContent is equivalent with setting innerHTML.

There are also links about javascript functions that would replace, improve or otherwise ease the developer's work by adding the same functionality.

I was looking for ways of speeding up my web pages, considering that one utility page I built reached 500Kb and from that, only 170kb where actually content, the rest was Javascript. Bad Javascript, I accept, but it works, ya know?

So, after thinking and thinking I thought of a novel approach to this: how about googling for it? and I found this very nice and comprehensive article: Speed Up Your Javascript Load Time.

There isn't much else I can say about it.

In a previous post I was writing about a fix to remove the Press Spacebar or Enter to activate or use this control message. But it also made a mess out of a flash file I was trying to use. After a lot of looking into the source code (Flex) and trying to understand what happened, I found a solution.

First of all, you will find a lot of web pages advocating using a parameter called flashVars for sending parameters to Flash applications. Then you would use Application.application.parameters to get the variables URLEncoded in flashVars. That works in most cases, but not when:
a. you used an IE fix for the annoying message
b. you have in the movie and/or src parameters an url that has parameters. (like when you would get the SWF file out from an HttpHandler, for example)

The solution is to put all the variables you would put in the flashVars in the url of the movie or src parameters.

So, instead of :
<param name='movie' value='test.swf' />
<param name='flashVars' value='a=%27test%27&b=12' />

use
<param name='movie' value='test.swf?a=%27test%27&b=12' />

Don't forget to UrlEncode the values.

But why does this happen? Apparently, the problem is that after setting the innerHTML property the FlashVars param element has an empty value. I tried to fix the javascript to 1. get the value of FlashVars 2. do the fix 3. replace the empty FlashVars value with the saved value. It did not work! Even by javascript, after finding the param element with the name of FlashVars and an empty value, I could not set the value of the element. It probably has to do with the IE "fix". Something must clear the FlashVars when being set from anything else but from source.

Ok, the why is something I could never truly understand. It's some lawyer thing. But the fact remains that Microsoft was legally bound to show that message on each ActiveX control in Internet Explorer, thus screwing everybody and all their Flash pages.

When you Google this you find a miriad solutions. Some of them rewrite the entire HTML, others just take all the objects and embeds and rewrite their innerHTML or their outerHtml. But sometimes, it just seems that none of them work. And here is the catch for all of them: in order to work, the function that does the replacing of the HTML must be in an external Javascript file. Yes, you read right, if the function is inside the page, it doesn't work. Weird, huh?

Anyway, here is the script I use. It works, apparently.

function fixFlash() {
//ediy v2
n=navigator.userAgent;
w=n.indexOf("MSIE");
if((w>0)&&(parseInt(n.charAt(w+5))>5)){
T=["object","embed","applet"];
for(j=0;j<2;j++){
E=document.getElementsByTagName(T[j]);
for(i=0;i<E.length;i++){
P=E[i].parentNode;
H=P.innerHTML;
P.removeChild(E[i]);
P.innerHTML=H;
}}}
}

For more information about other solutions and the legal issue between Microsoft and Eolas read this specialised blog: IE ActiveX Change "Click to activate and use this control"

Update:
Well, I noticed that the Flash file I wanted to use stopped working after using this fix. Luckily I had the source and so I found a fix. The next post details it.

One of my projects involves translation of pages and I have built a general framework that not only translates, but also tries to preserve the capitalization of text. For example, for English to Italian translations, MORNING would be translated into MATTINA and morning into mattina. But I've stumbled into an issue with ACTIVITY.

You see, the Italian for activity is attività, which would be translated into the UTF8 of html to attivit&#192; or attivit&agrave;. Well, then how would one translate ACTIVITY? Maybe ATTIVIT&AGRAVE;? No! Because, apparently, both IE and FireFox (and possibly any other browser) don't count &agrave; unless it is in lowercase, even if, as far as I know, HTML should be case insensitive.

So watch out! Use the numbering system, it is more compatible.

Internet Explorer has a lot of "features" that are completely useless. One of them is the infamous "Can't move focus to the control because it is invisible, not enabled, or of a type that does not accept the focus.". So what?! Just return a false value! Why do you have to throw an error?
Anyway, I've stumbled upon a bug accidentally while reviewing a html control on DynamicDrive. This is the basic setup:

<style>
.div {
display:none;
}
</style>
<script>
function loadGoogle() {
 document.getElementById('div').style.display='';
 document.getElementById('iframe').src='http://www.google.com';
 return false;
}
</script>
<div class=div id=div style="">
<iframe id=iframe src="" ></iframe>
</div>
<a href="#" onclick="loadGoogle()">Click me!</a>

And it returns an error. Why? Because the javascript on Google tries to focus something:

document.f.q.focus();

But the display is cleared before changing the src. For all purposes, the div has the display set to an empty string (and you can check it with an alert right after it is set). The funny thing is, and that might come as a surprise, that if you move the display:none to the style attribute of the div, the script above doesn't return any error!

So, bottom line: attribute set in style tag or css cannot be changed dynamically without an error, while a control attribute can. What's up with that?! (Bug found on IE7.0). If you encounter this weird error, try moving the display attribute (I couldn't replicate the bug with the visibility attribute) in the control style attribute.