Textpattern Support Forum

Here are a few ideas, some already mentioned, briefly, in the past, on txp-dev list and in my comment at the bottom of Bloke’s weblog post: On being a Textpattern developer. This are a bit “old” (have to revise if there aren’t better practices/techniques, or confirm if this are still good enough):

• Paul Irish’s markup based unobstrusive comprehensive DOM ready execution technique¹ on TXP admin side, helping plugin developers to keep their JS code tidy and sandboxed, and letting other plugin developers trigger/reuse already existing JS non-anonymous function, by having a big, extensible object literal $.TXP = {}. This could greatly improve the loading/rendering times of TXP admin side, when plugins begin to bloat them with JS. Also, I think this technique could play nice with that backbone.js thing that Bloke mentioned on Textpattern.com Weblog, if its implemented.
• a de-facto code standards² and
• a set of patterns³ for TXP backend, while trying to applying some concepts of
• the so-called OOCSS approach⁴,
• a good&simple grid system⁵, and
• a simple-but-reliable CSS reset with sensible standards⁶,
• while progressively adding some bits of HTML5-friendly markup.

— — — —

¹ http://paulirish.com/2009/markup-based-unobtrusive-comprehensive-dom-ready-execution/

² http://molecularvoices.molecular.com/standards/

³ http://developer.fellowshipone.com/patterns/

⁴ http://wiki.github.com/stubbornella/oocss/

⁵ http://www.1kbgrid.com/

⁶ http://sencss.kilianvalkhof.com/

My greatest recent discovery in the world of CSS comes from the Ruby world – the trio of Sass, Compass, and Susy. But, there’s no reason we can’t use these just because they are written in Ruby.

Sass makes writing CSS rules a lot faster and enjoyable. Both Sass and CSS files could be included with a Txp distribution. Just always work on CSS using the Sass files, while letting Compass “watch” the Sass file directory. This way, users can customize the admin using Sass, with CSS files replaced automatically as changes are made.

Compass includes a lot of common CSS design patterns so you don’t have to waste time re-inventing the wheel constantly, a big time saver and perfect complement to Sass.

Susy is a Compass plugin for making customized grids, with full control over padding and gutter / column width (no need to hack little changes into someone else’s grid to make it the way you want). It’s the lightest of any grid framework because there is no framework at all (just math) – it generates only the CSS rules needed to make your site look like it’s on a grid.

I guess none of this is really all that crucial to the next Txp admin, but just making sure everyone knows about these powerful tools. I wish I had found them sooner.

Last edited by aswihart (2011-08-10 20:23:21)

Phil — No, sorry if I wasn’t clear, CSS files are always the end result of working with Sass. You never serve Sass files directly and no one has to install anything to use the CSS files that were made using Sass.

I’m just saying, if Sass was used to build the admin, you could include the Sass directory containing the “source” files in the Txp directory. Sass is immensely cleaner and easier to read and understand than corresponding CSS. It is extremely helpful even for small sites, but obviously a bigger site would benefit even more so.

You only have to install Ruby if you personally want to customize the CSS using Sass / Compass. This takes all of a minute on a Windows PC. Otherwise you could just edit the CSS files directory like in olden days. Sass files can also be generated in reverse from CSS. Sass is not a replacement for CSS, it just makes writing CSS a lot faster and more enjoyable.

Again, just wanted to raise awareness of these optional tools. They have been around for some time, but I just realized what I was missing recently.

aswihart & philwareham

FYI, I’ve been suggesting (to Stef) the addition of a pluggable set of transformations to Txp for some time now.

The basic idea being that on save of any admin-side presentation element (page, form or style) there could be an optional transformation applied to it in much the same way that articles are currently parsed by one of Textile, nl2br or the verbatim (leave text untouched) transformation when they are published or saved.

If Txp had an extensible set of transformations (like text->HTML via textile or markdown, Sass->CSS or even Haml->HTML) then you could use tools like Sass not only for developing the Admin theme CSS but also for your site’s own CSS. You could use textile in your forms or have entire pages passed through some other transformation.

aswihart wrote:

Again echoing Phil’s thoughts, it wouldn’t be good to require people to have Ruby installed to do the automatic Sass -> CSS, Haml -> HTML compiling. I know there are compilers written in other languages, perhaps there is a good drop in solution written in PHP we could use.

I’m not sure about the compatibility of the various PHP implementations of Sass and Haml compared with the rather more active Ruby implementations — however, I don’t think a deficiency in PHP based implementations of those two examples would negate the usefulness of an extensible set of transforms. I also don’t see why a transform couldn’t make use of a Ruby component if it happens to be available on the system.

I think I was somewhat reticent in my earlier comments. Honestly I feel like modern webdev tools like Haml and Sass must be a part of Txp’s future to attract new users. They’re like the hot new toy all the kids are getting this Christmas, wouldn’t want Txp to be left out.

Making the set of transformations extensible would be the key (unlike the current fixed trio of options for the write-tab). In that way you could provide a PHP wrapper for almost any external transformations as they become available. So not only would you get to play with today’s new toys (if a wrapper is available) but you get to play with the newer toys that are yet to be published.

BTW, forgot to say that the write tab should be able to use any of the available transformations you have installed. So if you happened to prefer Markdown over textile, and had a markdown transformation installed, then you could use it.