On Fri, Sep 27, 2013 at 7:22 PM, Ecaterina Moraru (Valica) <[email protected]> wrote: > 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 of > the cache. Maybe http://jira.xwiki.org/browse/XWIKI-6073 ?
Yea this one is a tough one we have since a while now... > > __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: > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgJuncoHomepage/testCentered.png > **Full width: > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgJuncoHomepage/testFull.png > > 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 width, > so the centered width is just for large resolutions; > > Let me know what you think, Centered is one thing but right now the width of the content is way too small for me. This can be OK on a website with very few information but xwiki.org is a wiki, not just a website with a few pages designed specifically for small width. Sure I don't need to move my eyes much in http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ but at the same time it's totally unreadable anyway. Whatever the scientific arguments I can say that a layout taking the full available width is way more comfortable for me. > Caty > > > > On Thu, Sep 26, 2013 at 11:08 AM, Ecaterina Moraru (Valica) < > [email protected]> wrote: > >> >> >> >> On Wed, Sep 25, 2013 at 11:13 AM, Ludovic Dubost <[email protected]>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 HTML. >>> 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 (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. >> >> >>> 2/ In terms of work, how much and what is needed to get to a point where >>> this could become our default skin, knowing that we should not have >>> feature >>> regression, for instance users should still be able to build their color >>> 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 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-colortheme.less >> - <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-colortheme.less >> >> 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 in >> the xwiki-common.less >> https://github.com/evalica/bootswatch/blob/junco-themes/global/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 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. >> >> >>> >>> 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 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 >> >> >>> >>> Ludovic >>> >>> >>> >>> 2013/9/20 Ecaterina Moraru (Valica) <[email protected]> >>> >>> > 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< >>> > >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin#HTheme:Blueberry >>> > >) >>> > for xwiki.org. >>> > I prepared some responsive screenshots for the xwiki.org Homepage and >>> an >>> > Extension page. >>> > >>> > >>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgJuncoHomepage >>> > >>> > 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 the >>> > website; >>> > - the skin is responsive; >>> > - by using Bootstrap we have the whole framework's power to use (grids, >>> > 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 we >>> were >>> > to use some Bootstrap JS components (carousel, menus, etc.) - which we >>> > currently don't on xwiki.org, so I could use the old doctype (but lose >>> > 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 problem. Is >>> > 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 integration. >>> > >>> > 3. Being build on Bootstrap, it needs LESS to compile the files into >>> CSS. >>> > Again I would need a developer to see how we could integrate the >>> building >>> > of the themes in platform. Right now this is done locally, partially >>> manual >>> > by using Grunt. >>> > >>> > Tell me what you think and take some time to test the skin, >>> > Caty >>> > >>> > [1] http://getbootstrap.com/ >>> > _______________________________________________ >>> > devs mailing list >>> > [email protected] >>> > http://lists.xwiki.org/mailman/listinfo/devs >>> > >>> >>> >>> >>> -- >>> Ludovic Dubost >>> Founder and CEO >>> Blog: http://blog.ludovic.org/ >>> XWiki: http://www.xwiki.com >>> Skype: ldubost GTalk: ldubost >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
