Monday, 7 February 2011


This morning I was doing some more work on my Ebay Wordpress plugin. There is a bug in LIBXML that causes entities to become decoded (i.e. & becomes &). This causes problems when outputting to HTML and XML as & must be encoded as an entity.

I thought I had worked round it using a fix to convert the named entities to numeric entities:
$resp = str_replace(array('&', '<', '>', '"'), array('&', '&#60', '>', '"'), $resp);

However, when I checked, the numeric entities were still being converted to characters. So I switched my code to instead double encode the entities, and this is working okay, at least on my local machine.
//If we're using a buggy libxml version, we need to double encode the named entities to prevent them from being converted to characters
if(LIBXML_VERSION >= 20700 && LIBXML_VERSION <= 20708){
 $resp = str_replace(array('&amp;', '&lt;', '&gt;', '&quot;'), array('&amp;amp;', '&lt;lt;', '&gt;gt;', '&quot;quot;'), $resp);

In the afternoon I was struggling with keeping a custom tooltip style div faded in when you hovered over it, or the element it was a 'tooltip' for, but otherwise fading it out. So I had some code like so (where $desc is the tooltip):

I thought that this should make it so that when you mouseout of $desc it will fade out, but if you mouseover $desc again before it has finished fading, the fade will be cancelled and it will fade back in again.

However, what actually happens is that if you mouseover $desc again while it is fading out, the fade will stop, but it won't fade back in. And if you now let $desc fade out completely, next time you fade it in, it will only fade in to the opacity that was set when the previous fade out was cancelled.

So I spent a long time trying to find out how to fix this, and in the end I have found that the following seems to work okay:
  $(this).stop(true).fadeIn(500, function(e){$(this).css({"opacity" : 1});});
  $(this).stop(true).fadeOut(500, function(e){$(this).css({"opacity" : 1});});

I've only tested in Chrome and FF so far though!

I did some more testing, and came across a weird bug in IE where setting position: relative makes it as if you have set position: fixed. I did a page with an example of the bug: IE6 bug with overflow and position:relative, but unfortunately they say they no of no cure (other than quirks mode). Luckily, I found I could remove position: relative, and the problem elements still displayed in normal browsers okay, as well as this fixing it in IE.

In the evening I watched an episode of Star Trek TNG (which was actually alright), and an episode of Let's Learn Japanese Basic 1 with Mauser and Bo.

No comments: