Clicky

Why are HTML editors in CMSes?

Thank you Jay. Your list of

Thank you Jay. Your list of features to give content contributors is useful. And you make a good point about why the view HTML can be helpful.

Do you (or other readers) have any thoughts on the best way to handle the table use case listed above, especially if preview is to work? There seems to be that tension between ease of editing, standardization, more complex elements, and live preview (so pure XML editing would mean good standardization but probably not as good for the other aspects, a limited palette with regular HTML editor will help but only for simple elements).

Thanks,

-- David

David, In the case of

David,

In the case of TinyMCE (and likely other RTEs) you can assign a user stylesheet (a special CSS sheet that is only used to style for the RTE) to the RTE that mimics the front end type and design styles of the elements. While this is yet another additional step in implementation, it is worth it for some clients or users. So the case of having a table that has branded/styled display that isn't hosed by the RTE and looks on the back end as it does on the front is a non issue if we as implementors take the time to do it.

I addition, as an implementor, you need to customize the input fields. Pages are often structured and site sections have individual on-page information architecture. It is important that we don't expect users to have to maintain complex information layouts where they have no choice but to refer to a style guide or copy some template. This is another place where limiting decisions of the editor wins. Custom fields that relate to specific content elements, checkboxes and radio buttons for selecting optional page elements such as a sidebar block or comma separated lists of tags.

Giving a content editor the keys to HTML or an RTE that still requires manual formatting is little better than the days of using GoLive or Contribute from a desktop editor to update the site via ftp. Failure to do the above is our failure and any complaint about the client breaking the site (in most cases) should be at our selves for not doing it right.

I'd love to hear your thoughts on the above.

Don't give users choices.

Don't give users choices. Don't leave them every styles or oblige them to learn HTML to manage site content. It is critical that whomever implements the site should tailor it for the content type or the end user.

When I was building sites daily for clients it was important for me to limit the Rich Text Editor toolbar to only those essential items the user will be permitted or need to use.

It typically boils down to the following:

* Format: p, h3-h6 ( I reserve H1 and H2 for page title and subtitles), blockquote
* Strong/bold
* Em/Italic
* Lists (numbered and bulleted)
* Custom CSS classes
* Copy/paste tools (text/Word)
* Occasionally Tables and View HTML

The reason I occasionally leave view HTML in case a user needs to view the source to remove orphaned elements, anchors and etc that all the RTEs eventually will (CKEditor, TinyMCE, WysiwsygPro and etc).

Most of these can limit the toolbar buttons and plugins can extend the buttons available or add additional actions.

The fact that the default toolbar is there is specifically because the implementor didn't customize it, the tool can't be customized or the implementor didn't know it could be done.

In any case this is critical for maintaining corporate standards and in addition making it easier and more approachable for site editors to work with the tools.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.

Need Help?

Most Buzz