[development] let's cleanup /misc

vlado vlado at dikini.net
Fri Jan 6 10:47:10 UTC 2006

Replying to myself?

> * get rid of misc/ - in favour of 
>     - sites/all/themes/all/js
>     - sites/all/themes/all/css
>     - sites/all/themes/all/css/images
>   the disadvantage of this is the directory depth both to type and to
>   see in browser, the latter can be remedied in code 
It just occured to me that http://drupal.org/node/13095 will be made trivial
in this case. Which will probably as well reduce the drupal.css hit on
webhost traffic.

Earlier I made an experiment with splitting the drupal.css file into
logical (for me) parts - color.css, framing.css, typography.css,
icons.css and would say that it improved the maintainability and theme
development. It was easy to find what do I want to change. Maybe it's
me, but it is definitely a nightmare reading/editing/understanding huge
stylesheet files.

So implementing if xyz.css is not  in my theme directory then load the
default xyz.css will work fine. As a plus it removes redundant css code,
simplifies the css dependencies, removes the need for dirty css hacks to
override drupal.css defaults. The negative side is that a designer will
always need to start with a copy of the default css file.

> *  */vendor  is a worthy contender to consider - this way we won't mix
>   drupal and non-drupal code too much - this will be easier to upgrade
>   but otherwise I don't have an idea on all implications
> * Although I use something like the suggested public/private separation
>   already, I would NOT make it the DEFAULT - it is not for the faint
>   hearted, it needs an installer for the majority of people. I have
>   sets of shell scripts to do the maintenance here, but for an average
>   webhost that is not good. It can be implemented with an installer.
> * I wouldn't touch the css bundling with modules now - it is too
>   complicated to achieve, but I would put it in the longer term
>   TODO - having all css files in one location is logical, it is easier
>   for the designer, it will be easier to handle within the theme
>   engine the selection of which css files to include - for example
>   a custom event.css for your carefully crafted theme- How would you 
>   do that with the current layout?

More information about the development mailing list