PapayaSoft Phuket web development

The Google Translate widget allows webmasters to add on-demand translation of a website page. Very easy to configure and deploy.

The rendered widget appears in the browser as a simple select dropdown with options for all the language supported by Google Translate. When the user selects his desired target language, the widget is supposed to contact the Google Translate mother ship, translate the text on the page, and then add an fixed iframe panel at the top of the browser viewport, followed by the translation of the page. The translated page even implements onmouseover handlers for text-based elements that display the original source text. Sweet.

It has worked great for me in the past. But I recently did a new deployment and I was unable to get the widget to work. When I (as the user) selected my target language, I got the following:

Error: The server could not complete your request. Try again later.

A bit more poking showed that it was only happening in Firefox. All my other browsers were ok. Eventually, I narrowed it down to a conflict with the Flashblock extension. Disabling the extension solved the problem.

Now, the tough choice is to run without the Flashblock or without the Google Translate. But at least I can deploy for the customer.

2010-02-20 Update: The mere presence of the enabled Flashblock extension when visiting a page with the translate widget does not cause the problem. The issue only occurs when the page has Flash content and the extension is configured to block Flash on that page.

The reason: The widget appears to actually use Flash!

In the file

http://translate.googleapis.com/translate_static/js/element/main.js

the function wf() seems to add Flash embed code into the page. I imagine that Flashblock is detecting this attempted insertion and is doing its magic.

I actually find it interesting - and impressive - that the Flashblock extension is smart enough to not only find/block Flash content on initial page load, but also at any time after that. I imagine it monitors the DOM and is vigilantly swaps out any Flash embeddings with its own replacement button.

