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

Hi, Thank you for your votes. I've integrate the Homepage changes and we are using the Junco skin on xwiki.org __Discussion 1__ So one of the problems is 'Clearing your Cache'. In order to see the changes correctly you need to refresh the page and make sure the cache is updated with the new style rules. It would be great if someone would know how we could force the clearing

the cache. Maybe http://jira.xwiki.org/browse/XWIKI-6073 ?

__Discussion 2__ On a related topic, Vincent thinks we should not use a 'centered' design, instead have (just like Colibri has) a 'full width 'design. I've made some screenshots (please take a look at them in full view): * Centered:

**Full width:

Why I disagree (having full width and prefer the centered version): - xwiki.org is a documentation site so most of its content needs to be read; - From a readability point of view, if the line is too long it is harder for the eye to read it, please read http://baymard.com/blog/line-length-readability ; - Being a responsive skin, for smaller devices the content goes full

so the centered width is just for large resolutions; Let me know what you think,

Caty On Thu, Sep 26, 2013 at 11:08 AM, Ecaterina Moraru (Valica) < valicac(a)gmail.com&gt; wrote: wrote: > >> Great job indeed. I installed on a test wiki on a 4.5 farm and it looks >> quite nice. >> >> I have a few questions. >> >> 1/ If I understand properly we have a legacy.css where lives all CSS of >> HTML that would not have been made clean plain bootstrap compatible

>> Is that so ? >> > > 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

> 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. > > >> 2/ In terms of work, how much and what is needed to get to a point

>> this could become our default skin, knowing that we should not have >> feature >> regression, for instance users should still be able to build their

>> themes in Wysiwyg like they can with colibri. >> >> I'm sure we can find a solution to do on the fly compiling when saving >> color themes so to solve the issue of needing LESS. >> > > The integration problems are presented above (__Platform integration > problems__). One is the need to be able to build LESS files and update

> 'on the fly'. > Regarding ColorThemes values, there are 2 files: > - global/xwiki-colorthemes.less - which is kind of a colorThemeInit.vm > >

> - <theme>/xwiki-colortheme.less - which overrides the initialization and > provide colors for a specific theme > Blueberry example: >

> > So when changing ColorThemes values, we need to make sure we update this > files. > > >> >> 3/ How much is needed to get rid of legacy and have a fully native skin >> with the new system ? >> > > 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

> the xwiki-common.less >

> > If we rewrite it whole, the only problem is that it will be harder to > update both Colibri and Junco. > > >> >> 4/ What is the migration path for a wiki where a custom skin has been >> built >> on colibri >> > > 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

> had any default padding, while after mapping they do. If someone use

> 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. > > >> >> 5/ What are the potential consequences on future compatibility with >> colibri >> based skin, particularly if we start modifying our HTML produced by >> different modules ? >> > > 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

> not called in legacy or xwiki-mapping. If a class is present in these

> 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

> their existence). > > Thanks, > Caty > > >> >> Ludovic >> >> >> >> 2013/9/20 Ecaterina Moraru (Valica) &lt;valicac(a)gmail.com&gt; >> >> > Hi devs, >> > >> > For the past weeks I've been working on a skin based on Bootstrap[1]. >> You >> > can read more about it and test the new Junco Skin at >> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin >> > >> > This proposal is about using the Junco Skin (Blueberry >> > Theme< >> > >>

>> > >) >> > for xwiki.org. >> > I prepared some responsive screenshots for the xwiki.org Homepage

>> an >> > Extension page. >> > >> > >>

>> > >> > This is my +1 >> > >> > Please report any issues on >> https://github.com/evalica/bootswatch/issues >> > >> > __Advantages__ >> > - a change is always welcomed, shows the users there is activity on

>> > website; >> > - the skin is responsive; >> > - by using Bootstrap we have the whole framework's power to use

>> > components, etc.); >> > - we have the chance to test a bit the skin in production and see the >> > possible bugs, in order to later integrate; >> > - IMO the skin looks nice :) >> > >> > __Disadvantages__ >> > - the only disadvantage is that there will be bugs and they will take >> some >> > time to be detected and fixed; >> > >> > __Platform integration problems__ >> > 1. currently the new skin uses the HTML5 doctype. This is needed if

>> were >> > to use some Bootstrap JS components (carousel, menus, etc.) - which

>> > currently don't on xwiki.org, so I could use the old doctype (but

>> > some >> > of the testing purpose). Because of the HTML5 doctype, the HTML >> validation >> > fails. See http://jira.xwiki.org/browse/XWIKI-7552 >> > >> > 2. Junco Skin currently doesn't have support for changing the >> ColorThemes >> > on the fly. I would need the help of a developer to fix this

>> > not so much a problem for xwiki.org (I could fix them by duplicating >> some >> > code in the xwiki.org skin), but it is a problem for the

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs