Standardista and web development community leader Molly Holzschlag pointed me to the “very awesome iJustine”, who posted this hilarious rap by m0serious about standards-based web design. User interface tips, semantics, accessibility — it’s all there! Perfect for nerds and gangsters alike… Molly and iJustine’s posts are complete with transcript, so educate yourself 
Web browser drama!
Microsoft is still reeling in the web browser market from its own five-year failure to update Internet Explorer before version 7 last year. After being poised to continue their arrogant imperial approach to said market with a new proposal called “version targeting“, I’m thrilled to see they’ve changed course and will now heed the wishes of the greater web development community.
Version targeting is the idea that web sites should explicitly specify which version of the browser they’d like to use, and Microsoft was going to require web sites to “opt-in” to using the latest version of Internet Explorer every time a new version of the browser was released in the future. (If they didn’t, even IE99 would still show the web site exactly like IE7 did!) This proposal is a reaction to the trouble they created by fixing many of their own bugs with the release of Internet Explorer 7, and it would be a sea-change for web development: moving away from the convergence on web standards and the idea of progressive enhancement, back to the use of specific bits of code dictated by browser vendors from the top down for their one particular browser.
The version targeting proposal and explicit opt-in requirement has created a huge upswelling of comment and debate in the web development community, and while 99% of “blue collar” web developers like me seemed opposed to the idea, I was disappointed to see so many rockstar standardistas coming out apologetically in favor. Many thanks to Jeremy Keith, who took a strong stand against the idea in a recent article on A List Apart. Jeremy wrote:
The proposed default behavior for version targeting in Internet Explorer solves the problem of "breaking the web" in much the same way that decapitation solves the problem of headaches.
Well, as of yesterday, Microsoft has changed course and said that while their new version targeting scheme will remain intact, web sites will no longer have to explicitly opt-in! IE will continue to adhere to web standards as best it can by default, and the onus to “version target” will be on developers who explicitly want to use an old version of IE. This is great news.
Workers of the web unite! And kudos to Microsoft. It’s excellent to see them listening, and working with the greater community.
Warning: Drupal nerddom ahead! (I spent enough time on this issue that I wanted to post this write-up in the hopes that it’ll help someone else out there…)
Though I’ve recently gushed about how version control has helped us upgrade Drupal much more easily, I had a bear of a time getting one site upgraded recently. The site is very simple as Drupal goes, with only a handful of contributed modules, but a decent amount of content, including lots of images. After struggling with issues related to both the Image and Image Assist modules, I finally decided to just bite the bullet and make some radical changes to the way the site handles images.
This site just uses images to be displayed inline with other content (and doesn’t use any other file uploads). So i’d been planning to make these changes due to my agreement with the Drupal prevailing winds that such images should not be their own nodes, nor do they require the overhead of “private” Drupal files.
I made these changes:
In a nutshell, the process went like this:
The changes to Drupal’s download method (from “private” to “public” files), and file system path (changed to a web-accessible path relative to the Drupal install) were smoother than I’d anticipated. The database revealed no instances of the old path other than the files table, which I’d address after changing image-handling modules. So essentially i just needed to move the files on the server, change Drupal’s settings, and clear Drupal’s cache.
The image converter script was obviously what took all the time. I wrote a script that bootstrapped Drupal, ran through every node in the database that was using Image Assist’s bbcode-like markup, and converted each instance of that markup to xhtml, doing its best to get the proper image dimensions as it went.
Special care had to be taken with Drupal’s input formats and desired image sizes. Specifically, I needed to anticipate what xhtml tags and attributes would offer the most flexibility (e.g. image captions and varying image sizes…) while still working within a reasonable HTML filter.
The script is pretty clunky, but got the job done.
Next I enlisted Apache’s mod_rewrite to help keep old image URLs (e.g. all of those indexed and cached by search engines) from breaking. This consisted of two parts: 1) rewrite all requests for the old private image paths to the new public ones; and 2) rewrite all the old ‘+’ marks Drupal had used to represent spaces in image names for the old private URLs to the proper ‘%20′ encoding required by the new public URLs (and remind the site editors that image file names should not include spaces!).
The first rewrite was simple — I just added the following line to Drupal’s .htaccess file:
RewriteRule ^system/files/images/(.*)$ /files/images/$1 [R=301,L]
The second one was more complex… A big hat tip goes to dkg for supplying the solution. I added the following lines to the .htaccess file in the new files directory:
RewriteCond %{SCRIPT_FILENAME} ^.*\+.*$
RewriteRule ^([^+]*)\+(.*)$ $1\%20$2 [N]
Here’s dkg’s explanation:
the [first] line says “if there is a plus in the filename, apply the next rule”
and the rule itself says:
“match the first bunch of text that is not a +, then match the plus, then match everything else. keep the first bunch of stuff ($1), put in a literal %20 (we need the backslash or the % is interpreted as a backreference to the RewriteCond itself), and then put in the trailing business.”
the [N] says “now restart the rewriting from the top again with the new string.” This is useful in case there is more than one + character, since each application of the RewriteRule only replaces a single character.
Next, I switched the contributed image-handling modules. I installed and configured IMCE, and made sure I could see all of the previous images. Then I removed and uninstalled Image and Image Assist, and related settings/data like the image gallery vocabularies, any remaining image node path aliases, and some leftover image records from the files table in the database.
Finally, I was ready to try the Drupal upgrade again. No problems this time
Many thanks go to all of the awesome Drupal developers who’ve contributed untold hours to the Drupal community!
As more and more of our clients and partners want dynamic web sites and the ability to update their own site content, we’ve been doing a ton of development with Drupal (content management platform) and WordPress (blogging platform), including four such projects under active development presently. (Stay tuned for details!)
This has meant bigger projects, and more collaboration with colleagues. To manage these complex software packages, we’re turning more and more to version control systems, which let us track all of our development in a thorough way, manage software patches and upgrades easily, and “roll back” to previous versions if there are any problems.
With WordPress, the switch to version control has been a breeze, and has let us manage WordPress’ regular software updates for clients much quicker than we previously could.
With Drupal, it’s a bit more of a challenge due to Drupal’s complexity and the huge number of configuration changes that are made through the administrative interface and stored in the database. But version control has still been essential to let us test and deploy Drupal in a sane way.
What does this mean for you? Version control gives us an efficient way to administer more dynamic web sites, meaning a smoother and less costly development and maintenance process. So if we’ve built you a static web site in the past, let us know if you think WordPress or Drupal might make sense for you. And if you know anyone looking for a dynamic web site or content management system, send them our way!
A friend of mine works for a public advocacy law firm that often represents disabled folks who are denied access to services in the physical world. He said he realized recently that his firm’s web site itself is not accessible to many of these same people! So what does “accessibility” mean on the Internet? It’s an issue we discuss with our clients often, so I thought I’d give our take on it here.
My friend was not too worried about his site’s lack of accessibility, saying essentially that the Internet was inherently limiting and it would be a fool’s errand to try to make his site available for everyone. But therein lies the rub… “Accessibility” in web development does not mean “how can I make my photography web site politically correct for blind users”! Rather, accessibility (combined with other concepts like writing semantic and valid code) is a set of best practices that will make your web site available to as wide an audience as possible.
Yes, these best practices will allow blind and visually-impaired folks to interact with your site as best possible. They’ll also help people like me who want to maximize the browser and jack up the font size late at night when their eyes are droopy, or actually print one of your web pages. And don’t forget these other goodies… they’ll increase your site’s search engine optimization, ensure that your site works optimally on the steady stream of new user agents (browsers, mobile phones, etc), and make your site easier to maintain!
In short, writing accessible code is simply good web development. It’s a symbol of the “new professionalism” that we are excited to provide for our clients.
