XHTML guideline discussion: Part 1
By Cash
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
- Valid XHTML.
- 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.
- 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.
- Markup should be content driven rather than presentation driven. IDs and Class names should not describe presentation: Bad Example: two_column_left_sidebar.
- Avoid inline javascript
- Accessible markup
- 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.
Feedback and Planning
Discussions about the past, present, and future of Elgg and this community site.
This is surely too late, but the core has many input elements wrapped with labels? Isn't that what the "for" attribute is for?
I just read this article and I remembered this thread. JQuery already adds an specific header to ajax requests, that can be checked in the server script. So, the parameter I suggested is not even necessary.
- Previous
- 1
- 2
- 3
- 4
- 5
- 6
- Next
You must log in to post replies.