Christian Heilmann

You are currently browsing the archives for the Common Issues category.

Archive for the ‘Common Issues’ Category

The future is hybrids – how JavaScript can purify pure CSS solutions

Monday, September 4th, 2006

Over the last few months there were more and more requests on mailing lists and articles published how you can achieve functionality with pure CSS that was traditionally achieved with JavaScript. This post will explain why that is an interesting concept, but hopefully make you aware of the benefits of JavaScript enhanced solutions versus pure CSS solutions.

I have to thank a lot of people I asked in the research for this, foremost James Edwards, John Resig and Andrew Dupont. I’ve also given a short presentation – PDF -96KB on the same topic at the Barcamp in London last weekend.

First of all let’s investigate how pure CSS solutions became so popular. (more…)

Shortening strings to a fixed length in JavaScript

Friday, August 25th, 2006

I have this function I’ve used for quite a long time to shorten a string to a fixed amount of characters without breaking in between words:

function constrain(str,n){
var words = str.split(’ ‘);
var resultstr = ‘’;
for(var i = 0; i < words.length; i++ ){
if((resultstr + words[i] + ’ ‘).length>=n){
resultstr += ‘…’;
break;
}

resultstr += words[i] + ’ ‘;
}

return resultstr;
}

ately that it can get really slow with massive strings in Internet Explorer. This is a well-known issue and the solution is to use arrays instead of concatenating strings.

This made me realise how convoluted the above example is and that it is much easier to do the same with an array:

function constrain(str,n){
if(str.length > n){
var s = str.substr(0, n);
var words = s.split(’ ‘);
words[words.length-1] = ‘’;
str = words.join(’ ‘) + ‘…’
}

return str;
}

You send a string and the amount of characters wanted as parameters and the function returns the string with the right lenght followed by a “...”.

Another way to work around the MSIE issue of slow concatenation is to use thea string builder.

Drew made me do it: Cover all your CSS class tasks with one small JavaScript

Monday, August 21st, 2006

Drew McLellan asked for a tool script for an upcoming project that would allow him to do all kind of tasks related to CSS classes.
He wanted to dynamically add, remove and check for classes and get all elements that have a certain class applied to them.

It is nothing fancy or new, but come in handy for you, too: Check the CSS class scanner tool

Sneakily reading out your browser history

Monday, August 21st, 2006

Via Stuart Colville I got a URL that uses a sneaky trick to see where you have been surfing. Jeremiah Grossman shows how you can check for visited sites.

The common complaint of developers who don’t see the security and privacy issues with that is that you can read out the history of the window with JavaScript but you only get the amount of visited sites, not their URLs. With this trick, you can.

The trick is pretty easy: He uses a whole array of sites to check against, writes out a style for visited links to the page, writes out a list of these links and checks their computedStyle color attribute against the colour he set in the style. If it is the same, the page is in cache and has been visited beforehand.

I already commented that it may be more stable if you set a different style to the visited links like display block and a height and read the offsetHeight instead of computedStyle. In any case, it is a clever and worrying trick.

\”More content\” links, cloneNode(), YUI and Safari/MSIE issues

Monday, August 14th, 2006

cloned sheep When I was creating a proof of concept the other day about how to create ‘more content’ links with JavaScript and the YUI I stumbled across an interesting problem with the YUI Event utility.

The Event Utility is IMHO the cat’s pajamas as it solves a lot of issues the tried and true addEvent didn’t: It retains the scope allowing you to use “this” in the listener method, makes preventDefault work in Safari and also allows you to send another custom object to the listener method, all of which make is a lot easier to write unobtrusive JavaScript without the memory leaks.

Now, the interesting problem I stumbled upon is that if you do the following

  • create a new link
  • add attributes, content and all that jazz
  • apply an event handler
  • clone the link
  • apply another handler to the second link

you’re in for trouble. Safari applies both handlers to the first link and none to the second, and MSIE applies both the first and the second handler (in reverse order) to the second link! Here’s the test case using YUI. The MSIE problem of the double handler on the second link also happens when you use the tradional addEvent.

I talked to the YUI folks and Adam told me that applying unique IDs to the links solves the issue in Safari, however it doesn’t make a difference in MSIE.

The lesson to take away:

If you clone elements, make sure to clone them before you apply the handlers, and remove all handlers just to be on the safe side

A shame, as I really like the idea of cloning elements. The other option of course is a constructor method for repeated elements.