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

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

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

On Thu, Dec 11, 2014 at 1:54 PM, [email protected] <[email protected]> wrote:

On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:

...

Related to Vincent's comment: As a designer I would want to be able to write CSS as simple as possible.

Then just write CSS directly :)

...

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.

That’s not CSS, that’s LESS.

...

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.

What’s the need for a CSS macro?

Thanks -Vincent

I don't want to write {{less}} or {{css}} every time I do some styling. I really don't think we need wiki syntax (scripting macros precisely) when writing style sheets. No one has ever asked for this. So I'm -1. As Caty said, users should be able to paste their CSS/LESS code without doing any useless wrapping. It's a big difference between the content of a wiki page and the style sheet object. I want to be able to use wiki syntax in the content of the wiki page because it doesn't have any specific purpose. The content can be used to generate HTML, JSON, XML, whatever, depending on the application. On the other hand the style sheet extension object has a very specific purpose. It should be very easy and really straightforward to use it (e.g. "don't make me think").

PS: Saying that you’ll never need scripting is just wishful thinking IMO… I can already find tons of use cases where you’d need it (not even counting the many places we use velocity in our SSX)...

From my experience we don't use scripting that much in SSX objects. And when we do, it really boils down to:

(1) color theme variables, which will be replaced by LESS variables (2) getting the URL of some internal resource (getSkinFile / getAttachmentURL). For this, if we want to get rid of scripting we can introduce a special syntax for the url('xyz') CSS value: background-image: url("skin://icons/xwiki/create-link.png"); background-image: url("attach://myOwnIcon.png"); In any case, +1 for Guillaume's proposal (adding a new property to the SSX object). Thanks, Marius

...

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] :

...

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

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

  On 11 Dec 2014 at 14:40:31, [email protected] ([email protected](mailto:[email protected])) wrote:

On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:

...

On Thu, Dec 11, 2014 at 1:54 PM, [email protected] wrote:

...

On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:

...

Related to Vincent's comment: As a designer I would want to be able to write CSS as simple as possible.

Then just write CSS directly :)

...

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.

That’s not CSS, that’s LESS.

...

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.

What’s the need for a CSS macro?

Thanks -Vincent

I don't want to write {{less}} or {{css}} every time I do some styling.

My idea would be to have a default source syntax to be plaintext + macro (i.e. plaintext but also support to specify macros, possibly using the same syntax as for XWiki Syntax 2.x).

...

I really don't think we need wiki syntax (scripting macros precisely) when writing style sheets.

Yes I didn’t express myself properly. I meant a Rendering Syntax (not Wiki Syntax).

...

No one has ever asked for this. So I'm -1. As Caty said, users should be able to paste their CSS/LESS code without doing any useless wrapping.

It’s very simple it boils down to only 2 possibilites:

1) Either you have a select box that you need to click to explain what your content is about 2) or you have a context field only and you decide what it contains by using some type of annotations (and in my first proposal the default was CSS since this is what a SSX object is about, so for CSS you don’t need to specify anything).

Now 1) initially seems to be fine with “Syntax” combo with various options: “CSS”, “LESS”, “CSS+Velocity”, etc. The only problem is that you’ll never be able to specify all the syntax combination that exist.

2) makes it even more easy than now to write pure CSS (since it removes the velocity checkbox and you paste CSS directly) but also allows extending with other more exotic features such as LESS, SAAS, scripting, include (so that the content is defined on some other pages and can be reused between SSX)

...

It's a big difference between the content of a wiki page and the style sheet object. I want to be able to use wiki syntax in the content of the wiki page because it doesn't have any specific purpose.

There’s no difference at all. Whenever you have a text area you need to put content in it that’s of a given syntax, whatever the syntax! This is exactly the same for a wiki page. 

BTW on a different but related topic we will need in the future to have some metadata to let the user specify what syntax he’s using when filling the context of a text area. The need is double: - let the user decide the syntax of the content he’s entering - let the developer of the xproperty decide what syntaxes are supported (to limit the list of proposed syntaxes to the user) Thanks -Vincent

...

The content can be used to generate HTML, JSON, XML, whatever, depending on the application.

A wiki page generates content in XHTML. A SSX text area generates “CSS” syntax as output (which can be assimilated as plaintext for our need).

...

