Theming for the future

Involved Joined: Sep 15, 2008 Posts: 352

I'm ready

Theme Guru Joined: Jan 11, 2006 Posts: 170

An example of what Raven is seeking would be:

<table cellspacing="0" cellpadding="0" style="background-image: url('themes/whatever/images/back.jpg"); background-repeat: repeat-x; border: 1px solid #000; width: 100%; height: 250px;"><tr><td>

or external css:

<div class="container"></div>

.container {
position: absolute;
top; 5px;
left: 0;
border: 2px solid #000;
background-image: url('../images/back.jpg');
background-repeat: repeat-x;
width: 100%;
height: 250px;
padding: 0;
spacing: 0;
}

Posted: Fri Feb 06, 2009 7:59 am

If it was me I would still use a class or id with the table instead of the inline way. This way all the css attributes are in the css file and doesn't crowd up the code.

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

Moving to CSS themes is a good idea, but it requires standardizing the classes for the different components (e.g. block header, block content, block footer, etc.). That should address papamike's valid concern that we need to define the direction we're heading and specifically state what has to be in a theme to be an official RN product.

On Smarty: I read the same book that Raven read and have the same opinions.

papamike is correct: the transition to new themes must not break all the old themes that attracted many users in the first place. But it doesn't have to. We can leave the bgcolors there for old themes and define the standard CSS classes for those that use CSS.

papamike wrote:

Why not give the Your Account area a facelift it desperately needs one and the admin area too?

I know this is off topic, but we're working on improvements to the Your Account profile and Nuke admin area, and the registration and the Your Account admin was recently improved with RNYA. What else did you have in mind?

Posted: Fri Feb 06, 2009 9:08 am

Sometimes if you just sit here quietly others will say what you've been thinking. I've been involved with themes for Ravennuke for a couple years now. I started out not understanding the importance of maintaining compatibility and I was all for just breaking with the old approach and developing a new "architecture" that made more sense. However, working as a support moderator here over the course of several releases made me realize the extent that older and third-party themes are built in and how much "business" we would lose if we obsoleted those. So, I have to agree with Papamike and later Kguske that we need to (and can) maintain compatibility.

Now let me add a couple more things that we should look at:

1. Many of the functions in the current RN themes are duplicative or at the very least largely overlapping. Look particularly at themearticle and themeindex withing the themes that come in the RN package. They are at least 90% the same code with idiosyncratic differences that really don't add any value. I believe it would be possible to "abstract" the similarities to one standard themearticle and themeindex that would be in /themes. Then let the individual themes override the presentation aspects through CSS (or code if necessary). Most likely we should have a standard for the presentation of news article both on the home page (title --( bolded) author, date, posted, content, comments ) and let the theme choose the colors, whether there are surrounding graphics, rounded corners and the like. I think it might be possible to totally eliminate the need for themearticle and themeindex functions within the individual themes -- and by doing that you'd eliminate a ton of unnecessary code.

2. The same thing could probably be done for themefooter. Just have one themefooter function in the whole /themes directory and have it use styles that are individual to the different themes, where presentation differences are called for.

3. Virtually every site customizes themeheader. We ought to write a new general purpose themeheader that recognizes that. For instance have the site's logo.gif file name be determined in preferences (settings) and be modifiable without touching the PHP code. Likewise, everyone wants different "shortcuts" going across the top line of the screen below the banner. Allow these to be customized and changed without altering PHP code and also to not be overwritten every time there is a version upgrade.

4. This has been posted elsewhere but if you look at the css files in the various theme directories you will see that they are mostly (90%) duplicative. We should have 1 /themes/css file which contains the common styles then override within individual themes as necessary. If the "content" class is 10 points for instance in the standard and Karate needs it to be 12 points, let it override. That's what "cascade" stands for. This way the /themes/style.css file could essentially be a library of styles that a theme designer could consult with and use.

Posted: Fri Feb 06, 2009 9:52 am

fkelly,

I agree 100% Compatibility for the old and new. I love the 4th part... Genius!

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

I believe that in-line styles should be used, if at all, very sparingly. I know that due to CSS anomalies you sometimes need to use them, or do you? Most all can actually be done w/o in-line styles. It's much easier for maintenance.

The majority of all the CSS should be contained in external css files and included as needed. We should have, as Franks' #4 above states, a universal type sheet and then modifiers as required by the individual themes/tweaks, etc.

