Ideation Limitation

I think coding a site to upload some photos, automate them into a simple slideshow is a no brainer. Your mom on the other hand thinks that’s about the most fan-futon-tastic thing ever. She and all the ladies in her card group use it religiously; sharing photos of their baby grandchildren drooling and gnawing on the dogs chew toys. Who knew.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

A Diagnosis to Which I Relate (using a word I’ve never heard)

1. Created a plugin
2. Created a repository for that plugin at BitBucket

ReadyAgain at BitBucket

The ReadyAgain jQuery Plugin

Prior to version 1.4, the array of functions saved by jQuery for execution when the DOM is ready (i.e. those functions added by $(document).ready(function...)) was an accessible property of jQuery. This meant that you could reference the array directly using something like $.readyList. Now, however, that array has been hidden within an anonymous, self-executing function (the deepest, darkest well of data hiding in javascript, here’s a bit of a primer). So re-executing all of the ready functions by grabbing a copy of that array becomes impossible.

The ReadyAgain plugin is my attempt to solve that issue. The specifics can be seen by looking at the code, but the basic concept is to override jQuery.ready to intercept each function as its added, and to save it within our own internal array.

Public Code

So the initial commit of the code is there and I’ve typed up a page on the Wiki with some examples. I hope that people use it and maybe even contribute to it. It would certainly be something fun for me to be a part of and from which to learn.

The Path to Here

An issue that has come up a couple of times regarding my ‘Read More Right Here’ Wordpress plugin is that, when the post content is loaded, effects like a thickbox or lightbox or whatever-box are not applied to images in the new content. More generally speaking, any javascript fanciness used on any of the new content elements is missing.

The reason is that most every javascript based modification is applied to the document within a ‘DOM Ready’ function (and rightly so) . With jQuery, this is the jQuery.ready function. So a plugin might add some nifty image effects to all images on the page like so: $('img').NiftyStuff(). But the images within the content pulled down by my plugin aren’t yet there. They don’t arrive to the page until after the ‘Read More’ link is clicked.

So how do you re-execute NiftyStuff and the potentially countless other plugin functions on that new content?

Live & Delegate

One quick solution would be to make use of jQuery’s live or delegate functions. When used, they will monitor the DOM for new elements and execute code as needed. But I guess this is still a relatively new process since it’s not something I’ve noticed in any of the plugins I’ve come across.

Rerun Ready (i.e. my plugin)

Re-execution of each of the saved ready functions is another possibility. What’s more, the ReadyAgain plugin will allow you to execute all of the ready functions within a more specific context (instead of the default ‘document’ context, see the wiki for more). So potentially only the new content will have the saved ready functions applied.

Risky Business: Not the final solution

At this point you might be thinking to yourself “Great, so you’ve packaged this with ‘Read More Right Here’ and everything works perfectly”. Sorry, but no. At least not yet.

I experimented with it a bit, and it’s honestly just too hazardous. I mean, it’s a serious case of “Use at your own risk”. It is generally assumed (and again, rightly so) that the code executed within jQuery’s ready function will only be executed once. So you might see a new element with a static ID value added to the page over and over. Or you might see some element that’s animating with relative values (e.g. top:'+=25px'), which could happen over and over. Or any other number of possible side-effects.

This plugin is really something that (at least in its current form) should only be added on an individual basis. You have to examine what happens within the ready function of other jQuery based Wordpress plugins. There’s just no way that I can see to have this become default behavior within the RMRH Wordpress plugin.

But time will tell. Maybe creating this public repository will put some eyes on it and who knows what solutions will develop from that.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

The ReadyAgain jQuery Plugin: Re-executing Ready

Miter Box Slider is my submission. It’s a jQuery ’slider’ plugin (i.e. when there’s a slideshow display of images at websites). What’s awesome about it is that it provides the ability to create truly unique animation transitions. With other sliders you’ll see a set of predefined transition effects, but with Miter Box, you create the transitions. It’s actually very powerful. One of the largest issues I had developing it was that I would often end up just playing with it. It’s a fun tool for experimenting.