On the other hand the style sheet extension object has a very specific purpose. It should be very easy and really straightforward to use it (e.g. "don't make me think”).

I don’t see why this would be a privilege of a SSX. This should be true for any part of xwiki, be it for writing the content of a page or anything else.

And BTW having 2 checkboxes to choose from all the time (one for parsing and one for the CSS preprocessor to use) even when you all you need is simple CSS isn’t simplicity for me… My solution is actually simpler than what we currently have and simpler than GD’s proposal when the need is to use CSS.

...

...

PS: Saying that you’ll never need scripting is just wishful thinking IMO… I can already find tons of use cases where you’d need it (not even counting the many places we use velocity in our SSX)...

From my experience we don't use scripting that much in SSX objects. And when we do, it really boils down to:

(1) color theme variables, which will be replaced by LESS variables (2) getting the URL of some internal resource (getSkinFile / getAttachmentURL). For this, if we want to get rid of scripting we can introduce a special syntax for the url('xyz') CSS value:

background-image: url("skin://icons/xwiki/create-link.png"); background-image: url("attach://myOwnIcon.png”);

You’ll always have edge case needs where having some script will help you.

BTW it’s true that LESS can replace velocity to some degree (since you can set some variables and reuse them for example) but it’s quite primitive compared to Velocity and all our java API behind and it’s also a lot lot less performant. LESS is a pain on performance and the more we can avoid it the better. Also we’re not guaranteed that LESS will be here to stay…

...

In any case, +1 for Guillaume's proposal (adding a new property to the SSX object).

So to sum up I’m less against having a “Syntax/Content Type” combo specifying what syntax the Code property will contain with 2 values for now: - CSS - LESS

This removes the need for a {{less}} macro (which could potentially be useful if you want to write a

I'm +1 for the first proposition of Guillaume. We lived for a few years with only CSS in StyleSheetExtension objects and not XWiki syntax (or Rendering Syntax, I don't really know the difference). Having LESS will add a significant improvement and we can still think about something else later. And I agree that, as a developer (sometimes), I would prefer to type only CSS or LESS instead of wrapping my code inside a macro. @Marius, I like your idea of url('attach:something') :-) Hope this helps, On Thu, Dec 11, 2014 at 03:06:20PM +0100, [email protected] wrote:

 

On 11 Dec 2014 at 14:49:18, [email protected] ([email protected](mailto:[email protected])) wrote:

...

On 11 Dec 2014 at 14:40:31, [email protected] ([email protected](mailto:[email protected])) wrote:

...

On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:

...

On Thu, Dec 11, 2014 at 1:54 PM, [email protected] wrote:

...

On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:

...

Related to Vincent's comment: As a designer I would want to be able to write CSS as simple as possible.

Then just write CSS directly :)

...

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.

That’s not CSS, that’s LESS.

...

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.

What’s the need for a CSS macro?

Thanks -Vincent

I don't want to write {{less}} or {{css}} every time I do some styling.

My idea would be to have a default source syntax to be plaintext + macro (i.e. plaintext but also support to specify macros, possibly using the same syntax as for XWiki Syntax 2.x).

...

I really don't think we need wiki syntax (scripting macros precisely) when writing style sheets.

Yes I didn’t express myself properly. I meant a Rendering Syntax (not Wiki Syntax).

...

No one has ever asked for this. So I'm -1. As Caty said, users should be able to paste their CSS/LESS code without doing any useless wrapping.

It’s very simple it boils down to only 2 possibilites:

1) Either you have a select box that you need to click to explain what your content is about 2) or you have a context field only and you decide what it contains by using some type of annotations (and in my first proposal the default was CSS since this is what a SSX object is about, so for CSS you don’t need to specify anything).

Now 1) initially seems to be fine with “Syntax” combo with various options: “CSS”, “LESS”, “CSS+Velocity”, etc. The only problem is that you’ll never be able to specify all the syntax combination that exist.

2) makes it even more easy than now to write pure CSS (since it removes the velocity checkbox and you paste CSS directly) but also allows extending with other more exotic features such as LESS, SAAS, scripting, include (so that the content is defined on some other pages and can be reused between SSX)

...

It's a big difference between the content of a wiki page and the style sheet object. I want to be able to use wiki syntax in the content of the wiki page because it doesn't have any specific purpose.

There’s no difference at all. Whenever you have a text area you need to put content in it that’s of a given syntax, whatever the syntax! This is exactly the same for a wiki page.

BTW on a different but related topic we will need in the future to have some metadata to let the user specify what syntax he’s using when filling the context of a text area. The need is double: - let the user decide the syntax of the content he’s entering - let the developer of the xproperty decide what syntaxes are supported (to limit the list of proposed syntaxes to the user)

Note: There’s a problem with my logic: the XDOM is not meant to be a generic representation of any syntax… Its done for textual content only (heading, section, paragraphs, words, etc) so it’s not well adapted to any kind of syntax… So it works for textarea supposed to represent text only...

Thanks -Vincent

...

Thanks -Vincent

...

...

The content can be used to generate HTML, JSON, XML, whatever, depending on the application.

A wiki page generates content in XHTML. A SSX text area generates “CSS” syntax as output (which can be assimilated as plaintext for our need).

...