I can see that the widget creates several iframes, at least one of which has Flash content pulled from the domain translate.googleapis.com. It stands to reason - well, at least to me - that enabling Flash content for this domain should do the trick. But so far, no luck. ;-(

On one of my ongoing web projects, we have forms that require users to specify a date. The input field is a single text field with an expected format (as opposed to a trio of selectors corresponding to day, month, and year). On form submit, we perform server-side validation. All straightforward stuff.

In the spirit of progressive enhancement - or graceful degradation, depending upon whether you see your glasses as half-full or half-empty - we add some client-side enhancements.

The first bit of client-side enhancement is just validation on the expected format. Nothing special here. The second bit is a date picker with which to easily select dates.

Better, stronger, faster

In the first round of development, we used a popup window containing a server-generated HTML page, as is done in phpMyAdmin. It worked fine for a while but there were several downsides to our particular implementation:

• As a popup, it was subject to possible blocking
• As server-generated content, it was a bit slow, especially on our internet connections here in Thailand
• The javascript was inline, not unobtrusive. Not a capital offense, but one that still irked me.

Also, it was more than a bit old-fashioned. I mean, it’s like wearing your grandpa’s sweater: it may keep you warm, but it sure as heck ain’t gonna impress Mary Lou the cheerleader down at the soda shop.

With all the new javascript libraries, especially jQuery, it seemed high time to move into - or at least closer to - the modern era. So we deployed the Datepicker plugin from the jQuery UI package, enabled a little animation effect, and it’s pretty nice. Fast, clean, unobtrusive. Steve Austin would be proud.

The best part of it is ease of use: For any fields to which we want to bind a datepicker, we simply give that field a particular CSS class. So we could have HTML markup of the form:

<input type="text" name="mydate" id="mydate" class="dp">

and then we bind a datepicker to it with javascript code as follows:

(function($){
    $(document).ready(function(){
        $('.dp').datepicker();
    });
})(jQuery);

Very sweet.

Companions: Checking-in and Checking-out together

But like all things web-related, that’s not the end of the story. Turns out that there are places on the site where two date input fields are related, paired as companions, typically in a check-in / check-out scenario, like booking a hotel room or a flight.

Certainly it is possible for these fields and their datepickers to function in a fully independent manner. If the user tries to check-put before he checks in, both the client-side and the server-side validation kick in to ensure data integrity.

But it is somewhat sub-optimal to even allow the user to select such a situation in the first place.

Even better, don’t you love it when you go to a site and after you select the check-in date, the check-out date automatically sets itself to the day after check-in?

Or, on the other side, don’t you hate when: you are booking a room or a flight way in the future, like next year; you select the first date, perhaps by navigating through a sequence of months, and then are forced to do the same thing on the second datepicker?

[Actually, it's probably the case that the user shouldn't even have to do this on the first datepicker, that in addition to prev-month and next-month navigation, the datepicker control should have its own selectors that allow the user to jump to a desired year and month. Good, full-featured, datepickers actually have this as well.]

The selection of the first date (the preceder) inherently puts a lower bound on the acceptable values for the second date (the succeeder). So why not bake that into the operation of the form?

And, this thinking works in the other direction, too. Suppose I chance the check-out date to sometime before the current check-in date? It seems reasonable that I should change the check-in date to be something before the check-out date, and the most reasonable choice is the day before check-out. If the user wants to push forward further than that, then he his certainly free to do so, but at least we put him in a reasonable ballpark.

Of course, all date changes do not warrant changing the companion. If I already have a reasonable check-in that precedes a check-out, and then I push back my check-out to a later date, there is certainly no need to change my check-in. Symmetrically, if I move my check-in forward to an earlier date, I certainly have no basis for concluding that the check-out should change.

So what I need is a way to pair these two input fields to each other so that a change in one can automatically create a change in the other, but only when it is appropriate to do so. And I’d like to handle it all with a single set of DRY handlers. And I’d like it to be valid HTML markup. And I’d like it to be completely unobtrusive.

Es posible? Si!

My Companion Approach

The jQuery Datepicker UI plugin has the option to set an onSelect callback option. That is, when a date is actually selected by the user in the datepicker, this function will be executed by the plugin. This is the key to the handling.

But we need some way to identify pairs, and especially which one is the preceder and which one is the succeeder.

I created a class naming scheme as follows.

Consider paired fields representing check-in and check-out:

<input type="text" name="mycheckin" id="mycheckin">
<input type="text" name="mycheckout" id="mycheckout">

As before, we want them to be bound to their own datepickers, so we add the class “dp” yielding:

<input type="text" name="mycheckin" id="mycheckin" class="dp">
<input type="text" name="mycheckout" id="mycheckout" class="dp">

Now, we want to specify that mycheckin is a preceder, bound to the succeeder mycheckout. And vice versa. So, I add classes as follows:

<input type="text" name="mycheckin" id="mycheckin" class="dp dp_1_mycheckout">
<input type="text" name="mycheckout" id="mycheckout" class="dp dp_2_mycheckin">

The 1 and the 2 represent flags to help determine which is a preceder and which is a succeeder.

The part trailing the numeric preceder/succeeder flags is the object id of the companion.

Then I define a bunch of helper functions to:

• parse the class names to extract this information
• detect when a change in one actually warrants a change in the other
• add/subtract a day from a user selected date
• output dates in the desired format

and then use all these helpers in the single DRY datepicker onSelect handler.

Aaaah, sweet success.

If I get a chance - or an overwhelming deluge of requests - I’ll post some sample code in more detail.

Clients love HTML email.

Done correctly, it looks slick as all get-out; it prompts users to action; it drives traffic for a special promotion; presents an exciting, professional image; lifts you aloft and floats you to heaven. All with higher response/action rates than plain-text email messages.

However, as every web developer knows, doing it well is a nightmare. Design/layout is the easy part; the sticky parts are numerous. Different email clients render HTML email with, shall we say, somewhat uneven support for web standards that are increasingly respected in modern browsers. Further, many email clients come configured with default settings to that disable images, adding another factor to consider. Finally - well, not finally, but the list of issues feels effectively endless - HTML email is often used by spammers, so there are more complicated considerations associated to ensuring that your messages do not get incorrectly tagged as spam.

There is a growing body of best-practices that has slowly developed for HTML email. These practices are not “best” in the sense that they represent elegant, flexible coding philosophies (like DRY, OO, for example) or minimal load times or optimized development practices. Rather, these ideas are considered best-practices, IMHO, merely in the sense that they “work”: they offer the best chance that your message will be received by the intended recipient and be reasonably well-rendered when he views it.

These best-practices include foregoing all the techniques we learned for creating semantic markup that cleanly separates content from presentation using CSS; instead, we are told to use tables for layout. We should no longer refer to styles in an external style sheet since most email clients - especially web-based ones like Hotmail, Yahoo, and Gmail - will strip them out; rather, we should use inline styling, repeating style information on nearly every element that needs it, inducing bloat and making modifications a tedious search-and-replace activity rather than a simple change in a single style declaration.

Other best-practice resources often conclude by pointing to Campaign Monitor or MailChimp and advising readers to download their free templates and use them as directly or as a starting point for editing or even as a guide to these best-practices. Both sites claim that their templates have been tested to render fine in all major clients.

Now, Campaign Monitor is great. These guys are founders of the Email Standards Project. I totally support the idea that someone should be pushing email clients towards better support of web standards, especially CSS support. The first step in that direction is measuring and evaluating the current support. And their chart of CSS support in major mail clients is a tremendous resource.

But the first template I downloaded from CampaignMonitor violates a bunch of these best practices right off the bat and fails to render correctly in Gmail. The template has nearly all of its styling inside a <style> tag inside the page’s <head> section. CampaignMonitor’s own CSS support guide referenced above notes that such an approach will not work with Gmail, yet their template includes it and claims to render fine.

Gotta tell ya, I’m a bit disappointed.

Just noticed that the newly deployed Fresh theme claims to validate XHTML 1.0 Strict, but fails on the Pages (as opposed to posts) as a result of declaring two elements - the post wrapper <div> and the <h2> for the title - with the same id.

The theme is approx a year old, so I’m kind of surprised that no one else has mentioned it. Wondering if that makes me particularly perceptive. Or particularly compulsive? Or, horrors, particularly wrong?

I have posted a comment for iLEMONed, the theme author. In meantime, I have hacked my local copy with an obvious tweak.

2009-08-20, Update: No response from iLEMONed. Oh well, mine is hacked. and validates.

Now to tackle the invalid CSS produced by one of the plugins.

Onward!