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

XHTML

  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.

  • Hmmm, nope, the original lines are different, I have no idea where I got the modified version, but it works :)

  • Ok many thanks for your reply. :)

  • I would love to see some template system for Elgg at some point - maybe Smarty templates. This could be hard to implement with the current view system, though maybe thanks to caching it would lower the loading time of views. It would also greatly simplify work on the HTML for people who don't know PHP.

    I'm already experimenting with Smarty in plugins. If I manage to find a solution that would allow to use it without too much extra work, I will post it to the community.

     

    This is another level of complexity though. Asking plugin developers to know SMARTY markup and to use it may be too much...

  • @Vazco.. 

    You're right.. I think Elgg devs would find it a little complex to work with Smarty with Elgg's views build. And as you say, SMARTY has its own markup and that's another pain in head. I worked with SMARTY when I did a couple of site with 'Handshakes' from DZoic.. Not fun!!!

  • @cash: We already cleaned and are going to valid XHTM; for example have stripped all tables our of out templates we use. All fine with IE6

    @brett: IE6 is still used by 50% of our clients: yes all terrible-way-too-big-multinationals, but they pay our bills.

    @smeranda: Naming: #elgg_sidebar is still no good; we have this sidebar at the top;) #elgg_page_menu is already better maybe

  • I agree with what Brett said about IE6:

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

    @Tom - there is always a limit to how generic you make your markup. For example, 'footer' definitely has information about presentation but since it works for 99.9% of the sites out there and is expected by front-end developers, it makes to use it.

    I plan to pull out what rules smeranda used to go from his first markup example to the second. I think that is a useful exercise and helps to validate what we've come up with so far.

  • An overview of @smeranda's modifications on post 19 (Elgg needs unique links for each comment!):

    • Don't use a div if you don't need to - avoid divitis!
    • inline javascript was pulled out
    • form was used for the filter to make it more accessible
    • The markup is more generic and uses multiple-inheritence (item_list river rather than river_item_list)
    • lists are used rather than div elements when marking up lists

    Did I miss anything?

    So far we have not said anything about accessibility or using inline javascript. Do people have any comments on these?

  • Will Elgg stick with XHTML rather than move to HTML5?

    Thanks,

    doug

     

  • Doug - you may find this link useful in understanding how HTML5 relates to XHTML: http://dev.w3.org/html5/spec/Overview.html#html-vs-xhtml

    Of course, this link is a lot more fun: http://www.smashingmagazine.com/2009/07/29/misunderstanding-markup-xhtml-2-comic-strip/

Feedback and Planning

Feedback and Planning

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