XHTML and CSS guideline discussion: Part 2

The previous discussion on markup went well. Next up is CSS. I'll try to capture the consensus in this top post as we discuss. There is obviously overlap between the two discussions. We'll wrap everything up in a guideline on the wiki/in svn when done.


  1. Use underscores as separators in ids and class names
  2. Prefix with "elgg_" to namespace the CSS
  3. names should describe content/purpose and not presentation
  • 1. any formatting guidelines? I recommend that sections be set off with a comment block and plugins' css should always start with a comment block to make it easy to find. Should the comment block contain something to make it easy to search for? I've seen projects use something like /* @group blog */

    2. css reset?

  • ok for 1&3  ;   2- *all* css is for elgg here.... so does not make sense to prefix all with elgg_  I think...

    We do need to standardize, however. Never seen project with so much (often redundant) css... I've no idea how to structure this more then a lot of hard labour going through each css.php file...  

    Side topic: also browser caching of css could be improved ... could it not?


  • Tom, one reason to namespace elgg's css is that javascript packages often include css and you don't want their css to conflict with elgg's.

  • The namespacing of the CSS also allows for simpiler integration with templates. For instance, I have used Elgg in a site where the outer shell was HTML/CSS pertaining to the whole site, and the meat of elgg fit inside this shell. By namespacing, it would be much simplier to streamline CSS updates and eliminates the chances for confilcts.

    CSS reset is a very nice addition, I'd vote for it.


  • Since all the changes to css are made in css.php files and not in the actual file that is used on the page, I think it would be a good idea to format css that is used on the site - to remove white spaces and some redundand styles. It would lower the size of css file.

    When creating an Elgg site, I move styles to single file and format them there - here's a good tool for it. Still, I think most people won't do this.

  • I agree with vazco

    I personally am used to write css without spaces, all on one line. Appart from making smaller files it is easier to find and look at.

    I miss in this discussion the mentioning of cascading styles. The core (cash proposes namespacing) should define the basic set of css. Whoever wants to modify, overwrites, using the same name.  This would also reduce the css overhead as plugin users would need to consider the core css but still could overwrite by being later in the cascade.

  • For minifying css or javascript there is also the possibility of doing it on the server with something like this: http://code.google.com/p/minify/. This could be made into a plugin.

    I disagree that it should be done to the core files before distribution in the core Elgg package. The css needs to be readable by us humans while we develop.

    To bring up another discussion point, what do people think about adding primitives (classes that have some generic properties like color) that could be used by plugin authors? I know that I have tried at times to write my plugins without defining any new css elements but use what the core provides. The core css was just too specific though - anything that had the background and foreground color also had all sorts of spacing and font info. The problem with every plugin defining lots of css is that people building sites have even more css to handle in their site theme. I know that it is not easy to predict what primitives are needed but I think even a small start in this direction would be useful.

  • Some interesting points & discussion from these two threads, thanks everyone.
    Brett and I have talked a lot about these issues, and I thought it time to post our current direction and decisions here.

    1. ID's and classnames - lowercase, with underscores as separators
    2. namespacing - only on 'top level' blocks (see example below)
    3. semantic naming - ids and classes describe content not layout
    4. much reduced & simplified DOM (instead of trying to provide an underlying framework for all conceivable themes and layouts to be built on = divitis, keep it real simple/minimal. Theme authors can always override page shells and canvases in their theme bundle to add any additional framework they need)
    5. lots of re-usable elements
    6. inline js removed as much as possible
    7. no more tables - they were only really used to combat IE6 layout issues, and we're not so concerned with IE6 any more, as long as elgg remains usable (if not pixel perfect) in IE6.
    8. a conditional stylesheet for IE6, and another for IE7

    The default css file (views/default/css.php) will be logically laid out, with clear sectioning (via comment blocks), and a table of contents & additional notes at the top of the file. Any css pertaining to a plugin will be moved out of the default css file and into it's corresponding plugin!

            <title />
            <elgg_topbar />
            <elgg_header />
                <elgg_sidebar />
                <elgg_page_contents />

    Re. a css reset - elgg already has one at the top of the default css file (although it will be more clearly labeled as such from now on!).

    We did toy with the idea of moving chunks of css (reset, typography etc) into separate css files and use @import to load them, but decided against it due to the unnecessary extra http requests this will incur. One clean, semantic, vastly simplified, logically laid out, and fully commented default css file will be easier for all concerned. That's the aim anyway!


  • @cash:  

    -I like the idea of primitives. We have highly customised themes with parameters that change according to different sites It will greatly simplify changing the color scheme of the site. . Borders Corners. With fonts this could work as well. Not so sure about other elements...

    -I see the risk with external javascripts css includes and have experienced the issue. Still we overcome with good cascading. Prefixing *everything* with "elgg_" wow ... nightmare for all the dynamically created classes in our plugins... 


  • @Tom, I don't think I was particularly clear re. prefixing with elgg_ - we're only proposing doing this for (what I'm calling) 'top level' page elements, ie. the toolbar, header, content, sidebar, page_contents and footer. This way everything else below in the DOM can be namespaced still by cascading properly. Elements inside elgg_topbar, elgg_header etc won't carry the prefix.

    @Cash and @Tom - I meant to mention the use of primitives. Although not exactly what you meant, v1.8 will have an 'Appearance' area within the site admin. This will allow admins to easily change the color of common elements eg. links, h1, h2's etc, body and header backgrounds (incl images). As well as a custom css field where you can directly write out any additional css rules - all without having to touch the theme's css directly. Also there will be a logo upload form - for an easy way to place a logo in the header.

    One idea I've had in my mind for a while (and I haven't talked to Brett about this yet) seeing as our css is actually php and already being parsed - why not define a few color variables at the top of the file. Something like #color1, #color2, #highlightcolor1, #accentcolor1, etc and then refer to them in the element rules. That way when theme authors want to quickly change the site colors there is only one place you need to look - the variables at the top of the default css.

    However, now the default css is getting much cleaner and organised - I'm finding there is only a handful of places where colour is defined now, so having variables might be overkill and just increase parsing time?

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.