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#HHowtodealwiththeskin > > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
