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.
@smeranda Thanks for the example. Yes, I guessed the only way for doing this without inline js was doing some kind of parsing inside the function.
@smerand - What if we offload the id sniffing to PHP since it has handy functions for this already? If our ajax handler accepts a full URL, it will be dead simple to extract the query params from that...
@Brett - Sure, I don't see why that wouldn't work.
Well, in that case, couldn't ajax call the same href by appending another parameter like $(this).attr('href') + '&ajax=1' directly in the url (it works).
So, no href parsing is necessary in javascript nor php. The same page does the action, returning the result to the ajax call or following the navigation flow is javascript is disabled.
PS: I guess we need a branch thread for this offtopic divagation :)
@Morgar - That's definitely another possibility.
I think we're almost done with this thread. What's left?
How about style guidelines? lower camel case or underscores for classes and ids? I think Elgg mostly uses underscores (ex: page_container) with a few lower camel case mixed in (ex: contentWrapper).
I don't have a strong preference, as long as they are consistent.
How about using a psuedo-namespace and preferencing all elgg classes with 'elgg_' or 'elggXXX'?
Having a chat with Pete about this, we're leaning toward using underscores for consistency with the views names. Consistency is nice :)
CSS discussion here: http://community.elgg.org/mod/groups/topicposts.php?topic=424690&group_guid=212846
@smeranda , regarding event handlers in jquery. Have a look at the concept "event delegation". This technique is implemented in jquerys a the function .live();
http://api.jquery.com/live/
If used properly it will increase performance, for example on a page with 500 add/remove buttons. In your case an handler will be attached to each of those links. Using delegation, one. :)
- Previous
- 1
- 2
- 3
- 4
- 5
- 6
- Next
You must log in to post replies.