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:
We could do:
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>
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.