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 JSPWiki Stylesheet Design 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, 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


In a nutshell, the two main issues I ran into where these:

  1. class and id clashes between JSPWiki's css and corporate css (generic names like "header", "footer", "pagecontent", etc). This required a lot of editing of the JSPWiki's CSS to get the two to mesh.
  2. Irregularities in what classes were on elements like tables. The main JSPWiki code uses the wikitable class, the Referenced Pages plugin used a different class for it's tables, etc. There was something with the Contents plugin, but I can't remember what it is now.

Number 1 is a naming convention issue. Having a common naming scheme like prefixing wiki_ to the items in the CSS files would avoid conflicts with common elements. Granted, that would require a refresh and validation of the whole core, all the plugins... everything. Gotta break a few eggs to make an omelet, though. In the end, it would be a much cleaner design, I think, if things were thought through again.

Number 2 is an inflexibility issue. Having a way to change CSS classes currently hard coded inside JSP files without actually editing the JSP files would be great. Maybe a properties editing page and a style properties file for the core and one per plugin? At least that would get the configuration out to the designer level, even though it ends up changing a property file.

--AnonymousCoward, 21-Mar-2007


Rather than changing each ccs class, we'd better use the scoping feature of css selectors. This way only the jspwiki css file needs to be updated and we avoid long css class names. It will also solve any possible namespace conflict. Instead of using #pagecontent { ... } , we could use #jspwiki .pagecontent { ... } . --DF, 22 Mar 2007


Dirk's suggestion makes sense. Scoping is good, and it's pretty easy to wrap everything in an extra div (or put the id=jspwiki to the body).

However, making the css names settable for the core might still make sense. Making the JSP pages have such a feature would make them very messy, though.

--JanneJalkanen, 22-Mar-2007


To Dirk's comments - it's the #pagecontent ID, not the .pagecontent class. Classes and IDs are used for two different things, although they have almost the same function. Classes are things that can be used anywhere in a page, IDs can only be used once to uniquely identify a style for a particular subsection of the DOM tree.

Typically IDs define specific structural page areas (like "header", "footer", etc) that have specific styles associated with them. Classes are for generic style information that can be applied independently of the logical structure of the page.

Here's some more information with further links and examples.

--ELadner, 23-Mar-2007

Yep, you're right. I did mean '#' of course :-) Allthough, since ID's should be unique on the page, we may need to go for .pagecontent in stead of #pagecontent. --DF

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-14) was last changed on 20-Jul-2008 14:54 by DirkFrederickx