The Elgg Community: XHTML and CSS guideline discussion: Part 2

Home Plugins Groups Discussion

Elgg's roadmap group

Subscribe to feed

Group discussion

Group pages

Group discussion > XHTML and CSS guideline discussion: Part 2

XHTML and CSS guideline discussion: Part 2

Cash

Cash
192 days ago

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

Use underscores as separators in ids and class names
Prefix with "elgg_" to namespace the CSS
names should describe content/purpose and not presentation

Cash

Cash
192 days ago

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?

Tom

Tom
191 days ago

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?

Cash

Cash
191 days ago

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.

smeranda

smeranda
191 days ago

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.

Mike (vazco)

Mike (vazco)
191 days ago

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.

sawjer

sawjer
191 days ago

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.

Cash

Cash
191 days ago

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.

Pete Harris

Pete Harris
189 days ago

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.

ID's and classnames - lowercase, with underscores as separators
namespacing - only on 'top level' blocks (see example below)
semantic naming - ids and classes describe content not layout
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)
lots of re-usable elements
inline js removed as much as possible
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.
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!

<doctype>
<html>
    <head>
        <title />
    </head>
    <body>
        <elgg_topbar />
        <elgg_header />
        <elgg_content>
            <elgg_sidebar />
            <elgg_page_contents />
        </elgg_content>
        <elgg_footer>
    </body>
</html>

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!

Tom

Tom
189 days ago

@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...

Pete Harris

Pete Harris
188 days ago

@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?

Cash

Cash
188 days ago

@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.

Timothy Wall

Timothy Wall
188 days ago

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.

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.
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.
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.

Brett

Brett
188 days ago

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.

Timothy Wall

Timothy Wall
188 days ago

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).

Johan Bouveng

Johan Bouveng
182 days ago

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!

Cash

Cash
182 days ago

@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.

Elriique

Elriique
182 days ago

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.

Evan Winslow

Evan Winslow
177 days ago

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.

alfalive

alfalive
176 days ago

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

Evan Winslow

Evan Winslow
174 days ago

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

I find dashes easier to read (and fully admit that this reason is entirely subjective),
jquery-ui uses dashes; elgg uses jquery-ui,
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.

Kevin Jardine

Kevin Jardine
174 days ago

I would support Cash's original proposal for underscores in ids. Dashes are actually illegal characters for ids in other contexts (eg. PHP variables) and using two different id syntax rules for a PHP app is confusing in my view.

Brett

Brett
173 days ago

I agree with underscores for class names. Of the reasons listed for using a dash, I think #2 is the only compelling one.

If we ever need to use the [attr|=val] selector, we're probably doing something wrong. Defining the rules using [attr|=val] for class="message-error" is more complex than class="message error". It's better to separate the classes out instead of string them together with a dash.

rufuz

rufuz
171 days ago

hi all,

I would also suggest to write a comprehensive documentation about ids and classes changes/removes/additions as the project evolves, in order to make easier the transition for those users who customized the actual default theme.

bye!

Blue

Blue
165 days ago

I hope the geneal view and the widget view are separated completely in Elgg 1.8. In Elgg 1.7, When I change the style of a plugin, it's widget style changed at the same time.

alfalive

alfalive
163 days ago

What is about displaying tiny mce depending on class or id instead to replace all textareas in elgg with tiny mce?

Brett

Brett
163 days ago

@alfalive - This is already in SVN for the 1.7.1 and 1.8.

alfalive

alfalive
163 days ago

This is very cool!!! :)

Evan Winslow

Evan Winslow
163 days ago

What if we want plain textareas w/o tinymce (mixed with tinymce textareas on the same page)?

Brett

Brett
163 days ago

@Evan - views/input/plaintext will do it.

Evan Winslow

Evan Winslow
163 days ago

@Brett - so now I'm confused. How is this different from what's going on now? What did alfalive mean by "all textareas" if plaintext (which outputs a textarea) doesn't have tinymce?

Brett

Brett
163 days ago

#Evan - Previously you couldn't mix plain and tinyMCE textareas on a single page because TinyMCE would take over all textareas.

Evan Winslow

Evan Winslow
163 days ago

Ah, I see now. I read his suggestion completely the opposite way! >_< Thanks for clarifying that.

lord55

lord55
159 days ago

sprite all default river icons in one single file is more good

| About | Terms | Privacy |

Powered by Elgg

Powered by Elgg, the leading open source social networking platform