Crispy text in Chrome
Been bumping around on a social media website and one of the funny things I read about (in this article) as that setting a transparent text-shadow on text forces Chrome’s sub-pixel anti-aliasing.
text-shadow: 0px 0px 1px rgba(0, 0, 0, 0.01);
Here’s a quick example:
The best String.trim()…
…trims characters that aren’t even there!
I was having a strange bug (while developing the message/user polling for my MooTools chat class) where trimming wasn’t stripping the whitespace in the returned data. You see, unlike many good client-server apps, I am not using JSON, but rather a specialized CSV format. The regular expression methods I tried didn’t work.
The character matching/traversal methods I tried didn’t work. And then I found out that the character code for the whitespace characters that were popping up were 65279. Sixty seconds later (thanks to Google!) I found this article. So my trim method now looks something like this:
Did I mention it happens to be very fast? 
jQuery and assumptions…
I have been working on a bridge between my PHP and MooTools/jQuery template parsers. So far all has been going well, until I decided to try and load the templates via script tag injection. The MooTools version went swimmingly…
The jQuery version, not so much. It seems that when you do $(‘<script…’).appendTo(‘head’), jQuery assumes you want to get the file with XHR. No questions asked. It doesn’t actually do the XHR request until you append it to the head element (not sure where else it makes this assumption) but the assumption is wrong.
I specifically chose to load the templates with script injection so that the template loading wouldn’t clog up Firebug and could be done from another domain. Thanks jQuery! If you are wondering what worked; it’s actually quite easy to achieve with vanilla JavaScript…
PHP objects vs. arrays
Whenever I have to talk between PHP and JavaScript, and especially when it comes to JSON, I have to decide whether I am going to use arrays or objects. JavaScript plays well with both, but PHP doesn’t. json_decode outputs a steaming pile of stdClass instances which lack the simplicity of index accessors. I came up with (or found?) this method to recursively cast an object to an array.
Function.when
Ever wanted to run a snippet of code after a list of conditions were met, but weren’t sure when that would be?
Now you can make functions wait until conditions are met, which will be checked at intervals (default: 100ms). Check out this example…
EDIT: Thought just occurred to me that the vanilla javascript version is much the same:
EDIT: For those of you jQuery enthusiasts out there:
Can’t help myself…
So, I’ve been developing this jQuery chat thing, and it’s been teaching me so much about efficient data transfer and good API design. I have to say that I am by no means a David Walsh or an Aaron Newton, but I want to show you what I came up with after a few days of jQuery AJAX chat and a few hours of MooTools AJAX chat…
One of the most important questions you can ask, when developing something that is going to do a lot of data transfer (very quickly), is what data/information format you are going to use. As I see it; there are 3 widely available options when working with Javascript: CSV, XML and JSON. CSV is a simple format but what do you use as column/row delimiters? What if the data includes tabs or new lines? Bummer! Next up is XML. XML is horrible. Next up is JSON; this is probably the most widely used data format in Javascript. It’s concise and simple to do with both Javascript/PHP.
There are problems with JSON though – it requires a third-party library to parse it (from string to object, PHP -> Javascript) in Javascript, or eval (evil). It also requires a third-party library in PHP to parse from/to JSON. So it’s a good format, but there are problems.
It is possible to use characters that users can’t input (control characters) – which are similar to \t and \n – to delimit CSV data. You can also do this in PHP and the only methods required in both Javascript/PHP are string split/join.
Javascript AJAX chat clients
Over the last few days I have been building a jQuery AJAX chat application. It’s been tough – I am rather out of touch with jQuery. If you would like to see what it looks like, check out: this repo.
jQuery comet chat
I have been tasked with creating a comet chat app (in jQuery!) within the next 3 days. This is huge, in both good and bad ways; it will be fun to do, but challenging to get a grip on jQuery (again) and deal with Comet. Once I’m done I will psot it all here and on GitHub. Good luck me!
Facelift! Linked Select
The linked select (or chained drop-down if you prefer) is a simple solution to an old problem. If you build a site with it’s own database, and assuming there’s a big jumble of categories and sub-categories and sub-sub-categories etc., you may need javascript to associate values in 1 select element, with the values in another (based on some hierarchical structure). And when you do, there are a number of ways you can go about it.
One of the methods I used (last time I had this problem) was to create a hidden select and shuffle all the spare (child) options off to it when filtering according to the value of a parent select element. I wrote a Moo class for it too! Today we’re going to give it a facelift!
Before we can improve, we need to understand. So let’s look what this class does:
Old school
Firstly we create the ghost element and move all the child select’s options to it.
Then, in the filter method, we remove each option above the offset. The offset is the starting point from which our child’s options will be altered – this is so that we can have static options or even a placeholder option at the beginning of the child select’s options list. Then we filter through the options in the ghost select and move applicable options back to the child select based on the value of a particular attribute on the parent select.
If a ‘select’ value is passed then we attempt to select the option with that value.
Lastly, in the filter method, we enable/disable the child depending on whether there are options (after the offset) in the child select. That’s all there is to it – it’s a simple plugin after all. Now let’s see how we can improve it.
New school
Firstly, there are a number of ways we can simplify the options we give this class, while keeping the same flexibility:
The previous options were a little confusing; basically we need to be able to specify which attribute the parent options filter on, and which attributes on the child are filtered by. We’ve renamed ‘child’ to ‘selected’ for the sake of clarity.
Our new initialize method looks quite like the old, but we’re assuming less about the environment by including a ‘container’ option but defaulting to document.body. Because of our simpler options we can also get away with defining fewer variables, and still have readable code!
Our filter method also looks pretty much the same, but without the unnecessary variable declarations. We’re also erasing selected and disabled properties instead of setting them to blank. That’s it folks!
demo – old school – new school
Facelift!
I’m always looking at code I’ve written (barely a few months ago) and wondering just what I was thinking. It’s even worse when the plugin/snippet I wrote worked really well at the time (and in a few different situations), and is still being used in all its outdated glory! It’s times like that when I scheme of ways to turn it into something shiny. Something beautiful.
I am going to be doing that to a few plugins over the next few weeks, in the hope that I can help others who are thinking about how they can improve their coding style/old code. We shall call these posts…em…Facelift!
