The markup should be valid as defined by the w3 validator http://validator.w3.org/ .

Valid markup makes it easier to debug XHTML problems. It can make the rendering more consistent in browsers. It makes a project/site look more mature and professional. It's just a good idea.

Cash, I second your requirement for valid markup. To further your arguments, validity allows for enhanced JS/CSS functionality.

In addition, other recommendations regarding XHTML:

1. Table-based layouts should be removed. In looking at the profile page, the layout could be easily done with XHTML/CSS. This allows for further separation of presentation from markup.
2. Use the correct markup for the content. To continue dissecting the profile page as an example, the links underneath the avatar are wrapped in individual <p> tags. These should be list items. The markup descibes the content. It will also make it easier for plugins to integrate (I just need to add an <li> instead of <p class="X">).
3. To further the markup describing the content, the naming conventions of IDs and Classes should be better used. For instance, the names should not descirbe presentation. As an ID example:

   two_column_left_sidebar_maincontent_boxes

   What if I want to use the content on the right side of my page? Furthermore on this page, the following ID is also found on this page:

   two_column_left_sidebar_boxes

   Ideally, the IDs should be "elgg_maincontent" and "elgg_sidebar", respectivly and a class of "elgg_two_col" should be applied to both in order to provide the column structure in the CSS. Through this, we can also achieve reusable styles - which will be easier to maintain/update and will provide a smaller footprint.
4. Reusable Markup - As I just eluded, resuble markup will save a lot of time/troubleshooting. Check out the feedback messages: normal and error. Both appear as the same structure/intent yet they used different class names (.messages & .messages_error). Examining the CSS shows that most of the presentation is duplicated (border size, radius, position, margin, etc.). This should be setup to allow for .message to setup the presentation, and a new class of .error that can be applied to .message to provide the error-specific presentation (color changes).

These are a few of my quick thoughts. As Elgg gets more powerful, becomes more widely-adopted and grows larger in codebase, I'd like to see markup changes begin soon - it will make it much easier to scale and adapt.

+1 on valid XHTML.

I would love to see a more simplified DOM.  I know the DOM is on the Javascript side of things, but a simpler DOM also means faster rendering for page paints.  Elgg's defaults pages have a pretty complicated DOM and I'm not sure it's needed.

Sort of related to smeranda's comment #3, I'd like to have more semantic-based ids and classes.  Creating pages with such structures will greatly simplify theming and jQuery calls.  I know object oriented CSS is a fad at the moment, and I'm always wary of fads, but there is something attractive about it. Semantic structures generally make more sense, and sense is always good...

What I'll do is pull rules out and add them to the top post - people can lobby/complain as needed on what I select.

On smeranda #1 - I do have a layout for the profile page that is div based rather than table based. It is a lot cleaner and has fewer rendering problems than the table layout. I believe it should work with IE6 but I have never gotten around to testing that.

A different but related comment than #3: if there is a chance that an element may be used more than once on a page, it should be a class rather than an id. The current markup is too liberal in its use of ids.

What do you think about dropping support for IE6?  It's 9 years old and 2 major versions behind...And I really dislike it.

Last time I checked it still had 25% of the browser market due to corporate controls. There are plenty of sites that support IE6 with nice div layouts. There is no reason Elgg cannot.

Alternatively, you could drop support with the default theme but provide an IE6 friendly theme for those who want to run Elgg in an environment where IE6 is the mandated browser.

http://www.w3schools.com/browsers/browsers_stats.asp shows it down to around 11% as of the end of last year.

Regardless, you're probably right that between corporate control and school systems, IE6 should be supported at some capacity.  If it can be done and isn't a huge drain on resources, it sounds good to me.

Given the latest security exploits for the MS browsers, and the downward trend of IE6, delivering a stripped down experience in order to take advantage of new, advanced features like CSS3 is worth it. YouTube, Facebook, and many of the big sites have either already done so or have announced they intention to do so. As Cash mentioned, delivering an IE6 theme that renders with less sparkle could be appropriate.

A small suggestion based on the rule in the top thread:

Example: .messages & .messages_error have the same basic presentation logic and could be replaced with a single generic class and two smaller specific ids.

I'd propose this example to simply use two separate classes. By using a 2 class model, we allow for greater reusability. To demonstrate:

<div id="elgg_message" class="message">The message</div>
<div id="elgg_message_error" class="message">The error message</div>

While this will allow more flexibility in CSS, it still doesn't quite work correctly. For instance, what if I needed more than one error div on a page? Valid XHTML won't allow for duplicated IDs. An even more flexible markup would be:

<div class="message">The message</div>
<div class="message error">The error message</div>

In terms of the CSS, the IDs are not required (perhaps they are needed for JS targetting, but even this could be done simpler). All the presentation is handled by targetting the class (in this case 'message') and extended by doing simple color overrides with an additional class ('error'). This cleans up the markup by removing, and allows for more streamlined controls.

So, to continue on the resuable markup recommendation: utilize more class attributes and less id attributes.

Glad to see great activity in this topic. It was started sometimes in the past, but they didn't do too much progress. I agree it's the time for a move in that direction.

As Brett pointed, a DOM simplification is mandatory, the current html code is so unnecessary crowded.

We implemented XHTML/CSS in our Elgg site. I started trying to adapt the existing code but I finish rewriting most of it from scratch. It might have some glitches because it was my first big project in XHTML :)

I guess the right move should be start it from scratch.

I fully agree about the 'progressive' classes like in messages/errors. Some primitives will be also necessary, like profile and group widgets for example, that currently implement their own classes, resulting in a big mess.

Another decision is about using XHTML strict or transactional. I vote for this last one.

My 5c.

According to the Microsoft End of Life page for IE (http://support.microsoft.com/gp/lifesupsps/#Internet_Explorer), it looks as though they will no longer support it after April of this year.  Maybe that will provide enough incentive for people (i.e., corporations) to get off of it.

I have decided not to support it on my site (encourage users to upgrade or switch).  I waste enough time troubleshooting rendering issues with IE7 and don't want to hassle with IE6 as well.