The Comparative International Education Society (CIES) Language Issues (LI) Special Interest Group (SIG) is pleased to announce its 2014 Dissertation Award!  The award is open to dissertations that focus on educational language issues, broadly defined, in comparative and international education.  Dissertations will be reviewed based on the following criteria:

1. The dissertation’s relevance to current thinking in the field

2. The degree of sophistication or innovation of the methodology used

3. The soundness of data collection and analysis

4. The dissertation’s social utility and/or its implication for policy

5. The degree to which the dissertation incorporates a comparative perspective

Eligible dissertations must have been filed within an 18-month period prior to the LI SIG award’s extended submission deadline of February 15, 2014 (e.g., from August 15, 2012 to February 15, 2014).   Students in Ed.D. or Ph.D. programs are eligible and the applicant and/or the Dissertation Chair must be a current member of CIES.  The winning dissertation will receive $100.

Applicants should submit the following four documents to be considered for the award:

1. A detailed abstract of no more than five pages along with a self-assessment indicating how the dissertation meets the above five criteria; both should be doubled-spaced with no author identification (for blind review)

2. A title page (not counted within the page limit) with author’s name, address, institutional affiliation, telephone, e-mail address, and names of dissertation committee chair(s) and members

3. A reference page (not counted within the page limit) with only the references cited in the abstract, and

4. One letter from the Dissertation Chair recommending the dissertation for this award (this letter may be sent directly to the Committee at the e-mail address below).

After the initial round of consideration, the two highest rated candidates will be asked to send the Committee a file with their entire dissertation. Awardees will be recognized formally at the LI SIG business meeting at the CIES Conference in Toronto, Canada, March 10-14, 2014.

Submission Information

Please, submit the above documents electronically (as attachments in Word compatible files) with the key word “Dissertation Award Submission” in the subject line to:  cieslangsig@gmail.com by February 15, 2014.  If you have any questions, please do not hesitate to contact Awards Committee at the above e-mail address.

W3C has published the January 2014 edition of Standards for Web Applications on Mobile, an overview of the various technologies developed in W3C that increase the capabilities of Web applications, and how they apply more specifically to the mobile context.

A deliverable of the HTML5Apps project, this edition of the document includes changes and additions since September 2013, including 6 documents reaching Recommendation status (a record), which shows increased maturity of the platform; 4 FPWD and 4 new editors drafts illustrate it is still growing up nicely; and a lot of the changes are linked to performance, off-line support and packaging.

Learn more about the Web and Mobile Interest Group.

• Defining the project/research question
• Writing a budget
• Working with a faculty mentor

Application deadline SOON.

If you think you will be applying for a URA, e-mail mcglynn@umbc.edu to be included on the list of interested students.

A little while ago I wrote about the recent updates to the Brackets editor. Brackets is an open source project focused on web standards and built with web technologies. It has a narrow focus and therefore may not have a particular feature you've come to depend upon. Luckily, Brackets ships with a powerful extension API that lets you add any number of new features. In this article, I'm going to discuss this API and demonstrate how you can build your own extensions.

It is crucial that you remember that Brackets is in active development. This article is being written in December of 2013. It is certainly possible that the code demonstrated below is now out of date. Keep that in mind and be sure to check the wiki for the latest updates to the extension API.

Getting Started

I'm going to assume you read my last article and are already familiar with the extension manager. This provides a simple, one click method of installing extensions. One of the best ways you can learn to write extensions is by looking at the work done by others (that's how I learned). I'd recommend grabbing a few extensions (there's almost 200 available now) and tearing apart their code. Don't be afraid to break a few while you're at it.

Brackets puts all installed extensions within one main folder. To find that folder, go to the Help menu and select "Show Extensions Folder". For my OS X install, this was located at /Users/ray/Library/Application Support/Brackets/extensions/user. If you go up from that folder, you'll notice a disabled folder as well. Brackets will make a valiant effort to load no matter what, but if you ever find yourself in a situation where Brackets has completely crapped the bed and simply will not work, consider moving potentially bad extensions into the disabled folder. Later on in the article, I'll discuss how you can monitor and debug extensions to help prevent such problems in the first place.

Begin by going to your user folder and creating a new folder, helloworld1. Yes, even though it is completely lame, we're going to build a HelloWorld extension. Don't hate me, I like simple. Inside that folder create a new file called main.js. Listing one shows what the contents of this file should be. Note that in this article I'll go through a couple of different iterations of the helloworld extension. Each one will be named with a progressively higher number. So our first example is from helloworld1, the next helloworld2, and so on. It would make sense for you to simply copy the code into one folder, helloworld, instead of copying each one by themselves. If you do, you'll have multiple related extensions running at once and that can definitely confuse things.

Listing 1: helloworld1/main.js
    define(function(require, exports, module) {
    
        function log(s) {
                console.log("[helloworld] "+s);
        }
    
        log("Hello from HelloWorld.");
    });

The first line defines our extension as a module that will be picked up by Brackets automatically on application load. The rest of the extension is a custom log message (you will see why in a second) and a call to that logger. Once you have this file saved, go back to Brackets, select the Debug menu, and hit Reload. (You can also use Command/Control+R to reload as well.)

Brackets will reload and ... nothing else will happen. The extension we built didn't actually do anything that we could see, but it did log to the console. But where is that console? Brackets provides an easy way to view the console. Simply go back to the Debug menu and select Show Developer Tools. This will open a new tab in Chrome with a familiar Dev Tools UI. In the screen shot below I've highlighted our log. Other extensions, and Brackets itself, will also log messages to this screen. By prefixing my log messages with [helloworld], I can make my own stuff a bit easier to find.

Note that the full Chrome console.api works here. You can do stuff like this to format your console messages:

    
    function log(s) {
        console.log("%c[helloworld] "+s,"color:blue;font-size:large");
    }

Go crazy, but try to remove these messages before you share your code with the rest of the world. In case you're curious, you can't use dev tools in another browser, like Firefox, at this time.

Integration Points

Now that you know the (very) basics, let's talk about what Brackets extensions can do to the editor:

• They can create keyboard shortcuts, allowing them to respond to custom keystrokes.
• They can add to the top level menu.
• They can add context menus (and to a specific area, like the file listing or the editor window).
• They can create UI items. This can be a modal dialog or even a panel. (Currently the panel is locked to the bottom of the screen).
• They can create a linting provider (essentially they can register themselves as a code checker for a file type).
• They can create their own inline editors (a major feature of Brackets).
• They can register as a documentation provider (for example, adding MDN support for docs).
• They can integrate with Quick Find and Quick Open.
• They can add custom code hints and syntax colors.
• They can read the current file open in the editor as well as modify it. (They can also see the current selected text, if any.)

