Question K 1.0 / K 1.5: Read this if you are template designer

Sorry. Did not feel well yesterday.

Please don't forget to share the code, still waiting

Lintzy wrote:

I agree with Spocks proposal. When the buttons are only CSS styled rather than gifs, you have much more possibilities.

With CSS styled navigation, you have both: buttons as (background)graphic (take text-indent -3000px) and SEO and Screenreader are your friend and second you can put the buttons as Text, with other CSS styles around.

I totally agree, if and when it's done it will open up a whole new approach to Kunena template design. We are currently limited as far as implementing different layouts and features.

PS: I am not saying do it now or tomorrow or next week.

Lintzy wrote:

Please don't forget to share the code, still waiting

Sorry Lintzy. I will look for an example as soon as I arrive home. And don't misunderstand when I say I prefer graphic images for buttons if they are absolutely controlled by the CSS and not hard-coded into files. I do not prefer to look at sites where the buttons are simply colored rectangles with a simple background image and boring text.

OMG I forgot what a mess it was in these files. I remember why I stopped trying to figure them out as well. I hope these get re-written from scratch one day.

Anyway. Here's an example of what I mean.

This is the coding for a link with a button.
This is one without.
Logic would dictate that to replace the graphical button with text one would simply replace this with this since everything is already int he language files but it doesn't look so easy. As I haven't yet tried it I cannot say for certain. I'm still poking around because a lot of this code is so unlike any other that I've seen when it comes to templating. Entirely too damn complex for templaters to handle. Right now all we are reduced to is reskinning the same template over and over.

I'll report more as I poke around.

I think the icon issue is relatively minor compared to the problem of intermingled code and database access. There is no separation of function from appearance in the current templates. Theoretically, all the database access has to be rewritten eventually to use the 1.5 APIs instead of the 1.0 APIs. This is thousands of lines of code intermingled with HTML rendering statements.

While trying to upgrade I've seen some improvement in the individual file structure by separating database access to the beginning, and rendering to the end. It would be a much bigger improvement, I think, to start to separate the HTML into a separate set of includes and merging the database access at the beginning of many of the templates files into a single file. That way, changes could be made for 1.5 APIs that would not require rewriting parts of each and every file. For example, if showcat.php was split into db.showcat.php, and showcat.html.php, then one could hope only the showcat.html.php file needs to change for template display, and the db.showcat.php could eventually merge with db.listcat.php to reduce the number of files.

What do you folks think of that idea?