Loading...
 
 Error
  • The search index could not be updated. The site is misconfigured. Contact an administrator.
    SQLSTATE[42000]: Syntax error or access violation: 1064 unknown table 'themes_tiki_org_main_6620aca802169' in delete request
Tiki Design

Tiki Design

Forum List Topic List

Forums » Tiki Design » Separating parts
 
Thread actions
PDF Print this page
  • Print all pages

    • Separating parts

    Posted by Griebel on Thu 23 of Mar, 2006 17:17 GMT-0000 posts: 3

    Hello,




    I am a tikiwiki novice, I have now started creating themes. I will

    1. copy files
    2. modify files

    just like every theme creator does. For instance, I pick one theme with an odd 30 colours, history unknown, and modify the parts I don't care about to end up with 33 colours. Result: yet another theme, only more complex, there is not any obvious relation with the appearance at different ends of the wiki. The old css-files were almost unreadable, and the new ones are worse.

    I wish the theme definition process were less complex. There are many ways to obtain that, here are a few ideas.






    METHOD 1: Separate the definitions of fontfamily from fontsizes from colours from other elements. One file defines fontfamily, the theme just reads that file, and reads another one controlling colours etc.


    METHOD 2: Seperate the different parts of the wiki, e.g. one file controls blogs presentation, another controls forums etc. (This is not the same as what is called Theme Control in Tikiwiki, naturally.)


    METHOD 3: Something similar to the preprocessor directives of the C programming languages (who can live without it) would allow you to reduce the complexity considerably.





    - and you might combine these ideas, there are probably many more ways.


    Reads: 20646
    Link
    Posted by Gary Cunningham-Lee on Mon 27 of Mar, 2006 08:13 GMT-0000 posts: 254 Japan

    Hello,
    The old css-files were almost unreadable, and the new ones are worse.
    ...

    Have you looked at the CSS files for the Kubrick and Planetfall themes? I tried to organize them more coherently and add more useful comments. But there is still room for a lot of improvement. I plan to write up some wiki pages describing the selectors and properties in more detail, on a wiki feature basis and so on (when time permits).

    I wish the theme definition process were less complex. There are many ways to obtain that, here are a few ideas.

    ....
    - and you might combine these ideas, there are probably many more ways.

    I agree that there is a lot of potential to improve Tiki's CSS. There have been discussions about this, maybe with the idea of eventually revising the CSS selectors. But not much has been said recently. I think this should be a main topic at this themes site. Please make a wiki page here to present your ideas, if you like.

    One problem with Tiki CSS in the past is that, it seems, the different features have been created by different people, and each just adds his/her CSS selectors when writing the tpl files. This way we've gotten long lists of very specific selectors instead of few selectors covering many instances. At some point, there needs to be a CSS simplification process where the template files and CSS files are re-examined and rewritten. But this will cause all old styles and users' custom templates to be incompatible, so will have to be coordinated well with users and developers.

    -- Gary

    Link
    Posted by Griebel on Mon 27 of Mar, 2006 09:11 GMT-0000 posts: 3
    (I haven't got time to figure out the
    -tags. '>' hand-inserted ...)


    Gary wrote:
    >Mike wrote:
    >>The old css-files were almost unreadable, and the new ones are worse.
    >Have you looked at the CSS files for the Kubrick and Planetfall themes?
    >I tried to organize them more coherently and add more useful comments.

    No, I am very sorry, I hadn't realize that I could be misunderstood in this way. I wasn't referring to any specific css-files, by "new" css-files I certainly didn't mean Kubrick or Planetfall, I haven't examined them. I was describing in general terms the process of producing a theme which IMO leads to confusion, and I think we can agree on that.

    Are you saying, that if I want to create a new theme from scratch, I might be better off by starting out from Kubrick rather than from neat? (And Zuka, likey, likey much, can't wait to see it finished.)


    >topic at this themes site. Please make a wiki page here to present your
    >ideas, if you like.

    Could be, could be. marclaporte also has some interesting suggestions in another thread. I agree with all of the following:

    >One problem with Tiki CSS in the past is that, it seems, the different
    >features have been created by different people, and each just adds his/her
    >CSS selectors when writing the tpl files. This way we've gotten long lists
    >of very specific selectors instead of few selectors covering many instances.
    >At some point, there needs to be a CSS simplification process where the
    >template files and CSS files are re-examined and rewritten. But this will
    >cause all old styles and users' custom templates to be incompatible, so
    >will have to be coordinated well with users and developers.

    Link
    Posted by Griebel on Tue 28 of Mar, 2006 18:43 GMT-0000 posts: 3

    Gary wrote:
    >Mike wrote:
    >>The old css-files were almost unreadable, and the new ones are worse.
    >Have you looked at the CSS files for the Kubrick and Planetfall themes?
    >I tried to organize them more coherently and add more useful comments.

    Gary, I am sure you have done a great job with the new themes, but I counted the different colours used in the theme Kubrick:

    • #000000 #00FFFF #06C #112233 #147 #223344
    • #303F49 #304F30 #333 #333333 #334455 #336699
    • #395AAD #424242 #425262 #443F39 #444 #666666
    • #777777 #787878 #8CACBB #996600 #996633 #998833
    • #999999 #A1A1A1 #A9B8C2 #BBAA99 #C7D0D9 #CC0000
    • #CCCCCC #CCCCDD #CCDDCC #CCFFCC #DA9A9A #DAAAAA
    • #DAB0B0 #DABABA #DAC0D0 #DACACA #DAD0D0 #DADAC9
    • #DADCDC #DAE0E0 #DDD #DDDDCC #DDDDDD #DEDEDE
    • #DEE7EC #E7E7E7 #E7E9EA #E9ECEF #ECECEF #ECEFEC
    • #EEE #EEEE99 #EEEEAA #EEEEEE #F2F4F5 #F3F6F9
    • #F4F4F4 #F7F9CA #F7F9EA #F7F9FA #F7F9FD #F7F9FF
    • #F8F8F8 #FFCC77 #FFCCCC #FFD324 #FFF6BF #FFF7E6
    • #FFFFFF



    - over 70 different colours. I find that overwhelming.

    Link
    Posted by Gary Cunningham-Lee on Wed 29 of Mar, 2006 02:09 GMT-0000 posts: 254 Japan

    Gary wrote:
    Mike wrote:
    The old css-files were almost unreadable, and the new ones are worse.
    Have you looked at the CSS files for the Kubrick and Planetfall themes?
    I tried to organize them more coherently and add more useful comments.

    Gary, I am sure you have done a great job with the new themes, but I counted the different colours used in the theme Kubrick:
    [colors snipped]
    - over 70 different colours. I find that overwhelming.

    Yes, and it isn't even a very colorful theme. wink

    Part of the reason for the large number is that many people have worked on various parts of Tiki and set colors as they please for their own work. These are often "minor" elements like the border color around a particular class of box or text select gadget or something, or a new Tiki feature that is given its own styles. Sometimes I just copied these into the Kubrick style sheet (after checking the colors to make sure they were generally compatible) rather than changing them to match a limited number of colors in a Kubrick pallet.

    This is rather lazy on my part — a new theme should have a pallet specified at the beginning and then all colors to be used should come from that pallet rather than some being pasted in from another style.

    But in my opinion the main benefit of this, in itself, would be visual, rather than in reducing style sheet size. All color designations in CSS are the same byte size, so if a page element needs to be given a color style, it doesn't matter — from a file size perspective — if the color is the same as others or unique. But this reflects the problem of Tiki's CSS complexity.

    A stylesheet reduction/simplification could be done and would be beneficial if a general color setting would be set and then exceptions be very limited. This is done already, of course, but, for example, link colors are also set for cases where the background color is different or otherwise are a special case. If the link color variation is needed, fine, otherwise the general case should hold and specific specifications should be eliminated.

    Following your cue, I checked the Kubrick theme for instances of color being specified. Colors were specified over 300 times. This reflects the general over-specificity of Tiki CSS files, and even after I tried to trim the selectors down.

    The Snow theme, which I am just finishing now, has "only" 116 or so color specifications, so maybe progress is being made. smile

    Definitely work needs to be done on this. Even with all its features, there's no reason Tiki needs to have such huge CSS files.

    -- Gary

    Link

    Layout

    Subscribe to Tiki Newsletters!

    Delivered fresh to your email inbox!
    Newsletter subscribe icon
    Don't miss major announcements and other big news!
    Contribute to Tiki

    Site Config