On Wed, Dec 29, 2010 at 14:40, Anca Luca <[email protected]> wrote: > Hi Thomas, > > On 12/29/2010 01:31 PM, Thomas Mortagne wrote: >> On Wed, Dec 29, 2010 at 11:58, Anca Luca<[email protected]> wrote: >>> Hi Thomas, all >>> >>> On 12/29/2010 09:51 AM, Thomas Mortagne wrote: >>>> 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). >>> >>> 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. >> >> As you said yourself that's not a real issue since you can customize >> it with some more css. > > 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. > >> >>> >>>> >>>>> >>>>> 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. >> >> 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... > >> 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".
Not sure Firefox is a good comparison with XWiki architecture, it's more like Eclipse. > > 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 > >> >>> >>> 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 >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> >> > _______________________________________________ > 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
