Algorithms for the masses - julian m bucknall

CSS3 line height is important for drop caps

julian m bucknall — Sat, 11 May 2013 02:53:26 GMT

Recently I was playing around and added drop caps to the blog posts on blog.boyet.com. I decided to go for a pure CSS3 version (so, you’ll have to view this site in a reasonably fresh browser to see the effect) rather than a hacky <span> version that mixes presentation “hints” in the content. (For a brief discussion on the two possible methods, see Chris Coyier’s blog post here.) I certainly didn’t want to change all my posts to include spans on the first letter of the first paragraph.

The way I implemented it was to add a class style to the surrounding div:

.initialcap > p:first-child:first-letter {
  background: url("images/classy_fabric.png") repeat scroll 0 0;
  color: #efefef;
  font-size: 48px;
  padding: 8px;
  margin-right: 3px;
  float: left;
}

The style makes reference to a paragraph child of the div, and uses the cd:first-child and cd:first-letter pseudo-classes. The initial letter is styled with a background image, a contrasting color, a larger size and relevant padding and margins. The whole lot is then floated left, so that the text wraps around it.

Pretty good. I viewed it in Firefox, saw it was good, and went off to do something else.

A few days later, I happened to run Chrome and immediately saw a problem, the drop cap was stretched vertically:

The same problem happened in IE10, too. What was going on? Firefox still showed the initial capital just fine.

It turned out that I’d missed off a line-height clause from my style, and this was affecting the display in Chrome and IE, but not, for some unknown reason, in Firefox. So I changed the style to this:

.initialcap > p:first-child:first-letter {
  background: url("images/classy_fabric.png") repeat scroll 0 0;
  color: #efefef;
  font-size: 48px;
  line-height: 32px; /* that is, 48px font size - padding top&bottom */
  padding: 8px;
  margin-right: 3px;
  float: left;
}

As you can see, I added a comment for myself to explain how I’d calculated the value since it’s a little bit “magic”. If you now visit this blog in Chrome and IE (and Safari for that matter) the drop caps are displayed correctly.

The moral of this tale is: test your websites in all four major desktop browsers. You’d be wrong in believing that they all render the same way, even in this day and age.

Now playing on Pandora:
Groove Armada – Inside My Mind (Blue Skies) on Vertigo (Import)

Weird XML bug on iPad when displaying this site

julian m bucknall — Thu, 09 May 2013 03:09:22 GMT

The call came though the batphone from Mehul Harry: he was seeing an issue displaying blog posts from this site on an iPad. It was a new one on me and I quickly checked on my iPad using Safari: no problem.

After a bit of back-and-forth, we’d nailed it down. If you navigated to a blog post via the Facebook app, the iPad displayed an XML error (due to the missing schema, essentially). If you navigated to the exact same blog post using Safari, it displayed fine. The weird thing is that this site doesn’t use XML; it’s HTML5, not XHTML.

Although this was news to me on the iPad, it was something I’d run into before: when I try and validate the site with the W3C HTML5 validator, it complains of exactly the same problem: bad XML. At least with the W3C validator, I could glean a little more information: in its response the web server was sending the Content-Type as application/xhtml+xml in the response header, not text/html (which is what I was expecting and which is what I would get in the browser). Why would the web server (IIS7 as it happens) send this erroneous Content-Type?

By default, ASPX files (which this site serves up; it’s a big old .NET program) are assumed to be text/html by both IIS and ASP.NET. Since the same page gets the correct Content-Type when it’s a browser making the requests, I can only assume that ASP.NET 3.5 was miscategorizing the user-agent of the request when it’s a UIWebView (what the Facebook app is using) or the W3C validator and assuming that it required XHTML. (This is the job of the machine.config file, in essence; something that, in a shared hosting environment, I have no access to in order to change it.)

Time to be clear-cut since the default was wrong. I altered the ancestor page class’s OnLoad() method (it’s the TemplatedThemePage class if you’re interested) to explicitly state that the pages returned by GraffitiCMS were text/html:

