On Tue, Jul 8, 2014 at 6:35 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
> Hi. > > I'm thinking about this topic for weeks, and it is difficult to me to make > a choice, simply because I always focus on drawbacks, which all proposals > have. There is no perfect choice here. But there is probably a most > realistic one. > > My proposal is the following: > > - We still propose some standards like the Vertical Align Form ( > http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms ). Because > we like it. > Another reason why I prefer the .xform is the usage of dl-dt-dd in its structure. This means that if the CSS is disabled it fallback on the browser defaults (compared to BS usage of simple divs). Supporting CSS-disable or JS-disable use cases is a topic that we can discuss if we still want to support. > - We still propose some of our own CSS classes because we need them. > We have some classes that are used everywhere http://platform.xwiki.org/xwiki/bin/view/DevGuide/SpecialCSSClasses like (.suggestUsers, .loading, etc). Again we can discuss if we want to keep them and integrate them in our standard or if we should deprecate them (for some classes we have a BS replacement, some like .withTip are deprecated by placeholders, but we still might have some classes that are just XWiki specific). > > - People are allowed to use any Bootstrap feature they want. They are > packaged with Flamingo. > We cannot force anyone to use something that they don't want, the issue is what we recommend. If we recommend a specific version of Bootstrap and people start using it, we need to be careful on what solutions we provide if we upgrade Bootstrap to another version. > - When we upgrade to a new version of Bootstrap, it's the responsibility of > the developers to fix their applications if they are broken. > Another solution would be froze a specific BS version as our standard, but I don't think it's desired. Assuring ourselves backwards compatibility for a framework that doesn't care about it is not a solution either. An improvement at least would be the extensions creators to mention on which XWiki version they build their extension on, in order for us to determine the BS version they used. > - We need to update > http://platform.xwiki.org/xwiki/bin/view/DevGuide/FrontendResources > > - The theme Application will be skin-dependent (because of the preview), > and because some Theme variables have sense only on the CSS framework we > use in the skin. Moreover, some color themes are good looking on some skins > and ugly on some others. > As I said in a previous mail, we can have a common base, shared by both Colibri, Flamingo or any other future skin, and we can have skin-dependent variables. > > Example: here a color theme > http://extensions.xwiki.org/xwiki/bin/view/Extension/FlamingoColorTheme > - screenshot on Flamingo: > > http://extensions.xwiki.org/xwiki/bin/download/Extension/FlamingoColorTheme/flamingoPreview61M2.png > -> good looking > - screenshot on Colibri: > http://tof.canardpc.com/view/903b37a6-64c8-4ccd-9a02-d34fc1027266.jpg > -> ugly > > It might not look perfect but at least they are compatible. > It does not make sense to propose that same color theme for both skins. > > I do NOT propose: > - to add a namespace to the Bootstrap classes, because it implies to modify > the bootstrap sources (JavaScript + LESS code), which must be maintained > each time we upgrade to a new minor version of Bootstrap. > I agree. Too much work and except the separation advantage, it increased the time you need to use it, the size of the file, etc. > - to create our standards, simply because it is the business of Bootstrap, > and we do not have the manpower to do the same thing as well. > We still need to define our xwiki-specific things, but sure we shouldn't reinvent the wheel for everything. > > The drawback of this solution is that it might be broken if Bootstrap > breaks the retro-compatibility in the next versions. > We kind of need to take a leap of faith. If Bootstrap will break everything for us, we can: - create a new skin :) that uses another framework that cares about backwards compatibility or write our own standard; - the extensions could use a ssx with the correct BS version that they were created on or use an import to the needed version; - we might need to froze a specific BS version in our platform or rewrite our code to match the new BS version or another framework. > > > That is my thoughts. I think it is important to all agree on this, because > we would like to have the Flamingo Theme Application for 6.2. > As you said there is no perfect solution and having a third-party entity there is no way we can vouch for their actions or assure a perfect backwards compatibility. Flamingo is still not a clean skin and again it builds up on our old templates structure and still assures backwards compatibility as well as it can. But at least is a step further. Depending on the success of this skin, we can decide in the new future skin what path to take and maybe we can find solutions to provide multiple supported skins. Thanks, Caty > > Thanks, > Guillaume > > > 2014-07-02 15:19 GMT+02:00 Guillaume "Louis-Marie" Delhumeau < > [email protected]>: > > > Hi guys. > > > > I am starting this thread to talk about UI conventions that we should > > recommend to every developer who want to write an application in XWiki. > > > > Currently, we have some standards (see > > http://platform.xwiki.org/xwiki/bin/view/DevGuide/FrontendResources) and > > we need to update this documentation since it is still speaking about > > PrototypeJS and Bootstrap is not even mentioned. I think it is the time > to > > think about what these conventions should be now. > > > > With Vincent and Caty, we have thought about it and our ideas are written > > there: http://design.xwiki.org/xwiki/bin/view/Proposal/UIStandards > > > > I let you read this design page and express your ideas. I need your > > opinion to know how I should implement the (color) theme application for > > Flamingo. > > > > Thanks, > > > > Guillaume > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
