Themes / DRY?

XBleed

Working a bit on my own theme here and I have a slight concern. This is obviously easy to workaround, but I wonder if it's the way things are currently planned for: Garden, Vanilla 2, Conversations, and any other applications in the future.

The concern is garden.css, vanilla.css, profile.css, and conversations.css all contain styles that I think should be more "theme" / global based ( body, #Head, #Body, #Content, etc. ) which causes theme developers to repeat themselves multiple times, and would require a lot of (in my opinion) unnecessary editing when fixing bugs, or releasing new updates.

Is there a reason why body, #Head, #Body, #Content, etc are not in their own global css file that gets included across the entire site and all applications, and then applications can then have their own css file to overwrite / extend onto the global one? That way it is DRY (don't repeat yourself) friendly? If there isn't a reason, can I suggest that this be done with the default install?

Thanks, and thanks for this lovely framework. I'm really enjoying the simplicity of it all so far.

garymardell

Well with creating your own theme you could make a base theme and @import it. The reason they are repeated is probably to load fewer css files, so the profile page will only require the profile css file, and done as a feature. You can style the profile page completely differently to other pages and makes it clear what style will be called and override the other. For example if you had a base style and then a page specific stylesheet that needs to overwrite the basestyle, without doing !important you would not know what stylesheet is going to be called first.

XBleed

Thanks for the reply, I understand the benefit of loading fewer css files, but personally, I'd rather load one more css file rather than have to go in and alter the few right now, and possibly many down the road just to import my own.. Though that is the "easy workaround" I mentioned before.

I don't know, it just doesn't seem practical to have to use the same css code over and over in multiple files, rather than just include it once. I imagine that the caching of the separate files would / could cause some issues / conflicts down the road too, no?

Mark

I originally had a master view file, but the early adopters found it extremely confusing. It was much easier to give every application (and the profile/activity pages) their own css. The other benefit of this way is that it allows you to forget about styling the admin pages if you don't want to.

I realize it's somewhat cumbersome, but at least it's clear what you can and can't do right off the bat. I'm open to new ideas if people have any - but the underlying structure of applications with their own css files makes sense.

XBleed

@Mark - "I'm open to new ideas if people have any - but the underlying structure of applications with their own css files makes sense."

Absolutely, it does. I would not want that taken away. Since you're open to ideas, how does this sound:

One main file to rule them all, let's call it "structure.css" for now. From what I can tell, it would pretty much contain exactly what garden.css contains now by default, except I would @import not only reset.css, but also menu.css, and popup.css. Why? Because as default, Garden includes both of these files on every page, right? But what if someone developing a theme no longer needs menu.css? All they'd have to do is remove that one line from structure.css and they'd be done. Right now, and correct me if I'm wrong, they'd have to go in and alter several core files (I think core, since themes can't have their own controllers, right? I could be wrong on this, I haven't tested it thoroughly yet) to not include it, or just have an empty menu.css file that still gets included. I think since menu.css and popup.css have to do with Themes, they should be easily managed via themes, and not any of the actual programming.

Then we get to each applications css file. garden.css, vanilla.css, conversations.css, profile.css, etc would all @import structure.css. This way any styles set in structure can easily be overwritten depending on which application you are in, and then application specific styles would be placed within them natively.

Hopefully that all makes sense. I think that a setup like this would make themeing Vanilla / Garden a breeze, since themers would have 100% control over everything with just their theme folder. If this isn't all clear, I could quickly throw together a "Skeleton" type theme to give a better example?

el2ro

I do not master css very well and I just try to get something done. I have played few days with garden css stuff trying to get forum embedded in to my page / theme. It sounds great to have separated css files for all the application, but atleast the default theme is hard to tweak. Same setting are repeated all over again in many files and this is not good starting point to start tweaking your theme, atleast if you are not css guru. (I even found some copy paste errors from default theme to prove my point). I would not like to see any duplicate css setting in default theme. I would be nice to see base.css which has all the common stuff. Then common components like menu.css, panel.css. Then vanilla.css includes those and does some tweaks if needed. I even tried to build base.css, but seems like it is was a bit too complex already and it would take atleast 1-2 full days to build one up.

Second thing I would like to see is that vanilla/garded css files are "isolated" so that it would be much easier to embed Garden in to any web page. Now there are those base tags like H1, A etc which brakes the web layout you are using, could there be some othery way to define those to be more easier to integrate.

Mike.XIII

I haven't looked at the file structure or coding much, but I'd assume most people would want their entire site to have the same overall look and feel so there should be a master css file for which all applications inherit by default.
Then you should be able to have application-specific stylesheets that either add on to the master css file, or completely overwrite it to avoid having unused code. Maybe there could be a setting to choose when creating a new application?

I don't have much experience with these things, but I think this way would make it easy to reuse css without copy/pasting it everywhere, while still allowing completely different themes per application.

XBleed

@Mike.XIII - "I don't have much experience with these things, but I think this way would make it easy to reuse css without copy/pasting it everywhere, while still allowing completely different themes per application."

Absolutely, and that's my point here too.

@Mark - If you need any help with theme / css markup, I'd be more than happy to contribute. Not sure if it means much, but I do have over eight years experience with the web, and four plus years experience with semantic / tableless layouts.

Mark

It sucks, because I just changed it from exactly what you're talking about because people were saying the opposite of what you guys are saying.

Like I said, I'm open to changing it back. A couple of things, though:

Say you want to only customize the vanilla.css file so only vanilla pages are styled. You create a new theme, copy the vanilla.css into the design folder of your theme. Now your import is broken. So, you grab the main "base.css" file from the garden application, and copy it into your theme folder. Now you've got duplicated files. The vanilla.css will use this one, and the rest of the garden pages will use the other one.

It just keeps getting more and more complicated the more we separate them and apply themes. At least with the current setup, you know that everything in your vanilla.css file is the only thing that affects Vanilla pages.

Also, about your menu.css and popup.css imports - you could always create copies if those files in your theme's design folder and override them there as well - clearing them out if they're not necessary. Not the best solution, but it works.

XBleed

Dang, I posted a lengthy response but it must have been when the site was offline for a little while..

Anyways, to recap what I said, that's a good point and I knew there had to be a reason why the current set up is the way it is. I guess a solution to that would be to not use @import in the application styesheets since the pathing will just not work out correctly.

Let's say we have base.css, since it is theme specific, we could use @import (let's just say for example reset.css, menu.css, and popup.css). Perhaps the main master view should have a hardcoded tag in the Head for base.css, and then application stylesheets (which are no longer importing anything) would be loaded in after it with AddCssFile(); Or maybe AddCssFile() would work for adding the base stylesheet too? I'm not sure, I haven't looked into it that extensively yet.

