Easy! Reader

After making a ridiculously stupid mistake by axing the server that hosted this blog (without checking that I had actually moved it to the new server and without making sure I had a backup of the DB), Easy! Reader is back. Sort of. Thankfully, I had a backup from late '06 and I haven't been an incredibly prolific blogger in the time since that backup. And, thanks to the Internet Archive, it looks like we should be able to recover all but one article (my last post, from about a year ago) from the ether. It may take a little time, but we should have it all up in the next few weeks.

So what's going on? Well, a lot.

For one, we've relocated from New Haven, CT to Chattanooga, TN after being urged to visit by Mr. Shaun Inman and his lovely bride Leslie and falling in love with this awesome city. We made the move in August of last year and, after spending a few months in an apartment, have bought a house and will be moving in this weekend. Chattanooga is an amazing place. There's always something going on, it has a wonderful art scene and tech community, and is nestled in the mountains, right along the Tennessee River. It has many of the perks of Portland, OR and San Francisco, CA (other cities we considered moving to), but at 1/4-1/3 the cost. I couldn't ask for a better place to live.

Since relocating, Easy! Designs has also been growing. We've taken on two interns -- Matt Turnure and Sean McCarthy -- and have been joined full-time by both Dave Stewart (who I had previously worked with in CT) and Matt Harris (an excellent developer from the UK), so expect to be hearing from them on this site soon as well. In addition to our client work, we've been busily coding away on a few products of our own that should hopefully see the light of day in the coming year. We're also working on a relaunch of our own website and this blog.

Finally, there's eCSStender. I've been working on this project for ages and it's currently in a closed beta. Things are progressing smoothly on its development though and I expect it will be ready for its initial public release in the coming weeks.

Anyway, that's the nickel tour of the changes. I apologize profusely for rendering this blog pretty useless with my error, but hopefully we'll have it all back up and running shortly.

PS - If you happen to have an archive of my blog post on IE8 Standards Mode, please forward a copy of it to me. I can't seem to find it even though it appears to be somewhere in the Google Cache.

As some of you have read (or heard), WaSP organized a Round Table discussion on IE8’s standards mode and its default behavior of opting-out any sites that don’t engage in version targeting. We discussed a few different aspects of the issues this presents for standards-aware developers (and progress on the web in general) and discussed a few tacks Microsoft could take to make IE8 more standardista-friendly.

One proposal that, to me, appeared to hold the most promise was one that involved extending IE8’s scheme of automatically opting-in unknown valid DOCTYPEs to also include Strict DOCTYPEs of HTML and XHTML currently in use. The current proposal hinges on the relative popularity (or unpopularity) of a given DOCTYPE: unrecognized DOCTYPEs are assumed to be future or custom DOCTYPEs and will automatically be opted-in to the latest and greatest standards mode of any given future version of IE; that is, until that DOCTYPE becomes “popular” enough to warrant associating it with a given version of IE. This, in a nutshell, means that if a new DOCTYPE were to come along after IE8 launches—say, HTML 5—IE8 would render it in standards mode, but if that DOCTYPE became “popular” before IE9 came out, IE9 would likely act as though it was IE8 when rendering those pages.

Chris Wilson did not have numbers on the relative popularity of Strict mode DOCTYPEs vs. Transitional and Frameset on either HTML or XHTML, but given that most authoring tools do not automatically generate Strict documents, it is a strong possibility that the popularity of Strict mode DOCTYPEs may make them a candidate for being automatically opted-in to standards mode, at least in IE8. That would be great news for standards-aware developers who want IE8’s standards improvements, but don’t want to engage in version targeting.

In reaction to my latest article for A List Apart, on FigureHandler, many folks have boldly claimed that this sort of thing should be done server-side. Below are my thoughts on the matter as posted as a comment in the article’s discussion thread.

Many of you have brought up that this should be done server-side and, while I agree that it could, it would need to be done in the most flexible way possible (which many won’t bother with). You see, what this script allows quite easily is redesign; a designer can change page layout—"of an entire site or section by section—"without ever having to touch the back-end. It also allows for different columns to receive different figure classification schema.

If this were done on the content-entry side (as some have suggested), the image classifications would be stored in the database (or XML or whatever) along with the rest of the content HTML. That means that if the design were to shift to a wider column (for example), the figures that once occupied a half-column, may no longer continue to do so, making the classifications hard-coded in the HTML incorrect.

The only way to truly do this flexibly on the back end (as far as I can see) is to leave the classification step to be handled by a function which pre-processes the page output, dynamically assigning the classifications to each figure based on values obtained from the CSS for that page. Essentially, the script would need to go through the same steps as the JavaScript, but it would need to be able to go the extra step of determining applicable CSS rules to obtain the column width. Thankfully, most server-side languages support some means of DOM walking (albeit sometimes in less-than-desirable ways), but, as far as I know, none have a CSS parser, so you’d likely need to write that as well. From a server overhead point-of-view, I imagine that preprocessing would be fairly costly (most DOM-related stuff is), but the output for each page could be cached, reducing it somewhat.

If you’re interested in doing something like this, goodonya. I’ve built you a pretty decent roadmap for implementation, but I don’t imagine it will be easy to get it up and running. That said, I wish you luck…it would be yet another great tool for enabling designers to create consistent layouts with figures.