Re: [xwiki-devs] [discussion] Where to put java macros CSS?

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).