Hi Devs, I have setup a public demonstration of my Bluebird Experimental Skin in the incubator:
http://incubator.myxwiki.org/xwiki/bin/view/BluebirdSkin/WebHome This demo is aimed to support the purpose of this brainstorming. I hope it will inspire you to comment further on this thread. For those who will undoubtedly ask, no this skin is not yet published. I doubt I will publish it since it is unfinished with some rough edges and missing features, but you may try to convince me of the opposite ;) On Fri, Feb 1, 2013 at 12:43 PM, Denis Gervalle <[email protected]> wrote: > > > > On Fri, Feb 1, 2013 at 11:52 AM, Paul Libbrecht <[email protected]> wrote: > >> Correct Jean-Vincent, and I was probably too harsh describing it, >> >> but I understood Ecaterina's point to be a strive for a radical request >> to move away from html. >> Maybe this can be described in several stages? >> > > What we are discussing is mainly to get away from producing the same html > in several places of our standard UI, so we can change it easily for > creating different kind of skins. Currently, to produce a button in the > XWiki UI, we always use the same html, but we produce that same HTML from > different places in the source code, and it is therefore not easy to change > the way button are rendered (to conform with markup require by bootstrap > for example). > > Usually, you do not really care about the HTML since you can use a custom > CSS to change its appearance. But here, we definitely want to the opposite, > adapting our HTML to support existing CSS like bootstrap, and benefit of > all the derived CSS based on it very easily. > > In no way, this will change your ability to use HTML in XWiki, we will > propose additional way to produce UI elements that will > integrate seamlessly with the XWiki UI. For exampke, when you write an > extension, you may want your extension to look like the rest of the UI, and > not reinvent the button. > > >> >> paul >> >> >> On 1 févr. 2013, at 11:09, Jean-Vincent Drean wrote: >> >> > AFAIU the thread is not about breaking things, it's about using xwiki >> > syntax and macros (mostly for forms since the 2.0 syntax covers a lot >> > of the html markup) to benefit from a standardized styling. Existing >> > HTML would still be working, and it would be possible to write apps >> > with HTML, but you'd have to handle styling on your own. >> > >> > On Thu, Jan 31, 2013 at 10:20 PM, Paul Libbrecht <[email protected]> >> wrote: >> >> >> >> Breaking the very broad toolset and knowledge of developers in HTML to >> create XWiki content and applications is, to me, suicidal. >> >> Who would be ready to replace most of its html by macros? >> >> >> >> Paul >> >> >> >> >> >> On 31 janv. 2013, at 15:26, Ecaterina Moraru (Valica) wrote: >> >> >> >>> Hi Denis, >> >>> >> >>> When we discussed the Vertical Forms Standard [1] Thomas mentioned >> >>> something about "commons tools to follow that standard (like form >> related >> >>> wiki macros for example)". Some considered that having macros for >> standard >> >>> HTML controls will just duplicate HTML language. >> >>> >> >>> One advantage of having such macros would be that for example (let's >> say >> >>> the macros will be defined in macros.vm) if you want to change the >> classes >> >>> used by the controls (like .buttonwrapper class for example), you are >> just >> >>> changing the macros, not all the places that call them. >> >>> >> >>> This way you could easily change what classes you assign to a button >> for >> >>> example from span.buttonwrapper input.button.secondary to >> >>> button.btn.btn-primary (bootstrap way - of course we will also need to >> >>> standardize the usage component: input, button, a, etc.) >> >>> >> >>> The example above refers mostly to standard HTML elements. Of course >> if you >> >>> want to use other types of components from different frameworks you >> will >> >>> need to rewrite the templates, and this always calls for a new skin. >> >>> >> >>> I thought about new skins for XWiki and since I joined the project we >> >>> mostly deprecated old skins than creating new ones. But one problem I >> have >> >>> is the concept of base skin. For me the base skin should be something >> very >> >>> minimal. >> >>> It should contain just the typography, standard controls, the grid, >> the >> >>> reset, anyway elements that are not layout dependent and that will >> work for >> >>> any skin. I'm not sure about templates, because mostly templates >> refer to >> >>> layout and how you arrange things and what functionality you reveal >> and >> >>> where, and this usually change with a new skin. Technical the base >> skin >> >>> should contain the Standard, the base for things that will remain the >> same >> >>> no matter what. Right now Colibri covers much more than that. >> >>> >> >>> And this standard is absolutely necessary also for the way we go with >> >>> extensions. We know very well that in an Open Source project, >> everybody >> >>> codes with his own style and having a common ground is essential from >> a >> >>> consistency point of view. All the applications that will be created >> and >> >>> published by the community members should have a common style that >> could >> >>> make them integrate well inside XWiki, no matter of the creator. >> >>> >> >>> So the conclusion is that for this we will need a very well documented >> >>> standard and the tools to enforce it. Not sure what this means. >> >>> >> >>> Also other things worth discussing is colorthemes variables and macros >> >>> against LESS variables and mixins. >> >>> Also the Bootstrap / LESS is also a direction bet, just like >> Prototype vs. >> >>> JQuery, and the solution we pick it would be great if it would be >> loosely >> >>> coupled. >> >>> >> >>> Thanks, >> >>> Caty >> >>> >> >>> P.S. Another discussion somehow related to extensibility is >> [Discussion] >> >>> Problematic ColorTheme extensibility >> >>> http://markmail.org/thread/ex6fgou6fl6vjwfr >> >>> >> >>> [1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms >> >>> >> >>> >> >>> On Tue, Jan 29, 2013 at 8:10 PM, Denis Gervalle <[email protected]> >> wrote: >> >>> >> >>>> Hi Devs, >> >>>> >> >>>> As you may have noted from a previous mail, I have given a try to >> skin >> >>>> XWiki differently, based on Bootstrap. There is certainly many ways >> to get >> >>>> it done, but IMO, building over any pre-made css solution requires an >> >>>> adaptation of the HTML generated. >> >>>> >> >>>> In the early days of XWiki, the were few places were we have HTML >> >>>> generated. Most of the html produce came from three major places: >> >>>> 1) .vm templates including macros.vm >> >>>> 2) java generated (#display()) >> >>>> 3) XWiki tech document >> >>>> >> >>>> While 2) and 3) either provide very basic markup or customizable one >> and >> >>>> are not so much, and 1) was fully customizable by skins, to work out >> a new >> >>>> skin was not too complex. >> >>>> >> >>>> Today however, the UI of XWiki has considerably increase its >> complexity, >> >>>> and the source of HTML has followed, added to the above 3: >> >>>> 4) XWiki and Java macros >> >>>> 5) JavaScript (ie: annotation UI, comments preview) >> >>>> >> >>>> Changing all these places has become really more painful. There is no >> >>>> central place, and a lot of hidden dependencies between UI components >> >>>> exists. Worse examples are those written in JS, that hook into the >> UI. >> >>>> >> >>>> I should admit that I have not a clear idea of the best way to >> improve >> >>>> that, but my feeling is that changing so much places simply to adapt >> our >> >>>> wiki skin to the "a la mode" skin solution (something that will >> happen >> >>>> again) is not nice. >> >>>> >> >>>> So this thread is now open for anyone to discuss the situation and >> for >> >>>> anyone interested to provide its input to the discussion. >> >>>> >> >>>> Looking at what I face building the UI with bootstrap, here is what I >> >>>> noticed: >> >>>> >> >>>> 1) Bootstrap customize standard tags, without any css class >> associated >> >>>> 2) Bootstrap provide standard css classes to skin a given kind of UI >> >>>> component >> >>>> 3) Bootstrap use these class and custom attribute to inject JS >> >>>> interactivity >> >>>> >> >>>> All these are really clean methods and work really well at building >> very >> >>>> simple html construct while providing nice looking and easy >> interface. >> >>>> >> >>>> Let's take a concrete example, to build a button, you may use either >> an a >> >>>> tag, an input tag, a button tag or whatever, and set it a 'btn' css >> class. >> >>>> You may complement it with additional 'btn-primary', 'btn-success', >> ... css >> >>>> classes, to choose the kind of button you really want. >> >>>> >> >>>> However, in our XWiki UI, there no single place where we construct >> buttons, >> >>>> we do so in some velocity macros of macros.vm, we do so in .vm of >> the UI, >> >>>> we also do so in javascript, and finally in some wiki documents, >> maybe we >> >>>> also generate some in a java component. >> >>>> All those buttons are usually built the same, with a very similar >> HTML, but >> >>>> there is no central place where the button markup is produced. >> >>>> >> >>>> And the same is true for most UI component. You may say we don't >> care, and >> >>>> CSS could solve them all, making any kind of markup look the way we >> want. >> >>>> But, we will loose the benefit of using existing CSS solution. And >> there >> >>>> are interesting benefit to that, since those solution gets >> customized, see >> >>>> BootsWatch for example. >> >>>> >> >>>> Therefore, it seems to me that we need something like an UI >> generator, so >> >>>> that when you build a application, you would simply says, I want a >> primary >> >>>> button here, a secondary button there, and it gets created both the >> way it >> >>>> should for your apps to use it, but also for the UI design we want >> to use. >> >>>> >> >>>> Defining a list of these UI component is not simple, but we may take >> >>>> Bootstrap as a starting point. There is in Bootstrap a large number >> of >> >>>> control already, that should cover many UI possibilities. >> >>>> >> >>>> How to provide that UI component to all the places we need it may be >> less >> >>>> obvious. For example, we need to create button from .vm, XWiki >> document, >> >>>> XWiki and java Macros, and even from javascript. Also defining how >> you >> >>>> could expect to interact with each control, from Javascript or from >> java on >> >>>> the server needs clarification. >> >>>> >> >>>> I have not yet googled, but there may be existing experience >> regarding >> >>>> these matters on other project. Not reinventing the wheel is always >> better. >> >>>> Your ideas are welcome. >> >>>> >> >>>> IMO, we really need that if we want our Skin 4.x to be really more >> usable >> >>>> for customization. >> >>>> >> >>>> WDYT ? >> >>>> >> >>>> >> >>>> -- >> >>>> Denis Gervalle >> >>>> SOFTEC sa - CEO >> >>>> eGuilde sarl - CTO >> >>>> _______________________________________________ >> >>>> devs mailing list >> >>>> [email protected] >> >>>> http://lists.xwiki.org/mailman/listinfo/devs >> >>>> >> >>> _______________________________________________ >> >>> devs mailing list >> >>> [email protected] >> >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> _______________________________________________ >> >> devs mailing list >> >> [email protected] >> >> http://lists.xwiki.org/mailman/listinfo/devs >> > >> > >> > >> > -- >> > Jean-Vincent Drean, >> > XWiki. >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
