This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]
TitleCSS cleanup and changes
Date15-Mar-2007 18:00:52 EET
JSPWiki version2.x
SubmitterELadner
Idea CategoryGenericIdea
ReferenceN/A
Idea StatusNewIdea

After having spent some time integrating JSPWiki into a corporate environment where you have to follow style guidelines and templates, I've got some suggestions that, I think, would help JSPWiki in the long run.

CSS Names#

CSS naming in the jspwiki.css (and others) is pretty generic and it's easy to run into naming conflicts when trying to use CSS from an existing site. As a solution, the CSS could be modified to create a namespace, if you will, that would prevent naming conflicts. Prefixing all of the classes and selectors with something specific to JSPWiki (like "JW_" or something) would prevent overlaps with existing CSS.

CSS Hardcoding#

Quite a few elements of JSPWiki CSS are hardcoded into JSP files and Java files (the wikitable class, for example, is embedded in at least 4 Java files and 2 JSP's in the core code). It'd be REALLY nice if those things were pulled from a property, or could be overridden with a property. Something like:

# Set default class for grid type tables
jspwiki.style.displayTableClass = wikitable

Doing that would move presentation out of the code completely and allow a lot of flexability in integrating with existing CSS since major elements on the site could be styled with existing style sheets, instead of having to extensively hack JSPWiki's CSS to match (or duplicate) existing CSS.


Have to think about this... Changing everything now then again breaks the code of all the people who have already done some custom adjustments. Anyone else have any ideas on what would be the best way of handling this?

--JanneJalkanen, 18-Mar-2007

I agree with the problem that CSS is hardcoded into JSP files and Java files. The current templating system is not self containing (in the sense of an self explaining abstraction layer): A designer has to dig into JSP and Java files to get the big picture. Surely he can use something like Firefox Webdeveloper as an easy solution to get the names - still, it is hard to tell a designer "you don't need to know Java" - because it is impossible to change the all the css class names.

What would be nice is if you could give a designer the templates and css and tell him: that's all you need. The property file is an Idea, but I think it is one more thing a designer needs to touch. What if there would only be the JSP template files and the CSS files that need to be changed? Therefore all the CSS class names should be overwritable in the JSP template files: Would it be viable to overwrite the default CSS names in the JSPTags itself (as parameters of the tags)?

Someone (Lost in the depth of the mailinglist, was it Dirk Frederick?) had this Idea of using available templates of existing CMS systems. You could have a drupal template that overwrites the default CSS names in the JSP tags and then uses the CSS file of drupal for the particular skins.

I can't judge if it is that easy, because I am not a designer. Just an Idea.

--ChristophSauer, 18-Mar-2007


Having css class names hard-wired in the JSP files is not a problem, as long as the css class names are sufficiently descriptive. There should be little or no 'presentation' stuff (in terms of css styles) inside the JSP files. I think this is already the case today. (apart for some funny exceptions such as the little paper clip next to a non-inlined attachments, the logo, ...)

Documentation could definitely be improved, so it would be easier to update the jspwiki.css if you need to. I described some stuff in BrushedTemplateCSS but this page should be updated and brought inline with JSPWiki default template.

Having an additional level of 'configuration' via the jspwiki property file would make things unnecessary complex.

--DF|DirkFrederickx, 18 Mar 2007 ---- The more I think about this the more sense the idea of "propertyizing" the built-in styles makes. It shouldn't even be too hard. --JanneJalkanen, 18-Mar-2007

Add new attachment

Only authorized users are allowed to upload new attachments.
« This particular version was published on 18-Mar-2007 16:33 by JanneJalkanen.