I use this analogy and I am neither an artist nor a PhotoShop user. My reference to PhotoShop is strictly as to the layer methodology utilized. But most every Saturday for many years my wife and have followed a (now deceased) oil painter name Bob Ross, an oil painter, on The Best of The Joy of Painting show. The first thing he does is to prepare the canvas. Most of the time you don't even detect the colors that he has already used; the canvas looks white. Then as he adds different colors, shades, highlights, the undertones may or may not affect the newly added over painting. That's how I envision, in methodology/theory, a theme system.

We have a universal type CSS, ie, a primer. It's preparing our theme for what's to come. Maybe in structure, layout w/wo color tones, etc. That's layer 1 (or overlay 1) as an example. Then perhaps we build the left navigation column - the blocks/navigation layer. Now, each block may have its own CSS or there may be one CSS for the entire column. Those would be overlay 2 (the left column). Now, if we only wanted a 2 column theme then we would load the content layer (overlay 3). And so on. The principle of inheritance/cascading would apply each time. I left out the header/footer but you get my idea. Now we have built the outline and we now add the containers - divs, tables, paragraphs, etc. and assign the styles to them - another layer. Then, finally, the content, whether from a database or free text - a final overlay, perhaps.

Please note that the above is not necessarily the actual order of presentation. My point is that I feel a layered approach will be much easier to maintain and understand.

Over simplified? Not really in my mind. HTML5 may/will have a canvas element that will add some greater possibilities to all this (I suppose). But it's not treally on the horizon so we have what we have.

Posted: Fri Feb 06, 2009 10:50 am

I like the idea Raven.

registered · Posted: Fri Feb 06, 2009 11:28 am

(I am at work right now so this will be a short response, I will read more and reply more later tonight hopefully.)

I will try to touch on all of the points brought up in this thread, so if I miss something please remind me.

CSS Styles and CSS Layouts are NOT THE SAME THING and should not be confused.
Styles should be used in both table and table-less themes, this makes it easier to change fonts,colors, backgrounds etc all from the style.css file.
No color should ever be hard coded into any module or block, the only thing that should be coded is the class="ThisStyle" so that the site owner can then say that ThisStyle font color should be blue,red, purple or whatever without having edit a php file.

Css Layouts are similar to the styles I talked about above but they go a step further and replace the tables in a theme with divs,paragraphs, spans etc
These are also controlled by the style.css file and allow the site owner to change his layout by just editing the style.css and NOT having to be a php guru to make a layout change.
This is where the module and block creators should just uses div's and paragraphs with a class="MyModuleDiv" or class="MyBlockDiv" so then the site owner can change the layout and styles with the style.css and not in a php file in the module.

I am a strong proponent of using CSS for both style and layout, but I am not one of the people that tries to force someone to not use tables, (tables validate W3C too)

Now I would also strongly suggest that if you are looking to go the route of using a theme system then download the AutoTheme module and give it a test on your machines. I will also supply some theme examples to anyone who wants to test it out.

AutoTheme basically takes plain HTML files and turns them into working themes for Nuke based sites. There are literally thousands of themes out there that with small tweaks will work on any AutoTheme capable nuke system. So that right there adds a TON of themes to the RavenNuke system right off the bat.
The other nice thing is the regular theme system doesn't get replaced, so any existing theme will still work without needing to be modified.

You can do full XHTML compliant themes, table-less, tables, etc
I can provide both types for people to look at and test. Just ask.

More to come...

Posted: Fri Feb 06, 2009 1:00 pm

Raven: I believe that in-line styles should be used, if at all, very sparingly. I know that due to CSS anomalies you sometimes need to use them, or do you? Most all can actually be done w/o in-line styles. It's much easier for maintenance.

I say a big no.... to inline CSS styling .. That's the old way and it kinda brings up back to the beginning with the variables that are already present. All css attributes should be editable from one file away from the modules, tables etc...

If anyone has an example why you would use it over classes then please show me.

Just my 2 cents Very Happy

Posted: Fri Feb 06, 2009 5:19 pm

I started looking around and just noticed that this thread is being discussed by admin's and moderators. I hardly ever come to the forums here so I think I'm out of my league. I don't have anything to do with the inner workings of RN so I'm really not in a position to add my input here.

I'm going to bow out of here. I design themes and have a theme making utility but that's about it in relation to RN. I do design/code applications which have nothing to do with RN.