That describes how extensions can modify Brackets, but what can extensions actually do in terms of code? Keeping in mind that you're writing extensions in pure web standards (HTML, JavaScript, and CSS), you actually have quite a bit of power. The only real limits relate to binary data. There is a File system API that gives you control over files but is limited to text data only. Luckily, you have a way out.

Any Brackets extension can integrate with Node.js. If you've got an existing Node.js package your extension can make calls to it and do, well, whatever Node.js can do, which is essentially anything.

Let's update our extension to integrate with the editor a bit better. I'll start by simply adding a menu item for the extension.

Listing 2: helloworld2/main.js
    /*
    Based - in part - on the HelloWorld sample extension on the Brackets wiki:
    https://github.com/adobe/brackets/wiki/Simple-%22Hello-World%22-extension
    */
    define(function(require, exports, module) {
    
        var CommandManager = brackets.getModule("command/CommandManager"),
                Menus = brackets.getModule("command/Menus"),
                AppInit = brackets.getModule("utils/AppInit");
    
    
        function log(s) {
                console.log("[helloworld2] "+s);
        }
    
    
        function handleHelloWorld() {
                alert("You ran me, thanks!");
        }
    
    
        AppInit.appReady(function () {
    
                log("Hello from HelloWorld2.");
    
                var HELLOWORLD_EXECUTE = "helloworld.execute";
    
                CommandManager.register("Run HelloWorld", HELLOWORLD_EXECUTE, handleHelloWorld);
    
                var menu = Menus.getMenu(Menus.AppMenuBar.VIEW_MENU);
                menu.addMenuItem(HELLOWORLD_EXECUTE);
    
        });
    
    });

We've got a few changes here so let's tackle them one by one. You'll notice that the extension begins with three calls to brackets.getModule. All extensions have access to a brackets object that provides an API where we can load in core functionality from the editor. In this case the extension has loaded two libraries we'll need for the menu (CommandManager and Menus) and one which will be used to help initialize the extension (AppInit).

Lets talk about AppInit. You can see that most of the extension is now loaded with a appReady callback. This callback is fired when Brackets has completed loading and is generally considered "best practice" for extensions to make use of.

Registering a menu item takes a few steps. I begin by defining a "command ID", a unique identifier for the item I'll be adding to the UI. The typical way to do this is with the format extensionname.someaction. In my case, I used helloworld.execute. I can then register this command along with the function (handleHelloWorld) that should be called when the command is fired.

The final step is to add this command to the menu. You can probably guess that my menu item will be added under the View menu based on this value: Menus.AppMenuBar.VIEW_MENU. How did I know that value? Simple, I saw other extensions do it. Seriously though, there is no specific list of items like this yet. Don't forget that Brackets is open source. I can easily pop over to the GitHub repo and check it out. In this case, the file is Menus.js, located on Github. In there I can see where the various different core menus are defined:

/**
      * Brackets Application Menu Constants
      * @enum {string}
    */
    var AppMenuBar = {
         FILE_MENU       : "file-menu",
         EDIT_MENU       : "edit-menu",
         VIEW_MENU       : "view-menu",
         NAVIGATE_MENU   : "navigate-menu",
         HELP_MENU       : "help-menu"
    };

As a general rule of thumb, it makes sense to have at least a cursory understanding of what's available in Brackets itself. Your extensions will, from time to time, make use of multiple different features so it's definitely in your best interest to at least know the lay of the land.

After reloading Brackets, you'll now see the menu item in the View menu. Exactly where it is may be a bit random as you may have other extensions installed.

You can actually be a bit more specific about your position. Again, this is where the source code will help you. The same file I linked to above also contains the addMenuItem definition.

Put Some Lipstick on That Pig

Now that you've seen a simple example of how an extension can integrate into Brackets, let's look at how we update the UI. In the previous version of our code, an alert was used to send a message. While this works, it isn't very pretty. Your code can access the Brackets editor just like any other DOM modification code. While you can do anything you want, there are a few standard ways extensions update the UI in Brackets. (As a warning, in general you do not want to touch the DOM of the main editor UI. You can, but with future updates, your code may break. Also, users may not be happy if your extension changes something core to Brackets.)

The first method we'll look at uses modal dialogs. Brackets already uses this and has an API available for extensions to call. As a simple example, let's just update the HelloWorld extension to use a modal instead.

Listing 3: helloworld3/main.js
    /*
    Based - in part - on the HelloWorld sample extension on the Brackets wiki:
    https://github.com/adobe/brackets/wiki/Simple-%22Hello-World%22-extension
    */
    define(function(require, exports, module) {
    
        var CommandManager = brackets.getModule("command/CommandManager"),
            Menus = brackets.getModule("command/Menus"),
            Dialogs = brackets.getModule("widgets/Dialogs"),
            DefaultDialogs = brackets.getModule("widgets/DefaultDialogs"),
            AppInit = brackets.getModule("utils/AppInit");
    
        function log(s) {
                console.log("[helloworld3] "+s);
        }
    
        function handleHelloWorld() {
            Dialogs.showModalDialog(DefaultDialogs.DIALOG_ID_INFO, "Hello World", "Same Important Message");
        }
    
        AppInit.appReady(function () {
    
            log("Hello from HelloWorld3.");
    
            var HELLOWORLD_EXECUTE = "helloworld.execute";
    
            CommandManager.register("Run HelloWorld", HELLOWORLD_EXECUTE, handleHelloWorld);
    
            var menu = Menus.getMenu(Menus.AppMenuBar.VIEW_MENU);
            menu.addMenuItem(HELLOWORLD_EXECUTE);
    
        });
    
    });

Note the addition of two additional Brackets modules: Dialogs and DefaultDialogs. The next change is in handleHelloWorld. One of the methods in the Dialog library is the ability to show a dialog (no surprise there, I suppose). The method wants a class, a title, and a body, and that's it. There's more you can do with dialogs, but for now, this demonstrates the feature. Now when we run the command, we get a much prettier UI. (Along with default buttons and behaviours to handle closing the dialog.)

That's one example, now lets look at another: creating a bottom panel. As with dialogs, we've got support from Brackets to make it easier. Let's look at an example and then I'll explain the changes.

Listing 4: helloworld4/main.js
    /*
    Based - in part - on the HelloWorld sample extension on the Brackets wiki:
    https://github.com/adobe/brackets/wiki/Simple-%22Hello-World%22-extension
    */
    define(function(require, exports, module) {
    
        var CommandManager = brackets.getModule("command/CommandManager"),
        Menus = brackets.getModule("command/Menus"),
        PanelManager = brackets.getModule("view/PanelManager"),
        AppInit = brackets.getModule("utils/AppInit");
    
        var HELLOWORLD_EXECUTE = "helloworld.execute";
        var panel;
    
        function log(s) {
                console.log("[helloworld4] "+s);
        }
    
        function handleHelloWorld() {
            if(panel.isVisible()) {
                panel.hide();
                CommandManager.get(HELLOWORLD_EXECUTE).setChecked(false);
            } else {
                panel.show();
                CommandManager.get(HELLOWORLD_EXECUTE).setChecked(true);
            }
        }
    
        AppInit.appReady(function () {
    
                log("Hello from HelloWorld4.");
    
                CommandManager.register("Run HelloWorld", HELLOWORLD_EXECUTE, handleHelloWorld);
    
                var menu = Menus.getMenu(Menus.AppMenuBar.VIEW_MENU);
                menu.addMenuItem(HELLOWORLD_EXECUTE);
    
                panel = PanelManager.createBottomPanel(HELLOWORLD_EXECUTE, $("<div class='bottom-panel'>HTML for my panel</div>"),200);
    
        });
    
    });

Let's focus on the changes. First, I dropped the Dialog modules as I'm no longer using them. Instead, we load up the PanelManager. Down in the appReady block I've defined a new panel using the PanelManager API method createBottomPanel. Like the menu command this takes in a unique ID so I just reuse HELLOWORLD_EXECUTE. The second argument is a jQuery-wrapped block of HTML (and in case you're wondering, yes we can do this nicer), and finally, a minimum size. This sets up the panel but doesn't actually execute it.

In the event handler, we have tied to the menu, we can ask the panel if it is visible and then either hide or show it. That part should be pretty trivial. For fun I've added in a bit more complexity. Notice that CommandManager lets us get a menu item and set a checked property. This may be unnecessary as the user can see the panel easily enough themselves, but adding the check just makes things a little bit more obvious. In the screen shot below you can see the panel in its visible state.

Right away you may be wondering about the panel HTML. Is there a better way to provide the HTML? Anyway to style it? Yep, lets look at a more advanced version.

Listing 5: helloworld5/main.js
    /*
    Based - in part - on the HelloWorld sample extension on the Brackets wiki:
    https://github.com/adobe/brackets/wiki/Simple-%22Hello-World%22-extension
    */
    define(function(require, exports, module) {
    
    
        var CommandManager = brackets.getModule("command/CommandManager"),
        Menus = brackets.getModule("command/Menus"),
        PanelManager = brackets.getModule("view/PanelManager"),
        ExtensionUtils          = brackets.getModule("utils/ExtensionUtils"),        
        AppInit = brackets.getModule("utils/AppInit");
    
        var HELLOWORLD_EXECUTE = "helloworld.execute";
        var panel;
        var panelHtml     = require("text!panel.html");
    
        function log(s) {
                console.log("[helloworld5] "+s);
        }
    
        function handleHelloWorld() {
            if(panel.isVisible()) {
                panel.hide();
                CommandManager.get(HELLOWORLD_EXECUTE).setChecked(false);
            } else {
                panel.show();
                CommandManager.get(HELLOWORLD_EXECUTE).setChecked(true);
            }
        }
    
        AppInit.appReady(function () {
    
            log("Hello from HelloWorld5.");
            ExtensionUtils.loadStyleSheet(module, "helloworld.css");
            CommandManager.register("Run HelloWorld", HELLOWORLD_EXECUTE, handleHelloWorld);
    
            var menu = Menus.getMenu(Menus.AppMenuBar.VIEW_MENU);
            menu.addMenuItem(HELLOWORLD_EXECUTE);
    
            panel = PanelManager.createBottomPanel(HELLOWORLD_EXECUTE, $(panelHtml),200);
    
        });
    
    });

As before, I'm going to focus on the changes. First note that I've included a variable called panelHtml that is loaded via require. This lets me define my HTML outside of my JavaScript code. (You can also use templating engines. Brackets ships with Mustache.) The HTML behind the panel is rather simple.

Listing 6: helloworld5/panel.html
    <div class="bottom-panel helloworld-panel" id="helloworldPanel">
    <h1>My Panel</h1>
    
    <p>
    My panel brings all the boys to the yard,<br/>
    And they're like<br/>
    It's better than yours,<br/>
    Damn right it's better than yours,<br/>
    I can teach you,<br/>
    But I have to charge
    </p>
    </div>

Returning to main.js, I've demonstrated another feature, loadStyleSheet. This lets you load an extension specific style sheet. I created a file, helloworld.css, with some simple (but tasteful) CSS styles.

Listing 7: helloworld5/helloworld.css
    .helloworld-panel h1 {
            color: red;
    }
    
    .helloworld-panel p {
            color: blue;
            font-weight: bold;
    }

Note that I prefixed my styles with a unique name. This helps ensure my classes don't conflict with anything built into Brackets. With these simple changes my panel now looks much better, and you can see why I'm known world wide for my superior design skills.

Packaging and Sharing Your Kick Butt Extension

Of course, just creating the coolest Brackets extension isn't quite enough. You probably (hopefully!) want to share it with others. One option is to just zip up the directory and put it on your website. Folks can download the zip, extract it, and copy it to their Brackets extensions folder.

But that's not cool. You want to be cool, right? In order to share your extension and make it available via the Brackets Extension manager, you simply need to add a package.json file to your extension. If you've ever used Node.js, then this will seem familiar. Here is a sample one for our extension.

Listing 8: helloworld6/package.json
    {
        "name": "camden.helloworld",
        "title": "HelloWorld",
        "description": "Adds HelloWorld support to Brackets.",
        "homepage": "https://github.com/cfjedimaster/something real here",
        "version": "1.0.0",
        "author": "Raymond Camden <raymondcamden@gmail.com> (http://www.raymondcamden.com)",
        "license": "MIT",
        "engines": {
            "brackets": "<=0.34.0"
        }
    }

Most of this is self-explanatory, but the real crucial portion is the engines block. Brackets updates itself pretty rapidly. If Brackets added a particular feature at some point that your extension relies on, you can add a simple conditional here to ensure folks don't try to install your extension on an incompatible version. (You can find a full listing of the possible settings on the Wiki.)

Once you've done this, the next part is to upload it to the Brackets Registry. You will need to log in via your GitHub account, but once you've done that, you can then simply upload your zip. Your extension will then be available to anyone using Brackets. Even better, if you update your extension, the Extension Manager will actually be able to flag this to the user so they know an update is available.

What Else?

Hopefully, you've seen how easy it is to extend Brackets. There's more we didn't cover, like the Linting API and NodeJS integration, but this article should be more than enough to get you started. As a reminder, do not forget there is a large collection of extensions available for you to start playing with right now. Good luck!

A little while ago I wrote about the recent updates to the Brackets editor. Brackets is an open source project focused on web standards and built with web technologies. It has a narrow focus and therefore may not have a particular feature you’ve come to depend upon. Luckily, Brackets ships with a powerful extension API that lets you add any number of new features. In this article, I’m going to discuss this API and demonstrate how you can build your own extensions.