Regardless of whether other people decide to use it, I really am pretty proud of it. Remember that those who run the site review the code and set the price? Right now, mine is the highest priced (one of only two at that price) item in the javascript section of code. I don’t know everything that goes into that price point, but I will say that I think it’s an indication of the power my plugin offers.

If you’ve got a site, or create sites, and are looking for some way to spice up the way you display your images, check out the Miter Box demo.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

Miter Box Slider

The original inkling of issues came via Anon’s comment, on my previous update post, that YouTube videos pulled down as part of the “more” section were broken. I tested this locally and saw that, with IE7, he/she was right. Of course, it’s not just YouTube. It would be any of the <object>/<embed> elements video sharing sites provide.

That really sucks.

The Fix (sorta)

After spending one night trying to figure out what I could do to fix this, it became obvious that the generally accepted solution to dynamically adding those flash objects to a page is to use SWFObject, which:

Offers a JavaScript API that aims to provide a complete tool set for embedding SWF files and retrieving Flash Player related information

I really (always optimistic) thought this would be a quick set of changes to the javascript file; call the swfobject.embedSWF method and be done with it. Best of all, swfobject.js is already distributed with the Wordpress install (which, by the way, I don’t see mentioned in the codex, the script handle to use to enqueue or set is as a dependency is 'swfobject'). But I couldn’t seem to get it to work, at least not in IE7.

That really sucks.

What IE Doesn’t Like

In the end, after much debugging with the uncompressed version of SWFobject, Firebug Lite and beaucoup de calls to console.log, I found the issue to be SWFobject’s call to outterHTML.

You see, when it creates this new element for the DOM, it needs someplace to put it. You provide the id of the element which will be used as that replacement. Sort of like the sacrificial lamb for the the new <object>. It’s through outterHTML that the replacement occurs. It sets the old element to be the new one.

435

el.outerHTML = '<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"' + att + '>' + par + '</object>';

createSWF function (line number as of version 2.2)

My plan was to replace the original object with the new one. When that didn’t work, I tried inserting a <div> as the target for replacement, right before the object, but that failed in the same way. Finally, I realized what was going on, and set as the replacement an item that already existed in the DOM (in other words, it wasn’t something pulled in and added dynamically by the RMRH plugin). That worked.

The problem seems to be that, when the element to be replaced has also been dynamically created, IE throws an exception when you try to change it. In other words, I created the sacrificial lamb and IE wants for it to have always existed.

The Fix Again (sorta, again)

But it bugged me that the call to outterHTML was the point-of-failure here. After all, I know I manipulate the DOM all the time in jQuery. Right? It provides replaceWith as part of its API after all, and that always seems to work.

So I replaced SWFObject’s call to outterHTML with jQuery’s replaceWith (does that count as ironic?), and the problem was solved.

So What Do I Do?

I don’t really want to change that one line and then bundle the modified swfobject.js file with my plugin. But that’s the only solution I can think of. Well, that and maybe just recreate (i.e. copy) the relevant SWFObject code in my javascript, to be used only with IE. But I can’t help but think there must be a better line of action here.

This has to be a relatively common situation. I mean, pull down content using AJAX, content happens to contain an embedded flash player, use SWFObject to make sure it renders in IE. I guess what’s missing is that in the common scenarios, an existing element is already set aside and ready to accept the new object. But I can’t do that with my plugin.

So what do I do?

~~~~~~~~~~~~~~~~ This has been a woolie posting.

SWFObject, IE and Dynamic Content (a problem)

Details, Details

I previously was calling a function I wrote to set the URL to the plugin root directory. This was then used to register the script with WP and was also passed down to the javascript using wp_localize_script.

The one-liner function:

function wt_rmrh_getBasePath()
{
    return get_bloginfo('wpurl') . "/" . PLUGINDIR . "/" . plugin_basename("read-more-right-here/");
}

With the 2.8.1 update, the above no longer worked. Before 2.8.1, the path in a page’s header was (in part):

   plugins/read-more-right-here/js/wt_rmrh.js

After the 2.8.1 update, the path became:

   plugins/read-more-right-herejs/wt_rmrh.js

Needles to say, that javascript file isn’t going to load.

I looked through wp-includes/plugin.php and found the plugin_dir function which

Gets the URL directory path (with trailing slash) for the plugin __FILE__ passed in

(their function comment).

So I deleted the function (which was only being called once) and replaced

$pluginUrl = wt_rmrh_getBasePath();

with

$pluginUrl = plugin_dir_url(__FILE__);

Everything seems to be in working order now. At least until the next Wordpress version!

~~~~~~~~~~~~~~~~ This has been a woolie posting.

RMRH Update for WP 2.8.1

1
2
3
4
5
6
7
8
9
10
11

$values = get_values();
$display = "<ul>";
 
foreach($values as $value)
{
    $display .= "<li>$value</li>";
}
 
$display .= "</ul>";
 
echo $display;

Why was my list spilling out of its well defined boundaries? A staggering amount of time was spent fiddling with every possible CSS property for that element and those around it. Edit, save and reload. Edit save and reload. It was driving me insane.

Solution? Append a newline after each list element.

6

$display .= "<li>$value</li>\n";

I have no idea why. If you do, please enlighten in the comments.

Dear Lord I hope this helps someone else out.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

Overflowing List Elements

I just updated this site to use the latest WP (2.8) and now my “Read More Right Here” plugin doesn’t work quite right. When you click the “Read More” text, the rest of the post successfully downloads and is displayed. However, the next “click” takes you to the post’s single page display instead of just collapsing the new content.

I will hopefully get this sorted out soon. Whenever I do, I’ll update here.

UPDATE:

Unfortunately I haven’t been able to fix this. The problem is caused by the latest version of jQuery (1.3.2), to which WP apparently updated. Actually, it was caused somehow in the changes made in between 1.2.6 and 1.3.

Specifically, the function curCSS is throwing exceptions during the animation of the new content “away” (i.e. hiding).

800

var computedStyle = defaultView.getComputedStyle( elem, null );

The elem parameter being passed to getComputedStyle that causes the exception is a “\n“. With jQuery 1.2.6, I don’t see that element being passed to that function.

I tried some of the other animation techniques, but they I guess they all hit curCSS at some point or another. Even plain old hide causes problems.

So…..sorry. As of right now, the RMRH plugin does not work with WP 2.8. The only solution I can see at the moment is to include the older version of jQuery with the plugin. But I’m not sure yet how that will work out.

UPDATE 2: FIXED

It’s funny how a day away can make a difference. It only took about 10 minutes to get this fixed.

So I knew that jQuery couldn’t have a defect that serious that wasn’t already fixed. The most recent version has been available for more than four months now, and too many people use it for that issue to still be around. I figured the the problem had to be how I was creating the new content that is inserted into the DOM.

My previous method for doing this was:

var newEl = $j("<p> + newContent + </p>");

And the fixed method of the above code is:

var newEl = $j("<p>").html(newContent);

All I can think is that the use of "<p> + newContent + </p>" somehow results in newline characters (/n) being inserted as part of the string. The new method does not use string operators, only the <p> element and its html content are created.

Anyway, it’s fixed. If you use the “Read More Right Here” plugin and have updated to Wordpress 2.8, you need to update the plugin to version 1.0.3.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

Wordpress 2.8 Breaks RMRH Plugin

I was at one of those lulls where, instead of worrying about the code, I started playing with the layout. My <canvas> element is sitting inside a <div>, whose “positioning” property I changed to absolute. After this edit, the top-left corner of my <canvas> was no longer (0,0). It had changed to the (x,y) coordinate of the <canvas> element on the page.

