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 <
gdelhumeau(a)xwiki.com> 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 vincent(a)massol.net <vincent(a)massol.net>et>:
On 11 Dec 2014 at 11:08:16, Ecaterina Moraru (Valica) (valicac(a)gmail.com
(mailto:valicac@gmail.com)) 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, vincent(a)massol.net
> 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, vincent(a)massol.net (vincent(a)massol.net
(mailto:
> vincent(a)massol.net)) 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 (
> gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) 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
(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 (gdelhumeau(a)xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the
XWiki.org project
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> >
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the
XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs