29 Dec
2010
29 Dec
'10
2:49 p.m.
On Wed, Dec 29, 2010 at 14:40, Anca Luca <lucaa(a)xwiki.com> wrote:
Hi Thomas,
On 12/29/2010 01:31 PM, Thomas Mortagne wrote:
My point is that we need a solution for third party anyway. Also for
me you are putting way to many thing in what you call "platform".
I agree...
Not sure Firefox is a good comparison with XWiki architecture, it's
more like Eclipse.
On Wed, Dec 29, 2010 at 11:58, Anca
Luca<lucaa(a)xwiki.com> wrote:
More or less. Yes we can customize it, but not fully (cascading works
only if you can have stronger selectors, etc).
Also I'm not sure I want to go for this as the "default" and
"recommended" method, since it means packing css and js in
"binaries",
when CSS is declarative. It doesn't make too much sense as a principle,
it would mean that if one wants to read such a css, remove or edit it,
he would have to go in the jar, unpack, see what's in there. It's a bit
awkward as a paradigm, for me.
But then again, ff extensions are packed as jars as well, so I guess
it's an ok archiving format.
Hi Thomas, all
On 12/29/2010 09:51 AM, Thomas Mortagne wrote:
As you said yourself that's not a real issue since you can customize
it with some more css. On Tue, Dec 28, 2010 at 16:13, Anca
Luca<lucaa(a)xwiki.com> wrote:
> Hi guys,
>
> Short story:
>
> Where to put the css which is needed by java macros (e.g. the columns
> layouting of the container macro)
>
> 1/ in colibri.css
> 2/ in a .css included on demand by the macro
> a) from platform resources (using ssfx)
> b) from the jar (using ssrx)
> c) from an object in a page with ssx
> 3/ refactor the skin concept and create a 'platform css' to store all
> these and not be affected by skin customization.
>
> Long story:
>
> I can see I've caused the web standards tests to fail for the trunk
>
(http://hudson.xwiki.org/job/xwiki-product-enterprise-tests/org.xwiki.enterp…)
> because of the inline style attributes used by the columns layout of the
> container, whijch is now used on the main page.
>
> Now, I would like us to agree about where to store the styles needed by
> the java macros to work right, such as the container macro with columns
> layout. The options I see are:
>
> 1/ as until today (e.g. box macro, warning, error, info, etc), in
> colibri.css/toucan.css/otherskinwehave.css. I don't like this solution
> too much because it means that when another skin is used, things won't
> work anymore unless the person writing the new skin takes care of
> copying all these "things that must be there". The advantage of this is
> having a single .css file to load on page load, the disadvantage being
> that their css is loaded on all pages, regardless of it being used or not.
We can't really see that as a solution, it kid of work for us because
we have access to colibri skin but we have to find a real extendable
solution for anyone who write a java macro.
>
> 2/ loading of the styles on demand, each macro loads its style when it
> needs it
> a) from a .css file located in the platform resources, which the macro
> has to include using the ssfx plugin when is executed -- much like a
> wiki macro would to with a ssx.
> b) from a .css file located in the macro archive (using ssrx), which the
> macro includes when executed.
> c) from a ssx page
>
> c) has the advantage of being very very much more easy to change than a)
> and finally than b) which is the hardest to customize. But on the other
> side c) means the java macro depends on a page, which is not that good.
> Note that "cascading" customization is possible for all these choices
> (adding an extra css with rules to overwrite the rules in the default
> css for the macro) and that in my view, it's enough, since the idea is
> that the layout should be preserved no matter what (e.g. a user might
> want to add a red border to the columns, but not make the columns
> display as two paragraphs instead of two columns).
I think the only clean solution from extension architecture POV is b).
2b makes it a bit tough to customize, which might be ok for third party
macros, but for the platform macros, we might want to leave room for this.
>
> 3/ refactoring the whole skin thing and creating a "platform" css, which
> contains things that should work regardless of the skin used. Pros: it's
> an adaptation of the current approach (1/), that solves the problem.
> Cons: takes longer, might be very hard to separate what's platform and
> what's skin.
For me this is almost as bad as 1/
For the macros that come with the platform it's not such a bad solution,
third party macro authors will still have 2b as a solution. For
me most of the macros are extension you have installed or not in your
wiki, the fact that a macro is provided by us does not make it a
forced macro.
... BUT, I'm just trying to figure out how to create a distributable
which is not slow _by default_.
It's like you'd download the default Firefox, run it with no
modifications, complain it's slow and then be told that "well, it's not
firefox which is slow, it's the extensions, you have too many extensions".
Either we need to rethink what we distribute, or we need to have a way
to make at least the default package(s) as fast as possible.
Thanks,
Anca
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
The issue with 2 in general is that the css becomes immensely
fragmented: you'd have a separate CSS file fetch for each macro that
needs styles, which slows down page loading. I guess this is the very
reason why we have everything in colibri.css at the moment. Which is
why, for the macros that come with the platform by default, we should
have a solution that optimizes this and grabs all the css in one fetch.
Of course, we could make it an 'on demand', meaning that this
platform.css will be asked for by the macros in the platform that know
they need it. Also, we can also improve the skin extension to make it
generate a file from multiple ".use" calls that it receives, but it
should still be one single file, to allow caching on the client side.
>
> These being said, I think I prefer 2/ if 3/ is not realistic, and for
> the container macro at least, I would prefer to implement 2b).
Side note: be careful with css and macros it's easy to make it
unusable for anything except XHTML renderer.
well, well... :) I guess when it comes to layout and decoration, it's
gonna be necessarily bound to a renderer. e.g. in the columns case, I
don't know how to make sure that columns will happen on any renderer. I
do have groups around each column allowing a potential other renderer to
lay them out the way it needs them, but more than that I don't know how
to do.
Unless we make these decoration notions (or some of them), part of the
abstract syntax tree model (i.e. invent blocks for it, or reserved
attributes at XDOM level, etc). It will be hard to cover it all, though.
Thanks,
Anca
>
> Thanks,
> Anca
> _______________________________________________
> 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