Hi,
On Sat, Sep 28, 2013 at 9:54 AM, Thomas Mortagne <[email protected]>wrote: > 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. > I was looking at the site and I think a fixed width would be good for plenty of pages. For instance on this page: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki43#History Once you scroll down the page on a largish screen (mine's 1680px wide) you see plenty of one-line text interspersed between images, which is hard to read. Thus I'm more in favor of a fixed width website, but maybe slighyly larger than 960px. Maybe around 1164px wide? Guillaume > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