Response.AppendHeader("Content-Type", "text/html");

I recompiled, uploaded the new assemblies, and – zing – the problem was solved both on the iPad and for the validator.

Now playing on Pandora:
IIO – Runaway on Runaway [Maxi-Single]

Adventures with JSONP and jQuery

julian m bucknall — Mon, 06 May 2013 20:50:15 GMT

This whole thing started out as a nice-to-have. I have a blog (you’re reading it). I have a URL shortener (jmbk.nl). They are separate apps on separate domains. When I publish a post here, I diligently create the short URL for it manually in order to publish that short URL on social sites (the URL shortener has some minimalist stats associated with each short URL; so minimal, it’s only a count of the number of times it was used). Yeah, I know, silly, huh: why can’t each post generate its own short URL?

Now I could have done this in C# and .NET as a plug-in to the blogging software I use, but where’s the fun in that? Let’s do it in JavaScript!

What I want is some code that will get the URL of a blog post when that post is displayed in the browser (easy!), call my URL shortener service with it via good-old AJAX, and receive the short URL as a reply. The big issue about this simple plan is the so-called “Same-Origin Policy”. In essence, getting data from the same site (that is, protocol, domain/host, and port number) via JavaScript is smiled upon, but getting data from another site entirely is frowned upon to the point it doesn’t work. Since my pages are on blog.boyet.com, I can only get data from blog.boyet.com. It’s all to do with maintaining strict security boundaries (think of cookies as a big example).

Nevertheless, sometimes it might be advantageous for your code to get some data from another site. An example might be to display the top ten most recent of your tweets from Twitter in your blog webpage. The problem here is that twitter.com is not the domain of your personal blog, so what can be done?

If you think about it, the one thing you can get from other sites is JavaScript code inside script elements. Here as an example is how this site gets jQuery:

<script type="text/javascript" src="http://ajax.microsoft.com/ajax/jQuery/jquery-1.9.1.min.js"></script>

When the browser encounters a script element likes this, two things happen: first, the JavaScript file referenced by that URL is downloaded (via HTTP GET), and second, the script thus downloaded is executed. Hmm.

Let’s continue this thought experiment. These days we get our data in the JSON format; that is, code that defines a JavaScript object. Here’s an example of a JSON object that is relevant to my discussion:

{
    shortURL: "http://jmbk.nl/j6Q2K",
    requestCount: 42
}

Running before I can walk, I could construct the source URL I need in a <script> tag, say something like “http://jmbk.nl/MakeUrl/?shorten=http://blog.boyet.com/” (that isn’t the real URL I use for this operation, by the way, so there’s no point in trying it), and the browser would GET the URL, which would return the above JSON. Which would then be executed and crash with some kind of syntax error: it’s not executable code.

OK, then, let’s alter the URL shortener’s code to return this instead:

foobar({ shortURL: "http://jmbk.nl/j6Q2K", requestCount: 42 });

This time it’s real executable code, and the browser will call the foobar() function for me once the AJAX request is done, passing the JSON object I want as a parameter. Except I don’t have a foobar() function yet in my client code, so I have to write one and include its code in some kind of script tag. This function must take the JSON object and so something with it (like replace the href attribute on an anchor element I have somewhere in my HTML markup).

This, in essence, is this mysterious protocol called JSONP you may have heard of. JSONP stands for JSON with Padding, where the “padding” is wrapping the JSON object inside a function call as a parameter.

Now it’s a real pain to have to have two different ways of getting JSON objects from servers: one for your “same origin” server (a simple AJAX get request) and one for everything else (adding a silly script element, having a special function that does something with the JSON object, yadda, yadda), so jQuery simplifies it in one function: $.getJSON(). The code in this function looks at the origin for the URL that’s passed in. If it’s for the same site, the function issues an AJAX get request and the callback gets called normally on completion. In the other case, jQuery does some pretty fancy footwork in the background that creates a temporary script element on the fly with a slightly modified version of the URL you pass in, creates a callback function that saves the returned JSON object and that calls your callback with that object (and deletes the temporary script element). To you, the developer, it’s as if a ‘local’ and a ‘remote’ getJSON call just work in the same way: you specify the URL, and your callback is executed once the JSON object is returned.

