theming `#themename` (how to reuse existing themes..? eventually how to replace css files directly if theme changes)

[Klap-in]

Some notes:

• fancytree default styles are partly overridden by DokuWiki styles (e.g. the alignment of the expanded nodes)
  • needs prefix with selector:
    • rebuild with the provided fancytree less files the style sheets ourselves by including in all.css, but needs some workarounds for paths and a) retrieving the config setting which style sheet should loaded(variables dependent on DokuWiki’s config settings seems not possible…)/or b) manner to include all the different ‘skins’ next to each other were the skins should not influence each other.
    • modify the existing fancytree style sheet by prefixing all rules with a selector (can that prefixing may be scripted?). Such a style sheet can be included with TPL_METAHEADER_OUTPUT event (works).
  • can we keep using more styles on the same page? default structure of fancytree is including a style sheet per page. So one style per page. This would remove the possibility of style sheet i.e. skin per Indexmenu, I will in that case not implement per page, so only global setting in the config.
  • ~Probably with rebuilding styles via less~, all styles can be prefixed with skin selector as well. Includes a huge chunk of style sheets in the css.php, with lot of (almost) duplicated code, of which just a limited part is used.
  • Not working: the less parser in DokuWiki does not support @import (multiple) "../skin-common.less";, therefore this import is only performed once.
  • Add via javascript (using aan entry in JSINFO?) only the used stylesheet links in the header. Does this give undesired effects during loading of the page? Needs still prefixing with selectors for each skin style sheet.
  • About prefixing each skin style sheet with extra selectors:
  • Using grunt for regenerate is cumbersome as that environment needs to be set up, and fancytree provided grunt config seems for deploying their entire setup. We needs much smaller.
  • Via less compiler in a separate run of css.php seems bloated as well.
  • Remains is creating a script to prefix each rule off the supplied fancytree style sheets?

There is not yet a simple copy-paste example for creating a skin. All provided skins seems more different then I expected on first sight. We have now 32 themes for the js version of Indexmenu, if we like to offer something similar, a simple base example should be available, which let people create their own by mainly creating the images. Probably also a svg example is desired, to encourage higher quality? Bootstrap/svg/awesome needs also extra javascript settings/extra fancytree extension?

skin-bootstrap needs bootstrap styles. This skin works only at the moment with a template that includes these e.g. template:bootstrap3, not sure how about newer bootstrap versions as used by plugin:combo or template:mikio. Probably similar for skin based on awesome/material framework?

[Klap-in]

My idea was now to offer some skins for indexmenu, as provided by Fancytree. One approach could be to include all these skins with the all.css of the plugin. With the current skins that is already 10 to 20kB times 10 skins = 0.1 to 0.2MB of extra styles, unfortunately with a lot of (almost) duplication. The dTree based index had 32 skins, if someone makes an effort to convert some of these, it will become even more... That is already a bit compared to ~160kB size for my current setup (for 300B transferred).

Is it worth to split these sheets off and only load if they are used? In my first attempt for that I already observed the issue that I do not know which extra pages are shown next to the main article. For the main article I can request the used themes, stored as metadata, for the global $ID. The sidebar I could maybe retrieve by copying the logic from the 'dokuwiki' template for determining a sidebar, but that is one template. Of course other pages can be included in different manners around the main page (or with include plugin in that page). So it is difficult to know for which pages I should check the metadata for the used themes. Is there a relevant alternative?

[Klap-in]

Not working for importing all skins in one go, because @import can only import once in lesserphp. It does not support @import (multiple) "foo.less";

 //Mixins
.importSkin(@skin-foldername) {
    &.@{skin-foldername} {
        @import "scripts/fancytree/@{skin-foldername}/ui.fancytree.less";
        //overwrite default variable: @fancy-image-prefix: "./skin-win8/"; the current less compressor does not update paths
        @fancy-image-prefix: "/lib/plugins/indexmenu/scripts/fancytree/@{skin-foldername}/";
    }
}

//wrap everything by plugin class to ensure its dominates default dokuwiki paddings etc.
.indexmenu_js2 {
    //workaround needed for LESS processor of DokuWiki
    .setBgImageUrl(@url) when not (@fancy-use-sprites) {}
    .useSprite(@x, @y) when not(@fancy-use-sprites) {}

    //.importSkin(skin-lion);

    .importSkin(skin-win7);
}
 //skin files are loaded separatedly, and should all prefixed with .indexmenu_js2.skin-<name>

I guess some handwork is needed... suggestions welcome of course.

[Klap-in]

@splitbrain The themes for Fancytree come with a lot of similar, but not same, style sheets. Do you have suggestions how to approach loading the css? just include all of them in screen.less? or do you think it is worth to use manners to load them more on demand? (so far via TPL_METAHEADER_OUTPUT was not working, because I have not yet a way to let sidebars, included pages and other rendered pages around the main page (for which I can easily, with global $ID, request the theme from metadata) tell they have a theme in use.

[Klap-in]

Workaround now by replacing @import "../skin-common.less"; in the skin's less-file by @import "skin-common.less";, and placing a copy of that file in every skin folder.

[Klap-in]

Skins work. There are still improvements possible with the svg skins, but that is another issue.