On the other hand the style sheet extension object has a very specific purpose. It should be very easy and really straightforward to use it (e.g. "don't make me think”).

I don’t see why this would be a privilege of a SSX. This should be true for any part of xwiki, be it for writing the content of a page or anything else.

And BTW having 2 checkboxes to choose from all the time (one for parsing and one for the CSS preprocessor to use) even when you all you need is simple CSS isn’t simplicity for me… My solution is actually simpler than what we currently have and simpler than GD’s proposal when the need is to use CSS.

...

...

PS: Saying that you’ll never need scripting is just wishful thinking IMO… I can already find tons of use cases where you’d need it (not even counting the many places we use velocity in our SSX)...

From my experience we don't use scripting that much in SSX objects. And when we do, it really boils down to:

(1) color theme variables, which will be replaced by LESS variables (2) getting the URL of some internal resource (getSkinFile / getAttachmentURL). For this, if we want to get rid of scripting we can introduce a special syntax for the url('xyz') CSS value:

background-image: url("skin://icons/xwiki/create-link.png"); background-image: url("attach://myOwnIcon.png”);

You’ll always have edge case needs where having some script will help you.

BTW it’s true that LESS can replace velocity to some degree (since you can set some variables and reuse them for example) but it’s quite primitive compared to Velocity and all our java API behind and it’s also a lot lot less performant. LESS is a pain on performance and the more we can avoid it the better. Also we’re not guaranteed that LESS will be here to stay…

...

In any case, +1 for Guillaume's proposal (adding a new property to the SSX object).

So to sum up I’m less against having a “Syntax/Content Type” combo specifying what syntax the Code property will contain with 2 values for now: - CSS - LESS

This removes the need for a {{less}} macro (which could potentially be useful if you want to write a

---

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 Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org

So the field would be called "Content Type" with these 2 following options: "CSS", "LESS". I have nothing against this. Do everyone agree? 2014-12-11 15:54 GMT+01:00 Thomas Mortagne <[email protected]>:

Guillaume is about to introduce a way to indicate what is the content, I would suggest to name this field in something more generic than pre processor (for example content type) and we can add more stuff to that list later the default staying none. Vincent can add wiki to that list if he really wants it would stay an optional type and everyone is happy IMO. Le 11 déc. 2014 15:06, "[email protected]" <[email protected]> a écrit :

...

On 11 Dec 2014 at 14:49:18, [email protected] ([email protected]

(mailto:

...

[email protected])) wrote:

...

On 11 Dec 2014 at 14:40:31, [email protected] ([email protected]

(mailto:[email protected])) wrote:

...

...

On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea (

[email protected](mailto:[email protected])) wrote:

...

...

...

On Thu, Dec 11, 2014 at 1:54 PM, [email protected] wrote:

...

On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica) (

[email protected](mailto:[email protected])) wrote:

...

...

...

> Related to Vincent's comment: > As a designer I would want to be able to write CSS as simple as

possible.

...

Then just write CSS directly :)

> 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.

That’s not CSS, that’s LESS.

> 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.

What’s the need for a CSS macro?

Thanks -Vincent

I don't want to write {{less}} or {{css}} every time I do some styling.

My idea would be to have a default source syntax to be plaintext + macro (i.e. plaintext but also support to specify macros, possibly using the same syntax as for XWiki Syntax 2.x).

...

I really don't think we need wiki syntax (scripting macros precisely) when writing style sheets.

Yes I didn’t express myself properly. I meant a Rendering Syntax (not Wiki Syntax).

...

No one has ever asked for this. So I'm -1. As Caty said, users should be able to paste their CSS/LESS code without doing any useless wrapping.

It’s very simple it boils down to only 2 possibilites:

1) Either you have a select box that you need to click to explain what your content is about 2) or you have a context field only and you decide what it contains by using some type of annotations (and in my first proposal the default was CSS since this is what a SSX object is about, so for CSS you don’t need to specify anything).

Now 1) initially seems to be fine with “Syntax” combo with various options: “CSS”, “LESS”, “CSS+Velocity”, etc. The only problem is that you’ll never be able to specify all the syntax combination that exist.

2) makes it even more easy than now to write pure CSS (since it removes the velocity checkbox and you paste CSS directly) but also allows extending with other more exotic features such as LESS, SAAS, scripting, include (so that the content is defined on some other pages and can be reused between SSX)

...

It's a big difference between the content of a wiki page and the style sheet object. I want to be able to use wiki syntax in the content of the wiki page because it doesn't have any specific purpose.

There’s no difference at all. Whenever you have a text area you need to put content in it that’s of a given syntax, whatever the syntax! This is exactly the same for a wiki page.

BTW on a different but related topic we will need in the future to have some metadata to let the user specify what syntax he’s using when filling the context of a text area. The need is double: - let the user decide the syntax of the content he’s entering - let the developer of the xproperty decide what syntaxes are supported (to limit the list of proposed syntaxes to the user)

Note: There’s a problem with my logic: the XDOM is not meant to be a generic representation of any syntax… Its done for textual content only (heading, section, paragraphs, words, etc) so it’s not well adapted to any kind of syntax… So it works for textarea supposed to represent text only...

Thanks -Vincent

...

Thanks -Vincent

...

...

The content can be used to generate HTML, JSON, XML, whatever, depending on the application.

A wiki page generates content in XHTML. A SSX text area generates “CSS” syntax as output (which can be assimilated as plaintext for our need).

...

