Easy Reader

RIP XHTML 2

2009-07-09T13:46:58+00:00

I wasn't planning to weigh in much on this subject, but I've been asked by several people for my thoughts, so here we go... This decision by the W3C to not renew the charter for the XHTML 2 Working Group has, rather unfortunately, brought out the worst in the Web standards community. Sure, as a community, we're prone to holy wars over seemingly inconsequential things—abbr vs. acronym, use vs. abuse of definition lists, etc.—but this move has sparked a particularly ugly fight between proponents of XHTML and its detractors (primarily those folks who think it's pointless to use XHTML if you aren't serving it with an XML MIME type).Personally, I have mixed feelings about the decision. I think there were a lot of good ideas in XHTML 2 (everything can be a link, for one), but it also had a number of shortcomings. I feel much the same about HTML 5; some of the new elements make a lot of sense, but others seem to be solving a problem that really wasn't there to begin with.In the end, I think this is probably a good move for the W3C as it will, hopefully, allow them to reallocate resources to projects that need them.But does it mean I think XHTML is a failure? No.I think XHTML was a phenomenal success as it made us look at HTML in a new light. It forced us to think about how we marked up documents and applied much-needed pressure on developers to make smarter decisions. Without it, I dare say the Web standards movement would never have gotten as much traction as it did and we would still be in the midst of the browser war started more than a dozen years ago.

Links for 2009-07-08 [del.icio.us]

Thu, 09 Jul 2009 00:00:00 PDT

Downloadable font formats for the Web
A thoughtful piece by David Baron. He brings up some good points.

Links for 2009-07-02 [del.icio.us]

Fri, 03 Jul 2009 00:00:00 PDT

Extreme JavaScript Compression With YUI Compressor
An excellent presentation from Nicholas on how to squeeze the most code out of your JavaScript when it comes to compression.

Links for 2009-07-01 [del.icio.us]

Thu, 02 Jul 2009 00:00:00 PDT

Google is using hProduct!
I completely missed this, but it looks like Google is parsing hProduct now when crawling he web. As one of he first people actively working on he spec, I'm thrilled to see this happen.

Oh, did you need this arm for something? [Flickr]

Aaron Gustafson — Fri, 26 Jun 2009 15:56:31 PDT

Aaron Gustafson posted a photo:

Oh, did you need this arm for something? [Flickr]

Aaron Gustafson — Fri, 26 Jun 2009 15:53:50 PDT

Aaron Gustafson posted a photo:

Links for 2009-06-25 [del.icio.us]

Fri, 26 Jun 2009 00:00:00 PDT

Why the Critics of a Public Option for Health Care Are Wrong
A good piece debunking many of the claims against a public health care plan.

$50 bar tab for 1st place [Flickr]

Aaron Gustafson — Thu, 25 Jun 2009 19:01:11 PDT

Aaron Gustafson posted a photo:

Our trivia team at T-Bones, DPRK 4 Lyfe, took 1st place tonight!

Links for 2009-06-23 [del.icio.us]

Wed, 24 Jun 2009 00:00:00 PDT

NimbleKit
Use JavaScript to write iPhone apps.

Once bank, now 'bucks [Flickr]

Aaron Gustafson — Mon, 22 Jun 2009 12:31:01 PDT

Aaron Gustafson posted a photo:

Will Your Next Data Center Be Solar Powered? [Flickr]

Aaron Gustafson — Thu, 18 Jun 2009 04:40:36 PDT

Aaron Gustafson posted a photo:

www.greenercomputing.com/blog/2009/06/16/will-your-next-d...

Links for 2009-06-12 [del.icio.us]

Sat, 13 Jun 2009 00:00:00 PDT

Grrrrr
When good post-its go bad.

Links for 2009-06-04 [del.icio.us]

Fri, 05 Jun 2009 00:00:00 PDT

Run Internet Explorer 6 (or IE7, or IE8) images in VMware Fusion on Mac OS X
Microsoft's official VMs, converted for your pleasure.

We’re back (sort of)

2009-04-22T12:05:26+00:00

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.

