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.

CSS

  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
  • @Pete - By primitives, I meant defining css elements that only have a few (or one) property such as color scheme, spacing, or fonts. As a plugin developer, there have been times when I did not want to include any css in my plugin but just use what was available in the core theme and I couldn't. There wasn't a single generic element to be had. If something had the right foreground and background color, it also had a large left margin making it only usable for the exact piece of markup that it was intended for. The css color variables you mentioned would be an example of what I'm calling primitives.

  • Having been embroiled in getting several different sets of CSS to work together (elgg, jquery ui, other integrated modules) I have a few points to mention.

    1. Separate functional and appearance CSS.  Things like auto-hiding a dialog or popup, many forms of floating, are functional.  If you take it out and the page stops working, it's functional.  Put these in a separate CSS area.  All the rest make it possible to omit or overwrite entirely.  Elgg has so many ad hoc selectors in its CSS that require an explicit override it's painful. 
    2. I bring in some other module and I get inadvertent effects from elgg's CSS selector being too broad.  Using elgg prefixes will help address this issue.
    3. Use some sort of templating for the suite of elgg core settings (I've filed an issue on this).  The elgg core CSS can be based on a few variables (column width, border width, fg/bg, header bg, etc) so that rather than overwriting the entire core CSS for a theme, you can just change one of the input values.

    I agree with cash on the use of primitives.  Similar to jquery UI's themeroller, identify some attributes to abstract (themereoller has ui-widget, ui-widget-content, ui-widget-header).  These make some assumptions about the actual appearance and design, but it'd be much nicer to have plugins using somethign like this:

    <div class='ui-widget-header'>

    than this:

    #bummer: { background-color: #00FF00; } /* same color as elgg widget header */

    <div id=bummer>

    It's important that these "primitives" not include extraneous info, but contain enough useful settings that you don't have to string 10 primitive classes onto a single element to get the desired effects.   Tt'd be nice if CSS could define styles which aggregate and inherit other styles, but we're not there yet.

  • Until now I have never heard anyone else call this concept "CSS primitives."  I was sure I had read an article about it, but started to think I had dreamt it!

    I think we all agree with Timothy's first point, as this basically describes primitives.

    I don't think we need to be concerned with the performance issues of using variables in CSS.  First, CSS is cached at many levels (browser, possibly server-side, and in Elgg's simplecache) so one page load wait time turns to nothing once cached.  Second, the overhead of loading the Elgg engine to spit out a text file is far greater than parsing that file for variables.  There are tons of threads where people say "I just want to edit the CSS" so I think adding this feature would be a good idea.  This is essentially the ticket Timothy mentioned.

  • Let me clarify my first point.  The functional stuff needs to be in a separate view than the display stuff.  Right now, if I want to wipe *all* of elgg's appearance settings, I can't without affecting its functional stuff.  And replacing the css view is the only way to remove all those ad hoc settings that I need to override (without duplicating and modifying nearly every single line of the original CSS).

  • Hello! Im a expert front end developer from Sweden, willing to help out on this project.

    To really start the buzz and take this project to the next level (read, higher than WP), i would suggest the following:

    • Have consistent and 100% valid strict markup.
    • Superoptimized,clean and correct css,without #id-selectors, using units,grids.
    • Only one js-file, containing the elgg-functions. Themes & plugs can provide their own
    • Perhaps a even cleaner and consistent default theme?

    I can provide tips,hints,development,design and consultancy for all of the above.

    Im currently theming elgg for a.. well, _large_, company. And currently dont have the paid time to fix the above, but i think this project has a huge potential.

    Cheers!

  • @Johan - you may have missed the previous discussion here: http://community.elgg.org/mod/groups/topicposts.php?topic=397103&group_guid=212846

    Between that one and this one, we have covered a lot of what you suggest.

    The work has already started on this and you can take a peak by checking out the source: http://docs.elgg.org/wiki/Development/Subversion

    This thread is as good as any other to offer feedback on the changes.

  • Cash, I'm all for a "css reset?" as you delicately put it in your second post in this thread.

    With a proper CSS reset and using em instead of pixels in the CSS definitions, you can get a styled webpage that looks 99% identical in all modern browsers including the unsupported older versions of Internet Explorer.

    That way you can give the enduser the power of scale the webpage should be shown in, as opposed to hardcoding it in the markup and the stylesheet. Other than that I'm also a strong advocate of alternate style with high contrast and support for people with disabilities. The latter group should be able to interact with the website on equal terms as those without disabilities. And that is also quite easy to accomplish with proper markup coupled with alternate styles depending on media used and stylesheet switching.

  • To flesh out number 3 a little bit in Cash's original post, I've been trying to push consistency of class naming by matching them up with elgg's backend naming convention (i.e. if I am displaying an entity with type 'object', it should get an 'object' class; the same could be said for subclasses).  This is also perhaps related to the 'primitives' concept that Cash brought up.

    For example, an "announcement" might be:

    <div class="entity object subtype [full] [context] [editable]" data-guid="12345">
        <div class="access_id"></div>
        <div class="actions">
            <a class="delete"></a>
            <a class="edit"></a>
        </div>
        <div class="title"></div>
        <div class="description"></div>
    </div>
    

    The exact names might be different, for example if in order to avoid conflicts with other frameworks we do class="elgg-entity-object-announcement" or possibly class="elgg-entity elgg-object elgg-announcement".

    In any case, this provides loosely coupled, intuitive (at least to Elgg developers) class names that can be mixed and matched (e.g. .announcement .title, .object .title, .announcement.full .icon, etc.).

    In this way, different visualizations for entities would be controlled much more heavily by css, not by markup.  For example, if I wanted to visualize the announcement in a search, I could just change the 'full' class to 'search' and have different css rules for '.announcement.search' and its descendants.  Obviously, in some cases it will simply be more practical to change the markup rather than write complicated css rules, but I rather like the idea that most objects can have ridiculously simple markup and let the css do the magic.

  • For next versions please leave hardcoded things like this

                            <span class="river_item_time">
                                (<?php
                                    echo friendly_time($vars['item']->posted);
                                ?>)
                            </span>

    Who need that? ( )

    wrapper.php files on river

  • Another suggestion I would have is to use dashes '-' instead of underscores '_' when naming css classes.  Three reasons:

     

    1. I find dashes easier to read (and fully admit that this reason is entirely subjective),
    2. jquery-ui uses dashes; elgg uses jquery-ui,
    3. you can use the CSS selector [attr|=val] to get objects whose attribute attr has value val in a dash separated list.  This cannot be done with underscores, so far as I know.

     

Feedback and Planning

Feedback and Planning

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