On Tue, Dec 28, 2010 at 16:13, Anca Luca <[email protected]> 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.enterprise$xwiki-enterprise-test-webstandards/252/testReport/) > 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). > > 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/ > > 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. > > Thanks, > Anca > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
