Standard spot for .CSS files?

I’ve just been wondering if it might be a good idea for MODx to have an /assets/css directory in the spirit of the /assets/js directory. It’s one of the first things I looked for when I installed MODx.

I know I can certainly put one there if I like, but having a standard default spot for .css files might save both casual users and MODx add-on creators a lot of time. When MODx newbies ask "where do .css files go?" I can imagine them cringing when they get the standard answer: "Anywhere you want." That’s not what you want to hear as a newbie.

Maybe it’s my imagination but the current .css files (and embedded <style></style> statements) in MODx and its snippets seem to be scattered all over the place with no conventions on where to find them.

Maybe there’s some good reason for not putting them in a central location that I’m not seeing.

Bob

MODx puts no restrictions whatsoever on your HTML, which includes the links in the <head> tags. And it never will. That’s one of the major points of using MODx; not being locked into any HTML structure.

It is customary, however, to have css files in the assets/templates/templatename folder.

As far as the assets/js folder, I seldom use it, I usually put any js file in my assets/templates/templatename/js folder. If I need js files for a snippet or plugin, I’ll put them in the assets/snippets/snippetname/js folder. This is to keep versions of various js files separated. I know my particular "whatever.js" file won’t overwrite someone else’s "whatever.js" file, breaking his snippet.

I tend to store the CSS files at the root level of the assets directory myself. That way paths to images are shorter:

I suppose that would be more convenient than having both css files and template-specific images in the assets/templates/templatename folder, but then I tend to have multiple templates on my sites, and just got into that habit to keep them organized.

All good points, but there’s a tradeoff between structure and flexibility and a difference between rules and guidelines.

MODx could, for example, suggest that users put their snippet code "any where they want," (and they could if they wanted to), but having the guidline of putting all snipppet auxilliary resources in the assets/snippets/snippetname directory saves everyone a lot of unnecessary time and aggravation.

I’m just suggesting that we might do the same for .css files with the same positive effect.

Bob

Very good suggestion Bob. Though I do think the "best practices" for CSS really depend on the type of site you’re building. Snippets/plugins/modules definitely make sense to suggest they go in your assets/snippets(or plugins or modules) directory indeed.

For Susan who builds a template showcase with multiple completely unique templates, sticking it all in the assets/templates/template-name/ directory makes sense. For me, I like to save a few bits when working on CSS files that get a bit intense at times.

Future versions of MODx will likely ship with fewer subdirectories inside of the main assets directory, simply because we don’t believe in prescribing a way to work, and also because we’re going to get rid of the image/file browser that needed so many subdirectories to work in the first place. In fact, future versions of MODx will be entirely configurable as to where your assets reside. We will have the ability to make purpose-specific "builds" of MODx, so a newbie-friendly build with some best practices in place for general sites probably makes sense indeed (including a consensus on "assets/templates/", etc.).

Quote from: rthrash at Dec 26, 2007, 01:24 PM

Very good suggestion Bob. Though I do think the "best practices" for CSS really depend on the type of site you’re building. Snippets/plugins/modules definitely make sense to suggest they go in your assets/snippets(or plugins or modules) directory indeed.

For Susan who builds a template showcase with multiple completely unique templates, sticking it all in the assets/templates/template-name/ directory makes sense. For me, I like to save a few bits when working on CSS files that get a bit intense at times.

That looks like a pretty good set of guidelines to me.

The only question left is whether there would be anything left to go in the root or in an assets/css directory. It sounds like any site .css would go in the /templates directory and all the rest in the respective snippet/plugin/module directory, no?

Bob

Quote from: BobRay at Dec 26, 2007, 12:59 PM

All good points, but there’s a tradeoff between structure and flexibility and a difference between rules and guidelines.

MODx could, for example, suggest that users put their snippet code "any where they want," (and they could if they wanted to), but having the guidline of putting all snipppet auxilliary resources in the assets/snippets/snippetname directory saves everyone a lot of unnecessary time and aggravation.

I have to disagree with any attempt to try and impose structure of any kind on MODx add-ons or external file dependencies, but let me explain a bit...

First, let me say that everything in assets should be, and will be site specific in the future. This isolation is absolutely necessary to build a shared layer of elements accessible to multiple sites via the core (i.e. a library). In these scenarios, the only thing that needs to live in assets are things specific to an element running in a particular site (i.e. cache files, etc.); the rest makes more sense in a reusable, centralized location (i.e. the model). It will be up to the developers to decide where and how to work with site-specific assets vs. making use of the now completely isolated MODx core or creating a totally customizable location for a specific add-on.

But the real issue here is one of installation, upgrade, and packaging of MODx add-ons. As developers learn to make use of the new transport package API’s in the upcoming releases of MODx, the location of add-on dependencies will become a total non-issue; it will be completely defined and maintained by the install/upgrade facilities. And xPDO makes it easy to define new "library" packages in the core/model location or in any custom include location an add-on developer defines.

Quote from: rthrash at Dec 26, 2007, 01:24 PM

Future versions of MODx will likely ship with fewer subdirectories inside of the main assets directory, simply because we don’t believe in prescribing a way to work, and also because we’re going to get rid of the image/file browser that needed so many subdirectories to work in the first place. In fact, future versions of MODx will be entirely configurable as to where your assets reside. We will have the ability to make purpose-specific "builds" of MODx, so a newbie-friendly build with some best practices in place for general sites probably makes sense indeed (including a consensus on "assets/templates/", etc.).

Clarification: the main core distributions will not contain an assets directory at all; these external file dependencies will be the responsibility of an add-on transport package to install. But as Ryan suggests, putting together custom distributions of MODx with a specific prescription for file locations will be possible with a MODx SDK distribution, if you still feel the need to impose a set of common standards in your deployments.

I don’t use the templates directory and probably never will. I think what makes the most sense is to mirror how you’d build it in the real world if it were a static site. I’d never use a css directory either for that matter, but that doesn’t make my way right.

Personally I’d like to see the assets directory for demo/tutorial/learning content overhauled along the lines of:

assets/
*.css (loose css files at the root level of assets/)
img/ or i/ or images/ (images)
js/ or j/ (optional for javascript)
media/ or m/ (optional for media including flash, .mov, .wma, mp3s, etc.)

I think I like the single-letters again just from the standpoint of saving bits, and they’re still very easy to figure out.

I started reading this post with one conviction concerning my best practice, but as I read the post a lot of interesting ideas have been brought up and I am rethinking my process. Very interesting.

I think what makes the most sense is to mirror how you’d build it in the real world if it were a static site.

I like this idea. Makes sense. But I can see reasons for doing it other ways and all being ’right’. So much freedom