Re: [xwiki-users] Creating my own skin

On 3/14/07, Antonio Goncalves <antonio.mailing(a)gmail.com> wrote: History: 1. At first, the skin was written in a few (~5) css files, where all the css properties were put together. (early variants of the 'default' skin) 2. Then came the idea of separating the different components of the skin: basic elements, layout, colors, etc. Some of the files from 1/ were split, part of the css was moved around. This happened along with working for the new skin ('xwiki10'), so old content was reorganized and new content was added. Together with the fact that very little time was available, the whole process ended in the mess you see in the current skin. 2b. At the same time, there was the idea of making a XWiki.Skin class, containing some options for colors, margins, widths, and to generate the skin based on these variables. For example, there should have been a 'padding' property which should have been used for panels, menu, page content... It was working for a while in the 'xwiki10' skin. The skin was supposed to be customized (well, based on the same general layout) using a skin wizard. 3. When work for the current skin ('xwiki10b1') started, even more css rules were created and added. 4. In the (near) future, the skin will be cleaned up, resulting in a clear separation of file purpose, no more deprecated code, and the ability to change easily the skin. 5. In the distant future, xwiki plugins will be able to register new css files, which won't be stored in the skins directory, but either as files in the jar/xar, or as attachments to a page. Core files: - style.css = top level style file. It's purpose is to include all the other files. If there is any other css in there, it shouldn't. - elements.css = intended to provide general design rules regarding the html elements. For example, default font size and family for headings, underline for links, etc. It should not provide color properties. - classes.css = like elements.css, but formats elements having a similar semantic meaning (after all, a class should have a semantic name, and not a random id). As examples, .underline, .hidden, .sep, .wikicreatelink, or .heading-1-1. This should only contain general classes, for specific elements see presentation.css - screenlayout.css = the place where the general layout of the interface is specified. This file should contain rules regarding position, dimension and display mode for the major elements of the interface (header, side panels, menu, footer...) - presentation.css = refinement of screenlayout.css. This is where borders, margins, paddings are set, font styling for objects not in elements.css or classes.css, along with some specific elements of the layout which are not affecting the general layout (where is the profile picture displayed, how is the comment auther displayed, etc.) - colors*.css = the place where the skin gets painted. Without this file, the skin should be black and white only (except the blue links). Font color, background, border color, Special purpose files: - rss.css = a few rules to format how profile rss is displayed - microformats.css = stylesheet to format the different microformats-enabled pages (user profile, blog, calendar...) - chwSkin.css = formatting for the Chart Wizard (soon to be re-released) - tdwSkin.css = formatting of the Table Datasource Wizard (part of Chart Wizard) - print.css = formatting for the @media print. Currently kind of empty and useless, it must be written once the albatross skin is ready. Deprecated (soon to be removed) - wiki.css = it was supposed to format wiki generated syntax, like .wikilink and .heading-1-1 - xwiki.css = it was one of the few files holding css (stage 1) - ie.css = some old hacks to make the 'default' skin work in IE too. - styel1/2/3.css = variants of the 'default' skin, with green, pink and ~yellow colors. - temp.css = used for some tests; generally a buffer before splitting rules among the other files. Possibly usable files, if somebody makes the skin wizard. - customlayout.css = a dynamic version of screenlayout.css, using properties defined in a skin object. Should be parsed by velocity. - customcolors.css = same, but for colors. Hope this helps. Sergiu -- http://purl.org/net/sergiu