15 Dec
2014
15 Dec
'14
12:06 p.m.
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#HHow…
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 <thomas.mortagne(a)xwiki.com>om>:
On Fri, Dec 12, 2014 at 11:55 AM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
Type':
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
On Thu, Dec 11, 2014 at 5:03 PM, Guillaume
"Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> 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 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
content, I
I have nothing against this. Do everyone agree?
> 2014-12-11 15:54 GMT+01:00 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
>
> > Guillaume is about to introduce a way to indicate what is the > > 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, "vincent(a)massol.net" <vincent(a)massol.net>
a
> écrit :
> >
> > >
> > >
> > >
> > >
> > >
> > > On 11 Dec 2014 at 14:49:18, vincent(a)massol.net (vincent(a)massol.net
> > (mailto:
> > > vincent(a)massol.net)) wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 11 Dec 2014 at 14:40:31, vincent(a)massol.net (
vincent(a)massol.net
> > > (mailto:vincent@massol.net))
wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 11 Dec 2014 at 14:03:59, Marius Dumitru Florea (
> > > mariusdumitru.florea(a)xwiki.com(mailto:
mariusdumitru.florea(a)xwiki.com))
> > > wrote:
> > > > >
> > > > > > On Thu, Dec 11, 2014 at 1:54 PM, vincent(a)massol.net wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 11 Dec 2014 at 12:46:48, Ecaterina Moraru (Valica)
(
> > > valicac@gmail.com(mailto:valicac@gmail.com)) 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
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs