Re: [xwiki-devs] [Proposal] Use Junco Skin for xwiki.org

On Wed, Sep 25, 2013 at 11:13 AM, Ludovic Dubost &lt;ludovic(a)xwiki.com&gt; wrote: I've took colibri.css: - stripped it from any rules that Bootstrap already covers (reset, standard html elements, forms, etc.); - mapped what I could to Bootstrap components (tables, boxes, panels, etc.); - stripped layout elements and tried to get rid of ColorThemes values (in the end realizing that I can't, without loosing functionality); - cleaned the remaining selectors and properties (removed IE6,7 rules; removed rules that maybe are covered by Bootstrap; etc.) What remained are classes that will be needed by any new skin; classes that kind of represent the CSS API (although there are still parts that could be moved to their specific component file). I though that if someone makes a change in Colibri and that selector is also in legacy.css it should be ported here (that's why I left the selectors as original). Everything that is in legacy.css could be rewritten in junco.css, but it will create a bigger gap between the two skins. The integration problems are presented above (__Platform integration problems__). One is the need to be able to build LESS files and update them 'on the fly'. Regarding ColorThemes values, there are 2 files: - global/xwiki-colorthemes.less - which is kind of a colorThemeInit.vm https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-colort… - <theme>/xwiki-colortheme.less - which overrides the initialization and provide colors for a specific theme Blueberry example: https://github.com/evalica/bootswatch/blob/junco-themes/blueberry/xwiki-col… So when changing ColorThemes values, we need to make sure we update this files. As stated above, legacy.css is not a limitation. We could rename it from legacy.css to base.css or api.css, we could maybe write some more performant selectors or maybe write them using LESS nested selectors. The file contains the common denominator for Colibri and Junco and some parts of the layout could be removed from it, in order to make it a true API file. All the selectors that will be removed from here will end up in the xwiki-common.less https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-common… If we rewrite it whole, the only problem is that it will be harder to update both Colibri and Junco. Because of the mapping between XWiki and Bootstrap the Colibri classes will be covered in Junco. The problem are base HTML elements, that may have other default values. I'm sure tables will produce some problems, because in Colibri they didn't had any default padding, while after mapping they do. If someone use table for layout, there will be some extra spacing. There is not migration path for skins like that. Although we should have minor problems, they will need to be tested and fixed manually. So the current HTML structure is covered by legacy.css and xwiki-mapping.less. If someone will want to change the HTML structure, you need to: - make sure that the classes you delete are not 'API', this means they are not called in legacy or xwiki-mapping. If a class is present in these files means it also has a significance in Colibri; - if you find a certain class, don't delete it. Instead just append your new class or Bootstrap class. Keeping the legacy class, it will have a fallback if Colibri skin will be used. Of course there will be differences between skins if we start using Bootstrap components and that is normal (because Colibri will not know of their existence). Thanks, Caty