1 (edited by Louis 2004-05-31 17:56)

Topic: Compact Styles v0.2.1

##        Mod title:  Compact Styles
##
##      Mod version:  0.2.1
##   Works on PunBB:  1.1.4 (and possibly others)
##     Release date:  2004-05-27
##           Author:  Louis St-Amour (CSpotkill@CSpotkill.com)
##
##      Description:  New, compact versions of existing PunBB styles. 
##                    Mercury (and other dark themes) are reduced to two 
##                    lines of CSS, thanks to the "cascade" in Cascading 
##                    Style Sheets. Common framework CSS and light/dark 
##                    background rules are stored in separate files. This 
##                    speeds up loading time for new styles by caching 
##                    common repetitive rules, and makes it easier to 
##                    create new styles, by simplifying the CSS code and 
##                    reducing the number of edits required to make basic 
##                    colour changes.
## 
##   Affected files:  profile.php
##                    style\Cobalt.css
##                    style\Lithium.css
##                    style\Mercury.css
##                    style\Oxygen.css
##                    style\Radium.css
##                    style\Sulfur.css
##
##       Affects DB:  No
##
##            Notes:  v2.0 - Now works with the default PunBB code.
##
##        Generator:  ModGenerator (http://punres.cactuz.nu/modgen/)
##                    on: 2004-05-27 22:04:58
##
##       DISCLAIMER:  Please note that "mods" are not officially supported by
##                    PunBB. Installation of this modification is done at your
##                    own risk. Backup your forum database and any and all
##                    applicable files before proceeding.

Download: http://punbb.org/forums/viewtopic.php?pid=14642#14642

Changelog:

27-05-2004 / v0.2.1 released - Fixed a small bug with hover styles on lighter themes. (I had to re-order the A:hover rule so it was the last rule applied.)


27-05-2004 / v0.2 released - Now works with the default PunBB code.

I've taken off the "Beta" status, since I've tested it further now and it seems to work fine with the default code, after a few modications. I've even managed to reduce the code for the individual dark styles to only the bare essential two-line differentiations, with only 7 lines for the lighter themes. 8)


26-05-2004 / v0.1.1 Beta released - Updated Dark styles: Fixed link rules to use the color property instead of the background-color property. Whoops.


26-05-2004 / v0.1 Beta released - May not be fully optimized.

Because I haven't checked this on a default install yet, it may not work as advertised. Seems fine on my modified PunBB installation at http://www.CSpotkill.com/ -- I've changed the main page layout and added a gradient and a menu, none of which are included in this modification, though may be released in the future.

Let me know what you think of it. Thanks.

Re: Compact Styles v0.2.1

I've considered this before but chose not to do it like that to allow people maximum flexibility when designing styles. It might not make much sense in 1.1, but in 1.2 it will :)

"Programming is like sex: one mistake and you have to support it for the rest of your life."

3

Re: Compact Styles v0.2.1

Rickard wrote:

I've considered this before but chose not to do it like that to allow people maximum flexibility when designing styles.

Okay, whatever -- but you know you can override CSS, right?

Check out my new Mountains theme for an example of this, compare it to my version of Lithium:
http://www.cactuz.nu/forum/viewtopic.php?id=58

Re: Compact Styles v0.2.1

Louis wrote:

Okay, whatever -- but you know you can override CSS, right?

Yes, but don't you think it will make things harder for style authors?

"Programming is like sex: one mistake and you have to support it for the rest of your life."

5 (edited by Louis 2004-05-28 02:55)

Re: Compact Styles v0.2.1

Actually, I don't think it will make it harder, I think it will make it easier.

By encapsulating the CSS it helps protect younger CSS authors from themselves. After all, if they add something to their template, it's a conscious decision -- they can't wonder where they went wrong, or why half the forums have suddenly shifted off screen, changed colour, or disappeared, because they can't accidentally edit the framework code.

If they make a mistake, it's much easier to experiment by erasing parts of your new stylesheet and let the previous inherited versions fill in what's missing. It's also easier to focus on what you have to change or edit now, when it's all you can see.

If you want to change the colours of a forum, which is easier to start customizing?

@import url("Common_Light.css");