It is crucial that you remember that Brackets is in active development. This article is being written in December of 2013. It is certainly possible that the code demonstrated below is now out of date. Keep that in mind and be sure to check the wiki for the latest updates to the extension API.

Getting Started

I’m going to assume you read my last article and are already familiar with the extension manager. This provides a simple, one click method of installing extensions. One of the best ways you can learn to write extensions is by looking at the work done by others (that’s how I learned). I’d recommend grabbing a few extensions (there’s almost 200 available now) and tearing apart their code. Don’t be afraid to break a few while you’re at it.

Brackets puts all installed extensions within one main folder. To find that folder, go to the Help menu and select “Show Extensions Folder“. For my OS X install, this was located at /Users/ray/Library/Application Support/Brackets/extensions/user. If you go up from that folder, you’ll notice a disabled folder as well. Brackets will make a valiant effort to load no matter what, but if you ever find yourself in a situation where Brackets has completely crapped the bed and simply will not work, consider moving potentially bad extensions into the disabled folder. Later on in the article, I’ll discuss how you can monitor and debug extensions to help prevent such problems in the first place.

Begin by going to your user folder and creating a new folder, helloworld1. Yes, even though it is completely lame, we’re going to build a HelloWorld extension. Don’t hate me, I like simple. Inside that folder create a new file called main.js. Listing one shows what the contents of this file should be. Note that in this article I’ll go through a couple of different iterations of the helloworld extension. Each one will be named with a progressively higher number. So our first example is from helloworld1, the next helloworld2, and so on. It would make sense for you to simply copy the code into one folder, helloworld, instead of copying each one by themselves. If you do, you’ll have multiple related extensions running at once and that can definitely confuse things.

Listing 1: helloworld1/main.js
    define(function(require, exports, module) {
    
        function log(s) {
                console.log("[helloworld] "+s);
        }
    
        log("Hello from HelloWorld.");
    });
    

The first line defines our extension as a module that will be picked up by Brackets automatically on application load. The rest of the extension is a custom log message (you will see why in a second) and a call to that logger. Once you have this file saved, go back to Brackets, select the Debug menu, and hit Reload. (You can also use Command/Control+R to reload as well.)

Brackets will reload and … nothing else will happen. The extension we built didn’t actually do anything that we could see, but it did log to the console. But where is that console? Brackets provides an easy way to view the console. Simply go back to the Debug menu and select Show Developer Tools. This will open a new tab in Chrome with a familiar Dev Tools UI. In the screen shot below I’ve highlighted our log. Other extensions, and Brackets itself, will also log messages to this screen. By prefixing my log messages with [helloworld], I can make my own stuff a bit easier to find.

Note that the full Chrome console.api works here. You can do stuff like this to format your console messages:

    
    function log(s) {
        console.log("%c[helloworld] "+s,"color:blue;font-size:large");
    }
    

Go crazy, but try to remove these messages before you share your code with the rest of the world. In case you’re curious, you can’t use dev tools in another browser, like Firefox, at this time.

Integration Points

Now that you know the (very) basics, let’s talk about what Brackets extensions can do to the editor:

• They can create keyboard shortcuts, allowing them to respond to custom keystrokes.
• They can add to the top level menu.
• They can add context menus (and to a specific area, like the file listing or the editor window).
• They can create UI items. This can be a modal dialog or even a panel. (Currently the panel is locked to the bottom of the screen).
• They can create a linting provider (essentially they can register themselves as a code checker for a file type).
• They can create their own inline editors (a major feature of Brackets).
• They can register as a documentation provider (for example, adding MDN support for docs).
• They can integrate with Quick Find and Quick Open.
• They can add custom code hints and syntax colors.
• They can read the current file open in the editor as well as modify it. (They can also see the current selected text, if any.)

That describes how extensions can modify Brackets, but what can extensions actually do in terms of code? Keeping in mind that you’re writing extensions in pure web standards (HTML, JavaScript, and CSS), you actually have quite a bit of power. The only real limits relate to binary data. There is a File system API that gives you control over files but is limited to text data only. Luckily, you have a way out.

Any Brackets extension can integrate with Node.js. If you’ve got an existing Node.js package your extension can make calls to it and do, well, whatever Node.js can do, which is essentially anything.

Let’s update our extension to integrate with the editor a bit better. I’ll start by simply adding a menu item for the extension.

Listing 2: helloworld2/main.js
    /*
    Based - in part - on the HelloWorld sample extension on the Brackets wiki:
    
    https://github.com/adobe/brackets/wiki/Simple-%22Hello-World%22-extension
    
    */
    define(function(require, exports, module) {
    
        var CommandManager = brackets.getModule("command/CommandManager"),
                Menus = brackets.getModule("command/Menus"),
                AppInit = brackets.getModule("utils/AppInit");
        function log(s) {
                console.log("[helloworld2] "+s);
        }
        function handleHelloWorld() {
                alert("You ran me, thanks!");
        }
        AppInit.appReady(function () {
    
                log("Hello from HelloWorld2.");
    
                var HELLOWORLD_EXECUTE = "helloworld.execute";
    
                CommandManager.register("Run HelloWorld", HELLOWORLD_EXECUTE, handleHelloWorld);
    
                var menu = Menus.getMenu(Menus.AppMenuBar.VIEW_MENU);
                menu.addMenuItem(HELLOWORLD_EXECUTE);
    
        });
    
    });
    

We’ve got a few changes here so let’s tackle them one by one. You’ll notice that the extension begins with three calls to brackets.getModule. All extensions have access to a brackets object that provides an API where we can load in core functionality from the editor. In this case the extension has loaded two libraries we’ll need for the menu (CommandManager and Menus) and one which will be used to help initialize the extension (AppInit).

Lets talk about AppInit. You can see that most of the extension is now loaded with a appReady callback. This callback is fired when Brackets has completed loading and is generally considered “best practice” for extensions to make use of.

Registering a menu item takes a few steps. I begin by defining a “command ID”, a unique identifier for the item I’ll be adding to the UI. The typical way to do this is with the format extensionname.someaction. In my case, I used helloworld.execute. I can then register this command along with the function (handleHelloWorld) that should be called when the command is fired.

The final step is to add this command to the menu. You can probably guess that my menu item will be added under the View menu based on this value: Menus.AppMenuBar.VIEW_MENU. How did I know that value? Simple, I saw other extensions do it. Seriously though, there is no specific list of items like this yet. Don’t forget that Brackets is open source. I can easily pop over to the GitHub repo and check it out. In this case, the file is Menus.js, located on Github. In there I can see where the various different core menus are defined:

/**
      * Brackets Application Menu Constants
      * @enum {string}
    */
    var AppMenuBar = {
         FILE_MENU       : "file-menu",
         EDIT_MENU       : "edit-menu",
         VIEW_MENU       : "view-menu",
         NAVIGATE_MENU   : "navigate-menu",
         HELP_MENU       : "help-menu"
    };      
    

As a general rule of thumb, it makes sense to have at least a cursory understanding of what’s available in Brackets itself. Your extensions will, from time to time, make use of multiple different features so it’s definitely in your best interest to at least know the lay of the land.

After reloading Brackets, you’ll now see the menu item in the View menu. Exactly where it is may be a bit random as you may have other extensions installed.

You can actually be a bit more specific about your position. Again, this is where the source code will help you. The same file I linked to above also contains the addMenuItem definition.

Put Some Lipstick on That Pig

Now that you’ve seen a simple example of how an extension can integrate into Brackets, let’s look at how we update the UI. In the previous version of our code, an alert was used to send a message. While this works, it isn’t very pretty. Your code can access the Brackets editor just like any other DOM modification code. While you can do anything you want, there are a few standard ways extensions update the UI in Brackets. (As a warning, in general you do not want to touch the DOM of the main editor UI. You can, but with future updates, your code may break. Also, users may not be happy if your extension changes something core to Brackets.)

The first method we’ll look at uses modal dialogs. Brackets already uses this and has an API available for extensions to call. As a simple example, let’s just update the HelloWorld extension to use a modal instead.

Listing 3: helloworld3/main.js
    /*
    Based - in part - on the HelloWorld sample extension on the Brackets wiki:
    
    https://github.com/adobe/brackets/wiki/Simple-%22Hello-World%22-extension
    
    */
    define(function(require, exports, module) {
    
        var CommandManager = brackets.getModule("command/CommandManager"),
            Menus = brackets.getModule("command/Menus"),
            Dialogs = brackets.getModule("widgets/Dialogs"),
            DefaultDialogs = brackets.getModule("widgets/DefaultDialogs"),
            AppInit = brackets.getModule("utils/AppInit");
    
        function log(s) {
                console.log("[helloworld3] "+s);
        }
    
        function handleHelloWorld() {
            Dialogs.showModalDialog(DefaultDialogs.DIALOG_ID_INFO, "Hello World", "Same Important Message");
        }
    
        AppInit.appReady(function () {
    
            log("Hello from HelloWorld3.");
    
            var HELLOWORLD_EXECUTE = "helloworld.execute";
    
            CommandManager.register("Run HelloWorld", HELLOWORLD_EXECUTE, handleHelloWorld);
    
            var menu = Menus.getMenu(Menus.AppMenuBar.VIEW_MENU);
            menu.addMenuItem(HELLOWORLD_EXECUTE);
    
        });
    
    });
    

Note the addition of two additional Brackets modules: Dialogs and DefaultDialogs. The next change is in handleHelloWorld. One of the methods in the Dialog library is the ability to show a dialog (no surprise there, I suppose). The method wants a class, a title, and a body, and that’s it. There’s more you can do with dialogs, but for now, this demonstrates the feature. Now when we run the command, we get a much prettier UI. (Along with default buttons and behaviours to handle closing the dialog.)

That’s one example, now lets look at another: creating a bottom panel. As with dialogs, we’ve got support from Brackets to make it easier. Let’s look at an example and then I’ll explain the changes.

Listing 4: helloworld4/main.js
    /*
    Based - in part - on the HelloWorld sample extension on the Brackets wiki:
    
    https://github.com/adobe/brackets/wiki/Simple-%22Hello-World%22-extension
    
    */
    define(function(require, exports, module) {
    
        var CommandManager = brackets.getModule("command/CommandManager"),
        Menus = brackets.getModule("command/Menus"),
        PanelManager = brackets.getModule("view/PanelManager"),
        AppInit = brackets.getModule("utils/AppInit");
    
        var HELLOWORLD_EXECUTE = "helloworld.execute";
        var panel;
    
        function log(s) {
                console.log("[helloworld4] "+s);
        }
    
        function handleHelloWorld() {
            if(panel.isVisible()) {
                panel.hide();
                CommandManager.get(HELLOWORLD_EXECUTE).setChecked(false);
            } else {
                panel.show();
                CommandManager.get(HELLOWORLD_EXECUTE).setChecked(true);
            }
        }
    
        AppInit.appReady(function () {
    
                log("Hello from HelloWorld4.");
    
                CommandManager.register("Run HelloWorld", HELLOWORLD_EXECUTE, handleHelloWorld);
    
                var menu = Menus.getMenu(Menus.AppMenuBar.VIEW_MENU);
                menu.addMenuItem(HELLOWORLD_EXECUTE);
    
                panel = PanelManager.createBottomPanel(HELLOWORLD_EXECUTE, $("<div class='bottom-panel'>HTML for my panel</div>"),200);
    
        });
    
    });
    

Let’s focus on the changes. First, I dropped the Dialog modules as I’m no longer using them. Instead, we load up the PanelManager. Down in the appReady block I’ve defined a new panel using the PanelManager API method createBottomPanel. Like the menu command this takes in a unique ID so I just reuse HELLOWORLD_EXECUTE. The second argument is a jQuery-wrapped block of HTML (and in case you’re wondering, yes we can do this nicer), and finally, a minimum size. This sets up the panel but doesn’t actually execute it.

In the event handler, we have tied to the menu, we can ask the panel if it is visible and then either hide or show it. That part should be pretty trivial. For fun I’ve added in a bit more complexity. Notice that CommandManager lets us get a menu item and set a checked property. This may be unnecessary as the user can see the panel easily enough themselves, but adding the check just makes things a little bit more obvious. In the screen shot below you can see the panel in its visible state.

Right away you may be wondering about the panel HTML. Is there a better way to provide the HTML? Anyway to style it? Yep, lets look at a more advanced version.

Listing 5: helloworld5/main.js
    /*
    Based - in part - on the HelloWorld sample extension on the Brackets wiki:
    
    https://github.com/adobe/brackets/wiki/Simple-%22Hello-World%22-extension
    
    */
    define(function(require, exports, module) {
        var CommandManager = brackets.getModule("command/CommandManager"),
        Menus = brackets.getModule("command/Menus"),
        PanelManager = brackets.getModule("view/PanelManager"),
        ExtensionUtils          = brackets.getModule("utils/ExtensionUtils"),        
        AppInit = brackets.getModule("utils/AppInit");
    
        var HELLOWORLD_EXECUTE = "helloworld.execute";
        var panel;
        var panelHtml     = require("text!panel.html");
    
        function log(s) {
                console.log("[helloworld5] "+s);
        }
    
        function handleHelloWorld() {
            if(panel.isVisible()) {
                panel.hide();
                CommandManager.get(HELLOWORLD_EXECUTE).setChecked(false);
            } else {
                panel.show();
                CommandManager.get(HELLOWORLD_EXECUTE).setChecked(true);
            }
        }
    
        AppInit.appReady(function () {
    
            log("Hello from HelloWorld5.");
            ExtensionUtils.loadStyleSheet(module, "helloworld.css");
            CommandManager.register("Run HelloWorld", HELLOWORLD_EXECUTE, handleHelloWorld);
    
            var menu = Menus.getMenu(Menus.AppMenuBar.VIEW_MENU);
            menu.addMenuItem(HELLOWORLD_EXECUTE);
    
            panel = PanelManager.createBottomPanel(HELLOWORLD_EXECUTE, $(panelHtml),200);
    
        });
    
    });
    