On the other hand the style sheet extension object has a very specific purpose. It should be very easy and really straightforward to use it (e.g. "don't make me think”).

I don’t see why this would be a privilege of a SSX. This should be true for any part of xwiki, be it for writing the content of a page or anything else.

And BTW having 2 checkboxes to choose from all the time (one for parsing and one for the CSS preprocessor to use) even when you all you need is simple CSS isn’t simplicity for me… My solution is actually simpler than what we currently have and simpler than GD’s proposal when the need is to use CSS.

...

...

PS: Saying that you’ll never need scripting is just wishful thinking IMO… I can already find tons of use cases where you’d need it (not even counting the many places we use velocity in our SSX)...

From my experience we don't use scripting that much in SSX objects. And when we do, it really boils down to:

(1) color theme variables, which will be replaced by LESS variables (2) getting the URL of some internal resource (getSkinFile / getAttachmentURL). For this, if we want to get rid of scripting we can introduce a special syntax for the url('xyz') CSS value:

background-image: url("skin://icons/xwiki/create-link.png"); background-image: url("attach://myOwnIcon.png”);

You’ll always have edge case needs where having some script will help you.

BTW it’s true that LESS can replace velocity to some degree (since you can set some variables and reuse them for example) but it’s quite primitive compared to Velocity and all our java API behind and it’s also a lot lot less performant. LESS is a pain on performance and the more we can avoid it the better. Also we’re not guaranteed that LESS will be here to stay…

...

In any case, +1 for Guillaume's proposal (adding a new property to the SSX object).

So to sum up I’m less against having a “Syntax/Content Type” combo specifying what syntax the Code property will contain with 2 values for now: - CSS - LESS

This removes the need for a {{less}} macro (which could potentially be useful if you want to write a

---

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

On Thu, Dec 11, 2014 at 5:03 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

So the field would be called "Content Type" with these 2 following options: "CSS", "LESS".

You can name the property 'contentType' but until we expand the functionality, the pretty names could still be: - CSS Preprocessor: LESS, none After the expanding we can just rename the pretty names to: 'Content Type': LESS, CSS, etc. Not sure why we should have now an ambiguous naming, just for the sake of a possible future expansion. Thanks, Caty

I have nothing against this. Do everyone agree?

2014-12-11 15:54 GMT+01:00 Thomas Mortagne <[email protected]>:

...

Guillaume is about to introduce a way to indicate what is the content, I would suggest to name this field in something more generic than pre processor (for example content type) and we can add more stuff to that list later the default staying none. Vincent can add wiki to that list if he really wants it would stay an optional type and everyone is happy IMO. Le 11 déc. 2014 15:06, "[email protected]" <[email protected]> a écrit :

...

On 11 Dec 2014 at 14:49:18, [email protected] ([email protected]

(mailto:

...

[email protected])) wrote:

...

On 11 Dec 2014 at 14:40:31, [email protected] ([email protected]

(mailto:[email protected])) wrote:

...

...

On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea (

[email protected](mailto:[email protected])) wrote:

...

...

...

On Thu, Dec 11, 2014 at 1:54 PM, [email protected] wrote: > > > > > > On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica) (

[email protected](mailto:[email protected])) wrote:

...

...

> >> Related to Vincent's comment: >> As a designer I would want to be able to write CSS as simple as possible. > > Then just write CSS directly :) > >> 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. > > That’s not CSS, that’s LESS. > >> 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. > > What’s the need for a CSS macro? > > Thanks > -Vincent >

I don't want to write {{less}} or {{css}} every time I do some styling.

My idea would be to have a default source syntax to be plaintext + macro (i.e. plaintext but also support to specify macros, possibly using the same syntax as for XWiki Syntax 2.x).

...

I really don't think we need wiki syntax (scripting macros precisely) when writing style sheets.

Yes I didn’t express myself properly. I meant a Rendering Syntax (not Wiki Syntax).

...

No one has ever asked for this. So I'm -1. As Caty said, users should be able to paste their CSS/LESS code without doing any useless wrapping.

It’s very simple it boils down to only 2 possibilites:

1) Either you have a select box that you need to click to explain what your content is about 2) or you have a context field only and you decide what it contains by using some type of annotations (and in my first proposal the default was CSS since this is what a SSX object is about, so for CSS you don’t need to specify anything).

Now 1) initially seems to be fine with “Syntax” combo with various options: “CSS”, “LESS”, “CSS+Velocity”, etc. The only problem is that you’ll never be able to specify all the syntax combination that exist.

2) makes it even more easy than now to write pure CSS (since it removes the velocity checkbox and you paste CSS directly) but also allows extending with other more exotic features such as LESS, SAAS, scripting, include (so that the content is defined on some other pages and can be reused between SSX)

...

It's a big difference between the content of a wiki page and the style sheet object. I want to be able to use wiki syntax in the content of the wiki page because it doesn't have any specific purpose.

There’s no difference at all. Whenever you have a text area you need to put content in it that’s of a given syntax, whatever the syntax! This is exactly the same for a wiki page.

BTW on a different but related topic we will need in the future to have some metadata to let the user specify what syntax he’s using when filling the context of a text area. The need is double: - let the user decide the syntax of the content he’s entering - let the developer of the xproperty decide what syntaxes are supported (to limit the list of proposed syntaxes to the user)

Note: There’s a problem with my logic: the XDOM is not meant to be a generic representation of any syntax… Its done for textual content only (heading, section, paragraphs, words, etc) so it’s not well adapted to any kind of syntax… So it works for textarea supposed to represent text only...

Thanks -Vincent

...

Thanks -Vincent

...

...

The content can be used to generate HTML, JSON, XML, whatever, depending on the application.

A wiki page generates content in XHTML. A SSX text area generates “CSS” syntax as output (which can be assimilated as plaintext for our need).

...