Of course, the above conclusion was only reached after a bunch of “W.T.F is going on? Why T.F. is everything broken?”. After some other debugging routes, it dawned on me what might have happened. So I set the frame rate to 1, and used Firebug to log the mouseX and mouseY as I moved the mouse around. Sure enough, my positioning of “top: 200; left:200;” was reflected in Firebug’s console output showing coordinates near those values while hovering around the top left corner. Commenting out the style sheet’s absolute positioning returned the console output to the (0,0) area code.

So this is a defect, right? I can’t imagine that’s how it’s supposed to work. Anyway, consider this a heads-up if you decide to embark on a little processing.js play.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

Absolute Positioning and the Canvas Element

And awesomely enough, he found the cause of the problem!

The Defect

I was constructing the path to the plugin’s directory using the Wordpress function get_bloginfo, and passing to that function the value 'url'. However, the doc shows that value will result in Wordpress returning the blog home URL, and not the location of the actual core Wordpress files (which is what I needed). To get that path, you have to send in 'wpurl'.

Another Problem

But this fix uncovered another problem. That same path I assumed to be correct is hardcoded in the javascript function used to create the “loading” animated gif that appears while the “read more” content is being pulled. I fixed this issue by having the javascript asynchronously (ajax) ask Wordpress for the correct path (using the now updated function I described in the previous section). But that’s not really how I wanted to do it.

More Ideally

WOW, I FEEL STUPID.. I just typed a whole section here describing how I would rather have the javascript value used as the plugin URL somehow set by Wordpress. I envisioned something similar to wp_enqueue_script that could be used to inject some javascript value to the header along with the linked script sources.

So of course, after I’ve spent loads o’ time trying to find such a solution, figured “maybe next time” and officially updated the plugin, now I find this article (and I quote):

WordPress provides an elegant way to pass parameters to your JavaScript code using wp_localize_script function.

Arg and Doh and all that. Be on the lookout for another release!

~~~~~~~~~~~~~~~~ This has been a woolie posting.

Defect Fix for RMRH Plugin

I make this recommendation with a bit of hesitance though, as the total running time is a bit over 90 minutes. I actually skipped the last third or so of the first video (slicing the PSD). But there is something strangely mesmerizing about watching someone else progress through their work like this. It’s also interesting for me to see someone else’s work flow and tools use.

The presenter/author, Jeffrey Way, states that the tutorial is for beginners, but I’d say that it edges closer to the intermediate level. The CSS section, though long, progresses pretty quickly. You have to already be pretty familiar with the selectors syntax. And he moves right past terms like “inline” and “block”.

If you’ve got the time and the inclination, it’s an excellent howto for that area of web work.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

A Thorough Video Tutorial for Slicing and CSSing

But if you look down at the comments (you have to “expand all”), number eight mentions:

Have you thought about using the html selector when adding two images? One on html and one on the body.

So the author updated example number three with styling rules that, in part, look like this:

html 
{
	background: #73ADD7 url(images/gradient.gif) repeat-x;
}
body 
{
	background: url(images/sky.jpg) no-repeat center top;
}

I would have never thought to add a background image to the HTML element. Is that legal?

Valid?

The example page passes validation for transitional doc types and for strict (the warning is given for overriding the doctype).

However, the CSS 2.1 recommendation says:

For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element.

The CSS 3.0 draft does not seem to include a statement either way, though it does state that it “includes and extends the functionality of CSS level 2 [CSS21]….” (see the Abstract).

So even though there is a recommendation against doing this, it does pass muster with the validation service.

In the long run, though, it is somewhat of a moot point. This is because CSS 3 includes the ability to define multiple background images for one element.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

Using the HTML Element for Background Images

