Theme using best-practice web design techniques ?

[robotlogin99]

I'm trying to create a new theme for my site, using 1.1.b3.

Starting this I am somewhat disapointed that the default theme for SMF seems to use very old-school web design techniques.

What I would expect from a modern web application is that as much graphic design as practically possible should be doable by modifying only the CSS file (Zen Garden example [nofollow]).

If I want to change the background color for, say, the avatar part of a post, I should not need to take the entire 50Kb (or whatever) post-display-php-script-thingie, just to change one lousy class="bgcolor-used-everywhere-indiscriminately" into class="post-avatar-bg".

I would much prefer if all distinct logical parts of the interface had it's own classes.

Each disinct part should also be enclosed by a <div> tag with a distinct classname, so it would be possible to reposition the part using only the central CSS file. (Example: moving the "New topic" button to the left side by only changing alignment to "left" in the CSS file.)

I think putting all the graphic design stuff outside of the rendering loops and code would make a tremendous impact on the quality and choise of themes available. A person skilled in graphic design should not have to learn PHP to create a new skin, she should only need to modify the CSS file and the images.

I've read the development version of PhpBB3 [nofollow] is going to make themes this way, it's being kept secret until it is finished. 


Question #1a:

Is there any theme for SMF 1.1b3 that does use CSS, classes and DIVs according to current best-practice ?


Question #1b:

If not, is there any truly minimal theme without any graphic design whatsoever (but with full functionality), which I could try to adapt to (what I see as) current best-practice?


Question #2:

I am quite new to the SMF community, and am curious: Are you SMF users quite happy just hacking around in the very program code itself if you need to do only minor design changes? Does not that lead to a lot of extra work when upgrading or adding mods ?

[tentronik]

I think too all css should be editable with the main css file.
Its a little time taking till you realize that the info box stuff for a fact has its own hardcoded css stylesheets.And the infos box well looks not perfect yet to me.
The news stats box need to be same size in relation to the user box.

Also it would make sense to announce core css tags.

Btw. what oldschool technique its php template very kewl i think beside the css stuff there.
And i really liek the way the theme loads.

[bloc]

While i can understand the willingness to be able to change EVERYTHING in a theme from the stylesheet, it simply isn't feasible. Imagine having a class for every aspect of the forum..that would at least mean 20-25 more classes to tinker with. And the stylesheet is now already a handful for many people...

I think less is better..change the few classes you have now and you change the look much already. Need more control - go into the template. Now, a forum is more strict than a website, because it presents information in different structured ways..the look is often determined by functionality.

Creating a theme is never an easy task - if you go beyond pure color changes - and even if you replaced all the tables with divs, it still would be complicated.

But I am not dissing this idea, just arguing that it isn't as simple as just converting everything and then everyone can create outstanding themes - and be very modern at the same time. Just because something is "oldschool" doesn't mean its worse. CSS garden is a light beacon in css design..but its not the best solution for everything IMHO.

[robotlogin99]

Thanks for good comments, Bloc!

Imagine having a class for every aspect of the forum..that would at least mean 20-25 more classes to tinker with.

I personally would be very happy dealing with 100 extra classes (providing the are logically named).

The visual interface consists of 2 parts:
- rendering logic (loops, conditionals, connections to lower level code, ...)
- "eye candy" (colors, fonts, background images, alignments, ...)

Currently these parts are more or less jumbled together in one pot. What I suggest is splitting the theme into 2 distinct "application layers".

Moving the "eye candy" part altogether away from the "machinery", would mean that I, as a theme designer, would not be forced to rip out and take maintenance responsibility for a file containing application critical logic (enforcing display options etc.).

That is perhaps the most weighty argument, in my mind - the fact that the theme designer assumes a responsibility to maintain all parts of all files she opts to modify. Then a bugfix or update is released for the file I've rummaged around in, how would I go about incorporating the new changes into my theme?! How can I be sure none of my changes have caused some logic to break?

What I would suggest is to create a theme incorporating this 2-layer rendering model.

