Setting the z-index of a jQuery UI datepicker

I ran into a collision issue with two of my absolutly positionned elements on a form page. I had an invisible flash buttun (used to launch an upload process) as well as jQuery UI datepicker.

The form was built in a way that when the datepicker was displayed, it was supposed to be on top of the invisible Flash button. Unfortunatly the button was in fact "on top" of the datepicker, but being invisible you do not notice it until you click.

This resulted in an upload dialog popping up and many confused users.

The fix

The Flash z-index is fixed in my CSS (10), so I thought that adding a greater z-index to the jQuery UI datepicker in CSS would be enough.

It is not. The jQuery UI datepicker seems to automatically set the z-index to 1, whatever you specified.

I checked the datepicker options, looking for a zIndex key, but found nothing...

I tried the beforeShowevent, to manually set the z-index, but it seems that jQuery still update my value to 1 AFTER the event.

So I finally resorted to adding a small timeout to re-add my value after jQuery. This is a bit of a hack but given the context this is the only way I found.

// Set the datepicker zIndex on load
element.datepicker({
[...]
  'beforeShow': function(input, datepicker) {
    setTimeout(function() {
      $(datepicker.dpDiv).css('zIndex', 100);
    }, 500);
  },
[...]
});

Finding a string in multiple files

Lately I was receiving emails with just the text "Blablabla" from an old (online) production server. This was obviously from an old debug script that I should have put online and forgot.

Unfortunatly, I wasn't able to track down exactly from where it originated. I had no mention of that string in my local files.

So I connected to the serveur using ssh and ran the following command : grep -R Blablabla /path

After some processing, I got the incriminating file and was able to delete it.

Some CSS hacks to target IE6 and IE7

After stopping using ugly IE hacks and moving to conditionnal comments to load a special IE stylesheet, I now use conditional comments to mark my body element with classes reflecting the current IE version.

<!--[if IE 6]><body class="ie ie6 ie-lt8 ie-lt9"><![endif]-->
<!--[if IE 7]><body class="ie ie7 ie-lt8 ie-lt9"><![endif]-->
<!--[if IE 8]><body class="ie ie8 ie-lt9"><![endif]-->
<!--[if IE 9]><body class="ie ie9"><![endif]-->
<!--[if !IE]><!--><body class="nie"><!--<![endif]-->

This saves me a lot of trouble : less files to manage and easier fixes to write. I quite happy with this solution and have tested it accross several projects for the past 3 months. It works really well.

I had to work on a legacy project last week, where this technique wasn't implemented but all the css code was still compressed using CSSTidy. And I ran into a couple of issues.

CSSTidy messes the star and underscore hacks

Using the brilliant _property and *property hacks to target IE6 and IE7 does not work in conjunction with CSSTidy.

For the _property hack, the property is kept as-is, with the underscore, but as they are alphabetically arranged, the _background gets added before the background, rendering it absolutly useless.

On the other hand, on the *property, the * gets removed, and the value is merged with the original value of the correct property. Useless too.

Other solutions that worked

To avoid digging into CSSTidy one more time, I tried to find other ways to achieve the same effect.

To target IE6 I used the !ie6 hack by writing .mySelector { property:value !ie6; }. IE6 is dumb enough to understand any !blahblah as !important.

I could have also used the fact that IE6 understands .class1.class2 as .class2, and could have written .ie6.mySelector { property:value; } (of course, you have absolutly no class="ie6" in your code)

To target IE7 I made a custom selector that its parsing engine is the only one to understand : *:first-child + html .mySelector { property:value; }

Preventing tinyMCE from wrapping <img /> in <p>

If you just want to add a presentational image in a tinyMCE editor, you'll find out very quickly that it will be wrapped in <p></p> without you asking.

The question has been asked several times on the tinyMCE forums, but the answers never quite satisfied me. It ranges from the classical "Why do you want to do this ? You should better use <insert semantic element and css here>" to "Just do a regexp before displaying your content to remove the bad <p>...</p>".

This clearly did not satisfy me.

The solution was to define theforced_root_block setting value to false, allowing us to create any element on the top level, and not having it automatically wrapped in <p>.

Fixing the side effect

Allowing for elements to be input directly in the root level has the nasty side effect of creating tinyMCE editor instances with a default text of, well, nothing, instead of the really usefull <p> tag. Also, if you do a Ctrl+A and delete all content, you'll end up with an empty editor without the initial <p> tags

To fix this part, I just added an onNodeChangeevent to fire every time the content is changed. I test the current content and if empty add the <p> tag. There is a little subtelty though, to correctly place the caret where needed.

In your tinyMCE.init call, just add the following setup key :

tinyMCE.init({
[...]
  setup: function(editor) {
    editor.onNodeChange.add(function(editor, cm, e, c, o) {
      var editorContent = editor.getContent();
      if (editorContent==="") {
        // We set content as a <p> containing a placeholder, then we delete the placeholder to place the caret
        editor.setContent('<p><span id="__CaretPlacholder">Placeholder</span></p>');
        editor.selection.select(editor.dom.select('#__CaretPlacholder')[0]);
        editor.dom.remove(editor.dom.select('#__CaretPlacholder')[0]);
      }
    });
   }),
[...]
 });

Before finding this solution, I tried the onBeforeSetContentcallback, but due to a bug in the tinyMCE source, it couldn't handle well the case where the editor is empty. So I had to resort to a more generic callback.

Displaying HTML mails sent from cakePHP in SquirrelMail

I just stumble upon the fact that my automated multipart (text + html) mails sent from my apps weren't correctly displayed on SquirrelMail.

I'm personnaly using GMail for my day to day email needs, but one of my client was using the default SquirrelMail (v1.4.21) install on their Dreamhost account. The received mails are not correctly parsed and get displayed as plain text, even if the header clearly specifiy a Content-Type: multipart/alternative; boundary="alt-"

The first culprit was that no boundary were given. This does not seem to cause GMail any problem, but I thought that SquirrelMail may choke on that. So I manually added a $this->Email->_createboundary(); call before my $this->Email->send();

Still, no succes. After some googling I found a bug report for a similar problem. I tried adding the suggested MIME header, and that solved my problem.

So here's my updated code :

$this->Email->sendAs = 'both';
$this->Email->_createboundary();
$this->Email->__header[] = 'MIME-Version: 1.0';
$this->Email->send();

I'll now have to add those two additional line of code everytime I'll have to send a multipart (html + text) email in cakePHP, until it get fixed (no specified milestone).