REQUEST: Refinement Themes & Styles (add VARIATION)

TomTester

PROBLEM
I wish there were a method similar to the conf/language 'overrides' to allow for simple
'theme & style' overrides to the default theme (or any theme for that matter).

SUGGESTION
How about adding another level called 'VARIATION' which redefines some of the underlying
base style, but none of the main structure.

BENEFITS
Style developers can create multiple variations on one base style (think colors, widths,
fonts etc., see example below)

'Style' add-ons that aren't actually much more than color variations on the default template, such
as Vanilla Greeen, no longer require a full 'clone' of default vanilla.css and can simply be defined
as 'VARIATIONS' instead. This means 'less porting' of changes to the release-version of
vanilla.css files to default-derived styles.

IMPLEMENTATION
CSS is already 'cascading' , hence it should not be difficult to implement: we merely include the
CSS VARIATION code as the last CSS link in the header.

USER INTERFACE
User interface-wise we expand the drop-downs with one more (VARIATIONS), e.g.

THEME:
VANILLA

STYLE:
DEFAULT

VARIATION:
DEFAULT (LIQUID LEFTPANEL)
LIQLP (LIQUID - LEFTPANEL)
LIQRP (LIQUID - RIGHTPANEL)
FIX740LP (FIXED 740px - LEFTPANEL)
FIX740RP (FIXED 740px - RIGHTPANEL)
FIX940LP (FIXED 940px - LEFTPANEL)
...
etc. etc.

Tom

PS: if in the example above rightpanel were selected as a variation, the page HEADER would simply read:
<link rel="stylesheet" type="text/css" href="/community/themes/vanilla/styles/default/vanilla.css" media="screen" /> <link rel="stylesheet" type="text/css" href="/community/themes/vanilla/styles/default/vanilla.print.css" media="print" /> <link rel="stylesheet" type="text/css" href="/community/themes/vanilla/styles/variation/rightpanel.css" media="print" />

Mark

If you want to create a variation off the default style, just copy the template you want to play with into the /vanilla/themes/vanilla/ folder and edit it there. Voila - a variation.

Evic

wouldn't stylesheet be the variation? The way I see it - a theme is the HTML/XHTML structure whereas the stylesheet is the visual elements. I'm not sure there is a need for anything else... you either want to alter the visual elements so you make a new style or you are generating a different structure therefore it's obviously a new theme.

TomTester

OK. I see your point.

My remark was sparked by a the new rightpanel style Stash made... and his reticence to call
it a 'style' when only 20-odd lines had changed.

I then 'diffed' a bunch of styles on my system and noticed the following:
- Default Vanilla.css is 1500 lines
- The vanilla.css file for styles I compared(*) with the default version all differed less than
150 lines, and 80-90% of the changes were mere color palette changes.

The 'style variations' I suggested above (width, color palettes) would require the same or fewer
changes to the default file as Stash's right-panel did.

Hence, to me it made sense to separate REAL styles (i.e. significantly different from the default)
from mere variations on the default as a layered approach could limit the amount of post-release-
updates (the problem of course is where to draw the line...)

Anyway, no need to confuse things further. I just hope the styles I tested are updated to incl.
the new classes for account management, update check form and IE7 fixes.

Perhaps a better conclusion from my little Diff experiment would be to attempt the creation of
a new default-based style that's optimized to separate color from lay-out...

TT

(*) EuropeAfterTheRain, Cloud6, BlackAndWhite, Dizzy, B3SLite, Invader

Stash

When I was doing the right panel variation, I actually did it as an extension first! I thought about creating a "Style Variations" extension that literally allows you to do what you just suggested Tom.

The reason I backed away from this was because you're then mixing Themes, Style and Extensions together and everything becomes a shade of grey rather than the nice crisp black and white we have currently. I still kinda like the idea, but then it would be best to have a new category of Addon, something like "Sub-Style", or as you suggested "Style Variation".

Another strength of the existing method is that when a style is modified/updated, the variation doesn't get affect. Or is that a weakness - I can't decide...

Mark

All this gets me thinking about those guys who wanted to create a smarty-based template engine for Vanilla...

TomTester

@Stash: we must have been brothers in a different life ;-)

@Mark: is that a good thing, or does it give you more headaches?

Stash

Mark, do you think a Style Variation Extension would be a bad idea?

Evic

Wouldn't the best way to do these simple 150 line style changes be to make a new stylesheet with just those 150 lines and then include it via an extension?

Mr Do

I think the OP has a good idea, but I agree about keeping themes and styles separate. I have been editing the vanilla.css file to change some color around as I prefer the default layout, but just want a few visual changes. the variation thing would be perfect for me. I even posted earlier a question about how to best edit the css styles without ruining the actual theme/style one is using, and I think something like this could be the answer. (By ruining I refer to forward compatibility, and being able to upgrade to new version and keep changes)

TomTester

Stash/Evic,

Exactly, a StyleVariation Extension to enforce placement of the 'default style override'
CSS link all the way at the bottom of the linked styles list, should work, not?

e.g.
<link rel="stylesheet" type="text/css" href="/v/themes/vanilla/styles/defaultdefect/vanilla.css" media="screen" /> <link rel="stylesheet" type="text/css" href="/v/themes/vanilla/styles/defaultdefect/vanilla.print.css" media="print" /> [...] <link rel="stylesheet" type="text/css" href="/v/extensions/StuffDisplayer/style.css" /> <link rel="stylesheet" type="text/css" href="/v/extensions/StyleVariation/style.css" />

Krak

