Starting from the building blocks, what should an editor allow? Most of the browser based editors allow people to edit the source HTML. Indeed, if you allow people to (from ATAG):
Allow the author to edit all properties of each element
Then allowing people to edit the source is a possible method. However, one of the top priority guidelines is also:
Ensure that the tool automatically generates valid markup.
So the editor will have to filter what gets saved, the requirement is to allow the developer to restrict what HTML elements and attributes are allowed.
This filter should basically get rid of anything not recognised as valid HTML, and in fact, anything that doesn’t separate style and content. This leaves us with the following (X)HTML elements, list from W3Schools:
Assuming that the editor does not open the whole page, but just part of it, items outside of the content area (e.g.
title), have been removed.
The list also removes deprecated elements such as
Some items should not be edited by a WYSIWYG editor, such as form elements, frames, and scripts, although these could be included with specialist functionality, that is beyond the scope of this article.
<var> are also of limited value, and could be ignored.
I would not include
style, as this would allow inline styling. I also wouldn’t include
accesskeys. Accesskeys have various problems, and although there are good accesskey implementations, they should be part of the site templates, not editable by authors. Tabindex is primarily useful for elements such as form controls, and should only be tackled (if at all) in a site wide, consistent way, therefore not controlled by the author.
Element Specific Attributes
Some elements need particular attributes to add meaning,
alt text on images for example. These are the attributes for each element that should be allowed:
Editor support for restricting HTML
This section of the page could change, these are just preliminary notes which I’ll update at the end of the series. If I’ve missed something (quite likely when trying 3 things at once!), please leave a comment, preferably with a useful link.
The documentation outlines how to restrict the output with a configuration called
valid_elements, which is aimed at providing exactly this functionality. Subject to experimentation, TinyMCE seems to support this requirement well.
The FCKeditor documentation doesn’t mention a configuration for this purpose, although you can remove toolbar options easily, unless you take off the HTML button there doesn’t appear to be a way of enforcing certain HTML.
Although the Xstandard documentation doesn’t give any indication of how to restrict the available tags, it does appear to restrict people to valid XHTML. In fact, the code produced when you view source is excellent, actually well-spaced XML rather than HTML.
Still, even without this specific configuration option, it is leagues ahead of FCKeditor (and ahead of a default installation of TinyMCE). It almost supports this requirement for restricting the code allowed anyway, although it would be good to remove many of the ‘
properties‘ in the interface.