On the other hand the style sheet extension object has a very specific purpose. It should be very easy and really straightforward to use it (e.g. "don't make me think”).

I don’t see why this would be a privilege of a SSX. This should be true for any part of xwiki, be it for writing the content of a page or anything else.

And BTW having 2 checkboxes to choose from all the time (one for parsing and one for the CSS preprocessor to use) even when you all you need is simple CSS isn’t simplicity for me… My solution is actually simpler than what we currently have and simpler than GD’s proposal when the need is to use CSS.

...

> PS: Saying that you’ll never need scripting is just wishful thinking IMO… I can already find tons of use cases where you’d need it (not even counting the many places we use velocity in our SSX)...

From my experience we don't use scripting that much in SSX objects. And when we do, it really boils down to:

(1) color theme variables, which will be replaced by LESS variables (2) getting the URL of some internal resource (getSkinFile / getAttachmentURL). For this, if we want to get rid of scripting we can introduce a special syntax for the url('xyz') CSS value:

background-image: url("skin://icons/xwiki/create-link.png"); background-image: url("attach://myOwnIcon.png”);

You’ll always have edge case needs where having some script will help you.

BTW it’s true that LESS can replace velocity to some degree (since you can set some variables and reuse them for example) but it’s quite primitive compared to Velocity and all our java API behind and it’s also a lot lot less performant. LESS is a pain on performance and the more we can avoid it the better. Also we’re not guaranteed that LESS will be here to stay…

...

In any case, +1 for Guillaume's proposal (adding a new property to the SSX object).

So to sum up I’m less against having a “Syntax/Content Type” combo specifying what syntax the Code property will contain with 2 values for now: - CSS - LESS

This removes the need for a {{less}} macro (which could potentially be useful if you want to write a

---

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

On Fri, Dec 12, 2014 at 11:55 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:

On Thu, Dec 11, 2014 at 5:03 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

So the field would be called "Content Type" with these 2 following options: "CSS", "LESS".

You can name the property 'contentType' but until we expand the functionality, the pretty names could still be: - CSS Preprocessor: LESS, none

After the expanding we can just rename the pretty names to: 'Content Type': LESS, CSS, etc.

Not sure why we should have now an ambiguous naming, just for the sake of a possible future expansion.

The result will always be CSS no matter what you put in there since that's what this object is about, so saying that the source is LESS is not ambigous.

Thanks, Caty

...

I have nothing against this. Do everyone agree?

...

2014-12-11 15:54 GMT+01:00 Thomas Mortagne <[email protected]>:

...

Guillaume is about to introduce a way to indicate what is the content, I would suggest to name this field in something more generic than pre processor (for example content type) and we can add more stuff to that list later the default staying none. Vincent can add wiki to that list if he really wants it would stay an optional type and everyone is happy IMO. Le 11 déc. 2014 15:06, "[email protected]" <[email protected]> a écrit :

...

On 11 Dec 2014 at 14:49:18, [email protected] ([email protected]

(mailto:

...

[email protected])) wrote:

...

On 11 Dec 2014 at 14:40:31, [email protected] ([email protected]

(mailto:[email protected])) wrote:

...

...

On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea (

[email protected](mailto:[email protected])) wrote:

...

...

> On Thu, Dec 11, 2014 at 1:54 PM, [email protected] wrote: > > > > > > > > > > > > On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica) (

[email protected](mailto:[email protected])) wrote:

...

> > > >> Related to Vincent's comment: > >> As a designer I would want to be able to write CSS as simple as possible. > > > > Then just write CSS directly :) > > > >> 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. > > > > That’s not CSS, that’s LESS. > > > >> 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. > > > > What’s the need for a CSS macro? > > > > Thanks > > -Vincent > > > > I don't want to write {{less}} or {{css}} every time I do some > styling.

My idea would be to have a default source syntax to be plaintext + macro (i.e. plaintext but also support to specify macros, possibly using the same syntax as for XWiki Syntax 2.x).

> I really don't think we need wiki syntax (scripting macros > precisely) when writing style sheets.

Yes I didn’t express myself properly. I meant a Rendering Syntax (not Wiki Syntax).

> No one has ever asked for this. > So I'm -1. As Caty said, users should be able to paste their CSS/LESS > code without doing any useless wrapping.

It’s very simple it boils down to only 2 possibilites:

1) Either you have a select box that you need to click to explain what your content is about 2) or you have a context field only and you decide what it contains by using some type of annotations (and in my first proposal the default was CSS since this is what a SSX object is about, so for CSS you don’t need to specify anything).

Now 1) initially seems to be fine with “Syntax” combo with various options: “CSS”, “LESS”, “CSS+Velocity”, etc. The only problem is that you’ll never be able to specify all the syntax combination that exist.

2) makes it even more easy than now to write pure CSS (since it removes the velocity checkbox and you paste CSS directly) but also allows extending with other more exotic features such as LESS, SAAS, scripting, include (so that the content is defined on some other pages and can be reused between SSX)

> It's a big difference between > the content of a wiki page and the style sheet object. I want to be > able to use wiki syntax in the content of the wiki page because it > doesn't have any specific purpose.

There’s no difference at all. Whenever you have a text area you need to put content in it that’s of a given syntax, whatever the syntax! This is exactly the same for a wiki page.

