Goals, features and implementation of the module

Hey katris,

I totally agree, CSScaffold should really use namespaced classes, that would help a lot. Maybe we should speak about this with the author.
I did not find any module that could cause conflicts, but that could happen, and IMO that's a sufficient reason for avoiding this approach (that is, as long as classes are not namespaced). But I agree that being able to control the $config values is useful, to say the least.

In short, having control on the library is ideal and way better, but those damned classnames make it risky like this. But I am confident we can find a solution, and the more I think about it, the more I think we really need to be able to control the parser directly finally.

So to summarize our options for this issue :

• Convince the author to namespace the classes.
• Let CSScaffold live its life in a separate context and let users configure it through the config.php file.
• Use the light bootstrap technique, but that would mean a constraint around the path of the library. But that could be an acceptable compromise. For now, it is the best option in my opinion.
• Keep your approach, with the risk of classnames clashes.

I attached my own version of the module, which uses the second approach, so you can see how I did it. Aggregation works fine with both regular stylesheets and CSScaffold stylesheets.

About the ugly hook_preprocess_page and $vars['style'], we do not have an alternative, so that's the way to go, unfortunately ;)

There are other things we could consider that I implemented in my version of the module :

• Showing errors returned on CSScaffold parsing, with my approach it is hacky, but using the library itself it would be more elegant since it is possible to get the response of the parser (I did it first when I had the same approach as yours).
• Support the libraries module.
• Let themers add specific css files for CSScaffold in the .info file :
  csscaffold[all][] = "css/style.css"
  csscaffold[print][] = "css/print.css"
• Let module developers add CSScaffold files using csscaffold_add_css().
• Another issue I found is that with CSS files that have the $Id signature, CSScaffold thinks it is as constant and does not find its definition, so as a workaround I added a file with this constant defined. With control over the library, this could be more elegant than this trick.

What do you think ?

If you want to add me as a maintainer, I'd be glad to help.

...And I'm a big fan of CSScaffold as well, such a brilliant thing, with hidden and undocumented treasures !

I realized that Scaffold has been updated since I wrote the module, so it won't work. It's really hard to follow its development, moving so fast. Anyway, my comment above still stands.

That's the version I am talking about : http://github.com/anthonyshort/Scaffold/downloads. It seems the author started another rewrite. Damn ! Your module won't work either with this version, since the whole bootstrapping and parsing methods have changed. I'm trying to adapt your code to this release, but I'm not sure it's worth trying if the author keeps working on what seems to be a new version ? (It is tagged 0.0.8 on GitHub currently, and last commit was on 2010-06-26).

I am totally lost :
http://github.com/anthonyshort/Scaffold
http://github.com/katris/csscaffold
http://scaffoldframework.com/ - does not work !

Damn it !

About the versions, on github the author says :

Scaffold is being rebuilt from the ground up. The core has been finished, and the extensions are well on the way. Without extensions, it will parse a CSS file or string, cache it and send it to the browser gzipped and with all the proper cache headers.

I have been using the module a little, had some issues and some more thoughts. I renamed the issue here since its scope goes beyond the initial discussion. Issues will go in separate issues.

Here is a summary of all the features I can think of :

• Implement a light bootstrap to be able to configure Scaffold while preventing potential clashes of class names.
• Integration between Drupal aggregation and Scaffold.
• Implement hook_preprocess_page in a way that lets theme developers and module developers use it to add or remove stylesheets before they are actually parsed by the scaffold module.
• Let Scaffold generate stylesheets on the fly without writing files when not in production mode.
• Support subthemes. This is a nasty problem. If you define a theme and then a subtheme, unfortunately the stylesheets of the base theme will be completely separated from its subtheme and thus we won't benefit from variables, mixins etc. defined there. That's a big challenge, but I think it's possible.
• Showing errors returned on CSScaffold parsing in messages.
• Support the libraries module.
• Let themers add specific css files for CSScaffold in the .info file :
  csscaffold[all][] = "css/style.css"
  csscaffold[print][] = "css/print.css"
• Let module developers add CSScaffold files using csscaffold_add_css().
• Work around the $Id signature.

BTW, I don't think a global switch for parsing themes stylesheets and module stylesheets is useful, since if module developers want to use scaffold stylesheets they could use csscaffold_add_css() and theme developers could use the .info file.

What do you think ?

And ehm, are you still around ? ;)

I finally used my old version of the module, which uses the same approach as yours (that is directly calling the Scaffold class), but is not configurable yet (and is still very rough, but works well). Here it is.

We should merge our modules and join our efforts to try to make it feature complete.

Hey katris ! Great to hear from you again.

Thanks for adding me as a co-maintainer, this will help to move things forward together. I've got a lot of professional work here too, but since Scaffold is an important part of the project I'm currently working on, I should invest some time on this.

I totally agree with your thoughts on the "module suite" thing. There are definitely good things that can be done around Scaffold that fit with the Drupal way of doing things. The ability to implement hooks to extend Scaffold is particularly valuable, I thought about this when I wanted to add "functions" to Scaffold processing. Another thing that I came across was conditional stylesheets for IE, having separate stylesheets is a problem with Scaffold. But I'm afraid there is no ideal solution for this - at least when you want to reuse existing mixins, constants...

Let's take some time to think about all this, I'll come to say hi to everyone at Treehouse on the IRC chan some time ;)

Ok ! I just commited a complete rewrite of the module to the CVS repo. It should be available as a development snapshot soon.

I had to remove and re-add the files to add keywords marking to the files.

Lots of things added / changed :

- Settings have moved to their own page.
- Constants can be set through the UI.
- Compatible with base themes.
- API to add Scaffold stylesheets through a function : scaffold_add_css().
- Ability to add Scaffold stylesheets from the .info file of the theme.
- Ability to call Scaffold files through an URL.
- Compatible with the libraries module.
- Displays parsing errors.
- Aggregation is handled differently. Should work fine with theme files, module files, with aggregation ON / OFF, with or without preprocessing.

Read README.txt for more information.

BTW, reviews are welcome !

I am currently playing with lastest version of Scaffold (the ongoing rewrite), and good surprise, all classes have been namespaced !

Setting this issue as fixed.