cssSyndicate content

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.

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.