BTW on a different but related topic we will need in the future to have some metadata to let the user specify what syntax he’s using when filling the context of a text area. The need is double: - let the user decide the syntax of the content he’s entering - let the developer of the xproperty decide what syntaxes are supported (to limit the list of proposed syntaxes to the user)

Note: There’s a problem with my logic: the XDOM is not meant to be a generic representation of any syntax… Its done for textual content only (heading, section, paragraphs, words, etc) so it’s not well adapted to any kind of syntax… So it works for textarea supposed to represent text only...

Thanks -Vincent

...

Thanks -Vincent

...

> The content can be used to generate > HTML, JSON, XML, whatever, depending on the application.

A wiki page generates content in XHTML. A SSX text area generates “CSS” syntax as output (which can be assimilated as plaintext for our need).

> On the other > hand the style sheet extension object has a very specific purpose. It > should be very easy and really straightforward to use it (e.g. "don't > make me think”).

I don’t see why this would be a privilege of a SSX. This should be true for any part of xwiki, be it for writing the content of a page or anything else.

And BTW having 2 checkboxes to choose from all the time (one for parsing and one for the CSS preprocessor to use) even when you all you need is simple CSS isn’t simplicity for me… My solution is actually simpler than what we currently have and simpler than GD’s proposal when the need is to use CSS.

> > PS: Saying that you’ll never need scripting is just wishful thinking IMO… I can already find tons of use cases where you’d need it (not even counting the many places we use velocity in our SSX)... > > From my experience we don't use scripting that much in SSX objects. > And when we do, it really boils down to: > > (1) color theme variables, which will be replaced by LESS variables > (2) getting the URL of some internal resource (getSkinFile / > getAttachmentURL). For this, if we want to get rid of scripting we can > introduce a special syntax for the url('xyz') CSS value: > > background-image: url("skin://icons/xwiki/create-link.png"); > background-image: url("attach://myOwnIcon.png”);

You’ll always have edge case needs where having some script will help you.

BTW it’s true that LESS can replace velocity to some degree (since you can set some variables and reuse them for example) but it’s quite primitive compared to Velocity and all our java API behind and it’s also a lot lot less performant. LESS is a pain on performance and the more we can avoid it the better. Also we’re not guaranteed that LESS will be here to stay…

> In any case, +1 for Guillaume's proposal (adding a new property to the > SSX object).

So to sum up I’m less against having a “Syntax/Content Type” combo specifying what syntax the Code property will contain with 2 values for now: - CSS - LESS

This removes the need for a {{less}} macro (which could potentially be useful if you want to write a

---

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

-- Thomas Mortagne

We can start with what you have and maybe add later the possibility to skip the skin if many people ask for it. On Mon, Dec 15, 2014 at 12:06 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:

Hi.

For your information, when LESS is used on an SSX, I include the main LESS file of the skin which includes, at least in Flamingo, the color themes variables and the bootstrap mix-ins. More explanations there: http://design.xwiki.org/xwiki/bin/view/Proposal/LESSModuleImprovements#HHowt...

I was thinking about if this behaviour should be optional or not. Currently, I enforce the SSX to include the other LESS file, but it makes the compilation slower. And it is useless if the user does not use the color theme variables or the bootstrap content.

On the other hand, making it as an option makes the LESS language more complicated to use in an SSX, making the user think "what the hell is this option?".

The implementation could be to have a new content type. So you would have the choice between: "CSS", "LESS" or "LESS (with skin integration)".

I don't have a strong opinion on this. What do you think?

Thanks, Guillaume

2014-12-12 12:23 GMT+01:00 Thomas Mortagne <[email protected]>:

...

On Fri, Dec 12, 2014 at 11:55 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:

...

On Thu, Dec 11, 2014 at 5:03 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

So the field would be called "Content Type" with these 2 following options: "CSS", "LESS".

You can name the property 'contentType' but until we expand the functionality, the pretty names could still be: - CSS Preprocessor: LESS, none

After the expanding we can just rename the pretty names to: 'Content Type': LESS, CSS, etc.

Not sure why we should have now an ambiguous naming, just for the sake of a possible future expansion.

The result will always be CSS no matter what you put in there since that's what this object is about, so saying that the source is LESS is not ambigous.

...

Thanks, Caty

...

I have nothing against this. Do everyone agree?

...

2014-12-11 15:54 GMT+01:00 Thomas Mortagne <[email protected]>:

...

Guillaume is about to introduce a way to indicate what is the

content, I

...

...

...

would suggest to name this field in something more generic than pre processor (for example content type) and we can add more stuff to that list later the default staying none. Vincent can add wiki to that list if he really wants it would stay an optional type and everyone is happy IMO. Le 11 déc. 2014 15:06, "[email protected]" <[email protected]> a écrit :

...

On 11 Dec 2014 at 14:49:18, [email protected] ([email protected]

(mailto:

...

[email protected])) wrote:

> > > > > > On 11 Dec 2014 at 14:40:31, [email protected] ( [email protected] (mailto:[email protected])) wrote: > > > > > > > > > > > > > On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea ( [email protected](mailto: [email protected])) wrote: > > > > > On Thu, Dec 11, 2014 at 1:54 PM, [email protected] wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica) ( [email protected](mailto:[email protected])) wrote: > > > > > > > >> Related to Vincent's comment: > > > >> As a designer I would want to be able to write CSS as simple as possible. > > > > > > > > Then just write CSS directly :) > > > > > > > >> 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. > > > > > > > > That’s not CSS, that’s LESS. > > > > > > > >> 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. > > > > > > > > What’s the need for a CSS macro? > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > > I don't want to write {{less}} or {{css}} every time I do some > > > styling. > > > > My idea would be to have a default source syntax to be plaintext + macro (i.e. plaintext but also support to specify macros, possibly using the same syntax as for XWiki Syntax 2.x). > > > > > I really don't think we need wiki syntax (scripting macros > > > precisely) when writing style sheets. > > > > Yes I didn’t express myself properly. I meant a Rendering Syntax (not Wiki Syntax). > > > > > No one has ever asked for this. > > > So I'm -1. As Caty said, users should be able to paste their CSS/LESS > > > code without doing any useless wrapping. > > > > It’s very simple it boils down to only 2 possibilites: > > > > 1) Either you have a select box that you need to click to explain what your content is about > > 2) or you have a context field only and you decide what it contains by using some type of annotations (and in my first proposal the default was CSS since this is what a SSX object is about, so for CSS you don’t need to specify anything). > > > > Now 1) initially seems to be fine with “Syntax” combo with various options: “CSS”, “LESS”, “CSS+Velocity”, etc. The only problem is that you’ll never be able to specify all the syntax combination that exist. > > > > 2) makes it even more easy than now to write pure CSS (since it removes the velocity checkbox and you paste CSS directly) but also allows extending with other more exotic features such as LESS, SAAS, scripting, include (so that the content is defined on some other pages and can be reused between SSX) > > > > > It's a big difference between > > > the content of a wiki page and the style sheet object. I want to be > > > able to use wiki syntax in the content of the wiki page because it > > > doesn't have any specific purpose. > > > > There’s no difference at all. Whenever you have a text area you need to put content in it that’s of a given syntax, whatever the syntax! This is exactly the same for a wiki page. > > > BTW on a different but related topic we will need in the future to have some metadata to let the user specify what syntax he’s using when filling the context of a text area. The need is double: > - let the user decide the syntax of the content he’s entering > - let the developer of the xproperty decide what syntaxes are supported (to limit the list of proposed syntaxes to the user)

