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