16 Jul
2014
16 Jul
'14
11:44 a.m.
On Tue, Jul 8, 2014 at 6:35 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> 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…
-> 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 <
gdelhumeau(a)xwiki.com>gt;:
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs