CSS Question for Paul

Using import for your own styles is fine. One tip, if you are going to override the existing styles rather than edit them then make the selectors more specific. One easy way of doing this is to use #punwrap. For example if the existing stylesheet has something like .pun P {color: red} then using #punwrap .pun P {color: white} will always overrule it.

Just so you know, there are no minor changes to the style sheets or the markup planned. I think there is one small fix needed for profile.php to remedy a Safari bug but that won't impact on anybody.

There are major changes planned though exactly what and when is still under discussion. There are arguments for putting changes in sooner rather than later and then freezing the markup and css for the remainder of 1.2 and 1.3. There are also arguments saying dont make major changes except when there is a major version release. When that happens you will have to make changes to your own style(s) anyway. The changes should include

- Dispensing with clearer divs
- Probably dispensing with one layer of divs, most likely <div class="inbox">
- Some improvements to make integration less of a headache.
- less use of floats
- trying to design out some of the hacks
- generally tidying up and, hopefully simpifying, the css

Once that load of changes are in I would really like to see the markup and css frozen for a considerable time to allow styles to be developed without fear of them becoming outdated very quickly.

Just a thought. Would it be a good idea to put the version number of stylesheets in a comment at the top e.g. if you install PunBB 1.2.4 and the stylesheets that come with it are labelled 1.2.1 then you know there have been no changes.

That would be a good idea but if it's included in the changed files, then it's a given.

Looking forward, it would be nice to have the /styles and /include/template be outside the scope of the core. when changing a site, these two areas are affected the most. I know that whenever a major version comes out the templates and CSS do change somewhat.

So in order for our styles to follow us from rev to rev, there has to be some kind of abstraction. I know, I'm talking about some kind of skinning or templating system, but it would alleviate upgrades and bring more styles to the table.

If I were trying to come up with an alternative system I would do something like this. The php files would generate smaller snippets of xhtml consisting of the xhtml which immediatelly enclosed the content. These snippets could then be assembled using a .tpl file which contained the markup for the containers.  Since the bits of xhtml in the php file would be the semantically correct tags for the content they contained there is no reason why they would ever need to be edited. For example footer.php would generate the tags for the lists which contain the information and the containing divs would be in the tpl file with the variables representing the lists placed wherever the author wanted. The variables representing the items would of course be named to indicate the nature of the tags and any id/class names e.g. <dl_userinfo_conl> to indicate a definition list was being inserted with an id=userinfo and class=conl.

This is not a suggestion for future development, its just the way I would do it if I was so inclined. There is bound to be some performance impact though because of the increased amount of merging that it taking place to generate the final page.

One downside of templating is that you do end up with more redundant markup because the markup has to be able to accomodate whatever content is thrown at it. With the markup all being in the php files it can be made totally conditional upon the content thus avoiding empty tags and such like.

Paul, I think that you would be the best person to come up with a templating system scheme.

I know that the speed of punBB is why so many of us use it. I was just reading some posts on an Invision Power Board forum and it was to say the least, a bit dogged, I could see Firefox painting the screen.

But I believe that a scheme could be devised where the speed is impacted very little with a huge leap in customization for the end user.

Just my 2cents.

Paul, I hear you, I love speed over everything else.

From my own experience in using Nucleus, a well designed templating system close to the core has very little impact with the operation of a system.

If you visit any my sites and experience a slowdown, it's probably the Google ads

Whenever you'd like, I can say I'm somewhat familiar with the skinning aspect of Nucleus. I've already ported 3 skins for our skins site and assisted in the new default skin for v3.2. Honestly, it's more CSS knowledge than anything else.

As far as how the core does it, I haven't delved into the code yet.