Note: There’s a problem with my logic: the XDOM is not meant to be a generic representation of any syntax… Its done for textual content only (heading, section, paragraphs, words, etc) so it’s not well adapted to any kind of syntax… So it works for textarea supposed to represent text only...

Thanks -Vincent

> Thanks > -Vincent > > > > The content can be used to generate > > > HTML, JSON, XML, whatever, depending on the application. > > > > A wiki page generates content in XHTML. A SSX text area generates “CSS” syntax as output (which can be assimilated as plaintext for our need). > > > > > On the other > > > hand the style sheet extension object has a very specific purpose. It > > > should be very easy and really straightforward to use it (e.g. "don't > > > make me think”). > > > > I don’t see why this would be a privilege of a SSX. This should be true for any part of xwiki, be it for writing the content of a page or anything else. > > > > And BTW having 2 checkboxes to choose from all the time (one for parsing and one for the CSS preprocessor to use) even when you all you need is simple CSS isn’t simplicity for me… My solution is actually simpler than what we currently have and simpler than GD’s proposal when the need is to use CSS. > > > > > > PS: Saying that you’ll never need scripting is just wishful thinking IMO… I can already find tons of use cases where you’d need it (not even counting the many places we use velocity in our SSX)... > > > > > > From my experience we don't use scripting that much in SSX objects. > > > And when we do, it really boils down to: > > > > > > (1) color theme variables, which will be replaced by LESS variables > > > (2) getting the URL of some internal resource (getSkinFile / > > > getAttachmentURL). For this, if we want to get rid of scripting we can > > > introduce a special syntax for the url('xyz') CSS value: > > > > > > background-image: url("skin://icons/xwiki/create-link.png"); > > > background-image: url("attach://myOwnIcon.png”); > > > > You’ll always have edge case needs where having some script will help you. > > > > BTW it’s true that LESS can replace velocity to some degree (since you can set some variables and reuse them for example) but it’s quite primitive compared to Velocity and all our java API behind and it’s also a lot lot less performant. LESS is a pain on performance and the more we can avoid it the better. Also we’re not guaranteed that LESS will be here to stay… > > > > > In any case, +1 for Guillaume's proposal (adding a new property to the > > > SSX object). > > > > So to sum up I’m less against having a “Syntax/Content Type” combo specifying what syntax the Code property will contain with 2 values for now: > > - CSS > > - LESS > > > > This removes the need for a {{less}} macro (which could potentially be useful if you want to write a > _______________________________________________ > 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

-- Thomas Mortagne _______________________________________________ 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

-- Thomas Mortagne

On Thu, Dec 11, 2014 at 4:41 PM, [email protected] <[email protected]> wrote:

On 11 Dec 2014 at 15:54:52, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

...

Guillaume is about to introduce a way to indicate what is the content, I would suggest to name this field in something more generic than pre processor (for example content type)

Yes, this is what I suggested :)

...

and we can add more stuff to that list later the default staying none. Vincent can add wiki to that list if he really wants it would stay an optional type and everyone is happy IMO.