To do this it would be best to first create an absolute minimal theme for SMF. And I mean absolute minimal! No kind of "eye candy" or formatting (color,alignments,..). It should only contain basic logic bearing XHTML elements. Like <ul><li> <h1><h2><h3> etc. And use <div></div> to define the elements of the page (search box, post buttons, page selector, etc).
Then insert class="" on all divs and all other elements that would need eye candy, and add those to the CSS file. Tables should only be used where it is the only practical thing.

Creating a theme is never an easy task - if you go beyond pure color changes

All I initially wanted to do was to switch around the background color of topic-icons and topic-title in the topics listing. There was no way to do that in the CSS file, because the class on that <td> was being used througout the system. So I was forced to assume maintenance responsibility for the entire topics list to make a very minor color change.

But I am not dissing this idea, just arguing that it isn't as simple as just converting everything and then everyone can create outstanding themes - and be very modern at the same time. Just because something is "oldschool" doesn't mean its worse. CSS garden is a light beacon in css design..but its not the best solution for everything IMHO.

Agree!
Though it is not because using CSS is modern i suggest it. It is because I from experience have learned that using CSS extensively is the only practical way to safely and maintainably separate the graphic designer role and the programmer role.

I am sorry if this appears like a rant from my part. It is not intended as such. Only as constructive criticism of an outstanding open source project. I just wish to explore wether there is any practical way to make theming easier and/or more powerful to non-programmers.

[jasidog]

I think even you got exactly what you asked for it would still be necessary to go into the template files to create certain effects and styles. CSS can't do everything yet.

The CSSZenGarden is an ideal that's not ideal. It breaks, for want of a better word, a lot of the reasons for using CSS. It uses extra containers and classes to provide more ability for customisation.

In general I agree with you though Robot.

There's very few forum software's that do this kind of thing, Punbb is close but it bothers me that there is no templating system other than using CSS for that. Sometimes you do need to edit the HTML. If you look at some of the best standards based designs on the web none of them share the same mark up and that's not just because different people created them. At this time mark up still determines to some extent or another the ability of the CSS to do this or that. And because optimally you use as little CSS and XHTML to achieve what you want, you should reuse classes to cut down the style sheet.

As I say I do agree in general though that all forum software could make it easier to do a lot more with CSS off the cuff without touching HTML.

I only recently first attempted an SMF theme and was at first a little put off by the template containing more than HTML. I'd never really worked in and around PHP before and was used to other BBS which separate that. I think it likely that more people might take up theming for SMF if it was separated. However having worked with it I can see a lot of advantages to having it there. Mainly in terms of customisation.

For example If I wanted a different background colour on a forum with new unread topics (Rather than a different icon.) I could do it. I couldn't with say IPB or PhpBB. Not unless they added new/more conditional logic to their template system anyway. So the php in the templates is kinda useful.

I'm not really contributing anything but I thought I'd mumble away anyhow.

[robotlogin99]

I think even you got exactly what you asked for it would still be necessary to go into the template files to create certain effects and styles. CSS can't do everything yet.

Agree completely!
CSS is not a magic wand.
But when you only modify (and thereby assume maintenance responsibility for) the CSS classes, then you are guaranteed not to mess up any important parts or wreck the connections to the rest of the system. The worst you can do is make something look completely crappy or confusing, but it would still work as it should, from a technical point of view.
By being forced to modify PHP code for very minor adjustments, you can, through ignorance or bad luck, make some small adjustment that might cause erroneous behavior or reveal information that has been configured to be restricted.

One might argue that being an open source project developer role distinctions (graphic artist vs system programmer) are not all that important, since is usually is the same guy (a 22 year old white male hacker) that does all the artwork and code tweaking for his site anyways... That is (luckily  ) not always the case though.

The CSSZenGarden is an ideal that's not ideal. It breaks, for want of a better word, a lot of the reasons for using CSS. It uses extra containers and classes to provide more ability for customisation.

I do not view CSSZenGarden as the epitome of CSS. I only mentioned it because the site illustrates some of the benefits.
Practically one would have to weigh the benefits and drawbacks of using CSS or HTML on a case by case basis.

It would be interesting converting the theme to a distinct two--part "presentation graphic" + "presentation logic"  architecture.
But I do not know when I might get time for that.

[bloc]

Problem as I see it is that you can certainly sepearate the various bits of forum to div's with classes..but in broad strokes only. For example..the boardindex with all the boards..it really needs all the width it can get, making it difficult to divide any further. You can push it, and make sidebars for other content etc. but to really make it different the template HAS to use tables etc. Even php code. Its simply not enough with free-floating divs and spans to make it work...

But then again one should never say never , at least not before one have tried properly.  

[[Unknown]]

Doing the things I assume you mean to want, including:
  - using css classes and ids for all styling, avoiding the use of any inline styles.
  - avoiding the use of tables or divs except when conceptually correct.
  - allowing no PHP whatsoever in templates, and using only HTML.

Would mean all of the following:
  - lost support for Internet Explorer 4.0, many cellphones, possibly WebTV, and others.
  - much larger css files and html output leading to increased bandwidth usage.
  - large files to trawl through (still) to find what you want, especially when you want to modify a lot of things at once (unless multiple classes are used, along with ids, which will only lead to confusion.)
  - no ability to make more than basic aesthetic changes without hacking the source code.
  - general performance loss.
  - another "language" (however you do it) for people to learn, even if simpler than PHP (being one of the simplest programming languages.)

A lot of things are not done or are done because of browser compatibility.  For example, various versions of Internet Explorer either do not support or have buggy support for multiple classes.  Using one background color class "indiscriminately" is *EXACTLY* how most people want to modify things.  Changing it to be a class used in only that one place would give MOST PEOPLE headaches, not relief.

Thus, either ids or multiple classes would have to be used, and in many cases both.  There are already named problems for this.

You can write your own themes for SMF, and they can support Mozilla Firefox 1.1 only if you'd like.  But broader support is a goal for the default theme.  And with that, most unfortunately, comes working around problems in commonly used browsers.

And... if you think that moving all inline styles to a css file wouldn't lead to a 50kb css file (as compared to a 50kb PHP file) I'm afraid you're simply dreaming.

-[Unknown]

[robotlogin99]

Thanks for responding, Unknown!

Doing the things I assume you mean to want, including:
  - using css classes and ids for all styling, avoiding the use of any inline styles.
  - avoiding the use of tables or divs except when conceptually correct.

Correct!

  - allowing no PHP whatsoever in templates, and using only HTML.

No!
I am not saying not to allow PHP in templates.
What I'm saying is to allow the theme designer to do more graphic styling without forcing her to assume maintenance responsibility for PHP code.

The PHP-proficient designers who actually want to modify the rendering logic parts of the theme should of course be allowed to do that, just as they do today.

  - lost support for Internet Explorer 4.0, many cellphones, possibly WebTV, and others.

Why?
Because an extremely small minority of users might get margins 1px wrong, or a slightly larger font?

This perceived problem might be solved using browser tailored CSS for those specific problem browsers. SMF could easily detect browser version by looking at the request headers, and then serve the appropriate CSS file (or fallback to default).

  - much larger css files and html output leading to increased bandwidth usage.

To my knowledge it would actually lead to reduced bandwidth usage; because the CSS file will be transfered only once, and subsequenty accessed from browser cache.

  - general performance loss.

Such performance loss would only be if the designer must be able to do structural changes to HTML without touching PHP - effectively introducing another, middle layer to the "page rendering stack":

1. "Eye candy" (CSS + images)
2. HTML structure (HTML + intersperced tags to be interpreted and replaced by PHP)
3. Rendering logic (PHP code)

That is not what I suggest.
I would leave all HTML together with the PHP.

From what I can understand extracting all styles to an external CSS file and reducing non-necessary tables should have no negative impact on performance.

  - another "language" (however you do it) for people to learn, even if simpler than PHP (being one of the simplest programming languages.)

To me it looks like SMF uses CSS to some extent allready, though.
So the theme designers have to learn 2 languages allready...

Using one background color class "indiscriminately" is *EXACTLY* how most people want to modify things.  Changing it to be a class used in only that one place would give MOST PEOPLE headaches, not relief.

Is this a fact ?!
Will theme designers (who are today tweaking PHP files) actually get headaches if they have to modify five CSS classes instead of one, to change the background color of 5 completely separate sections ?

Maybe most non web designer people would get headaches, but I'm sure the same people would run away screaming if they ever saw the PHP code for a theme. 

[[Unknown]]

So, now, it's not just huge css files but multiple huge css files for each browser?  This would be easier to manage.... interesting.

It sounds to me, also, like you've not tried to develop things that work properly in IE4.  Some of the bugs cannot be worked around without changing a div to a table.  Even in IE 5 and 5.5 there are bugs that have such effects.

Pages will not get that much smaller, especially with the usage of many classes and ids everywhere, and the css file will be large enough to offset the difference you get from people who remain on your site.  First time visits happen more than just once and again.

Performance loss and another language would be required to remove and replace PHP in the templates.

I expect anyone who calls themself a theme designer to be proficient enough to use a text editor to search all of the template files for "windowbg" and change as necessary.  They can then provide windowbg's for mods and administrative templates.

You can choose your own css, because you know css and html.  People who are new to both of those also modify their themes, and as I hope you won't disagree, greatly outnumber the experienced web designers doing so.  Being able to change "blue" to "red" easily in the css file makes a world of a difference if that's *all you want to change* and moreover *all you really understand.*

-[Unknown]

[tentronik]

So, now, it's not just huge css files but multiple huge css files for each browser?  This would be easier to manage.... interesting.

What you mean huge css file mine has about 40% currently which i dont use and its 8kb huge.

Basicly you need the following css classes:
- body
- td, th, tr
- standard links
- menu links
- submenu links
- area pathway
- author
- create/modify date
- code
- quote
- b, p, hr, ul, li
- 1 font family (basic grafic design standard - well of course a logo or slogan could differ)
- text classes (small, normal, large, huge)
- footer
- custom1 - Newsfeed class
- custom2 -
- custom3

smf special classes
- board table classes1(windowbg1)
- board table classes2(windowbg2)
- special header, bodyheader, body, footerheader, footer classes
- special category classes1 (catbg1)
- special category classes2 (catbg2)

Well maybe i forgott a few but thats basicly it.
And i just want to suggest at this point that A FEW hardcoded css style tags inside nearly every default theme needs at least a readme, because to just quick edit something you need to know all default theme files.
Either have 1 css or a small readme/sitemap where which css is and what it does or update the theme to just use css (or only 1 hardcoded file such as index-template or display or boardindex.template).

Cheers

[robotlogin99]

]
It sounds to me, also, like you've not tried to develop things that work properly in IE4.

2 years ago I think IE4 would have been a relevant platform for a browser friendly site.

But not today!

Internet Explorer 4 is rapidly fading towards oblibion.

According to www.thecounter.com [nofollow] , it is at a mere 0.1 %

Source: http://www.thecounter.com/stats/2005/August/browser.php [nofollow]

I think you must go to very great lenghts to find a single site with more than 1% IE 4 users today.

Why should anyone go to any length supporting this long dead browser?!

Especially when doing so will force you to severely hack an otherwice clean and standard design structure.

]
Pages will not get that much smaller, especially with the usage of many classes and ids everywhere, and the css file will be large enough to offset the difference you get from people who remain on your site.  First time visits happen more than just once and again.

It probably will be more bandwidth consuming if 90% of your visitors disappear after just one page view, and do not return until the cache has expired.

That is not my impression of the behavior of a typical forum user. To my experience, forums generally have a high "page views pr user session" rating. But I may of course be wrong. Statistics for this would be interesting.

]
Performance loss and another language would be required to remove and replace PHP in the templates.

