Related to Vincent's comment: As a designer I would want to be able to write CSS as simple as possible. Already I need to know that I need to add my CSS to a SSX object. I wouldn't want to know that if I need to write LESS I need to use whatever other object or macro. Also I want a simple solution where the existing CSS written to be easily adaptable. If I need to use some FlamingoThemes variables, already is complicated that I need to know that I need less. So I'm not a fan of having the css in wiki syntax. I don't want to write css with ruby, python or whatever. I was in need of velocity because back then less didn't existed (so we didn't had variables, etc.) Also I assume css and less would need different macros and maybe they would need to be nested and mixed together, which is again more of a xwiki style, but definitely not a 'web' style.
Thanks, Caty On Thu, Dec 11, 2014 at 1:03 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote: > I would like to add some precisions. > > Most of my work during this week was on the LESS Module to be able to > compile (with a cache mechanism) any kind of resources and not only files > anymore. > > Thanks to that, my prototype of SSX implementation was easy to do in 2 > hours or so, and I believe using my refactored API in any other > implementation (new xobjects, etc...) could be done quickly. > > So I am not asking you to accept an already-written-solution and we can > still discuss :) > > What Vincent proposes seems to be a good idea. However, after some > discussions with him, it would require an amount of work that is not > compatible with the current release date. > > So my actual proposal is the following: > > - Modify the SSX object to introduce the LESS preprocessor, as I have > proposed previously, as a temporary solution/hack. > - In the future (7.x maybe?), deprecate the current SSX object and create a > new SSX object that will use the wiki syntax. Create a {{less}} macro too > to be able to use LESS everywhere (in new SSX objects but also in the > XDOM). > > I hope you like this idea, > > Thanks, > > 2014-12-11 11:29 GMT+01:00 [email protected] <[email protected]>: > > > > > > > On 11 Dec 2014 at 11:08:16, Ecaterina Moraru (Valica) ([email protected] > > (mailto:[email protected])) wrote: > > > > > Why do we need to add a new essx one? IMO we just add the new property > > and > > > make sure the default value for 'CSS preprocesor' is 'none’. > > > > I think you didn’t read my proposal because I explained why :) > > > > The solution with CSS preprocessor is a hack, doesn’t always work as > > Guillaume pointed out and doesn’t support all future use cases. > > > > The solution I proposed solves all the needs, a lot more, and goes in the > > general direction where we remove all places in xwiki where we support > only > > one specific language and replace that by wiki syntax (and thus support > all > > existing languages). In this case, it’s not normal that we support only > > velocity and my proposal not only solves this but also solves using the > > LESS processor or any other thing you wish to do. > > > > Thanks > > -Vincent > > > > > Thanks, > > > Caty > > > > > > On Thu, Dec 11, 2014 at 11:59 AM, [email protected] > > > wrote: > > > > > > > Note that if we don’t want to break backward compatibility we keep > the > > > > current ssx and deprecate it and introduce a new essx one (for > extended > > > > ssx, or any other name…). > > > > > > > > Thanks > > > > -Vincent > > > > > > > > On 11 Dec 2014 at 10:54:46, [email protected] ([email protected] > > (mailto: > > > > [email protected])) wrote: > > > > > > > > > Hi Guillaume, > > > > > > > > > > This is not a domain I know well so maybe what I’ll say is not > > correct.. > > > > :) > > > > > > > > > > What about keeping the exact same xobject structure as now but > > instead > > > > of considering the content of the textarea to be plain text we > > consider it > > > > to be wiki syntax that is rendered using our plaintext renderer. > > > > > > > > > > This would allow use to use any more (including the {{velocity}} > > macro, > > > > {{include}} macro, etc) but it also allows us to introduce some new > > > > {{less}} macro that would preprocess its content and generate CSS. > > > > > > > > > > This would also allow us to remove the “parse” option which tells > us > > if > > > > we run velocity or not (this is actually bad since we may want to run > > ruby, > > > > python, groovy, etc). > > > > > > > > > > WDYT? > > > > > > > > > > Thanks > > > > > -Vincent > > > > > > > > > > On 11 Dec 2014 at 10:20:49, Guillaume Louis-Marie Delhumeau ( > > > > [email protected](mailto:[email protected])) wrote: > > > > > > > > > > > Hi. > > > > > > > > > > > > Since the beginning of the week, I am working to have the LESS > > > > > > pre-processor inside our Skin Extension objects (see: > > > > > > http://jira.xwiki.org/browse/XWIKI-10708). It would enable us to > > use > > > > the > > > > > > Flamingo Theme variables and all bootstrap's mixins inside SSX > (see > > > > > > http://jira.xwiki.org/browse/XWIKI-11374). > > > > > > Example of use-case: http://jira.xwiki.org/browse/XWIKI-11408 > > (Menu > > > > > > Application: Improve default look to make it better-looking with > > the > > > > > > Flamingo skin). > > > > > > > > > > > > I have created a design page there for the details: > > > > > > > > http://design.xwiki.org/xwiki/bin/view/Proposal/LESSModuleImprovements > > > > > > > > > > > > I propose to add a new property inside the > > XWiki.StyleSheetExtension > > > > class > > > > > > which will be called "CSS preprocessor". The actual possible > values > > > > would > > > > > > be "LESS" or "none", but in the future we can imagine having > > "SASS" or > > > > > > anything else. Then I propose to change the actual SSX action to > > > > perform a > > > > > > LESS compilation if needed. Note that the user would still be > able > > to > > > > use > > > > > > or not Velocity in addition of the CSS preprocessor. > > > > > > > > > > > > The other possibilities (that are not part of this proposal) are > to > > > > create > > > > > > a new XWiki.LESSStyleSheetExtension and a new LSSX action which > > would > > > > > > behave exactly as the previous objet and action, or to have the > > > > ability to > > > > > > choose the processor directly inside the SSX content, with a > > special > > > > line > > > > > > like "# preprocessor = less" or something like that. > > > > > > > > > > > > I have made a prototype that is working ( > > > > > > https://github.com/xwiki/xwiki-platform/tree/feature-less-ssx) > > and I > > > > am > > > > > > taking care of the compatibility with older skins that do not use > > LESS > > > > > > (Colibri for instance). > > > > > > > > > > > > Here is my +1. I would like to commit it today to have it in > > 6.4M2. I > > > > have > > > > > > done a lot of refactoring on the LESS module (with a better cache > > > > system > > > > > > among other things) that I don't want to commit in a release > > candidate. > > > > > > > > > > > > Thanks, > > > > > > -- > > > > > > Guillaume Delhumeau ([email protected]) > > > > > > Research & Development Engineer at XWiki SAS > > > > > > Committer on the XWiki.org project > > > > > > _______________________________________________ > > > > > > 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 > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Guillaume Delhumeau ([email protected]) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
