The style [ template, theme, imageset ] topic

[psoTFX]

I want any and all feedback on the styling system deployed in 2.2. I want to know what you think of it as it is now, what you'd like to see added to it, what you'd like to see change, etc.

I'm particularly interested in the following areas:

• How far should we go in transfering basic conditional statements from the source to the templates? e.g. row colouration, limiting output of content not applicable if not logged in, etc. etc.
• What needs to be moved from the source to the templates/style/imagesets? What needs to be moved back?
• How should we handle theming? i.e. completely freeform css with minimal/no essential [ source required ] classes? Basic set of "pre-defined" classes supplemented with freeform data? Something else?
• Are we handling imagesets in the right way? If not, why not?
• How should the admin controls for styles be arranged?

Remember to add your reasons for the selection and ideas for just "how" it should be done [ no code, just talk ]

Please, no "You should do it like inv-vb-yabb board" I want your comments as a potential future user of phpBB 2.2, not something regurgitated from elsewhere

Remember, not everyone will agree with your point of view ... please respect the position of others. Rational, well thought out argument is good ... name calling is bad

Also remember that I'm asking for feedback here ... in the end I'll make a judgement and go with what I think best works. This may or may not be something you suggest or like.

[Aexoden]

Ok, what follows is my attempt to finally comment on this styles stuff that you've been attempting to get feedback on for months now. Please note I call it an "attempt" for a reason. I'm not particularly opinionated on the matter.

As I was thinking about styles and templates the other day, I came to my own conclusion that the script should generate the data, and leave it fully to the style system to present it. Extending on that, I'm in favor of moving basic conditionals to the templates (as has already been done to some degree). As for how far... it's difficult without being able to think of any many of these conditionals off the top of my head. For instance, row colors or classes can probably be best served by the template. But some things (such as colorising based on group) seem to be best handled by the source. I think it would probably even come down to forcing the source to output the <span> code. Otherwise, the template would be complicated needlessly. I'm most interested in eliminating HTML generation from the core engine, so that I can change the look of things just by editing the template or CSS instead of having to hunt through the code. I don't really have any more specific ideas in this category.

Optimally, I'd like to see every image handled by an imageset (possibly even rank images, but that has problems of its own). This seems to be be somewhat conflicting with multiple language packs based on the current interface... then again you could simply have a generic button name, and then just require that all installed languages have the same named file available. So maybe have language-dependent images or something to that effect. I don't use multiple languages myself, so I haven't really thought of this. As I stated before, HTML is something I'd like to not see in the source... but I understand that with some entities (like selects) this could be somewhat difficult (implemented probably using a block that iterates through each option). Also, some things, such as hidden fields in a form, would probably need to stay fully source generated. It seems completely useless to have the template have complicated entries just to handle these.

As for theming, my original ideas were for some basic required classes along with additional freeform data. I imagine most freeform data (and possibly required classes) would want to be optimally placed in an external CSS file, so that poses some design problems, but that's mainly an issue for a template designer, as opposed to an admin who decides he wants to change the font size. I'll talk about that in a minute. The pre-defined classes came to my mind when thinking about BBCode. That is, each BBCode has an associated CSS class to enable easy templating without necessarily needing to edit the template file. Only more complex design changes would require anything other than changing the class on a span or div (depending on whether the particular BBCode was block or inline).

It really relates to admin controls. One of the biggest complaints I've dealt with in introducing phpBB to my friends is the difficulty of modifying the default template. Part of that is subSilver's design, but part was the weak style interface of 2.0.x. Specifically, it would be incredibly helpful to be able to change the style of the BBCode by editing a class in the admin panel. Or being able to quickly change colors by editing other specially coded classes. However, limiting the hard-coded directives is also important. Having a lot of experience with HTML and CSS, I don't really need this hand-holding, but I think it should seriously be considered. Then again, if you've installed a forum, I'm sure you can muck around with the CSS and figure out what it's doing, and how to change it to your desired look.

What I'd like to see as far as the admin interface... I like the template editing as it stands. I'd mostly edit my templates offline anyway, so that's not an incredible concern. For CSS editing (or other theming), a demonstration of a particular class could be useful. However, it seems it would be difficult to decide just what to apply the class to. Definitely some kind of preview mode would be incredibly helpful. This comes back to pre-defined classes... they make coding a standard interface easier (at least on first thought...) but they limit the power of the advanced designer. I guess I'm just really divided on this issue.