No! That is the opposite of what I suggest. As mentioned in my previous post, I think all the PHP and HTML should stay together exactly as they are today - in order not to reduce performance.

[[Unknown]]

Internet Explorer 4, again, is reflective of PDAs.  And people do, more commonly than you might think, use or want to use PDAs to browse forums.  Especially when looking for information.

Obviously it depends on the nature of the site.  But, again, the *default theme* is meant for all sites.  I'm sorry, but for me academic purity isn't important if it comes at a price.  If it's free, I'm all for it... but it's only academic purity.  Having classes and ids doesn't help acessibility, doesn't make it work on more browsers, and again doesn't make it easier for the larger portion of the administrators.

There are tables, in 1.0, used where it is unnecessary.  There are places, especially in 1.0, it would be nice to have a class where there is none.  But the web is just not ready for XHTML 1.1, using classes and ids everywhere, etc.  It's ready for CSS, but not for using CSS for everything.

And, yes, *PARTS* are ready for it.  Growing parts.  But they're just parts.

-[Unknown]

[robotlogin99]

What would be the best way for me, as a theme designer (who modifies a lot of code heavy PHP files in order to tweak colors and td-widths), to ensure my theme is 100% compatible with new versions of SMF 1.1 ?

Must I install my own version control system (like CVS or SourceSafe), and compare differences?

Or is there some easier way ?

What method do you fellow theme designers use ?

(I assume you are not all programmers by heart..? )

[forsakenlad]

I use winmerge and load up the two different template files from each version (default template) and do changes to my themes

[bloc]

I use Beyond Compare and just go through it.

[jasidog]

I do the same as Bloc using a text editor I saw mentioned on the forums here. ConTEXT.

[smack]

Man this is giving me a pain in the head that I need to go and take two Tylenol's.  I don't know much about CSS, PHP, MySQL, XHTML, HTML or what ever language you guys want to add to the list but I can see a pain in the arse when I take a look at it.

DIV, Uh?  CSS? Uh?  man I have a question.  To position all of the require data from recent post, calendar, Profile and many other options into a division that require many other divisions with multiple positioning sounds easy to you?.  Then on top of that make it compatible with many browsers then while we at it everytime UNKNOWN decides to greatfully release another of his wonderful updates you have to make sure it is still compatible with your theme?. 

Sound to me like we are trying to create another puzzle.  Keep SMF as it is I use both of these HTML CSS PHP thingies at my site and it is far from been professional but I can move around and play around with it.  As a newbie I think CSS DIV and php will confuse me more then just plain tables.  And I don't really see what is the problem with tables.  I have another question why everytime I go to a site to learn about CSS and DIV there site is develop using tables? <GRINN>

To me I use all DIV, Table, I personally like to use tables and dress them up with CSS, and a DIV here and there to help with some color stuff.

I don't know what I' am talking about but positioning scares me let me go and hide.

[tentronik]

It take years to understand and learn all the technologys you mentioned.
Also your way of creating a theme (css div positioning) is not the easyest.

Also i dont see any problems with tables - either you use a table with a constant width/height or you use e.g. 80% or 100% for the width and other values.

If you have problems programming the template i suggest to read some basic css/html tutorials or you could still REQUEST a free/or paid theme.

And the problems you described comes with every theme and or tempalte this is nothing particular SMF.

The best you can do to learn and understand SMF themes is altering 1.
Make a copy of the default from the themes admin and then start editing it.
Thats how i do it.

Cheers

[Kindred]

Basically, what is being said is, Robot...   if you want to design a theme that does this, then go ahead.
You will have to redesign every template.php file...  but that's why the system is laid out like it is!

hmmm...   although (I just realized) there is some code called in the Source files as well, isn't there?


Anyway...   try it.    Design a theme that uses DIVs and CSS.
I'll tell you this, Some template deisgners for mambo have done just this...  which is great if you want to run mambo "as-is". However, the moment you add a component or module to the site, you now have issues....