On 01/03/2011 11:47 PM, Andreas Hahn wrote: > Am 28.12.2010 16:13, schrieb Anca Luca: >> 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. >> >> 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). >> > 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.
As Anca said, you can add classnames to any portion of text with (% class="..." %)((( content here ))), and the macros for which a classname makes sense do usually have such a 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. No, that's not true. Let me get this straight: *It is much harder to style WordPress or other "popular" frameworks than XWiki*. And I mean that without any tutorials, samples or tools, styling XWiki is much more flexible, and much easier. The advantage of popular frameworks is that they are more popular, with much more users, much more interest, and an already established market. 1. When you style WordPress, you don't write a CSS file for it. You write the full frontend, from <html> to </html>, and you're forced to respect their requirements: "you must call this PHP function to display the login/logout section, you must call this PHP function to display the panels, ...". In XWiki you write as much code as you need, you can start with just a color theme (for which there's a nice WYSIWYG wizard), or a SSX object, or a Skin document with overridden templates attached to it. Sure, you can go low-level and write a full skin on the filesystem, but that really should be avoided unless you need a major interface overhaul. 2. Installing a theme for all those PHP applications is hard. Sure, they make it sound easy, "download the zip, extract it, put it in this folder on the server, change this configuration file". Installing a proper XWiki theme could be as simple as selecting a xar from the future XWiki app store. We don't have support for .xar extensions in the extension manager yet, but it will be available in 3.0, and during the 3.x cycle we'll build a very user friendly extension manager. And we don't have such easy to install skins yet because nobody provided one yet. The core developers don't have enough time to write extra skins when the users are complaining about core functionality. And the users aren't contributing their skins back in the extensions.xwiki.org repository, although I've seen spectacular skins on top of XWiki out in the wild. 3. XWiki is not a blogging software, it is a *Development Platform*. This means that you can't style XWiki, you can style the generic layout, and then you can style different components. We're adding new macros all the time, and users can develop whatever application they want, so we can't make a style for *everything that ever was and will ever be running in a XWiki instance*. Thus, given the extraordinary flexibility that only XWiki provides, we're doing pretty well when it comes to styling. 4. To help overcome a bit the many degrees of freedom mentioned in 3, we're providing several tools. The most important one is the color theme, which allows to style components in a consistent manner with the global skin. Then there are all the skin extensions plugins that allow to develop standalone components/applications which bring their own style, of course closely integrated in the current theme, since they're using the color theme. Then there are the standards that we've been creating and documenting, like http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms and http://platform.xwiki.org/xwiki/bin/view/DevGuide/SpecialCSSClasses which should help users (and committers as well) create extensions that fit well inside XWiki. And we're planning more for the future. 5. Let me repeat that: XWiki is not harder to style than other popular frameworks. There are so much more skins to use or buy for them simply because there's a well established market for them. Simple users can't easily write a skin for WP, but they can easily find an existing one to download for free or for money. That's not a merit of the technical aspects of WP, but of the community and market size. > 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 -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
