A CSSEdit AutoCompletion.plist of my own

by Adrian 16th Dec, 2009 @ 17:37

I came across Andy Ford's modified AutoCompletion.plist for MacRabbit's CSSEdit today, and not being entirely convinced of all Andy's modifications I decided to make my own.

The main differences are: I've moved the browser specific and CSS3 properties into their own sections, added a comment above each of those sections and removed the font-family values. Generally I add font stacks from an external source like code style's font stack builder, so these font names make no sense to add, especially without spaces (that's just asking for trouble)!

But thanks go to Andy for writing up the tip, it's a handy addition to CSSEdit while we wait for MacRabbit to finish playing with Espresso and get around to updating CSSEdit.

Attached is a patch file with my modifications to the original AutoCompletion.plist.

CSS sprites using Imagecache and ImageMagick Raw Action module

by Adrian 30th Nov, 2009 @ 16:04

A question in one of the Drupal IRC channels recently reminded me to write about my ImageMagick Raw Action module (im_raw) and its ability to generate CSS sprite style images from uploaded image files. This is not a recipe for a whole site CSS sprite containing all icons and backgrounds used, but a way to process a single uploaded image and append that processed version to the original.

ImageMagick raw action also opens up a wide array of potential visual effects driven by ImageMagick to be used in CSS hover effects in galleries or anywhere else you use imagecache presets. Read more »

Desktop Clock with Geektool 3

by Adrian 6th Aug, 2009 @ 15:05
There may not be many posts on this blog but one of the most popular has always been “Desktop clock with geektool” (possibly because Google directs people here looking for actual physical desktop clocks, but still).

Howto install PECL uploadprogress indicator for Drupal on Ubuntu 9.04 (Jaunty)

by Adrian 18th Jul, 2009 @ 22:25

I installed the PECL uploadprogress PHP extension on my Debian Lenny development server for the Drupal filefield module just before Psynaptic's excellent Read more »

Living with Opera 10 alpha, leaving Opera 10 alpha

by Adrian 17th Jun, 2009 @ 22:54
In “Why in the world would one not use Opera 10?” Joe Clark lists three reasons why he won’t be using it, and I can’t resist adding some of my own.I’ve tried so hard to like Opera over the years: I spent time tweaking the UI so I could avoid tabs on top[1] and I’ve tried out several Opera themes in the hope they’d make it less ugly.Recently despite being disappointed by Jon Hicks ‘lipstick on a pig’ redesign of the Opera UI[2] but prompted by Opera 10 alpha’s speed, I tried it as my main browser for a week. It’s fast – but speed alone is not enough.My main frustrations derive from the lack of a plug-in/add-on feature, I’ve grown used to easy login via 1Password, tidy downloads via Speed Download and easy access to delicious for bookmarks. These all work in the other browsers I use on OSX, but not Opera, because it has no support for third party integration at all.Opera is in something of a tricky position, it has a core of users it doesn’t want to annoy by say, completely redesigning the UI, but it can’t attract large numbers of new users without doing so. It also seems somewhat distracted as a company, apparently prioritizing projects like Opera Unite over a plugin system for the browser.There’s hope yet. Opera 10 alpha’s ‘presto’ rendering engine is fast and has good support for web standards. If they can do better with the UI[3] and add support for 3rd party plugins they might just make me an Opera user yet. In the mean time Opera has once again been removed from my dock and put in the ‘open only for site testing’ folder.Opera 10 alpha: great rendering engine, poor browser.
  1. Though since using Google Chrome I’ve grown to like tabs on top, done right.
  2. It is much better, but it needs a complete reworking, not incremental improvements.
  3. Surely they’re not going to limit Jon Hicks to polishing? It’s like hiring Michelangelo and asking “just give it a lick of paint would you? Nothing fancy, maybe white or magnolia.”

Drupal markup: redundancy vs dependency

by Adrian 16th Jun, 2009 @ 16:13
I attempted to respond to comments on Moshe Weitzman’s blog with a comment, but it looks like it didn’t post, so I’ll elaborate here instead. Moshe made an excellent post detailing some frontend designer complaints about Drupal markup “Highlights from Design 4 Drupal” and some of the constructive attempts to improve things such as Studio theme, Skinr module and the 960 theme. The following comments however seem to be bitchy and ill informed, and even downright hurtful (see Merlin’s post “views-panels-economy-of-front-end-code-and-classes-and-namespace”).Now I love clean light semantic markup as much as the next code nazi but the comments by peach of alldrupalthemes.com and Christopher Calicott seem to stem from lack of experience and ignorance.”…because core output functions are so easy to override, but mainly it’s Views that outputs terrible code” – peachViews is just as themable and easy to override as core, if not more so.”To be honest, I never really got the developers’ confusion or reluctance about economy of code for front end” – Christopher CalicottDrupal developers aren’t reluctant, they like light code, and it’s not developers that are confused – it’s you Christopher, you’re just not seeing the big picture of code running on thousands of sites, being used by people with varying levels of technical expertise.”I would love to help out with cleaning it up if someone could guide me through the backend process. Same goes for panels.” – peachI’ve overridden views many a time only to find that I end up adding back so many wrappers and classes I might as well have not bothered in the first place. All those divs and classes are there for a reason. To assume that you can easily ‘clean up’ the markup used on tens of thousands of sites whilst simultaneously admitting that you have no idea of the backend process is either extremely naive or massively arrogant – quite possibly both! It’s easy to take one site and craft light semantic markup, doing the same for ten thousand sites at the same time all with different content…? Try to keep everyone happy and you’ll end up with a generic kitchen sink approach, there’s no other way.For me this is part of a larger debate, covered by Dave Shea’s post Redundancy vs. Dependency which deals with CSS but could be applied to markup and even programming code. Views markup is very redundant (and that’s a good thing for views.module to be) whereas you’re looking for highly dependent markup (which may well be a good thing for a specific site or theme) there is always a tension between the two.As fun as it can be to bitch about about things it’s really not constructive. So please, lets keep it nice and keep working towards constructive solutions.


by Adrian 29th May, 2009 @ 13:21

I’m joining technorati, here’s my Technorati Profile.

Typekit: another half-arsed attempt at getting a wide range of fonts on the web?

by Adrian 29th May, 2009 @ 10:34
Web design guru Jeffrey Veen has just announced Typekit, a Javascript based technique for embedding fonts in web pages backed up with a licensing and hosting platform that will apparently keep type foundries happy. Judging from the comments a lot of designers are pretty damn excited, drowning out the few dissenters questioning the technical approach.Typekit remains vapourware for the moment, but the fact that it’s based on Javascript is not a good omen. Systems like sIFR and Cufon can cause problems for screen readers and even break basic copy/paste of text. It’s hard to see Typekit doing much better – at the very least Typekit will fail for users with Javascript turned off, and will likely suffer occasional namespace issues with other scripts embedded in a page with the result of much cursing and hair pulling by web developers.All of these technical approaches to embedding fonts – sIFR, Cufon, Typekit – are very clever but complicated and inelegant. And inelegant solutions frequently break. We already have a simple and solid solution to font embedding for the web: @font-face property of CSS2. What’s been lacking is browser support, however sometime this year Safari, Firefox, Opera and Chrome will all have support for @font-face leaving the usual laggard, Internet Explorer, as the only exception. When Microsoft manage to add @font-face to IE the technical side is solved.But Typekit isn’t about the mere embedding of a font in a web page, it’s about licensing. The type industry lags even the music industry in its adaption to a world where the internet exists. Despite the huge demand from web developer/designers only a few foundries have taken the plunge (listed on the webfonts wiki) and developed a proper font license for the web. The rest steadfastly refuse to enter this market, instead they seem intent on yet more complicated technical solutions (see “Real fonts on the web” at ALA including discussion of permissions tables and new font formats) that amount to DRM for fonts.Such technical solutions will of course be circumvented and those that steal fonts will continue to find it just as easy as they do now (google for “fonts torrent” to see just how easy). It’s hard to see how @font-face will increase the problem of font piracy even a little. The major type foundries need to get there collective control freak knickers untwisted and realize that:
  1. @font-face embedding isn’t going to increase font piracy by any significant amount.
  2. Complicated technical DRM solutions will cause problems for web developers and be rapidly circumvented anyway.
  3. There is a huge pent up demand for proper licensing of fonts for the web which they are failing to make money on now.
Web developers and designers want to see two things happening right now, firstly Microsoft needs to announce that @font-face will be supported in IE sooner rather than later, and secondly all major type foundries need to draw up proper licenses for the web. It’s that simple.I suspect Typkit will be moderately successful in the short term but wither when a large font foundry finally realizes it can make more money licensing the fonts for web use properly. It will be sad if Typekit delays the inevitable day when font foundries wake up to the fact that they have everything to gain and nothing to lose by supporting @font-face.