Vital Logs

We have been battling with a dilemma of missing white spaces in IE6 for a while now. usernames that have been hoverized (your profile appears when you hover over them) start to stick to the text after them no matter how many white spaces you add and where. The only solution is to add an explicit non breaking space (nbsp) but then the interface looks clunky, due to the disproportional spacing.

It turns out that the reason is that IE6 doesn’t like a div inside inline text even if its display is set to none. Once I changed the div to a span, the white spaces were honored and the username link stopped sticking to the surrounding text. It also doesn’t matter if the span with display:none has divs inside it, as long as the outer tag of the non displayed html is not a block type element.

Example:

Link sticks to text after it: <a href=’somewhere’>link text</a><div style=’display:none;’>hover box</div> sticky text

link doesn’t stick to text after it: <a href=’somewhere’>link text</a><span style=’display:none;’>hover box<div>some internal div that doens’t make a difference</div></span> non-sticky text

So I was trying to use the memcache increment method during my implementation of the view counter. Whenever I issue a CACHE.incr, CACHE.get starts to fail on that key. I found out what the problem is.

When get is called without specifying the raw argument, it defaults to false, which means that the memcache-client lib will marshal the value passed before sending it to memcache. Then when we issue an incr to the memcached server, it tries to increment the marshaled version which is a binary sequence representing a ruby object (Fixnum in this case) and messes it up.

The solution is to pass the raw parameter to MemCache.set as true, which will prevent the marshaling (later we should call set with a true raw as well) which will give memcached an integer (although treated as string on the ruby side) that it can increment safely.

I created a raw_get, raw_put and raw_incr that can be used together. They are nicely contained in a Cache module (yes, I’m using the same name as the memcache_util.rb module) under our lib folder.