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