If Vanilla went this way you be taking about 90% of the current styles and placing them in this "variation" category. Your "variations" are styles. So your saying anything that causes minor changes such as color variations are no longer styles - to me that looks like most of the styles we have. Anything with small changes would be placed here? You would be turning the black/white into a nice bubble of gray. So if I took default vanilla and changed my colors to brown, I get a variation. But if I make it brown and change the width that now becomes a style? Doesn't make sense to me. Looks like repetition. Theme, style, variation? Style and variation are one in the same if you ask me. I guess I just repeated what everyone else said.

Mr Do

ur probably right krak..

y2kbg

umm i think that if it was seperate, if a new vanilla.csss came out all the stlyes , the way they are created now, wpould be obsolete and each change have to be made for the new one. The variation method would allow color AND width changes to be applied to an updated vanilla.css with minimal adjustments.

TomTester

Exactly, you get it Y2!

Krak, I'm NOT proposing to make ALL of the current styles 'variations' (though SOME however are just that...)

It's not that different from the HTML vs XML debate: i.e. do we separate STRUCTURE from REPRESENTATION.

Separating background images and color sets from CSS files seems like a good idea to me, especially since it
would allow *less experienced* users to change just the bare minimum to be "truly original" (something young
people seem to appreciate these days).

I agree it's somewhat muddy, so how about we define a VARIATION on a STYLE as:

"Small changes in the CSS that impact colors or background image elements (links only, not size), but
do NOT impact the original style layout (i.e. dimensions, columns, position, etc.)"

A style DESIGNER, could offer several COLOR VARIATIONS on the same STYLE (see original post) so we don't
have a glut of styles (VANILLA GREEN, VANILLA BLUE, VANILLA ORANGE) that ALL need to be updated when
the 'base style' changes (or IE8 is published).

We can settle for COLOR only like the drupal peeps did.

Check out the new advanced Drupal 5.0 themes where the theme color definition has become an interactive
experience (either pre-defined or custom color sets). Demo at http://blip.tv/file/141840

-
*edit: added link to drupal demo*

y2kbg

whoa thats sweet!!!!

Mr Do

Whisper TomTester: pssst. yea I agree with you :)

TomTester

Here's an approach that might just work (illustration only, other markers etc. may be better, should really have looked into Drupal implementation but did not):

STEP 1: 'VARIFY' the CSS

'Convert' the desired CSS template, into a VARIATION CSS TEMPLATE by replace colors and images with
'variable fields' of format $fieldname:defaultvalue$ e.g. (from Vanilla.css, line 98)#Header { background:#E5EAF6 url(waves.blue.gif) repeat-x scroll left top; border-bottom:1px solid #ACBEDF; border-top:1px solid #ACBEDF; }becomes#Header { background: $HDR_BGCOLOR:#E5EAF6$ url($HDR_BGIMAGE:waves.blue.gif$) repeat-x scroll left top; border-bottom:1px solid $HDR_BORDERCOLOR:#ACBEDF$; border-top:1px solid $HDR_BORDERCOLOR:#ACBEDF$; }

STEP 2: Stash or a non-self-proclaimed extension GOD (Mark, Jazz, et al.) will make an extension with THREE elements:

A. COLOR MANAGEMENT UI
- Parses our VARIATION-CSS for color fields & default values ($fieldname:defaultvalue$)
- Let's us CHANGE these values from default to whatever color we SELECT using the JQuery color picker
- STORES these the fieldname/newvalue in the database

B. IMAGE MANAGEMENT UI
- Parses our VARIATION-CSS for image fields & default values ($fieldname:defaultvalue$)
- Let's us CHANGE these values from default to whatever image we select using a JQuery image picker/uploader/cropper/resizer (fixed size equal to old image)
- STORES these the fieldname/newvalue in the database

C. CSS-INSERTION AND PARSING
- INSERTS a VARIATION-CSS' CSS-link as the last CSS link in the header, e.g. <link rel="stylesheet" type="text/css" href="/v/extensions/StyleVariation/variation-css.php" />
- Variation-css.php, retrieves custom color/image settings, inserts into our 'varified' CSS TEMPLATE, and returns it as a CSS file (on-the-fly or cached)

Notes:
- In the example above ONE variable ($HDR_BORDERCOLOR) is used in TWO places. For more variation, we could have inserted $HDR_BORDERCOLOR_TOP and $HDR_BORDERCOLOR_BOTTOM
- I suspect that converting a CSS template to a VARIATION CSS TEMPLATE *could* even be automated... (parse CSS file, look for color values or images, e.g. #FFBBCC, replace color value or image with $fieldname:defaultvalue$, e.g. $COLORFIELD[44]:#FFBBCC$, etc. etc.).

Whoo... me likey... if we add the image thing (not required at first) then we out-class even Drupal!

Mr Do

i so torn.. I both want what you want TomTester, but I also see the point of the adversaries (!). However, due to the lack of enough style variations (no pun intended), and relative complexity of changing these things (colors and bg img) without proper knowledge of css,html AND vanilla, and the problem about forward compatibility that first drew me to this idea, I support your suggestion. I'll help however I can, but I dont know enough to make it myself.

TomTester

Of course I see their point too, but I hope they see the 'compromise' of an elegant but simple 'variation plugin'.

What I proposed originally (extract parts of the CSS, store variations) is not what I ended up with (i.e. take an
existing style, make parts of it variable as fields, store the values for those fields variables). The END RESULT
could be almost the same however, allowing for more variations, more user control, easier upgrade paths, etc.

This 'VARIFYING' thing I just pulled out of my *** should really make things easier... (EXISTING STYLE conversion
is a mere smart REGEXP GREP away).