I’ve been doing quite a few responsive sites since I first started into them. I like doing them. They are fun to build, requiring new techniques and a different way of thinking to handle different situations. I like the concept and I like looking at the sites. One recent fun thing was dealing with an image map. Scaling the image and coordinates would be a pain and very expensive. An alternative option is to replace the image with a select drop down when the screen is too small for the image.
My most recent effort has been to bring in the use of Require JS. Require is an AMD implementation, which is an interesting extension of the module pattern. It takes the dependency injection part of the module pattern (ie passing variables the module will use as arguments into the function expression) a step further by handling auto loading of those modules with a script loader that will asynchronously load and run all dependencies for a module before running the dependent module, injecting the dependencies as either parameters or assigned variables. Require does this with names based on file path, sort of like a JS equivalent of PSR-0. Require also provides a build process that will combine all required module files into one and minify. I have not played with this yet, but am hoping it will take over my currently crappy build process.
So far, I’ve only converted over a small core part of my library, but I really like the direction it is going. The scoping/dependency wrappers around each module may add some bulk, but will also allow minification of all module dependencies and what not, so it may end up being insignificant in the build, especially since my current build process doesn’t involve much minification. Even if it ends up a bit larger than it could be, the development benefits outweigh that concern for me. It has also required a change in the way I construct my library pieces. The early pieces require being constructed in a certain order, and things don’t work as well when modules to depend on each other. But I think it will be really nice when I get the full library converted over and the build process figured out.
I’ve been doing the more manual approach for my library, but have been desiring for a while to get more organized and streamline repetition by adding my own namespace function. I got to thinking about doing more with the namespace objects, so that they can perform operations on themselves once created. For example, they might be able to create and return sub-namespaces as well as easily extend themselves.
JQuery UI Draggable and Droppable make it fairly easy to implement dragondrop on a web page. There are some things that are not easy to do with it though. One example is having a droppable accept multiple types of draggables with different responses depending on type, especially when added at different times (for instance, being attached by separate objects/scripts). The way JQuery UI is set up, only one droppable behavior set can be attached to an element, so doing
simply replaces the “.type1” options with the “.type2” options.
In a recent project, I needed multiple draggable types per droppable, so I created an object class to handle adding a new “accept” type and associated events to an element that is already a droppable. I do this using duck punching to overwrite the original event callbacks. The wrapper callback checks the draggable element to see if it matches the new “accept” value. If so, it runs the new callback, otherwise it runs the original callback. Every time a new set of droppable options is applied, a new wrapper callback is created that calls the previous, so that no functionality is lost. Perhaps not as efficient as a single function with an if/switch tree, but that would not be feasible for this use case.
jQuery makes it fairly easy to animate DOM elements. Animating a single-step animation on one or more elements is simple with the call of the animate method. Multi-step animations can be more complex because animations are run asynchronously, meaning that they will start running when called but the script will continue onto the next step before the animation is done. For these, jQuery has the ability to queue steps. jQuery automatically queues multiple steps on a single object and dequeues as each completes, so you don’t have to worry about managing things and setting up callbacks. But for more complex animations where multiple elements are animated at different times or other functionality must be performed after an animation step, there is no automatic queuing.
A common practice for simple queuing is to use the “complete” parameter of the animate method or of other similar asynchronous methods that is a callback to be run when the animation is finished. This works nicely when there are a few steps. It becomes more unwieldy though the more steps you add. That is where queue comes in, allowing for adding of as many steps as you want without having to nest in callback after callback.
The only other thing I put in the global namespace is the base object type I instantiate that variable with. I did this as an object so I could conceivably create multiple instances and so that I could declare it later in the file and have all of the site specific code at the top. I call it tmlib since it is my library. So a bare instantiation might look like this:
My boss at work doesn’t like the top-level items that have submenus in our two-level menus to be links. In most of the sites we build, there is really no page for the top-level items to link to. Having a duplicated link to the first item or just a worthless value could be confusing, especially for both bots and screenreaders. But with no anchors, the submenus are inaccessible via the keyboard, as browsers generally only provide keyboard navigation to anchors, inputs, and buttons. As I prefer to keep my hands on the keyboard most of the time, I was disappointed with this characteristic of the menu system I built.
The Piwik community doesn’t seem to have much mention of this, other than one mailing list thread. I modified the script to something similar to the one in that thread, like this:
The design of the gallery portion of the David Hawkins site I’m working on at Cogneato called for a reflection of the current image below that image. This could have been done by making reflections for each image in an image editor and then adding them to a separate field in the CMS. That would have been a pain and would require (most likely) us to be involved for each image added.
Because of the design of the site, I had to modify the script somewhat to make it work properly. One issue was that I had a border around my images.