There are countless solutions to this available via the normal searching mechanisms. I have to give credit to my first encounter of the solution I like the best: a “Background height problem” forum post with the solution being the very first response. The <img> element at the bottom of poster’s content could be modified with the “clear: both” style applied to it. The solution also points to this excellent article, “Clearing a float container without source markup“, which goes into some great detail (a must read).

So here’s my quick tutorial on the matter. For this to be worth while, you’ll need to be following along in Firefox. And again, for more details, please read the “Easy Clearing” article linked to above.

1. The Setup

A quick and easy two column design starts with three divs: the container, the left column and the right column (Amen).

<div id="container">
 
	<div id="left">
        <p>To the left.</p>
	</div>
 
	<div id="right">
        <p>To the right.</p>
	</div>
 
</div>

Let’s add some styling to make them distinguishable from each other. We’ll give the container a think, red dotted border. The left side gets a normal green border and, for the right, something blue.

#container
{
    border: thick dotted red;
    width: 610px;
}
#left
{
    border: thin solid green;
    width: 400px;
}
#right
{
    border: thin solid blue;
    width: 200px;
}

Here’s what we’ve got so far. I like how the big red dots seem to hug all the content, don’t you? Also notice we’ve given explicit width values, which are required for floating elements (added next).

2. Lorem Ipsum Floats

Let’s columnize it with a quick edit to our CSS. The “left” div will float left, and the “right” div will float…let me think….oh yeah…right!

#left
{
    float: left;
    border: thin solid green;
    width: 400px;
}
#right
{
    float: right;
    border: thin solid blue;
    width: 200px;
}

I can’t wait to F5 this sucker and see our cool new columns.

Whoops. No more hugging!?!?

When an element is given the float property, it’s removed from the normal layout flow of the document.

From W3C, 9.5:

Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float didn’t exist.

The container has nothing in it besides those two floating elements. Because they are no longer “in the flow”, that container essentially has nothing to define just how tall it needs to be. Let’s fix it.

3. Clearing House

They keyword here is “clear”. CSS2 defines the clear property as a way of specifying that a block element should not fall along the sides of a previous float. You can tell it to clear:right so that it pushes below any previous right floaters. You can tell it to clear:left to push past the southpaws. Or, as we’ll do here, you can tell it to clear:both, which basically means “Stop pushing me around”.

Now, at this point, one option is to manually insert a new, empty div immediately after the “right” column. We style it with clear so that it can ignore the two previous floats. This pushes it past them to the bottom of the container, which now must stretch out to fill all this new space. Voilà, we have a fix.

Here is our original HTML modified as an example, with the new div’s styling done inline:

<div id="container">
 
	<div id="left">
        <p>To the left.</p>
	</div>
 
	<div id="right">
        <p>To the right.</p>
	</div>
        <!-- Let's name him "stretch" -->
        <div style="clear:both"></div>
</div>

But it doesn’t have to be that way. I mean, do you want to manually insert extra cruft into your page like that? As an alternative, have you considered our shiny new model? The :after pseudo-element? It’s CSS that injects content for you! (Aside: On some level this seems wrong to me. Why would they create a method for the presentation mechanism to insert content? But then again, who cares. It’s there and it’s pretty cool, so let’s use it.)

Here is the new addition to our styling family:

#container:after
{
    content: "";
    clear: both;
    display: block;
    height: 0;
    visibility: hidden;
}

Now gander at what you have created. The hug is back!

Adding :after to an element’s style will literally add something (the “content“) after it. Examples I have seen use a period character for the content value (e.g. content: "."), which then absolutely requires that you specify a zero height and no visibility (otherwise the period would be displayed at the end of your content). But using an empty string seems to work just as well, and the two extra rules (height and visibility) aren’t needed. However, it seems prudent to just err on the safe side and go with both.

4. Handling the Exceptions

I only covered the Firefox relevant pieces here (which is the majority of it). But if you decide to use this technique to fix your missing background/borders, please read Clear a float container (linked to yet again for good measure) to view the extra information you’ll need to account for other browsers.

