XHTML guideline discussion: Part 1

As has been discussed on the community site, Elgg's XHTML, CSS, and UI could definitely be improved. As a starting place, I'd like to start a discussion on a guideline for XHTML. This guideline would be followed by core developers and serve as a good standard for plugin developers. The goal is better markup which makes it easier to do UI/UX work with Elgg.

What rules or recommendations would you like to see in an Elgg XHTML guideline? (Please note, this is for XHTML - not CSS. We'll get to CSS soon enough - edit - probably no way to keep them separate!).


  1. Valid XHTML.
  2. Keep the DOM simple. Don't use several divs when one or two can do. If you do find yourself using a lot of markup, you are probably trying to solve a presentation issue with XHTML markup rather than using CSS.
  3. Use the correct markup for the content. Tables should be used for tabular data not for layouts. Lists for lists (rather than paragraphs). And so on.
  4. Markup should be content driven rather than presentation driven. IDs and Class names should not describe presentation: Bad Example: two_column_left_sidebar.
  5. Avoid inline javascript
  6. Accessible markup
  7. Reusable markup.
    • Prefer classes to ids
    • Use general classes for shared presentation and specific classes/ids for unique presentation. See discussion on the .messages markup below
    • Do not design your markup so that all CSS needs to be on terminal elements - use CSS inheritence

The CSS discussion is here.

  • Thanks, Cash. I will look that all over!


    p.s. Posts here still seem to be slow, don't they?

  • There is at least one case where I'm not sure what is the right decision about inline javascript. The case is when you have an element list, like this thread for example, and you need a delete link for every one of them. As you can't use numeric only IDs or any other attribute for identifying the elements, using a jquery single call you must do some kind of ID parsing for knowing what was the clicked link.

    What do you think?

  • Cash, reading over the cartoon version :) it seems that XHTML1 transitional (which is the doctype for the page) can be simply interpreted as HTML 5 by changing the the doctype definition.

    But XHTML2 is dead, right?



  • @morgar regarding the inline JS, in this case would there not already be a unique attribute in the markup for each element? Like a href? For accessibity issues, whenever feasable, a JS disabled deprecation should be available, therefore the href for the delete link should go to a page where the unique ID is passed. With JS, we could simply sniff out that unique ID from the href, and use it run the AJAX delete function.

    Based on abilities such as this, I am in favor of stripping all inline JS. The result will be cleaner markup, central JS code and simplier debugging.

    @Tom I understand the sidebar can be defined in a presentation connontation, however I was going for a content connontation (items placed adjacent to the main content). Nonetheless, your suggestion for #elgg_page_menu is valid. However, as Cash pointed out, there is a threshold between generic and indistinct markup. This is a balance we're going to need to explore as the markup gets cleaned up.

  • @doug - XHTML2 is dead. I think of HTML as defining the tags and XHTML as defining a set of rules for using the tags (lowercase, must be closed, etc.).

  • @smeranda I'm not talking about the case of a direct link like <a href="delete.php?id=22"> but when you need to ask a confirmation, or maybe doing an ajax call for deleting the object. Do you mean using the id attribute like <a id="del22" href="#"> and parsing the id in the jquery code?

  • @morgar - jQuery allows you to use CSS selectors to bind multiple elements at once.  Ex:

    <a class="deleteLink onclickConfirm" href="http://delete_link?guid=1234">Delete message</>

    <a class="deleteLink onclickConfirm" href="http://delete_link?guid=3254">Delete user</>

    <a class="deleteLink onclickConfirm" href="http://delete_link?guid=6453">Delete file</>

    A confirmation prompt can be put on all of these links with one jQuery call:

    $('.onclickConfirm').click(function() {

        return confirm("Do you want to delete this?");


    @smeranda - Accessibility!  I'm glad you're the one who brought this up ;)  Since Elgg is used in government and education facility, it's very important to consider unobtrusive javascript and accessibility.  I know at least the US and the UK have pretty strict laws about accessibility when evaluating if a software can be used, especially in state-funded educational institutions.

    The easiest way to ensure accessibility is to write everything WITHOUT ajax at the start and add ajax in later.  This makes sure that links actually work.  When you start putting ajax in, you'll bind to the ajax links, extract the href, and send it to the (currently non-existent) ajax handler.

    I hadn't wanted to pollute this thread with my javascript goals or accessibility plans, but it's so hard to talk about just one aspect of this without including everything...

  • @Brett - For us (University of Nebraska-Lincoln), accessibility isn't just a nice feature, it is a requirement by law (at least the federally-funded institutions). We follow the same process: design for a fallback that won't require Javascript and then put in the JS functionality to improve the UX. At the minimum, a user should be able to do all tasks without JS enabled. Advanced features/presentation/effects can be hanlded with JS.

  • @Brett, yes, you are right, I know that way. I didn't choose the right example for my point, my fault. The specific case is when you need to do an ajax call and pass the id in the call. But yes, maybe this is not the right topic for discussing this in detail.

  • @morgar I'm inclined to believe all JS functionality can be done without auto-incrementing IDs or inline JS provided the markup and accessibility is carefully thought-out and created. For your example of deleting an item, you could use jQuery to target these links without modifying the markup (not even adding a class):

    Markup: <a href="delete.php?ID=22">Delete this item</a>.

    $('a[href^=delete.php?ID=]').click(function() {
    //We now have all the links to the delete page, let's catch the click and do JS instead.
    var IDtoDelete = $(this).attr('href').split('ID=');
    //Now we have the ID (22) which can be used in the AJAX call
    var confirmDelete = confirm("Are you sure you want to delete?");
    if (confirmDelete) {
    $.get('delete.php', {ID: IDtoDelete[1]}, function(data) {
    alert ("Item deleted: "+data);
    //or whatever else we want to do
    return false;

    *note: untested JS

    This is an over-simplified version for illustration purposes. In this case, we wouldn't need to parse out the unique ID (we could just simply use the href value as the .get() page), but I did it this way to show that we can use generic markup to grab an ID and then use that in any function we need.

Feedback and Planning

Feedback and Planning

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