/archive/ en aaron@easy-designs.net Copyright 2010 2010-03-17T19:16:40+00:00 http://easy-reader.net/archives/2010/03/17/counting-the-results-of-a-nested-query-in-expressionengine http://easy-reader.net/archives/2010/03/17/counting-the-results-of-a-nested-query-in-expressionengine {summary}If you've built anything remotely challenging in ExpressionEngine, you've no doubt discovered things that are easier done in native PHP than in EE tags. A lot of it has to do with how ExpressionEngine parses templates and what gets parsed first. One recent bugbear I ran into was trying to use the {count} "magic" variable from a call to {exp:query} that resided inside a {exp:weblog:entries} loop. I needed the {entry_id} from the entry in the SQL statement, but {count} (despite being used inside {exp:query}) was evaluating as the {exp:weblog:entries} count and not the {exp:query} count. To solve the issue, I came up with the following: {exp:gist id="335632" file="gistfile1.phtml"} You'll notice I'm using {exp:query} twice. The first time is to establish a variable in the SQL connection. Then I am free to use the variable in the second query and the count (returned as {query_count}) will be a count of the inner loop instead of the outer one. It is important to note, however, that MySQL will evaluate the variable's incrementation before paying attention to any ORDER BY clauses, so your mileage may vary. Regardless, it's a handy technique. design & development, programming 2010-03-17T19:16:40+00:00 http://easy-reader.net/archives/2010/01/18/a-new-onload-scheme http://easy-reader.net/archives/2010/01/18/a-new-onload-scheme {summary}A few projects back, I decided to rethink our JavaScript organization strategy and came up with a new technique that, I think, helps us better manage behaviors from page to page. For years, when I needed page-specific interactions, I would either embed the JS (unobtrusively, of course) at the bottom of the page or externalize it to a separate page-specific file. In some sites, that became a difficult setup to manage because we were juggling so many files and we were also forcing our users to download each of those files individually. Looking for a better way to manage all of the code, I built FunctionHandler. This script takes lets you declare blocks of JavaScript and then target them at pages based on the id attribute on the body element. When the targeted id is encountered, the code block is executed on DOM ready. Here's a quick example: {exp:gist id="313553" file="gistfile1.js"} As you can see, using it is pretty simple: you make a call to FunctionHandler's register method and pass it two arguments. The first is an array of the id values you want this code block to execute on and the second is an anonymous function that wraps your code block. What we've found really nice about this setup is that it encourages you to create discrete JavaScript components while, at the same time, easily allowing you to adjust the pages that those components run on by simply adding to or subtracting from the id stack. You can even blanket every page with a given script by supplying a string value of "*" as the initial argument: {exp:gist id="313553" file="gistfile2.js"} Anyway, I just wanted to take a brief moment to share this script because we've found it pretty handy. Perhaps you will too. PS - FunctionHandler is available in 3 flavors: native JS, jQuery, and Prototype. design & development, programming 2010-01-18T23:30:52+00:00 http://easy-reader.net/archives/2009/09/21/getting-tinymce-to-respect-empty-alt-attributes http://easy-reader.net/archives/2009/09/21/getting-tinymce-to-respect-empty-alt-attributes {summary}This one took a little futzing around and digging through the TinyMCE forum&nbsp;to figure out, but it's been nagging at me for a while. By default (or at least in the default configuration provided under the LG TinyMCE extension for ExpressionEngine), TinyMCE will remove the alt attribute if it is empty. Obviously, for accessibility and validation reasons, this is highly undesirable and needs correcting. Thankfully, the fix is pretty simple: add the following to your TinyMCE configuration options: {exp:gist id="313562"} I choose to add these options right after declaring my cleanup/output options but before the remainder of the configuration. If you choose to tack these options on at the end, just remember to remove the trailing comma. design & development, programming, web standards 2009-09-21T13:37:04+00:00 http://easy-reader.net/archives/2009/07/09/rip-xhtml2 http://easy-reader.net/archives/2009/07/09/rip-xhtml2 {summary}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&mdash;abbr vs. acronym, use vs. abuse of definition lists, etc.&mdash;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. design & development, coding, web standards 2009-07-09T13:46:51+00:00 http://easy-reader.net/archives/2009/04/22/were-back-sort-of http://easy-reader.net/archives/2009/04/22/were-back-sort-of {summary}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. business 2009-04-22T12:05:14+00:00 http://easy-reader.net/archives/2008/02/25/automatically-opting-in-to-ie-standards-mode http://easy-reader.net/archives/2008/02/25/automatically-opting-in-to-ie-standards-mode {summary}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. design & development, coding, design, web standards 2008-02-26T01:18:58+00:00 http://easy-reader.net/archives/2007/10/11/server-side-figurehandler-thoughts http://easy-reader.net/archives/2007/10/11/server-side-figurehandler-thoughts {summary}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. design & development, coding, design, programming 2007-10-11T13:19:53+00:00 http://easy-reader.net/archives/2007/09/10/alex-russell-is-not-a-heretic http://easy-reader.net/archives/2007/09/10/alex-russell-is-not-a-heretic {summary}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: <div dojoType="dijit.form.HorizontalSlider" name="horizontal1" onChange="dojo.byId('slider1input').value=arguments[0];" value="10" maximum="100" minimum="0" showButtons="false" intermediateChanges="true" style="width:50%; height: 20px;" id="slider1"> ... </div> 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: <select class="dojo-form-horizontalSlider" name="horizontal1" showButtons="false" intermediateChanges="true" id="slider1"> <option>0</option> <option>5</option> <option selected="selected">10</option> ... <option>100</option> </select> 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: <!ENTITY % Boolean "(true | false)" > ... <!-- attributes for Dojo Toolkit showButtons display buttons (boolean) intermediateChanges display intermediate steps (boolean) --> <!ENTITY % dojo-attrs "showButtons %Boolean #IMPLIED intermediateChanges %Boolean #IMPLIED" > ... <!ATTLIST select %attrs; name CDATA #REQUIRED size %Number; #IMPLIED multiple (multiple) #IMPLIED disabled (disabled) #IMPLIED tabindex %Number; #IMPLIED onfocus %Script; #IMPLIED onblur %Script; #IMPLIED onchange %Script; #IMPLIED %dojo-attrs; > 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? design & development, animation, coding, design, web standards 2007-09-10T21:39:05+00:00 http://easy-reader.net/archives/2007/08/27/a-better-createelementwithname http://easy-reader.net/archives/2007/08/27/a-better-createelementwithname {summary}Back in 2005, I wrote a piece about IE&rsquo;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( '&lt; '+type+' name="'+name+'" /&gt;' ); }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&rsquo;s very efficient one-time function definition: function createElementWithName(){} (function(){ try { var el=document.createElement( '&lt;div name="foo"&gt;' ); if( 'DIV'!=el.tagName || 'foo'!=el.name ){ throw 'create element error'; } createElementWithName = function( tag, name ){ return document.createElement( '&lt;' + tag + ' name="' + name + '"&gt;&lt;/' + tag + '&gt;' ); } }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( '&lt;div name="foo"&gt;' ); if( el.tagName !== 'DIV' || el.name !== 'foo' ){ throw 'create failed'; } return function( tag, name ){ return document.createElement( '&lt;' + tag + ' name="' + name + '"&gt;&lt;/' + tag + '&gt;' ); }; }catch( e ){ return function( tag, name ){ var el = document.createElement( tag ); el.setAttribute( 'name', name ); return el; }; } })(); Geat job Brian, thanks for sharing. design & development, programming, web standards 2007-08-27T15:44:36+00:00 http://easy-reader.net/archives/2007/07/29/tipr-now-with-added-txt http://easy-reader.net/archives/2007/07/29/tipr-now-with-added-txt {summary}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&rsquo;ve been keeping an eye on the traffic patterns, reviews, and mentions of Tipr across the intarwebs, but I&rsquo;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&rsquo;d like them to. I wanted to correct that. My first thought was to create an SMS service for Tipr, but there&rsquo;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&rsquo;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&rsquo;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&rsquo;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 &mdash; 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&rsquo;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&rsquo;re on Twitter, give it a shot and let me know what you think. business, design & development, programming 2007-07-29T19:50:52+00:00