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.
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).
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.
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).
Thanks,
Anca
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi devs,
as an Xwiki user for about 2 years I'm not so deeply familiar with all
the nuances of styling capatibilities - ssx ssfx ssrx and all the like.
However this is an important topic and I would very much like to see
that XWiki would move toward a styling architecture comparable to that
of wordpress and other popular 'social publishing' tools so that it
becomes easier to customize the look and feel of a site.
I am aware of the contradiction between either offering components that
are fully self supported - meaning macros and style bundled somehow
together - and offering flexible code templates with separate styling (css).
As an example the ColumnMacro and its successor: the Container macro.
Both are IMHO a misconception leaving out the obvious solution.
The colum macro (java) is limited as it uses hardcoded inline styles.
This makes almost any useful layout modification impossible - ok you
might rewrite the .jar but that's beyond what most people are capable
and willing to do.
Same with the container macro: To modify the Layout you should really
write an implementation of LayoutManager ?
Someone must be kidding there - that's total overkill.
Why not just pass a parameter - say cssClass to such a macro (as it is
the case with other macros) for example the 'box'-macro. That's useful
because it can be easily customized and you can provide an own class
name and associated css.
IMHO it would be much more benefical if there were a style guide for
writing macros or templates making a small set of parameters mandatory,
for example the 'cssClass' and maybe an 'id' parameter.
So if the parameter is not supplied you might go ahead with some
internal or bundled styling (a default .css file) otherwise it might be
overridden.
I think there is a general risk thats XWiki is falling behind other
platforms because of the lack of design standards allowing designers to
customize solutions in terms of look and feel.
Don't get me wrong - I do like XWiki and its concept much - what worries
me is that it is simply too much work to customize a site design that
compares favorable with wordpress sites and others.
regards
Andreas