is the DOM ready yet?

This post ( Order of Events @ dean.edwards.name) addresses the need for a better solution than window.onload for DOM scripting. window.onload only fires after all the content on a page (including images) has loaded.. which is frequently significantly after the page has appeared in the browser. Mozilla/Firefox apparenly have the little known “DOMContentLoaded” event. Very handy. Windows IE has the readyState (or, better, the also little known ondocumentready event. Take this and brothercake’s domFunction and there’s a cross-browser solution in there awaiting the motivated developer.

A cheese-inflicted injury

Today I suffered my first injury by cheese. My left thumb aches and has swollen from the cut I received under the nail. It happened like this:

At lunchtime I discovered the office microwave had been the site of a small explosion - probably featuring lasagna - and the debris had since baked on in a uneven patina of tomato red splotches. Not wanting to be a part of the problem in baking it on further (and being an occasional nice-guy,) I set about cleaning it. With a little soapy water and a few minutes to soak most came right off, but some residue on the glass turntable was more stubborn. I flipped the sponge and leaned hard on the scourer. That was when it struck. A flake of cheese, hardened to a vicious point, dug in deep under my thumbnail and drew blood. I was able to complete my task and heat my bean wraps with a clear conscience, but the damage was done and a small piece of history was made.

XML.com: Errors and AJAX

Client-side script errors seem to be everywhere, and no-one either knows about them or takes them seriously enough to fix. This article (XML.com: Errors and AJAX) proposes a solution (and supplies js code and a sample perl backend) to catch and send errors back to the server. (Of course one irony is that of all things that can go wrong, an XmlHttpRequest implementation is likely to be up there.) The premise is that you include this file or code block on every page of a site (after testing thoroughly). That way if future script errors are introduced, they will show up in your server's error logs. Anything already watching the error log will see the error (and the appropriate people can be notified, paged in the middle of the night etc.)

As web applications move more functionality to the client, the responsibility also increases. This seems like a good practice to adopt to bring some of the rigour and accountability you'd expect on the backend over to the frontend.

Test case for TBODY/THEAD/TFOOT with overflow

I happenned across this test page while looking into scrollable table implementations: HTML Test Suite for UAAG 1.0 (Draft). I demonstrates how it ought to be done: you assign overflow: auto and a fixed height to the table's tbody, and you're done. Sigh.. if only it was that easy.

The test does work in my Firefox 1.0.3, but then there’s the horizontal scrollbar. If you add in a 16px scrollbar, you just hid 16px therefore a horizontal scrollbar is necessary to scroll over to see it. Makes perfect sense but its maddenning, because as of this writing I’m unable to remove the need for it. There are other ways to get there of course, but it want this one to work!

For the record, border-collapse: collapse throws a spanner in the works in mozilla + cousins. Here’s that illustrated: 1, 2.

Perl Design Patterns Wiki

There's a world of goodness over at the perl design patterns wiki. Take this little snippet:

foreach my $i (qw(name price quantity)) {
my $field = $i;
*{"get_$field"} = sub {
my $me = shift;
return $me->{$field};
};
*{"set_$field"} = sub {
my $me = shift;
@_ or die "not enough arguments to set_$field, stopped";
$me->{$field} = shift;
return 1;
};
}

..All your getters and setters, done. I'm in awe, and I'm dumping php and going back to perl :) This and other wisdom comes from the AccessorPattern page.

The Piss List

I was reminded to dust this off and publish this again. Its the beginning of a list of some of the varying uses and meanings of the word "piss", which I trust is a mild enough word to not offend even my american readers.

The Piss List

I'd welcome any input from either side of the pond, and any Aussie/Kiwi variants would also be interesting.

Adobe / Macromedia

Well, this is some kind of news. I'm at a loss to see how anyone but possibly some shareholders will benefit though? This is not a sector that really needs consolidation, and (assuming product lines merge) I think most designers and developers will miss the Macromedia alternative.

Does it matter who makes Flash? Dunno. Dreamweaver vs. GoLive? I'd take DW, but I'm not going to pitch my tent outside Adobe's offices to petition for its continued development. Homesite? I'm still using Allaire's version. And the silver lining - I guess I can take Fireworks off my must-learn-more-about list.

User defined colors (CSS property values)

I learned something new today… font-family: menu. This should serve (me) as a reminder to go read the specs a little more often (or buy books, or both) as none of this is news. Anyhow, thanks for bringing them all together on one page .jeff

DotML

I just saw Dot in action here at work the other day - generating flow charts in SVG on the fly from a database of screen specs and interactions/workflows. Interesting and positively plump with possibilities. Generating and maintaining these kind of documents has been an irritation for me for years - particularly as the information they capture is essentially locked up and only accessible visually.

Implementing a workflow has always meant essentially starting over - with the document serving as a reference only. By flipping this on its head and making your flows *output*, rather than input, your application logic can stay fluid and be developed independantly. Ideally you would be able to round-trip - so you could model an interaction or workflow in a tool like Visio or Omnigraffle - export or merge into your XML that captures the application logic in its entirety, test, tune, and re-output to a Visio/Omnigraffle importable format for futher refinement. As I understand it this capability exists...

Any opportunity to defer the permanent entanglement of application, business, presentation logic allows for more testing, refinement and interation, at less cost. We don't necessarily need DotML to do this, but it will help. Once it becomes XML, half the work is already done for me.