Dispatches From The Internets

In our years of working with ExpressionEngine, we’ve tweaked our standard setup quite a few times. We generally handle most every asset, including CSS and JavaScript, as a template. Being a bit obsessed with organization and overall maintainability of code, we separate out our styles and scripts into separate templates for each major concern (e.g. typography, color, screen layout, etc.).

We use Subversion as our version control system for all client work here at Easy because we absolutely love Springloops’ hosted Subversion service, but we use Git for all of our open source projects because, well, Git is a lot more fun to work with and we love the community that’s built up around Github. In order to have the best of both worlds when working on client projects, we use git-svn as our front-end to Subversion. It’s a great tool, but it’s not without its limitations. One such limitation is its inability to translate Git submodules into svn:externals. Thankfully, Git offers an alternative that is comparable and plays nicely with Subversion: the subtree merge.

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.

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.

This one took a little futzing around and digging through the TinyMCE forum 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:

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.

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.

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.

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.

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.