| Additional Information | Suggestions:
-
Don't pre-configure allowable tags (multi-line entries can get decently formatted on display anyway; HTML is needed only for user audiences that are familiar with HTML coding). I'm speaking from experience here: I've seen far too many problems with end user posts using HTML breaking display in on-line forums and bug trackers: unless you're sure your audience has a good knowledge of HTML it's better to avoid it.
-
Administrator documentation: give a suggestions as to which tags would be useful:
- lists: [ul], [ol] and possibly [dl] with their elements [li], [dt], [dd];
- suggest to use [strong] in addition to [b] and [em] in addition to [i] for those users who like to keep accessibility in mind;
- [code] and [pre] can be useful for those installations where users may need to post code samples;
- avoid [p] since in combination with output formatting this can easily lead to invalid (X)HTML (as I've found)
- give a suggestion which tags not to allow as they would interfere with the user interface (specifically, form tags with content); don't assume an administrator is necessarily an (X)HTML expert.
-
User documentation: If HTML tags are allowed at all, dynamically generate a section explaining which tags are allowed, and give some hints about how to use them (especially that tags need to be closed) so that generated output will have a good chance of still being valid (X)HTML and thus accessible; there can be a section included/not included for each group of tags.
(Note that I'm avoiding lists in my post since I have no idea what this installation is allowing or even if it would allow them, whether the output would be still valid XHTML!) |
|---|