TABLE.punmain {background:#00176A}
TR.punhead {background:#AFBCEA}
TD.punhead,TD.punheadcent {color:#423F84}

A:link,A:visited {color:#002195}
A:hover {color:#4C51B5}

A:link.punhot,A:visited.punhot {color:#8730D2}
A:hover.punhot {color:#2049E2}

TR.puncon1,TD.puncon1,TD.puncon1cent,TD.puncon1right,TEXTAREA {background:#E3E8FB}
TR.puncon2,TD.puncon2,TD.puncon2cent,INPUT,SELECT {background:#EDF0FC}
TD.puncon3 {color:#000;background:#D1DAF9}
TD,INPUT,SELECT,TEXTAREA {color:#122B84}
BODY { background-color: #FFFFFF }

TD {
    font: 10px Verdana, Arial, Helvetica, sans-serif;
    color: #333333
}

INPUT, SELECT {
    font: 10px Verdana, Arial, Helvetica, sans-serif;
    color: #333333
}

TEXTAREA {
    font: 10px Verdana, Arial, Helvetica, sans-serif;
    color: #333333
}

FORM { margin: 0 }

PRE {
    font-size: 11px;
    margin: 0
}

TABLE.punmain {
    border: none;
    width: 100%;
    background-color: #606060
}
TABLE.punplain {
    border: none;
    width: 100%
}
TABLE.punspacer {
    border: none;
    width: 100%
}

TR.punhead { background-color: #9AC55A }
TR.puncon1 { background-color: #DEDFDF }
TR.puncon2 { background-color: #EEEEEE }
TR.puncon3 { background-color: #C0C0C0 }
TR.puntopic { height: 1.5em }

TD.punhead { color: #FFFFFF }
TD.punheadcent {
    color: #FFFFFF;
    text-align: center
}
TD.puncon1 { background-color: #DEDFDF }
TD.puncon1cent {
    background-color: #DEDFDF;
    text-align: center
}
TD.puncon1right {
    background-color: #DEDFDF;
    text-align: right
}
TD.puncon2 { background-color: #EEEEEE }
TD.puncon2cent {
    background-color: #EEEEEE;
    text-align: center
}
TD.puncon3 { background-color: #C8C8C8 }
TD.puncent { text-align: center }
TD.punright { text-align: right }
TD.puntop { vertical-align: top }
TD.puntopright {
    text-align: right;
    vertical-align: top
}
TD.punquote {
    background-color: #F6F6F6;
    border: #606060;
    border-style: dashed;
    border-width: 1px
}

A:link, A:visited {
    text-decoration: none;
    color: #415720
}
A:link.punhot, A:visited.punhot { color: #C03000 }
A:link.punclosed, A:visited.punclosed { color: #888888 }
A:hover {
    text-decoration: none;
    color: #709735
}
A:hover.punhot { color: #F43E00 }
A:hover.punclosed { color: #AAAAAA }

IMG.punavatar {
    margin-top: 3px;
    margin-bottom: 3px
}

.puntext { font-size: 11px }
.punedited {
    font-size: 10px;
    font-style: italic;
}
.punsignature { font-size: 10px }
.punheadline {
    font-size: 12px;
    font-weight: bold;
}
.puntitle {
    font-size: 14px;
    font-weight: bold
}
.punhot { color: #C03000 }

Re: Compact Styles v0.2.1

Louis wrote:

By encapsulating the CSS it helps protect younger CSS authors from themselves. After all, if they add something to their template, it's a conscious decision -- they can't wonder where they went wrong, or why half the forums have suddenly shifted off screen, changed colour, or disappeared, because they can't accidentally edit the framework code.

True, when and if they override any of the rules of the included common style sheet they will surely be aware of what they are doing. However, before that, they will come to these forums and ask how the hell they are supposed to change stuff like the table borders in only one of the styles. Having truly cascading style sheets has it's pros and cons.

I'm not sure how Paul has is set up in 1.2. I do remember talking to him about cascading, but I can't remember if he liked it or now. He's on vacation now though.

"Programming is like sex: one mistake and you have to support it for the rest of your life."

7 (edited by Paul 2004-05-28 11:49)

Re: Compact Styles v0.2.1

I'm back.

At the moment I have it set up as one css file which makes it easier for testing. Given the option I would use two, one structural and one cosmetic which would make it easy for people who just want to change color schemes, fonts etc and insulate the uninitiated from making a mess of things.

However, I see no reason why the structural stylesheet has to be common to all themes. I would prefer each theme to consist of two css files with links to both inserted by php. The stylesheets would be called something like oxygen_main and oxygen_theme. If somebody wants to alter something structural then they can do it directly in the _main stylesheet rather than using the cascade to override it. It also makes it easier to distribute complete skins and/or make an online skin generator. If you use a common stylesheet and rely on the cascade then making wholesale changes to structure will involve overriding large parts of the common stylesheet. The end result could be a cosmetic stylesheet which is as big and complicated as the common stylesheet.

Of course you could make things really interesting by making both the structural and cosmetic stylesheets selectable by the user. This means you could have say four structural stylesheets and 6 colour schemes each of which work with all of the structural stylesheets. This gives you a total of 24 possible themes from 10 files. A bit more complicated I know but the real advantage is it would make it easy to produce specialist/accessability skins e.g. large fonts, fixed width etc.

Now all I have to do is try to remember what I was doing before I left; three weeks in the sun has fried my brain.

8 (edited by Louis 2004-05-28 15:51)

Re: Compact Styles v0.2.1

Paul wrote:

However, I see no reason why the structural stylesheet has to be common to all themes. I would prefer each theme to consist of two css files with links to both inserted by php. So the difference between our methods is that I stripped the default themes to their bare essentials, and used @import in each individual theme instead of touching the PHP?

The stylesheets would be called something like oxygen_main and oxygen_theme. If somebody wants to alter something structural then they can do it directly in the _main stylesheet rather than using the cascade to override it. How would they know to edit the main theme to make structural changes? Why not just override the structure completely by @importing another structure stylesheet?

It also makes it easier to distribute complete skins and/or make an online skin generator. Perhaps, but if you set a standardized name and format for the cascaded stylesheets, you could use either method.

If you use a common stylesheet and rely on the cascade then making wholesale changes to structure will involve overriding large parts of the common stylesheet. The end result could be a cosmetic stylesheet which is as big and complicated as the common stylesheet. But they don't have to. They can make their own seperate structure stylesheets and @import them too.

Of course you could make things really interesting by making both the structural and cosmetic stylesheets selectable by the user. This means you could have say four structural stylesheets and 6 colour schemes each of which work with all of the structural stylesheets. This gives you a total of 24 possible themes from 10 files. A bit more complicated I know but the real advantage is it would make it easy to produce specialist/accessability skins e.g. large fonts, fixed width etc.

Again, the only difference between our methods is that I haven't touched the PHP code, beyond a one-line change to hide "Common_" stylesheets from the style dropdown. If you wanted to modify the style selection that much, then it would be easy to replace the @import with direct PHP-provided link tags.

So we both agree encapsulation is a good thing, the only difference is our methods. But there is no difference -- if the PunBB style selection code changes, it's easy enough to keep up with the multiple required links. I'm simply saying that if PunBB is loading one CSS file, then from a CSS designer's point of view, @import is a useful and well-known CSS mechanism to encapsulate the structure and shared colour rules, where modifying the PHP code would be unfamiliar and unecessary.

There are no rules about @import, except inheritance. So what I did was load the Mountains.css file in the HTML through PunBB, then had Mountains.css load the Common_Light.css, which loaded Common_Framework.css automatically. If I wanted to load a different framework, there's nothing stopping me from creating my own Common_Custom_Framework.css and importing that from any theme I wish.

However, more important than encapsulation, in my opinion, are the actual selectors involved. Personally, I feel that there's very little structurally we can do with the current table layout. If there's a new, completely CSS-based layout coming, I'd love to have a sneak peak at it. If we do it right, we might even be able to create custom classes, so instead of doing:

TD.punhead,TD.punheadcent {color:#423F84}
TR.puncon1,TD.puncon1,TD.puncon1cent,TD.puncon1right,TEXTAREA {background:#E3E8FB}
TR.puncon2,TD.puncon2,TD.puncon2cent,INPUT,SELECT {background:#EDF0FC}
TD.puncon3 {color:#000;background:#D1DAF9}

We could do:

.color1 {color:#423F84}
.color2 {background:#E3E8FB}
.color3 {background:#EDF0FC}
.color4 {color:#000;background:#D1DAF9}

Then apply whatever colours we liked to parts of the page.

<table class="punmain color4">
  <tr class="punhead color2">
    <td class="punhead color3">
      <h1 class="puntitle color1">PunBB.org Forums</h1>
    </td>
  </tr>
</table>

This would make creating styles for mods much easier, just insert the proper colour classes and create a custom structural stylesheet if necessary.

Also, it makes figuring out what to change a lot easier -- just create a stylesheet which overlays numbers on a :hover, perhaps, and people can figure out what to change based on that.

For structure, I understand the need to use H1 and other direct tags, however for colour schemes, I find it unecessary.

Comments? :)

Re: Compact Styles v0.2.1

Louis: Contact Paul and I'm sure he'll demonstrate the changes he has done so far.

"Programming is like sex: one mistake and you have to support it for the rest of your life."

10

Re: Compact Styles v0.2.1

Rickard wrote:

Louis: Contact Paul and I'm sure he'll demonstrate the changes he has done so far.

Okay, check your email, Paul :)

11 (edited by Louis 2004-05-31 17:57)

Re: Compact Styles v0.2.1

PunRes is down, temporarily. See this thread for details.

You can access this project's files at: http://www.punres.org/files/projects/pr_34/

Also available:

Mountains.css a theme based off of this mod. http://www.punres.org/files/styles/st_16/

For other mods and styles, see: http://www.punres.org/files/