UPDATE: (June 22, 2009)
The link above now contains an outbound link to here (a more than four year old post). See item d:

That was my ‘current state of play’ until last week when SitePoint Forum’s own CSS Guru, Paul O’Brien, nonchalantly pointed out that adding a ‘overflow:auto’ to the outer DIV did the trick.

I have not tested this out, but thought it was definitely worth passing along.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

Firefox, CSS and floats: Where’s my background?

If you’re reading this on the wooliet main page (with multiple posts listed), you can see it in action by clicking the link below. If the is the “single post page” display then..well….there’s nothing to see! Just go to Wooliet and find an entry with a link to more content.

(Updated with official WP plugin link)

I’ve tried to make it a very quick and easy plugin that can easily be thrown in and activated on any standard Wordpress installation. Another goal was to keep it ‘unobtrusive’ in that, once deactivated, there would be no trace left behind in the Wordpress database. Of course, at some point (if enough people use it), additional options might be necessary and beneficial. But we’ll see.

I’m still in the process of getting it listed and hosted with the official Wordpress plugins repository, but at the moment, the new subversion area for the code doesn’t yet seem to be available (anyone know how long that should take?). It took three days for the Subversion path to become active. The plugin should be available at the official location, which is right here.

As an aside and helpful tip for anyone else considering submitting their plugin to the official Wordpress listings: they have a “readme.txt” validator you can use to verify the correct syntax and content of the required “readme.txt” file. It was extremely helpful for me.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

Announcing the ‘Read More Right Here’ Wordpress Plugin

So let me take you through my links and hopefully summarize what I’ve learned. First though, let me say, I’m assuming that you already know what it means to hook into the Wordpress application flow by adding “actions”. If not, read up.

Inject Your Javascript

The Wordpress Codex for wp_enqueue_script has a list of other javascript libraries included as well as a link to this brief tutorial at Nick Ohrn.

Basically Wordpress provides the wp_register_script method to register a javascript file and its dependencies using a unique string to serve as a “handle”. After you’ve registered them, you can then use that handle when calling wp_enqueue_script. This will spit out the appropriate <script> elements to your document, in their correct order, and (hopefully) avoid any duplicate entries or conflicts with other scripts.

I’ve added both the wp_register_script and the wp_enqueue_script calls to the method I’ve added as part of Wordpress 'init' (i.e. add_action('init', myLoadJsMethod)). I think you can also just use wp_enqueue_script directly, without first registering, but it seems like a good idea to do both. For example, if things change, you can keep the registration in 'init' but then move the call to enqueue somewhere else, like the 'template_redirect'.

What’s important to know, though, is that you cannot call wp_enqueue_script as part of the 'wp_head' action. At that point, it’s too late. This was confusing to me because I was originally just echoing out the path to my script within the function I set for 'wp_head', and it worked fine. But to work within the Wordpress world, it has to happen before the header action, which means 'init' or 'template_redirect' (or possibly others, not sure).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

function my_init_method()
{
    // include the js if not a single post page
    if(!is_single()) 
    {
       wp_register_script(
       		'my_handle', 
                my_get_base_path() . "js/my_javascript.js",
                array('jquery')); // my_javascript.js depends on jQuery
 
       wp_enqueue_script('my_handle');            
    }    
}
 
function my_get_base_path()
{
    return get_bloginfo('url') . "/" . PLUGINDIR . "/" . plugin_basename("read-more-right-here/");
}
 
 
add_action('init', my_init_method);

Notice that at line #11 I only needed to use the string ‘jquery’ to register my script as being dependent on it. This is because ‘jquery’ is included with Wordpress and has already been registered with that handle.

Making jQuery Work

Let’s test this out with a simple call to alert in our javascript. Following good practice, we’ll make sure to do this after our page’s DOM is locked and loaded.

1
2
3
4

$('document').ready(function() 
{	
	alert("ready");
});