After re-reading what I've written, it seems like I've thrown down tons of generalities and almost no specifics. I hope I put down at least one concrete issue. For what it's worth, I liked the 2.0.x template engine (but not the style editor), and I absolutely love the additions. Part of the reason I lack so few comments is because you've already added the things I've discovered useful in template design. Anyway, I'll stop writing before I begin to bore my audience... oops, too late.

[dhn]

I agree with Aexoden mostly. I guess SHS` and me will give you some more heat regarding HTML produced by the code.

Why not keep it the way it is? Let the style designer offer variables the user can change via an easy control panel. I guess we would have had less of an outcry for an easier template system if this option would have been actually supported better by a standard non-subSilver template.

What might be very helpful is to add information to the template tables that describe what information type each field contains. Is it a color value, a text-size, a font, a border? Use this information to give the user pre-defined options, a color chooser e.g., a preview even.

[Daz]

Hi,

Is there going to be provision for online editing of the external CSS file and how is this going to be handled with regard to storage?

[dhn]

Daz, I guess this is what Paul is just trying to decide and wants feedback for. I don't think a CSS editor within the admin panel is needed, but that's just me.

[Daz]

Hi,

Someone has to start the ball rolling and my question leads to another - I was trying to keep it short.

[ShiningArcanine]

Daz, I guess this is what Paul is just trying to decide and wants feedback for. I don't think a CSS editor within the admin panel is needed, but that's just me.

If it makes skinning a board easier which it obviously would be meant to do. I am all for it.

[SHS`]

On the whole, what Aexoden said.

But to address some specific point asked by Paul:

How far should we go in transfering basic conditional statements from he source to the templates? e.g. row colouration, limiting output of content not applicable if not logged in, etc. etc.

I think this would be a good move. Despite the fact there would potentially more contitionals within the templates, and making them a bit more "code-like", it does mean that template changes are abstracted and completely contained within said HTML files.

One wouldn't have to go poking about with core code to change things.

I know Paul's concern would be that this would affect performance too much, but since templates are already cached, this would only be so for the "first pass"?

Guess some benchmarks on moderate to heavily loaded servers?

What needs to be moved from the source to the templates/style/imagesets? What needs to be moved back?

The only thing I can think of right now would be the image sizes being defined inline with the image URI within the DB.

Do we need the image sizes anyway? As the height/width attributes can be defined using HTML attributes or via CSS (classes or inline via style="")

People may use the same imageset across a number of templates, but in such cases, it's image dimensions will be the same, so sizes can be hardcoded.

If people want to use different imagesets, I can't see any reason why they would make said images the same size as their alternate anyway.

How should we handle theming? i.e. completely freeform css with minimal/no essential [ source required ] classes? Basic set of "pre-defined" classes supplemented with freeform data? Something else?

Pity CSS2 is still poorly implimented in a certain browser, otherwise it'd be possible to style a table and all it's contents just by assigning a unique id to it, no more stupid classes per td or whatever.

But anyway, CSS isn't that hard, and there are a good deal of tutorials. People typically just want to edit colours.

Are we handling imagesets in the right way? If not, why not?

I think we are, but I'm wondering if being able to "mix-and-match" a number of image sets be useful? Say one set of images had dark BGs, and another light BGs. One way want to be able to pick and choose depending how dark said area of the template was for that "area".

How should the admin controls for styles be arranged?

Need to think about thes, but I don't see any major problems.

But as Daz noted, an external CSS file needs to be "accessible", say putting it into ./cache/templates/templatename/whatever.css, as it appears from other peoples experiments, a PHP generated CSS file doesn't work very consitantly, but it could be specific browser/server set up issues.

[Shining Arcanine]

Pity CSS2 is still poorly implimented in a certain browser, otherwise it'd be possible to style a table and all it's contents just by assigning a unique id to it, no more stupid classes per td or whatever.

If you are talking about IE, Microsoft says it doesn't have CSS2 support yet:

http://msdn.microsoft.com/library/defau ... atures.asp" target="_blank

Note Level 2 support is not currently implemented.

[mlimburg]

Howdy,

I've got two thoughts that haven't been touched upon so far ...

Firstly, the use of user/group as a core feature within the template. For example <if !group['admin']> would show content to those not of the admin group.

Secondly, the generation of HTML within the codeset. Above was a mention of building a select tag. Why not implement a select.tpl file, where the select data is pushed into that, and then rendered. This would allow a greater level of customisation, and place it within the template layer, rather than having a MOD to do that ...

Random thoughts

--
Mark