Stash

Interesting conversation...
"Say you want to only customize the vanilla.css file so only vanilla pages are styled. You create a new theme, copy the vanilla.css into the design folder of your theme. Now your import is broken."

Sorry, not following why your import is broken (probably because I've not looked at the directory structure of Garden/V2). Unless, that is, the default theme isn't in the same (relative) directory structure as a normal theme. If so, why not?

Also, this made me laugh quite hard (what can I say, I'm a geek) http://vanillaforums.org/profile/import @import

XBleed

Your import would break because the url is no longer relative. The vanilla applications design folder has it's own reset.css file that vanilla.css imports. If you copy just vanilla.css, and not import, the @import no longer works cause it's reading in your themes folder, and not the application design folder. Same thing would go for images.. But I think images specific to that application should go in there, and I still think that styles specific to that application should go there. Nothing more, nothing less. The reset should be global / site wide, in my opinion.

I've set it up this way for my personal use. I altered applicatoins/garden/controllers/appcontroller.php to include structure.css (which then imports menu and reset (both theme specific files), then I've copied all the other application css files over to my design, removed the @import, and removed all the reused css code. It's much more beneficial to work with, but I am afraid when upgrades come out, I'm going to have to realter several core files... Unless, of course, this type of themeing system gets implemented. Were there any decisions made on this yet?

golampo

Best practice is to not use @import at all. It is most important to not use @import inside of another style sheet as it breaks parallel downloading of the files, which results in a slower load.
Detailed here: http://www.stevesouders.com/blog/2009/04/09/dont-use-import/

A few months ago I started a thread about a similar issue w/ Garden/Vanillas' JS files (I still think this should be looked at): http://vanillaforums.org/discussion/comment/94733/

My opinion about the CSS separation is that the option of global CSS files should certainly exist. This default file should probably have everything in reset.css, menu.css, and popup.css. In addition, there should be the ability to remove global styles for specific apps.

Mark

If anyone wants to take the dive at trying to come up with a better structure that keeps the "vanilla", "garden", "profile", and "activity" stylesheets, but separates all of the common stuff out to a "global" css file (or something like that), I'd be open to implementing that in the core.

Alternatively, you could create a theme with all of the css set up the way you think it should be, using imports for the time being, and submit that. I can then take that theme and implement it in the core, moving the imports out to standard link tags.

I was thinking of doing this myself so we could play around with some different scenarios until we find something we all think is good. But I don't have a lot of spare time lately, so it would be great if one of you stepped up to the plate...

XBleed

I pretty much already have this, but I'll need to make a few minor adjustments. I've altered the core appcontroller for garden (to include my structure.css file globally) though. Once I've cleaned it up a bit, I'll let you know. Thanks for taking this into consideration @Mark.

matt

Great discussion. I'll add my first few thoughts here.

Most people will be happy with the default theme, I think, but may want to simply brand it with their own colour—and perhaps logo—in the top left. How many blogs do you see with the standard Wordpress theme? Too many. It'd be great if people could avoid doing that with Vanilla as easily as possible.

I agree that splitting out the structure is the first step. But currently, the colour definitions are located throughout the CSS—where they are in a normal site build. And, of course, duplicated across all CSS files in as with #Head etc.

This means a simple "colour change" is a serious amount of work.

So I think it would be beneficial to break colours out into their own file. Of course, this would result in duplicate definitions containing only colour information but I don't think that's too big a deal these days. Servers gzip the files and you could even go so far as to automatically minimise/compress them in Garden if you really needed to. Perhaps going so far as introducing a pre-process step into the CSS–to allow "variables" and such–would be overkill? (Years ago I wrote a small Perl script to take one CSS file and split it into two - one for colour and the other for positioning, so I'll see if I can find that.)

If colours were broken out, things could get even fancier: you could pick a specific "main" colour, and then all other shades of that colour that are required for the default theme could be generated by Garden/V2. This would allow users to do a really quick brand/customisation of the default theme in seconds.

matt

> This means a simple "colour change" is a serious amount of work.

How much work? An hour or so.

I've just done a quick pass of everything and resulted in 85 lines or so of CSS (http://pastebin.org/12599) but which had to be appended to the end of vanilla.css, garden.css, profile.css, conversations.css and activity.css as well as having to duplicate reset.css (import breaks, see posts above).

Stash

An hour just to change the colour!? Wow, that's pretty bad IMO. Yes I know there could be a plugin written to make it "click, done" but it still... I actually quite like the idea of a colour style sheet Ah, if only I had time to burn like I used to.

XBleed, look forward to what you propose.

garymardell

There is a plugin to change the colour of the forum.

matt

A plugin that works with V2? Can you post a link?

el2ro

Matt: It comes with V2