Server-side FigureHandler thoughts

2007-10-11T13:19:52+00:00

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.

Alex Russell is not a heretic

2007-09-10T21:39:31+00:00

First off, let me preface this by saying I just got back to the East Coast after catching a red-eye from San Francisco on Saturday night, so if I seem a bit incoherent, that’s likely why. In perhaps the most intellectually-stimulating session at The Rich Web Experience, Alex Russell (of Dojo Toolkit fame) tackled the topic of Standards Heresy. For those who are not aware, Alex was once a staunch standards advocate who has turned to what he considers, “the dark side.” In truth, he’s sick and tied of the dysfunctional nature of the W3C and other similar organizations and I can’t say I blame him. As his session pointed out, the W3C has 60+ paid, full-time staff and yet we saw literally no movement on either (X)HTML or CSS for over five years. That is a travesty. In my opinion, fault lies not with the individuals on the various committees and sub-committees, but rather, with the process. And this isn’t just a problem in the W3C, an organization comprised almost entirely of representatives from the various software vendors (Microsoft, AOL, Opera, etc.) which pay tens of thousands a year to take part. Look at what’s happening with JavaScript 2 in ECMA. Or HTML5 for that matter—"just because it is an “open” organization which “anyone can join” doesn’t make the WHAT WG any better. They are all flawed because the process is flawed, and I think that is Alex’s main point (despite his assertion that the WHAT WG is not dysfunctional). So why is the process flawed? Well, for one, spec writing is largely an academic undertaking. In many cases there are invited experts in a Working Group (such as Andy Clarke in the CSS one), but, for the most part, specs are written by people who are not in the trenches. As Alex rightly points out, in fact, many times, the specs are nothing more than an official blessing of some proprietary technique or technology created by a member company. And good ideas that may be very useful to designers or developers are lost because of internal politics or because a browser vendor thinks it would be “too hard” to implement. Which brings me to Alex’s “heresy.” In his session, he proudly declared himself a heretic because he sees a need for innovation in (X)HTML which is currently unavailable because the specs are not evolving quickly enough. I feel his pain, but I think he is looking at the problem the wrong way. He sees the spec (and web standards in general) as stifling innovation. I see web standards as facilitating innovation. After all, were it not for the firm foundation of well-formed documents and a unified DOM (no matter how piecemeal the implementations), we’d still be writing spaghetti code whenever we tried to do anything with JavaScript. It is because of web standards that we can write clean JavaScript and that we can make truly innovative interactions that take us beyond what is allowed for in the specs themselves. But back to Alex’s complaint…as his example of how Dojo is heretical, he showed this code example:

...