Ahh Crap. Firebug is telling me that $ is not a function. A little google later and I’m at this thread, with the answer I’m seeking nine messages in, right here.

jQuery in WordPress uses the noConflict option to prevent issues with
Prototype…….Check online for jQuery.noConflict()

It’s always something. Alright, so what do the jQuery docs say?

By default, jQuery uses “$” as a shortcut for “jQuery”. However, you can override that default by calling jQuery.noConflict() at any point after jQuery and the other library have both loaded.

It goes on to say that you can also just set something else as the new “$” by setting a new variable to the result of jQuery.noConflict().

So the above javascript is changed to this:

1
2
3
4
5
6

var $j = jQuery.noConflict();
 
$j('document').ready(function() 
{	
	alert("ready");
});

And it works!

Summation (Because I Type Too Much)

• Use wp_register_script and wp_enqueue_script to load your javascript
• Do not use wp_register_script and wp_enqueue_script as part of the wp_head hook, it must happen earlier (e.g. init, template_redirect)
• jQuery in Wordpress uses “no conflict” mode, see here for workarounds

If I’ve misstated or completly misunderstood anything above, please feel free to correct me in the comments.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

Wordpress, jQuery and ‘noConflict’

Our lead designer wanted to find a way to keep coming up with great interfaces after carpel tunnel entered his body uninvited. As he pondered a design at home, he used refrigerator magnets as imaginary interface controls, since drawing and clicking was painful.
A journey of ideas and tests later resulted in the birth of GUImags which turned out to not only help hurting arms, but helped speeding up the design process as a bonus.

The site also has tabs for GUIPanes and GUIBoards, both of which are still underwraps.

Not a recommendation or anything, these just looked fun.

I came across them at a review by Design Shack, which pointed out two problems: 1. the whiteboard has to be magnetic and 2. there’s not a diverse collection of color choices. The first assumes you’re working on an early prototype at your customer’s office, but it seems just as likely that you would be sending photos of the mock-ups for early feedback. The second problem doesn’t seem like much of an issue to me. These magnets are geared towards early and quick iterations through a layout design. I don’t think color choices are the primary goal.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

GUI Controls For the Fridge

The original author, Joe Hewitt, open sourced Firebug sometime last year and back in mid-July, John Resig (a well-known javascript guru and Mozilla employee) announced that he was taking over its development. Today he laid out his initial plans:

• Improve the knowledge of Firebug that we have
• Build a runnable set of test cases to prevent regressions
• Track the state of Firebug performance
• Audit and Improve

I can’t wait to see how Firebug evolves now that Resig has reign.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

Firebug’s Future

div.links_list ul
{
	margin-top: -10px;
	margin-bottom: 0px;
	margin-left: 5px;
	padding: 0px;
}

~~~~~~~~~~~~~~~~ This has been a woolie posting.

List Items’ Indent in Firefox

The publication of this document by the W3C as a W3C Working Draft does not imply that all of the participants in the W3C HTML working group endorse the contents of the specification. Indeed, for any section of the specification, one can usually find many members of the working group or of the W3C as a whole who object strongly to the current text, the existence of the section at all, or the idea that the working group should even spend time discussing the concept of that section.

Got it…(awkward)

According to Firefox’s print preview, this sucker is a solid 238 page printout (including the table of contents), and as interested as I might be, it’s going to have be a “no” to reading this right now. Two reasons: 1. my eyes are fading fast 2. here are the cliffnotes (a more manageable 13 pages). To read the cool stuff, head straight to section four, “APIs”. There’s a new <canvas> tag in which graphics can be dynamically generated (i.e. games). There’s native support for drag-and-drop items via a new draggable attribute. It even mentions client-side storage of data using SQL statements. Neato.

Of course, all items subject to change. It’s still a “working draft” after all.

~~~~~~~~~~~~~~~~ This has been a woolie posting.

HTML5