Posted: Fri Feb 06, 2009 6:48 pm

You have already made a substantial contribution to this discussion Papamike and anything further you want to add is welcome. The admins and moderators on the RNteam are stretched thin and welcome any knowledgeable input from contributors such as yourself.

Posted: Fri Feb 06, 2009 6:51 pm

papamike: This is an open forum and anyone can throw in their opinion Wink

Alien73,

Not sure if you're agreeing or disagreeing with me Laughing

. So just to be clear, I am saying not to use inline styles unless there is no other way due to a limitation of the CSS version and/or a browser (version) limitation. So there could be a valid reason for using them. Also, in regard to your statement "If anyone has an example why you would use it over classes then please show me." and just for clarity, you only mention "classes". Style sheets use classes and ids. Both are valid and have their place/use. I just didn't want anyone getting confused with the delineation of in-line style and style sheets (classes and ids).

Posted: Fri Feb 06, 2009 6:54 pm

Still at work but I forgot to mention that AutoTheme gives you complete block
control as well as a whole list of other features including unlimited block positions, not just left center right.

Posted: Fri Feb 06, 2009 7:01 pm

Mars,
How dare you place work over RavenNuke(tm) killing me

Seriously, thanks for taking time to let us know you'll be taking time (sorry, couldn't resist) to respond when you get home. Drive carefully Wink

Posted: Fri Feb 06, 2009 8:11 pm

I know I know.. I really do wish I had more time to commit to here and my site, my job got transferred out to PA a little over a year ago to help open a new location.
This has had me super busy working long days for the last year. Sad

I am always open to help in any way I can with RN and themes, I think I summed up my thoughts in my earlier post but if there are any questions or comments I am all ears Smile

Posted: Fri Feb 06, 2009 11:09 pm

papamike wrote:

I'm going to bow out of here. I design themes and have a theme making utility but that's about it in relation to RN.

That's no small thing! And it's why we really value your input on this subject.

Posted: Sat Feb 07, 2009 4:17 am

mars, when you talk about Autotheme, are you talking about the full commercial version, or the lite version?

Posted: Sat Feb 07, 2009 6:26 am

mars wrote:

Still at work but I forgot to mention that AutoTheme gives you complete block
control as well as a whole list of other features including unlimited block positions, not just left center right.

Taking that one step further...........
Beauty and functionality are in the eye of the beholder. What might be your perfect layout/design might not appeal to everyone so at some point in the future it would be really nice to use other technologies like ajax to allow site users themselves to select which blocks they want active and where they would like to place them on the page.
Lets take as an example a Cycling website - you might not want to go to cycling club meetings but want to keep up to date with the latest cycling related technology and news. The user would find your site far more 'sticky' if they had the ability to disable or move center (up) blocks containing meeting events out of the way and replace theme with say an rss feeds block for cycling news etc.

Of course the webmaster should retain full control over what content he/she wants to provide but the end user should be able to select and position the data they want, where they want it if they are going to get the most use out of your site.

Posted: Sat Feb 07, 2009 6:33 am

The BBC website is a good example: http://www.bbc.co.uk/

Posted: Sat Feb 07, 2009 6:42 am

That is an excellent example, thanks!

Posted: Sat Feb 07, 2009 7:57 am

jakec wrote:

mars, when you talk about Autotheme, are you talking about the full commercial version, or the lite version?

Both actually, I use the Pro version because I like to support Open Source, but the free lite version works the same way.

The only difference is the Pro version has caching builtin for sites that want to use it.
The author Shawn also just patched it to support RN 2.3 as well.

Smile

Posted: Sat Feb 07, 2009 8:04 am

Cool, I downloaded the Lite version and had a play. There were a few $dbi in the code, which I guess is what Shawn has changed in the patch to get it to work.

The way it works is very similar to what I was saying before about taking a HTML template at adding in tags such as {module}. Except the tags look like  I don't know why I didn't look at this sooner. Very Happy

Posted: Sat Feb 07, 2009 9:36 am

Yep

I have been trying to get people to just give it a chance and they will see how great it is. Wait until you get into the more advanced features like block placements, custom pages for each module, theme based on what the date is, alternating summaries, etc etc. There is a ton of features.

Posted: Sat Feb 07, 2009 10:23 am

Its´not translated into other languages and because my native language isn´t english I gave up when I had to figure out how this thing works a time ago.
I guess other user from different countries will have the same problem with AutoTheme.