The problem that Dojo is attempting to solve here is the inclusion of a slider form control, which does not exist under the current HTML Forms spec. In order to function, the widget requires several custom attributes to be placed on the element to provide information to assist in the creation of that slider. The fact that Alex “cannot” add these attributes to the document and maintain XHTML validity is a major source of annoyance for him and part of why he has decided that validation is no longer important. But the truth is that Alex could make any or all of these attributes available to whatever elements he wants and still have a validating document by simply creating a DTD (based on any existing (X)HTML one) to include them. After all, the X in XHTML stands for extensible…the language is meant to be improved. Sure, there are some standardistas who think we shouldn’t muck about with the standards, but the powers that be put that extensibility in there for a reason (and I don’t think it was just as a tease). By extending the language to mix in features we desperately need, we drive innovation and, who knows, perhaps someone will take notice and add our extensions into the next version, thereby driving the evolution of the language so many of us desperately want. The same goes for CSS. The W3C made CSS extensible by allowing for custom properties utilizing the -*- syntax. Chances are, you’ve come across this when implementing -moz-border-radius or -webkit-border-radius (which, honestly, both seem superfluous to me when the CSS3 spec includes border-radius as an actual property…why not just support that?). In my mind, this is ripe for use in extension of CSS, not by individual browser vendors (as that is proprietary and closed), but by us (in an open, cross-browser/cross-platform way) to achieve what we want or need that CSS currently does not offer us. That was the basis for my work on gFSS (an experiment in presentational Flash generated from CSS, debuted at Web Directions North this year) and another project I will be releasing in the next few months. So, long story, long, I don’t think that Alex is a heretic. I think he can make a solid case for extending the language (and the interface) of the web for his particular needs (or the needs of his toolkit) as long as he backs it up with documentation in the form of a custom DTD. An aside I do have one problem with what Alex wants, however (or at least what he chooses as a code example) and that problem is the extension of the language, but rather the way in which it was done (i.e. the DIV in his example will degrade to nothing without JavaScript enabled). Dojo supports WAI-ARIA to improve the accessibility of this and many other widgets, which is commendable, but that extra markup is only generated when the Dojo methods are run. If JavaScript is turned off in his example, no form control is available whatsoever. What I’d prefer to see is something like this: There’s nothing that could keep Dojo from parsing that bit of XHTML and gleaning from it what it needs to make the slider. And now, when Dojo doesn’t run, there is a degradable interface for the user to adjust the setting. Sure, it may not be nearly as nice, but at least it works. Plus, it allows Dojo to be added as a progressive enhancement, which is what it should be. And to make this valid syntax, the Dojo team just needs to augment the XHTML 1.0 Strict DTD like this to include the custom attributes: ... ... Sure, it takes a little extra work, but at least it gives users of the Dojo Toolkit the ability to validate their documents, which will help reduce potential CSS and JavaScript conflicts and errors (just one of the many benefits of web standards). Beyond that, it takes advantage of the extensibility of the language to facilitate innovation, and isn’t innovation what we all really want to see?

A better createElementWithName()

2007-08-27T15:44:44+00:00