I mentioned that for a ‘remote’ call the URL is modified a little: jQuery adds a callback query string to the end of the URL. This query string defines the name of the function that should wrap the returned JSON. For example, for “http://jmbk.nl/MakeUrl/?shorten=someurl”, the URL actually used is something like “http://jmbk.nl/MakeUrl/?shorten=someurl&callback=foobar”. The server is supposed to read this query string and construct the reply so that it becomes a call to this function. Better still is to be explicit about the callback function name: write the URL as “http://jmbk.nl/MakeUrl/?shorten=someurl&callback=?” and jQuery will make up a function with a unique name on the fly. This is by far the preferred way to do it: jQuery will ensure the returned JSON is not cached for example.

(Note: it does get a little confusing since there are two callbacks in play. There’s the callback function you write and pass to the $.getJSON() function. This function has one parameter: the JSON object that is returned. This callback will get called by jQuery once the AJAX request has completed. The other callback is the function that is used by the server to return the JSON. The browser calls this callback by executing the code returned from the AJAX request.)

Of course, in my case, since the URL I’m trying to shorten may itself have query strings, it behooves me to encode the long URL and for the server to decode it. Here’s the code I use on the client:

$(function () {
    var url = encodeURIComponent(http://blog.boyet.com/?foo=this&bar=that);
    url = "http://jmbk.nl/MakeUrl/?shorten=" + url + "&callback=?";
    $.getJSON(url, function (json) {
        $("#shortURL").attr("href", json.shortUrl);
    });
});

And here’s the (somewhat redacted) code on the server:

  public void ProcessRequest(HttpContext context) {
    string urlToShorten = context.Request.QueryString["shorten"];
    if (!string.IsNullOrEmpty(urlToShorten)) {
      string jsonpCallback = context.Request.QueryString["callback"];
      if (!string.IsNullOrEmpty(jsonpCallback)) {
        context.Response.ContentType = "text/javascript";
        string responseFormat = jsonpCallback + "({{ shortUrl : '{0}', requestCount : {1} }})";
        urlToShorten = Uri.UnescapeDataString(urlToShorten);   

        ShortUrl shortUrl = new ShortUrl(urlToShorten);
        shortUrl.Save();

        context.Response.Write(string.Format(responseFormat, shortUrl.PublicShortenedUrl, shortUrl.UsageCount));
      }
    }
  }

And that’s about it. If you want to do more with JSONP, check out the relevant options for $.ajax.

Now playing:
Karminsky Experience Inc. - Exploration
(from The Power Of Suggestion)

PCPlus 321: Tilt-shift photography

julian m bucknall — Sat, 04 May 2013 21:02:00 GMT

This was one of those articles where I had to start from scratch with my research: I knew pretty much nothing about the subject. Sure, I was familiar enough with those photos of real buildings that looked as if they were made as a model on the kitchen table, but I had no idea how they were produced. I’d assumed that it might be some kind of digital post-processing of a photo, but I didn’t have any idea that you could purchase special tilt-shift lenses for DSLRs.

I start off with the universal problem of photographing tall buildings: in order to get the top of the building in along with the bottom, you are forced to angle your camera upwards to fit it in. And that leads to the vertical lines in the view converging upwards. Enter the old view cameras, where you could shift the lens up or down (or side-to-side) rather than the camera itself, the bellows that connected the camera to the lens ensuring ease of movement and the blocking of light. In fact for architectural photos these cameras are still in use today.

For SLRs and DSLRs, there is no such thing as bellows between the camera and lens, and so there’s evolved a similar setup where the lens will rotate or slide in front of the film plane. Compared to normal prime and zoom lenses, they tend to be expensive. I must admit that, while I was writing this article, I thought about finding and buying a secondhand one for my Canon DSLR. But, even secondhand, they command a steep price. (As an example, the 24mm Canon TS-E L Mark II lens is around $1500 secondhand, which, for a lens I’d probably not use all that much, is a little out of my price range. But maybe one day.)

So if the physical accessories are so expensive, is there any way to fake it? The answer is yes, and you can see an example alongside. This is a normal photo I’d taken on one of our vacations to England, and is ideal for a fake tilt-shift effect: the area of interest is a small band in the middle of the image. Enter Gaussian blur, especially a derived specialized algorithm that applies more blur the further away from the area of interest. This gives the effect of the foreground and the background being out of focus, providing the illusion of a tiny scale. I quickly discuss the mathematics behind Gaussian blur, including a quick way to calculate an approximation to it.

(While I was writing this article, I wrote a blog post about tilt-shift here, further expanding ideas for digital processing of photos.)

This article first appeared in issue 321, May 2013.

You can read the PDF here.

(I used to write a monthly column for PCPlus, a computer news-views-n-reviews magazine in the UK, which sadly is no longer published. The column was called Theory Workshop and appeared in the Make It section of the magazine. When I signed up, my editor and the magazine were gracious enough to allow me to reprint the articles here after say a year or so.)

Now playing on Pandora:
Jose Padilla – Lontano (TripHop Mix) on Navigator

Buying a sleeve for the Dell XPS 12

julian m bucknall — Fri, 03 May 2013 03:08:00 GMT

My new XPS 12 is a pretty nice machine. Small (0.8” × 12.5” × 8.5”) and light (3.35 lbs), despite the intricacies of the flip screen and the touch capability. The top and bottom are covered in some kind of black matt surface that’s easy to grip and doesn’t seem to mark that easily. Yet, I’d prefer having something to protect it. Unfortunately it’s not such a bestseller like, say, the 13” MacBook Air that a whole accessories industry has grown around it.

Dell sell a couple of cases (too big and unwieldy for an ultrabook like this in my view), and a sleeve at $45. The sleeve at least has a flap with magnetic clasp, but is a smidge expensive.

My wife has an XPS 13 for which I purchased a Speck TrimSleeve. This was ostensibly for a 13” MacBook Air (the two machines have very similar dimensions). The XPS 12 fits in it nicely: what it gains in height, it loses in width and depth and so just glides into the sleeve. Unfortunately it seems Speck don’t sell it any more: (a) it’s out of stock, and (b) you can’t even get to the product page from the home page. This is a shame since it works extremely well and is pretty stylish too.

Since this mini-experiment showed that a 13” MacBook Air sleeve would be ideal, I did some research and found the Slim Sleeve from Incipio at $30. It looks to be very well made and classy. There are eight possible colors, but I wimped out and got black. It was delivered today, and I’m glad to say the XPS 12 fits it just right. The only issue is that the device could slip out since there’s no flap or clasp to hold it in, but I can’t see that as being a problem with the way I use the machine. We’ll see.

Now playing on Pandora:
Zero 7 – Red Dust on Simple Things

Upgrading hardware: Dell XPS 15z and XPS 12

julian m bucknall — Thu, 02 May 2013 03:17:34 GMT

We’re getting close to the conference season at work: in June I’m going to both TechEd US in New Orleans and //build/ in San Francisco. Rather than cart around my very unloved Surface RT (haven’t used it in possibly two months), I’ve been dithering about buying an Intel Windows 8 machine, a touch device, say a convertible.I’ve had my eye on two possibilities, the Surface Pro and the Dell XPS 12. Since none of the touch machines available right now just aren’t powerful or expansive enough to be my main PC, I’ve been thinking of upgrading that too.

First things first, my current machine is a Dell XPS 15z and I’ve already been on the upgrade path with it (one, two). This time, I had a problem that I was continually bumping into: I was running out of disk space. I had a 512GB Crucial M4 SSD in there, partitioned into two drives, both 256GB-ish, and twice in the past couple of months I’ve hit the dreaded “red bar” in the Windows Explorer drive list on both of them. Yes, sure, I was able to clean some stuff out (including the recycle bin) both times, but with an SSD you’ve got to allow some breathing space.

I looked online and there’s a new Crucial 960GB SSD on the market (the Crucial M500) for about $600, but it’s been out of stock pretty well permanently. I’ve even had an email alert registered with Newegg to be notified immediately they got some. Still no response. Since Newegg had a 15% off coupon for the past couple of weeks, I finally decided to switch out my optical drive instead for another Crucial M4 512GB SSD. Saved $60 on the $400 price, which went immediately to a DVD replacement caddy (I got one from newmodeus.com that fit the slimline 15z optical drive). That was the 15z taken care of – once I got the drive I merely copied one of the old partitions onto it (my data partition), removed it, and then expanded the other partition.

Once that was sorted out, a great deal came up on eBay for a nearly new XPS 12. It was the i7 version with 8GB memory and a 128GB SSD. New, they’re $1,400 in that configuration, but this one was a three-month-old buy-it-now from someone in Denver for $1,000. The SSD is too small (one reason I stopped thinking about the Surface Pro), but replacing it is even simpler than with the 15z – opening the 15z can be frustrating in the extreme. Since Newegg had a Crucial mSata 256GB SSD in stock (there are no 512GB mSata SSDs yet), and the coupon was still valid, I snagged one for $180. In essence, I got a top of the line XPS 12 for $1,180, whereas new, they’re $1,700. Not too shabby.

In replacing the drive, the first thing to do was to create a recovery disk (or rather a recovery USB drive) from the partitions on the existing drive. This needs an 8GB drive for that – I had lots of spare USB drives of that size – and the process using the Dell recovery app was pretty painless, just lengthy. Of course I did not keep any of the existing data. Swapping the SSDs was easy too – removing the screws from the bottom of the Ultrabook causes the base to come off. The SSD is held in with one other screw. Next the reboot was simple: you just have to make sure the device boots from the USB drive. Half an hour later or so, I had a brand new repaved system. (And, man, it needs six partitions? I could work out which one is the recovery partition and delete and merge it, but to be honest, I can’t be bothered.)

Since I’m going to be using the XPS 12 as a Windows 8 development system and also a demonstration system at conferences, I installed everything needed for that: Visual Studio 2012, SQL Server Standard, Sublime Text 2, Office 2013, Firefox, and, of course, all of DevExpress’ products. After doing all that, I’ve got 146GB free for projects and data. I’ll probably copy over some of my current projects as and when.

Oh, and I installed a Start Menu replacement. Sorry, I just can’t stand the Start screen for normal work (just the flash of the Start screen as I type the name of an app to find it is irritating) and most of the apps I just installed are all desktop apps anyway.

Now playing on Pandora:
Daft Punk - The Game Has Changed on Tron Legacy

PCPlus 320: Error detection and correction

julian m bucknall — Tue, 23 Apr 2013 00:41:56 GMT

OK, I admit it. I’ve been in the programming industry for more years that I care to count, and although I’d vaguely considered error detection in the past, it wasn’t until I did some research for this next article that I finally got to have some understanding of it all. And not only error detection but correction too: now that was pure magic. But, as with all these things, once you get the basic idea about how it works, all the magic gets stripped away.

I suppose the first kind of error detection I’d come across was the parity bit, especially with regard to the dodgy RAM and diskettes and trundling hard disks you used to have in the MSDOS days. Here we suppose that the storage medium is subject to some errors (either writing to the storage medium or reading it back again). What happened was that bytes were stored as 9 bits, the required eight bits in the byte and a parity bit. If there were an odd number of 1 bits in the byte, the parity bit would be set to 1 for even parity or 0 for odd parity. When the byte was retrieved the hardware could check that the 9 bits read had an even number of 1 bits or an odd number, depending on the parity scheme in place. It couldn’t do anything about it if it detected an error, of course.

The next example of error detection I came across was a checksum calculation, such as credit card numbers: again, it detects errors but doesn’t help correct them. Mind you, with a credit card number you can just ask the customer for it again; it’s unlikely you’d have such a data storage problem that a credit card number gets corrupted. A more interesting checksum is Cyclic Redundancy Check (CRC), or cryptographic hashes like SHA-1 or MD5. These checksums try and identify cases where the input message is corrupted in a perhaps subtle way.

Then there’s barcodes. Although linear barcodes tend to have error detection though some kind of checksum, 2D barcodes generally have error correction as well since they can store more information per unit area. The familiar QR code uses the Reed-Solomon error correction algorithm. In the article I show how to calculate an earlier error correction algorithm, Hamming codes, and how they can be used to detect and correct errors. The (7,4) Hamming code I show is the best way to detect and correct single bit flips in 4 data bits.

In essence, in any situation where you are trying to transmit data (a message) from point A to point B digitally (scanning barcodes, streaming from a DVD, reading SSD memory chips, etc) where there is a possibility that some physical damage will cause data corruption, there will be some error detection and correction algorithm in the background trying to make sure that we get what we expect. Like many things in the digital realm, it’s just invisibly working for us.

This article first appeared in issue 320, April 2012.

You can read the PDF here.

Now playing:
Tears for Fears - God's Mistake
(from Raoul and the Kings of Spain)

Scientists in Paris

julian m bucknall — Sun, 14 Apr 2013 20:28:42 GMT

We were vacationing in Paris last week in a hotel in the 16eme arrondissement, just outside the boundary of the 8eme. We’d stayed there before, but I noticed this time that several streets in the vicinity has names commemorating scientists and mathematicians. I thought it would be fun to take pictures of the ones I could find that were close and put them in a collage:

In order, they are:

Augustin-Jean Fresnel. We also saw a lighthouse lens built on his principles in the Musée Maritime.
Johannes Kepler
Leonhard Euler
Isaac Newton
Galileo Galilei
Nicolaus Copernicus
Léon Foucault

I did also think that Avenue Raymond Poincaré might have been named after the mathematician (I couldn’t remember his first name offhand), but it turned out to be for the President during the first World War and not Henri Poincaré, he of the famous Conjecture.

Now playing:
Daho, Etienne - La Baie
(from Corps et Armes)

Inline scripts: sometimes the web is just screwed up

julian m bucknall — Tue, 02 Apr 2013 01:49:04 GMT

I don’t know about you, but one of my favorite commands in the browser is “View Page Source”, especially on a site that’s modern, visually attractive, or shows off some clever interactions. After all, I’m a developer: I like to find out how things work so I can, if I want to, replicate on my own web sites.

Some web pages though are really nasty when you look at their source. And one of the places they excel at nastiness is in their use of inline scripts. Now, don’t get me wrong, I’m not particularly objecting to inline scripts: sometimes they’re the biz when you just have some minor bit of JavaScript to execute, so minor it doesn’t seem efficient to create a brand new JS file and add the external script tag to the HTML on the page. And then sometimes you get web pages that can’t seem to decide how the heck they should represent inline scripts and throw everything but the kitchen sink at the problem.

Let’s take a look at the three main ways you can insert inline scripts into your HTML. First, there’s the obvious way, just unadorned:

<script type="text/javascript">
    $(function () {
        var inputText = $("#inputtext"),
            outputMath = $("#outputmath"),
            inlineMath = $("#inlinemath");

        inputText.on("keyup", function () {
            var expr = inputText.val();
            outputMath.text('\\[ ' + expr + ' \\]');
            inlineMath.text('The expression is <\\( ' + expr + ' \\)>.');
            MathJax.Hub.Queue(["Typeset", MathJax.Hub, "outputmath"]);
            MathJax.Hub.Queue(["Typeset", MathJax.Hub, "inlinemath"]);
        });

    });
</script>

Then, from way back when, there was the attempt to circumvent those browsers that didn’t support inline JavaScript by enclosing the code in HTML comments:

<script type="text/javascript">
    <!--
    $(function () {
        var inputText = $("#inputtext"),
            outputMath = $("#outputmath"),
            inlineMath = $("#inlinemath");

        inputText.on("keyup", function () {
            var expr = inputText.val();
            outputMath.text('\\[ ' + expr + ' \\]');
            inlineMath.text('The expression is < \\( ' + expr + ' \\) >.');
            MathJax.Hub.Queue(["Typeset", MathJax.Hub, "outputmath"]);
            MathJax.Hub.Queue(["Typeset", MathJax.Hub, "inlinemath"]);
        });

    });
    // -->
</script>

Notice that (1) the opening HTML comment tag is allowed to be “bare” (it’s not counted as part of the JavaScript code) but the closing end-comment tag must be itself commented out in the inline JavaScript.

Finally there’s the CDATA approach, which just seems wacky until you understand why it’s used:

<script type="text/javascript">
    // <![CDATA[
    $(function () {
        var inputText = $("#inputtext"),
            outputMath = $("#outputmath"),
            inlineMath = $("#inlinemath");

        inputText.on("keyup", function () {
            var expr = inputText.val();
            outputMath.text('\\[ ' + expr + ' \\]');
            inlineMath.text('The expression is < \\( ' + expr + ' \\) >.');
            MathJax.Hub.Queue(["Typeset", MathJax.Hub, "outputmath"]);
            MathJax.Hub.Queue(["Typeset", MathJax.Hub, "inlinemath"]);
        });

    });
    // ]]>
</script>

So what’s up with all this? Why the three different methods?

The first point to recognize is that there are two characters that should never be used un-escaped in HTML: the less-than angle bracket (<) and the ampersand (&). In the inline code I’m showing in method 1, there’s a left angle bracket. Luckily, in HTML, text that appears in a script element can contain these two characters un-escaped. (The only thing that cannot appear in a script element is the string “</script>”, since that signals the end of the script.) So, with all modern day browsers, this kind of unadorned inline script is accepted in an HTML file without issues (except for one special case, which I’ll come to in a moment).

Method 2 was used purely for those browsers that didn’t understand inline scripts. To be exact, the <script> tag was introduced in HTML 3.2 as a placeholder and browsers from that point on would no longer display the inline code as text when displaying the page – which is what happened prior to that. If you can remember those days, more power to you; I certainly can’t. So, back in the dim and distant past the inline code had to be commented out HTML-wise to make sure it wasn’t displayed by a horse-drawn user agent. Fast forward to the 21st century where even – shock, horror – IE6 recognized inline script. Method 2 then is not required ever, anymore. Just say no. (Incidentally there’s another issue with the “commented out” inline script: the code could not contain dash-dash (--), since it was that character sequence that officially denoted the end of the comment. So no post- or pre-decrements in your code, OK?)

Method 3 is an interesting one. It’s the only allowed way to have general text embedded in an XML file that isn’t going to be parsed as XML. Hence it’s the only way to have valid un-escaped less-than signs or ampersands in the XML file. And, of course, an HTML file that is flagged as XHTML in the file’s DOCTYPE is supposed to be valid XML. However, that’s not the end of the story. Basically browsers have two parsers: an HTML parser and an XML parser, with the HTML parser being used the vast majority of the time. This is true even in the case of an HTML file flagged as XHTML in the DOCTYPE: the HTML parser will be used. Since the CDATA section is not part of the HTML spec, both the start and end CDATA tags are just ignored: and this is especially so since they are both commented out in the inline script. The only time the CDATA section is parsed as such is if (a) the HTML file is flagged as XHTML, and (b) the HTTP response header sent by the web server marks the content as the “application/xhtml+xml” MIME type. In this case, the XML parser is executed on the content and your inline script had better be in a CDATA section just in case.

So, where does this leave you?

First, just avoid inline script. If you do, you don’t have to worry about any of this palaver.
Second, never use method 2. Never, ever, ever. It’s not been needed for years, and when even IE6 (spit, spit) doesn’t need it, you are completely safe in avoiding it.
Third, if you are at the cutting edge of web development and are writing HTML5 pages or web sites or applications and you absolutely have to have inline JavaScript, just use method 1. All modern browsers will understand what you want and none will barf at your succinctness.
Fourth, only use method 3 if you are declaring your HTML as XHTML in the DOCTYPE, and you have set up your web server to declare these files as “application/xhtml+xml”. If you are doing that, more power to you!
Fifth, use method 1 in all other cases.

Now isn’t that all just simple?

Now playing:
Fila Brazillia - Pollo De Palo
(from Luck Be A Weirdo Tonight)

Upgrading to jQuery 1.9.x

julian m bucknall — Sun, 24 Mar 2013 04:15:13 GMT

Today it snowed. It started before we awoke and pretty much kept at it all day. Hence it was a day to do some work inside, and what better task than to clean up my blog? First port of call, and a major one at that, was to upgrade to jQuery 1.9.

Before you say, so what, just change the version number in the <script> tag, consider this. jQuery 1.9 removes several APIs that “behaved inconsistently or inefficiently in the past” (here), ones that have been deprecated for a while. So, replacing the version number willy-nilly might break some code. Can’t have that.

The jQuery team have mitigated the problem by providing the jQuery Migrate plugin. This has two main benefits: it firstly adds back the removed APIs so that you can continue as before (however, doing so comes with some caveats), and secondly, when you use the un-minified version instead of the production version, it not only does that but also writes warning diagnostic messages to the console if such APIs are used. You can then use these messages to work out which JavaScript code needs to be changed and, by using the Upgrade Guide, fix the problems. And, in general, the fixes are quite easy.

After updating the jQuery version number ion my HTML and adding a new script tag to reference the uncompressed Migration plugin, I found I had one problem in my own code: the "hover” pseudo-event no longer exists.

This was my original code that triggered the warning:

sidebarDiv.unbind("hover");

In essence: unbind the hover event handler from the DOM element called sidebarDiv. Now, although bind() and unbind() are still valid, the documentation for them explicitly state that the new on() and off() methods are preferred to add or remove event handlers. OK, then. The removal code was pretty simple to fix, especially as the new methods allow for a space-delimited list of events, instead of just one at a time:

sidebarDiv.off("mouseenter mouseleave");

The setting of the hover event handler was a little more involved. The original API allowed for two callback functions to be defined in the one call:

sidebarDiv.hover(function () {
    mouseInside = true;
  },
  function () {
    mouseInside = false;
  }
);

but the new separate event types would either mean two separate calls to set the handlers, or a more clever handler. I went with the second route, using the passed in parameter to get at the event type:

sidebarDiv.on("mouseenter mouseleave", function (event) {
  if (event.type === "mouseenter") {
    mouseInside = true;
  }
  else {
    mouseInside = false;
  }
});

After that I just modified the other (albeit still valid) calls to bind() and unbind() I had in the code to use the new APIs just to be consistent.

And I’d have to say that was pretty much it for me. I had to update a third-party library I was using (a new version was available that supported jQuery 1.9), but nothing else was being flagged by the Migration plug-in. Score!

(Oh, I also added a drop cap for the initial paragraph for each blog post. Just because. To find out how, go here. I used the second method, which requires CSS3 support in the browser.)

Now playing:
Gabriel, Peter - The Drop
(from Up)