There are threads galore in various jquery discussion groups and blogs about the problems with IE7's user agent info, which, on some installations, returns version '6'.

In my case, I have the exact same numeric version of IE7 on two different vista computers, and one shows up as IE6 while the other shows itself to jquery as version 7.
(No idea why, and unless somebody can explain it i am done pondering the mystery - it hurts my head!)

This recently surfaced as a serious problem with my use of the incredible, wonderful "thickbox" plugin - a jquery lightbox plugin with tons of feature (more about that here )

Anyway, after much digging and scratching (ok, googling and clicking for you realistic non-metaphorical types), I found a few browser detection scripts with a different spin for IE7.

The first one, which obviously has worked for many users, did not work for me. Bummer.
Jamie obviously put a lot of effort into bringing this simple ie thickbox patch to the masses. But for whatever reason (did I mention I am done thinking about the reason?!?) my stubborn-as-I-am IE7 still wanted to look like a 6 to jQuery.
Then, I found this thread on Nabble, and worked it into a test page. Lo and behold, the fix appeared before my eyes.

/// here is the fix ///

$(document).ready(function(){
if ( document.all && !window.opera && !window.XMLHttpRequest && $.browser.msie )
{var isIE6 = true;}
else
{ var isIE6 = false;} ;
$.browser.msie6 = isIE6;

///

You can then use the  value of " $.browser.msie6 " , which will either be 'true' or 'false', to work your various IE-specific magicnesses.
In my case, thickbox now centers just as it should in both of my IE7's !

Here is my test page with the full browser user-agent info.
Point your IE7 here and see what you see.
It will show either 6 or 7 as the version info, but either way the last line, 'msie6', should read false.

I upgraded both my laptop and then, cautiously, my main pc to Firefox 3.
Aside from a few extensions where keyboard shortcuts conflict in the new versions, and needing to reinstall a few fav extensions, the upgrade was more or less trouble free. Happy me, happy browser, the 'awesome bar' in FF3 is pretty neat (not sure it deserves 100% awesome status but it is really dang useful once you get past it being in-your-face annoying).  Happy everythingFox... and then... I realized I was being forgotten.

No longer would my iGoogle page greet me full of distraction and headlines when i launched a new FF session. No more full thread view on the first click when going to Experts Exchange. No more 'remember me' function. ... but so strange, the laptop still remembered everything. Same FF, mostly same extensions, and no "TorButton" (google it to see the known cookies issues) to cause the problem. The more it went on the more annoyed I got.

Picking at a solution in between long sessions of work and annoyance, I found lots of people having the same problem and very few ideas how to fix it.  The prevailing suggestion seemed to be "create a new FF profile" , but with my confidence in the upgrade flagging a little, i didnt want to mess with anything that is actually working (which is pretty much everything else in FF3).

And then... tonight... on page 4 of 6 in a long Mozilla forums thread, I found the golden nugget. You need to delete a file called "cookies.sqlite" that is in your firefox profiles folder (hence why making a new profile also fixes the problem)

Here is the solution :

Go to 
C:\Users\<your username>\AppData\Roaming\Mozilla\Firefox\Profiles

On my setup there was just one profile, and inside that, I deleted a file called "cookies.sqlite".

Apparently the file had gotten corrupted somehow, and session information was not being saved correctly.
Deleting the file (with Firefox closed) caused a reset, and instantly  I can tell things are a-ok.

The thread where i found the fix
( http://forums.mozillazine.org/viewtopic.php?f=38&t=675175&st=0&sk=t&sd=a&start=45 )

said to also delete cookies.txt

quote: "Note that cookies.txt is not used in FF3, but if you have one leftover from the upgrade, delete it too"

The usual syntax for setting up your jquery script in any page looks like this, using the 'document.ready' statement to launch all your stuff as soon as the page loads:

<script type='text/javascript'>
$(document).ready(function() {
// all your jquery stuff goes here
});
</script>

This is great, better than window.onload or body.onload, since it runs before any images or other files have finished downloading to the browser. However...  there are times when this is not so great, i.e. my latest attempt at my own 'equal columns' script.

First, I had this:

<script type='text/javascript'>
$(document).ready(function() {
var lh = $('#mainCol').height();
var rh = $('#rightCol').height();
if (lh >= rh){
//alert('left : ' + lh);
$('#rightCol').height(lh);
} else {
//alert('right : ' + rh);
$('#mainCol').height(rh);
}
});
</script>

Using the dimensions plugin (which is now a part of the main jquery library as of the latest release), this script gets the height of the 'rightCol' and the 'mainCol', figures out which one is a greater number, and assigns that number as the height of the other column.

works great - unless you happen to have images loaded in either column that do not have a specified height attribute.

In my case, I was loading a full column of large thumbnails in the rightCol div, and since jquery was firing before the page was fully loaded, firefox was reporting the height of the images as 'null', which caused all kinds of problems - the most important of which was that the columns were equal to the *shorter* column length... oops.

(note the alerts in the script comments - remove the // to see which of your columns is showing as longer)
 
Along comes jQuery's simple load() method, to the rescue!

by simply wrapping all my jquery goodness in
$(window).load(function()....
and then calling that function as part of the usual 'document.ready',
everything seems just fine... the columns are equal, since the script to fix the height is loading *after* the images have loaded to the page.

This causes a slight bit of 'motion' as the page is loading, but on the longer pages it is below the first screen height, and is very quick anyway.

<script type='text/javascript'>
$(document).ready(function() {
$(window).load(function(){
var lh = $('#mainCol').height();
var rh = $('#rightCol').height();
if (lh >= rh){
//alert('left : ' + lh);
$('#rightCol').height(lh);
} else {
//alert('right : ' + rh);
$('#mainCol').height(rh);
};
});
});
</script>

From the very same very fine folks that created the previously-mentioned (and well-used) book jQuery in Action, DZone now offers a free 6-page CSS Selectors Reference Card.

More about it at Yehuda's Blog, here
http://yehudakatz.com/2008/06/09/jquery-selector-refcardz/

I'm printing my copy now - it'll be coffee stained, highlighted, wrinkled and well-worn within no time !

This is just too cool.

A frequent visitor on my web dev newsgroup kindly posted a link to this slick little app, fresh off the bench and ready for Vista.

** Get it here: http://www.my-debugbar.com/wiki/IETester/HomePage

Finally! A way to check all versions of IE in one fell swoop - including Javascript rendering!

From the website...

IETester is a free WebBrowser that allows you to have the rendering and javascript engines of IE8 beta 1, IE7 IE 6 and IE5.5 on Vista and XP, as well as the installed IE in the same process.
New in v0.2.2 : Search box and customizable Homepage !

This is an alpha release, so feel free to post comments/bugs on the IETester forum or contact me directly.
Minimum requirement : Windows Vista or Windows XP with IE7 (Windows XP with IE6 has some minor problems and IE7/IE8 instances do not work under this config)

Download IETester v0.2.2 (23.8MB)

Just noticed a short announcement on the FCKeditor 'safari browser' page.

" Safari compatibility has been officially declared as of FCKeditor 2.5 Beta! We would like to thank WebKit and our Community for being with us, working to make this compatibility effort a reality. "

This is great news.
Safari compatibility was never an issue for me personally, but some clients had troubles and it just isn't any fun to say 'use a different browser' - they still see it as broken.

I moved over to using wymeditor for my recent CMS work, but will be enticed to take another look at FCK for sure.

John Blayter has released a new version of his very versatile and ever-so-useful CF_GoogleMap.

Apparently another revision is already in the works with yet more features, but it sounds like some good stuff has been added in already.

http://www.blayter.com/john/index.cfm/2008/6/10/CFGoogleMap-14-Released

(1) Added the showTraffic attribute to the cf_googleMap tag.
(2) Added the showLocalSearch attribute to the cf_googleMap tag.
(3) Added a language attribute to the cf_googleMap tag.
(4) Added the enableZoomScroll to the cf_googleMap tag and defaulted it to true so a use can use their scroll wheel to zoom in and out
(5) Added the enableGE to the cf_googleMap tag and defaulted it to false to enable the Google Earth view of the map.

Common scenario: you want to show the first part of a long chunk of text, and then have the full text available via a link like " (more...) " , which would either show the text with javascript (more on that later) or take you to another page to see the full article.

For a long time now I have used the "fullLeft()" udf, which works just fine and does exactly what it should.  But the other day, I got a wild hair and, rather than calling in the fullLeft function to my page, decided to script something right in place... just 'because'.

And whaddyaknow, it works... works great, really.
But it is so simple - what am I missing?

Like most things, my 'aha' is haunted by a 'what if', as in 'what if it breaks on certain characters or other stuff in the text'?  What if I don't really know what the heck I am doing? But ...hey... it works!

//// Here is the logic:

take a chunk of text and a number, passed in as variables.

replace all line breaks in the text with <br> tags (easy to remove if not needed)

if the length of the text is more than the given number, cut it off at that
number of characters

find the number of characters at the end of the remaining string that come after the last space ( ' '), and remove them

if the text was trimmed, output the text in a p tag with a (more...) link  - this can all be modified to give the link a url, or in my case to use javascript to show the full text in place of the truncated content.

/// Here is the code:

<cfscript>
/**
 * Another version of "full left"
 *
 * @param trimlength      Length, in characters, to trim text to (Required)
 * @param rawtext           Text to trim (Required)
 * @return Returns a string with an ellipsis (...) 
 * @author Michael Evangelista (mredesign.com)
 * @created June 6, 2008
 
 Usage:
 <cfinclude template="func/trimtext.cfm">
 <cfoutput>#trimtext(recordbody, 160)#</cfoutput>
 */
 
function trimtext(rawtext, trimlength)
{
// this line replaced line returns in the text block with html breaks
   rawtext = replace(rawtext, chr(13), '<br />', 'all');
      if (len(rawtext) gt trimlength)
   {
   cuttext = left(rawtext, trimlength);
   trimlen = len(cuttext) - len(listLast(cutText, ' '));
   texttouse = left(rawtext, trimlen) & '... <em>(<a class="morelink" href="##">more</a>)</em>';
   }
   else
   {
   texttouse = rawtext;
   }
   textoutput = '<p>' & texttouse & '</p>';
   return textoutput;
   }
</cfscript>


Feedback and/or testing appreciated.
thanks