Back in 2005, I wrote a piece about IE’s abysmal generation of NAMEd elements via the DOM (which, interestingly enough, has proven to be one of the most popular posts on the blog, pointing to the fact that this is an obvious pain point for many DOM scripters out there). The the time, I wrote function createElementWithName( type, name ){ var element; // First try the IE way; if this fails then use the standard way if( document.all ){ element = document.createElement( '< '+type+' name="'+name+'" />' ); }else{ element = document.createElement( type ); element.setAttribute( 'name', name ); } return element; } It was a complete hack, but it worked. More importantly, however, it began a discussion of a better way to fix the problem in a cross-browser way. The best solution offered was Anthony Lieuallen’s very efficient one-time function definition: function createElementWithName(){} (function(){ try { var el=document.createElement( '<div name="foo">' ); if( 'DIV'!=el.tagName || 'foo'!=el.name ){ throw 'create element error'; } createElementWithName = function( tag, name ){ return document.createElement( '<' + tag + ' name="' + name + '"></' + tag + '>' ); } }catch( e ){ createElementWithName = function( tag, name ){ var el = document.createElement( tag ); // setAttribute might be better here ? el.name = name; return el; } } })(); And now Brian Adkins has refactored the script to be even fewer lines of code: var createElementWithName = ( function(){ try { var el = document.createElement( '<div name="foo">' ); if( el.tagName !== 'DIV' || el.name !== 'foo' ){ throw 'create failed'; } return function( tag, name ){ return document.createElement( '<' + tag + ' name="' + name + '"></' + tag + '>' ); }; }catch( e ){ return function( tag, name ){ var el = document.createElement( tag ); el.setAttribute( 'name', name ); return el; }; } })(); Geat job Brian, thanks for sharing.

Tipr, now with added txt

2007-07-29T19:50:17+00:00

So, as it turns out, this little app I built for myself is actually useful to other folks. Over the 3 weeks since it launched, I’ve been keeping an eye on the traffic patterns, reviews, and mentions of Tipr across the intarwebs, but I’ve also been busily adding some new features, which brings me to this post. I knew people with iPhones and other capable mobile browsers were quite happy with Tipr, but folks without a mobile browser or with a sucky one were not, in my opinion, getting as much out of Tipr as I’d like them to. I wanted to correct that. My first thought was to create an SMS service for Tipr, but there’s no way I can afford to rig up a server capable of receiving and replying to SMS messages and I certainly could not afford to pay the $1000-2000/month for an SMS short code (after all, I’m not making any money on this thing). Then the answer dawned on me: Twitter. Since Twitter offers an SMS interface (40404 once you register your mobile), I could simply piggy back on their service to offer Tipr via SMS. All I had to do was build a TwitterBot capable of receiving and responding to messages. Lots of folks have built IM bots in the past, but there weren’t that many TwitterBots and there was even less information about building one. Even with the odds stacked against me, however, after about an hour of reading the Twitter API documentation and 6 hours of actual programming, I had built a working PHP-based TwitterBot class. The whole thing works using Twitter’s direct message functionality and runs several independent services to do things like reciprocate friendships, check the inbox, process responses, and send messages back. Unfortunately, the API was only able to get me so far, so I did have to resort to a little hackery to get some of it to work, but in the end, the Tipr TwitterBot, which sits on top of my generic TwitterBot class is pretty solid and quite responsive — even with the 70 API calls in 60 minutes limitation, most messages receive a response in approximately 45 seconds (depending on your network and whether Twitter is releasing a new feature and takes the service offline for a few minutes). Overall, I’m pretty happy with the results and the early beta testers seem to be liking it as well. Hopefully some of you out there will find it as useful (if not more so) than the web interface. If you’re on Twitter, give it a shot and let me know what you think.

New Easy! app: Tipr

2007-07-12T19:07:25+00:00

Those of you who’ve been paying attention to the apps that came out of iPhoneDevCamp (or who are using Applists, AppMarks, or any of the other iPhone web app aggregators/launchers) are probably already aware, but we just launched our first micro-application named “Tipr” last week. Tipr is a super-simple web-based tip calculator aimed at mobile devices. You simply enter the bill total and choose a percentage to tip and Tipr does the rest, giving you the tip amount and the total. As an added benefit, the total is always converted to a palindrome to make it easy to spot fraudulent adjustment of your tip amount or total when scanning your credit card or bank statement. Tipr started off as a tool for me, really. I have been doing the palindrome thing for over a year now and, even with the calculator on my phone, it takes a minute or so for me to calculate out the tip amount to end up with a palindrome for a total. To speed things up a bit for myself, I built Tipr and it’s proven quite useful. I hope you will find it useful too. We’re trying to keep Tipr pretty simple, but if you have recommendations for improving it, let us know by leaving a comment.

Wouldn’t it be nice?

2007-06-27T21:25:41+00:00

Over the last two years, I’ve been wishing for just one thing in CSS: rotation. There’s been some discussion about it on the W3C lists, etc. but no one has made a solid pitch for it yet. Inspired a bit by Andy’s modest column-rule-image proposal, I drafted a spec for CSS 3 Rotation [PDF] back in February. I showed it to a few folks at Web Directions North and got some good feedback. Out of those discussions, I also realized we really needed a text-wrapping property in CSS 3, so I also drafted a spec for CSS 3 Polygonal Margins [PDF]. The idea is based on the polygons we used for image maps back in the day and would allow complete control over how text wraps around an element. Anyway, I’ve sat on these for a while and I figured now was as good a time as any to unveil them to the world and solicit your feedback. So what do you think? Could you use this sort of control in your everyday CSS work? How would you want to see it work? Do you think the plans I’ve outlined offer enough flexibility?

Whoops…

2007-06-26T16:58:00+00:00

I was doing a little server cleanup and moved this site’s folder, forgetting to set the new folder up for mod_rewrite, so permalinks have been broken for the last week or so. Everything is better now (I hope). Please let me know if you notice any lingering issues.

WebVisions wrapped

2007-05-04T17:58:44+00:00

I just wrapped my presentation at WebVisions and have posted the slides for my talk, titled “Learning to Love Forms,” up on SlideShare. I have also embedded them below (though the formatting is a bit off on some of the longer sidebars). I’d like to thank everyone who attended and especially those who asked the challenging questions. Hopefully this was a good start to my campaign for getting people to embrace forms instead of running from them. For those of you who couldn’t attend, enjoy the slides. I will post the audio for the session as soon as it’s available.