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
The CSS discussion is here.
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
Thanks, Cash. I will look that all over!
doug
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?
Thanks,
doug
@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 confirmation prompt can be put on all of these links with one jQuery call:
@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>.
*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.
- Previous
- 1
- 2
- 3
- 4
- 5
- 6
- Next
You must log in to post replies.