Actually I don’t want wiki! See my latest answers where I explained better what I had in mind than in the first reply.

Sure, but this is another discussion for later. What I mean is that you can add anything you want later.

Thanks -Vincent

...

Le 11 déc. 2014 15:06, "[email protected]" a écrit :

...

...

On 11 Dec 2014 at 14:49:18, [email protected] ([email protected](mailto: [email protected])) wrote:

...

On 11 Dec 2014 at 14:40:31, [email protected] ([email protected]

(mailto:[email protected])) wrote:

...

...

On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea (

[email protected](mailto:[email protected])) wrote:

...

...

...

On Thu, Dec 11, 2014 at 1:54 PM, [email protected] wrote: > > > > > > On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica) (

[email protected](mailto:[email protected])) wrote:

...

...

> >> Related to Vincent's comment: >> As a designer I would want to be able to write CSS as simple as possible. > > Then just write CSS directly :) > >> 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. > > That’s not CSS, that’s LESS. > >> 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. > > What’s the need for a CSS macro? > > Thanks > -Vincent >

I don't want to write {{less}} or {{css}} every time I do some styling.

My idea would be to have a default source syntax to be plaintext + macro (i.e. plaintext but also support to specify macros, possibly using the same syntax as for XWiki Syntax 2.x).

...

I really don't think we need wiki syntax (scripting macros precisely) when writing style sheets.

Yes I didn’t express myself properly. I meant a Rendering Syntax (not Wiki Syntax).

...

No one has ever asked for this. So I'm -1. As Caty said, users should be able to paste their CSS/LESS code without doing any useless wrapping.

It’s very simple it boils down to only 2 possibilites:

1) Either you have a select box that you need to click to explain what your content is about 2) or you have a context field only and you decide what it contains by using some type of annotations (and in my first proposal the default was CSS since this is what a SSX object is about, so for CSS you don’t need to specify anything).

Now 1) initially seems to be fine with “Syntax” combo with various options: “CSS”, “LESS”, “CSS+Velocity”, etc. The only problem is that you’ll never be able to specify all the syntax combination that exist.

2) makes it even more easy than now to write pure CSS (since it removes the velocity checkbox and you paste CSS directly) but also allows extending with other more exotic features such as LESS, SAAS, scripting, include (so that the content is defined on some other pages and can be reused between SSX)

...

It's a big difference between the content of a wiki page and the style sheet object. I want to be able to use wiki syntax in the content of the wiki page because it doesn't have any specific purpose.

There’s no difference at all. Whenever you have a text area you need to put content in it that’s of a given syntax, whatever the syntax! This is exactly the same for a wiki page.

BTW on a different but related topic we will need in the future to have some metadata to let the user specify what syntax he’s using when filling the context of a text area. The need is double: - let the user decide the syntax of the content he’s entering - let the developer of the xproperty decide what syntaxes are supported (to limit the list of proposed syntaxes to the user)

Note: There’s a problem with my logic: the XDOM is not meant to be a generic representation of any syntax… Its done for textual content only (heading, section, paragraphs, words, etc) so it’s not well adapted to any kind of syntax… So it works for textarea supposed to represent text only...

Thanks -Vincent

...

Thanks -Vincent

...

...

The content can be used to generate HTML, JSON, XML, whatever, depending on the application.

A wiki page generates content in XHTML. A SSX text area generates “CSS” syntax as output (which can be assimilated as plaintext for our need).

...

On the other hand the style sheet extension object has a very specific purpose. It should be very easy and really straightforward to use it (e.g. "don't make me think”).

I don’t see why this would be a privilege of a SSX. This should be true for any part of xwiki, be it for writing the content of a page or anything else.

And BTW having 2 checkboxes to choose from all the time (one for parsing and one for the CSS preprocessor to use) even when you all you need is simple CSS isn’t simplicity for me… My solution is actually simpler than what we currently have and simpler than GD’s proposal when the need is to use CSS.

...

> PS: Saying that you’ll never need scripting is just wishful thinking IMO… I can already find tons of use cases where you’d need it (not even counting the many places we use velocity in our SSX)...

From my experience we don't use scripting that much in SSX objects. And when we do, it really boils down to:

(1) color theme variables, which will be replaced by LESS variables (2) getting the URL of some internal resource (getSkinFile / getAttachmentURL). For this, if we want to get rid of scripting we can introduce a special syntax for the url('xyz') CSS value:

background-image: url("skin://icons/xwiki/create-link.png"); background-image: url("attach://myOwnIcon.png”);

You’ll always have edge case needs where having some script will help you.

BTW it’s true that LESS can replace velocity to some degree (since you can set some variables and reuse them for example) but it’s quite primitive compared to Velocity and all our java API behind and it’s also a lot lot less performant. LESS is a pain on performance and the more we can avoid it the better. Also we’re not guaranteed that LESS will be here to stay…

...

In any case, +1 for Guillaume's proposal (adding a new property to the SSX object).

So to sum up I’m less against having a “Syntax/Content Type” combo specifying what syntax the Code property will contain with 2 values for now: - CSS - LESS

This removes the need for a {{less}} macro (which could potentially be useful if you want to write a

---

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

-- Thomas Mortagne