As before, I’m going to focus on the changes. First note that I’ve included a variable called panelHtml that is loaded via require. This lets me define my HTML outside of my JavaScript code. (You can also use templating engines. Brackets ships with Mustache.) The HTML behind the panel is rather simple.

Listing 6: helloworld5/panel.html
    <div class="bottom-panel helloworld-panel" id="helloworldPanel">
    <h1>My Panel</h1>
    
    <p>
    My panel brings all the boys to the yard,<br/>
    And they're like<br/>
    It's better than yours,<br/>
    Damn right it's better than yours,<br/>
    I can teach you,<br/>
    But I have to charge
    </p>
    </div>
    

Returning to main.js, I’ve demonstrated another feature, loadStyleSheet. This lets you load an extension specific style sheet. I created a file, helloworld.css, with some simple (but tasteful) CSS styles.

Listing 7: helloworld5/helloworld.css
    .helloworld-panel h1 {
            color: red;
    }
    
    .helloworld-panel p {
            color: blue;
            font-weight: bold;
    }
    

Note that I prefixed my styles with a unique name. This helps ensure my classes don’t conflict with anything built into Brackets. With these simple changes my panel now looks much better, and you can see why I’m known world wide for my superior design skills.

Packaging and Sharing Your Kick Butt Extension

Of course, just creating the coolest Brackets extension isn’t quite enough. You probably (hopefully!) want to share it with others. One option is to just zip up the directory and put it on your website. Folks can download the zip, extract it, and copy it to their Brackets extensions folder.

But that’s not cool. You want to be cool, right? In order to share your extension and make it available via the Brackets Extension manager, you simply need to add a package.json file to your extension. If you’ve ever used Node.js, then this will seem familiar. Here is a sample one for our extension.

Listing 8: helloworld6/package.json
    {
        "name": "camden.helloworld",
        "title": "HelloWorld",
        "description": "Adds HelloWorld support to Brackets.",
        "homepage": "https://github.com/cfjedimaster/something real here",
        "version": "1.0.0",
        "author": "Raymond Camden <raymondcamden@gmail.com> (http://www.raymondcamden.com)",
        "license": "MIT",
        "engines": {
            "brackets": "<=0.34.0"
        }
    }
    

Most of this is self-explanatory, but the real crucial portion is the engines block. Brackets updates itself pretty rapidly. If Brackets added a particular feature at some point that your extension relies on, you can add a simple conditional here to ensure folks don’t try to install your extension on an incompatible version. (You can find a full listing of the possible settings on the Wiki.)

Once you’ve done this, the next part is to upload it to the Brackets Registry. You will need to log in via your GitHub account, but once you’ve done that, you can then simply upload your zip. Your extension will then be available to anyone using Brackets. Even better, if you update your extension, the Extension Manager will actually be able to flag this to the user so they know an update is available.

What Else?

Hopefully, you’ve seen how easy it is to extend Brackets. There’s more we didn’t cover, like the Linting API and NodeJS integration, but this article should be more than enough to get you started. As a reminder, do not forget there is a large collection of extensions available for you to start playing with right now. Good luck!

Responsive images have been, and are, one of the hardest problems in responsive Web design right now. Until browser vendors give us a native solution, we have to think on the fly and come up with our own solutions. “Retina” images are especially a challenge because if you have sized your layout with ems or percentages (as you should!), then you cannot be sure of the exact pixel dimensions of each image being displayed.

In this article, we’ll look at one solution to the problem that we implemented on our portfolio website at Etch, where you can see an early working version in the wild.

Requirements

We used a content-first approach on Etch. We knew we wanted to use a lot of images to quickly convey the atmosphere of the company. These would be accompanied by small snippets, or “soundbites,” of text.

The next decision was on image sizes and aspect ratios. To get maximum control over the design, we knew we needed maximum control over the images. We decided to use Instagram as the base for our imagery for the following reasons:

• The aspect ratio is fixed.
• Most employees here already use it.
• Those lovely filters.

Instagram allows for a maximum image size of 600 pixels, so we now had our first set of content constraints to work with: images with a 1:1 aspect ratio, and a maximum image size of 600 × 600. Having constraints on the content side made the design process easier because they limited our options, thus forcing decisions.

When the content was completed, we began looking at the design. Again, to keep maximum control, we decided on an adaptive design style with fixed column sizes. We used grid block elements that match our maximum image size. Each grid block would either be 600 × 600 or 300 × 300, which also conveniently fit our rough plan of a minimum width of 320 pixels for the viewport on the website.

During the rest of the design process, we noticed that we needed two other image sizes: thumbnails at 100 × 100, and hero images that stretch the full width of the content (300, 600, 900, 1200, 1600, 1800). All images would also need to be “Retina” ready — or, to put it another way, compatible with displays with high pixel densities. This gave us the final set of requirements for a responsive images solution for the website:

• Potential image widths (in pixels) of 100, 300, 600, 900, 1200, 1600, 1800
• Retina ready
• Must be crisp with minimal resizing (some people notice a drop in quality with even downsized images)

Having to resize that many images manually, even using a Photoshop script, seemed like too much work. Anything like that should be automated, so that you can focus on fun and interesting coding instead. Automation also removes the chance for human error, like forgetting to do it. The ideal solution would be for us to add an image file once and forget about it.

Common Solutions

Before going over our solution, let’s look at some common solutions currently being used. To keep up with currently popular methods and the work that the Web community is doing to find a solution to responsive images, head over to the W3C Responsive Images Community Group.

Picture Element

First up, the picture element. While this doesn’t currently have native support and browser vendors are still deciding on picture versus srcset versus whatever else is up for discussion, we can use it with a polyfill.

    <picture alt="description">
      <source src="small.jpg">
      <source src="medium.jpg" media="(min-width: 40em)">
      <source src="large.jpg" media="(min-width: 80em)">
    </picture>
    

The picture element is great if you want to serve images with a different shape, focal point or other feature beyond just resizing. However, you’ll have to presize all of the different images to be ready to go straight in the HTML. This solution also couples HTML with media queries, and we know that coupling CSS to HTML is bad for maintenance. This solution also doesn’t cover high-definition displays

For this project, the picture element required too much configuration and manual creation and storage of the different image sizes and their file paths.

srcset

Another popular solution, srcset, has recently been made available natively in some WebKit-based browsers. At the time of creating our plugin, this wasn’t available, and it looks like we’ll be waiting a while longer until cross-browser compatibility is good enough to use it without a JavaScript fallback. At the time of writing, srcset is usable only in the Chrome and Safari nightly builds.

    <img src="fallback.jpg" srcset="small.jpg 640w 1x, small-hd.jpg 640w 2x, large.jpg 1x, large-hd.jpg 2x" alt="…">
    

The snippet above shows srcset in use. Again, we see what essentially amounts to media queries embedded in HTML, which really bugs me. We’d also need to create different image sizes before runtime, which means either setting up a script or manually doing it, a tiresome job.

Server-Side Sniffing

If you’d rather not use JavaScript to decide which image to serve, you could try sniffing out the user agent server-side and automatically send an appropriately sized image. As a blanket rule, we almost always say don’t rely on server-side sniffing. It’s very unreliable, and many browsers contain inaccurate UA strings. On top of that, the sheer number of new devices and screen sizes coming out every month will lead you to maintenance hell.

Other Solutions in the Wild

We chose to make our own plugin because including layout code in the HTML seemed undesirable and having to create different image sizes beforehand was not enticing.

If you’d like to explore other common solutions to decide which is best for your project, several great articles and examples are available on the Web, including one on this very website.

• “Choosing a Responsive Image Solution,” Sherri Alexander, Smashing Magazine
  Alexander looks at the high-level requirements for responsive images, and then dissects the variety of solutions currently available in the wild.
• “Which Responsive Image Solution Should You Use,” Chris Coyier, CSS-Tricks
  Coyer takes us through imaging requirements while suggesting appropriate solutions.
• Adaptive Images
  A solution very similar to Etch’s in its implementation. It uses a PHP script to size and serve the appropriate images. Unfortunately, this wasn’t available when we were coding the website.
• Picturefill
  This is a JavaScript replacement for markup in the style of the picture element.
• “Responsive Images Using Cookies,” Keith Clark
  Clark uses a cookie to store the screen’s size, and then images are requested via a PHP script. Again, it’s similar to our solution but wasn’t available at the time.

Onto our solution.

Our Solution

With both picture and srcset HTML syntaxes seeming like too much effort in the wrong places, we looked for a simpler solution. We wanted to be able to add a single image path and let the CSS, JavaScript and PHP deal with serving the correct image — instead of the HTML, which should simply have the correct information in place.

At the time of developing the website, no obvious solution matched our requirements. Most centered on emulating picture or srcset, which we had already determined weren’t right for our needs.

The Etch website is very image-heavy, which would make manually resizing each image a lengthy process and prone to human error. Even running an automated Photoshop script was deemed to require too much maintenance.

Our solution was to find the display width of the image with JavaScript at page-loading time, and then pass the src and width to a PHP script, which would resize and cache the images on the fly before inserting them back into the DOM.

We’ll look at an abstracted example of the code, written in HTML, JavaScript, PHP and LESS. You can find a working demo on my website. If you’d like to grab the files for the demo, they can be found on GitHub.

Markup

The markup for the demo can be found in the index.html file on GitHub.

We wrap the highest-resolution version of an image in noscript tags, for browsers with JavaScript turned off. The reason is that, if we think of performance as a feature and JavaScript as an enhancement, then non-JavaScript users would still receive the content, just not an optimized experience of that content. These noscript elements are then wrapped in a div element, with the image’s src and alt properties as data attributes. This provides the information that the JavaScript needs to send to the server.

    <div data-src="img/screen.JPG" data-alt="crispy" class="img-wrap js-crispy">
        <noscript><img src="img/screen.JPG" alt="Crispy"></noscript>
    </div>
    

The background of the image wrapper is set as a loading GIF, to show that the images are still loading and not just broken.

An alternative (which we used in one of our side projects, PhoSho) is to use the lowest-resolution size of the image that you will be displaying (if known), instead of the loading GIF. This takes slightly more bandwidth because more than one image is being loaded, but it has an appearance similar to that of progressive JPEGs as the page is loading. As always, see what your requirements dictate.

(Large preview)

JavaScript

The JavaScript communicates for us between the HTML and the server. It fetches an array of images from the DOM, with their corresponding widths, and retrieves the appropriate cached image file from the server.

Our original plugin sent one request to the server per image, but this caused a lot of extra requests. By bundling our images together as an array, we cut down the requests and kept the server happy.

You can find the JavaScript plugin in /js/resize.js in the GitHub repository.

First, we set an array of breakpoints in the plugin that are the same as the breakpoints in the CSS where the image sizes change. We used em values for the breakpoints because they are based on the display font size. This is a good practice because visually impaired users might change their display’s default font size. This also makes it easier to match our CSS breakpoints with the JavaScript ones. If you prefer, the plugin works just fine with pixel-based breakpoints.

    breakpoints: [
        "32em"
        "48em"
        "62em"
        "76em"
    ]
    

As we pass each of these breakpoints, we need to check the images to make sure they are the correct size. At page-loading time, we first set the current breakpoint being displayed to the user using the JavaScript matchMedia function. If you need to support old browsers (Internet Explorer 7, 8 and 9), you might require the matchMedia polyfill by Paul Irish.

    getCurrentBreakpoint: function() {
          var bp, breakpoint, _fn, _i, _len, _ref,
            _this = this;
    
          bp = this.breakpoints[0];
          
          _ref = this.breakpoints;
          
          _fn = function(breakpoint) {
            // Check if the breakpoint passes
            if (window.matchMedia && window.matchMedia("all and (min-width: " + breakpoint + ")").matches) {
              return bp = breakpoint;
            }
          };
          
          for (_i = 0, _len = _ref.length; _i < _len; _i++) {
            breakpoint = _ref[_i];
            _fn(breakpoint);
          }
          
          return bp;
        }
    

After setting the current breakpoint, we gather the images to be resized from the DOM by looping through them and adding them to the plugin’s images array.

    gather: function() {
          var el, els, _i, _len;
    
          els = $(this.els);
          
          this.images = [];
          
          for (_i = 0, _len = els.length; _i < _len; _i++) {
            el = els[_i];
            this.add(el);
          }
          
          this.grabFromServer();
        }
    

The PHP script on the server needs the image’s src and current width in order to resize it correctly, so we created some serialized POST data to send to the server. We use jQuery’s param method to quickly convert the image into a usable query string.

    buildQuery: function() {
          var image = { image: this.images }
          return $.param(image);
        }
    

The images are then sent via an AJAX request to the server to be resized. Note the single request, to minimize server load.

    grabFromServer: function() {
          var data,
            _this = this;
    
          data = this.buildQuery();
          
          $.get("resize.php", data, function(data) {
              var image, _i, _len;
              for (_i = 0, _len = data.length; _i < _len; _i++) {
                image = data[_i];
                _this.loadImage(image);
              }
            }
          );
        }
    

Once we have retrieved the images from the server, we can add them to the DOM or replace the image already in place if it has changed. If it’s the same image, then nothing happens and the image won’t need to be redownloaded because it’s already in the browser’s cache.

    loadImage: function(image) {
          var el, img,
            _this = this;
    
          el = $("[data-src='" + image.og_src + "']");
          
          img = $("");
          
          img.attr("src", image.src).attr("alt", el.attr("data-alt"));
          
          if (el.children("img").length) {
            el.children("img").attr("src", image.src);
          } else {
            img.load(function() {
              el.append(img);
              el.addClass('img-loaded');
            });
          }
        }
    

PHP

With the JavaScript simply requesting an array of images at different sizes, the PHP is where the bulk of the action happens.

We use two scripts. One is a resize class (found in /php/lib/resize-class.php in the demo), which creates cached versions of the image at the sizes we need. The other script sits in the Web root, calculates the most appropriate size to display, and acts as an interface between the JavaScript and the resizer.

Starting with the sizing and interface script, we first set an array of pixel sizes of the images that we expect to display, as well as the path to the cached images folder. The image sizes are in pixels because the server doesn’t know anything about the user’s current text-zoom level, only what the physical image sizes being served are.

    $sizes = array(
        '100',
        '300',
        '600',
        '1200',
        '1500',
    );
    
    $cache = 'img/cache/';
    

Next, we create a small function that returns the image size closest to the current display size.

    function closest($search, $arr) {
        $closest = null;
        foreach($arr as $item) {
            // distance from image width -> current closest entry is greater than distance from  
            if ($closest == null || abs($search - $closest) > abs($item - $search)) {
                $closest = $item;
            }
        }
        $closest = ($closest == null) ? $closest = $search : $closest;
        return $closest;
    }
    

Finally, we can loop through the image paths posted to the script and pass them to the resize class to get the path to the cached image file (and create that file, if necessary).

    $crispy = new resize($image,$width,$cache);
    $newSrc = $crispy->resizeImage();
    

We return the original image path in order to find the image again in the DOM and the path to the correctly sized cached image file. All of the image paths are sent back as an array so that we can loop through them and add them to the HTML.

    $images[] =  array('og_src' => $src, 'src' => '/'.$newSrc);
    

In the resize class, we initially need to gather some information about the image for the resizing process. We use Exif to determine the type of image because the file could possibly have an incorrect extension or no extension at all.

    function __construct($fileName, $width, $cache) {
    
        $this->src = $fileName;
        $this->newWidth = $width;
        $this->cache = $cache;
        $this->path = $this->setPath($width);
    
        $this->imageType = exif_imagetype($fileName);
    
        switch($this->imageType)
        {
            case IMAGETYPE_JPEG:
                $this->path .= '.jpg';
                break;
    
            case IMAGETYPE_GIF:
                $this->path .= '.gif';
                break;
    
            case IMAGETYPE_PNG:
                $this->path .= '.png';
                break;
    
            default:
                // *** Not recognized
                break;
        }
    }
    

The $this->path property above, containing the cached image path, is set using a combination of the display width, a hash of the file’s last modified time and src, and the original file name.

Upon calling the resizeImage method, we check to see whether the path set in $this->path already exists and, if so, we just return the cached file path.

If the file does not exist, then we open the image with GD to be resized.

Once it’s ready for use, we calculate the width-to-height ratio of the original image and use that to give us the height of the cached image after having been resized to the required width.

    if ($this->image) {
        $this->width  = imagesx($this->image);
        $this->height = imagesy($this->image);
    }
    
    $ratio = $this->height/$this->width;
    $newHeight = $this->newWidth*$ratio;
    

Then, with GD, we resize the original image to the new dimensions and return the path of the cached image file to the interface script.

    $this->imageResized = imagecreatetruecolor($this->newWidth, $newHeight);
    imagecopyresampled($this->imageResized, $this->image, 0, 0, 0, 0, $this->newWidth, $newHeight, $this->width, $this->height);
    
    $this->saveImage($this->newWidth);
    
    return $this->path;
    

What Have We Achieved?

This plugin enables us to have one single batch of images for the website. We don’t have to think about how to resize images because the process is automated. This makes maintenance and updates much easier, and it removes a layer of thinking that is better devoted to more important tasks. Plug it in once and forget about it.

TL;DR? Let’s summarize the functionality once more for good measure.

In our markup, we provide an image wrapper that contains a <noscript> fallback. This wrapper has a data attribute of our original high-resolution image for a reference. We use JavaScript to send an AJAX request to a PHP file on the server, asking for the correctly sized version of this image. The PHP file either resizes the image and delivers the path of the correctly sized image or just returns the path if the image has already been created. Once the AJAX request has been completed, we append the new image to the DOM, or we just update the src if one has already been added. If the user resizes their browser, then we check again to see whether a better image size should be used.

Pros And Cons

All responsive image solutions have their pros and cons, and you should investigate several before choosing one for your project. Ours happens to work for our very specific set of requirements, and it wouldn’t be our default solution. As far as we can tell, there is no default solution at the moment, so we’d recommend trying out as many as possible.

How does this solution weigh up?

Pros

• Fast initial page download due to lower image weight
• Easy to use once set up
• Low maintenance
• Fast once cached files have been created
• Serves image at correct pixel size (within tolerance)
• Serves new image when display size changes (within tolerance)

Cons

• Unable to choose image focus area
• Requires PHP and JavaScript for full functionality
• Can’t cover all possible image sizes if fluid images are used
• Might not be compatible with some content management systems
• Resizing all images with one request means that, with an empty cache, you have to wait for all to be resized, rather than just one image
• The PHP script is tied to breakpoints, so it can’t be dropped in without tweaking

Responsive image solutions have come a long way in recent months, and if we had to do this again, we’d probably look at something like the adaptive images solution because it removes even more non-semantic HTML from the page by modifying .htaccess.

Wrapping Up

Until we have a native solution for responsive images, there will be no “right” way. Always investigate several options before settling on one for your project. The example here works well for websites with a few common display sizes for images across breakpoints, but it is by no means the definitive solution. Until then, why not have a go at creating your own solution, or play around with this one on GitHub?

(al, il)

SmashingMag front page image credits: PhoSho's front page showcase.

© Gavyn McKenzie for Smashing Magazine, 2014.