02May2008

My ideal CMS text editor

I recently read Richard Rutter’s The Elements of Typographic Style Applied to the Web after reading about it here. The essay makes several mentions of CMSes and the application of tags to help in the display of text. This got me thinking about the shortcomings of CMSes.

CMSes are a great way to empower website owners. Allowing someone to update their own site without needing to learn HTML or CSS. The use of JavaScript text editors like FCKeditor and Tiny MCE mean that people can even add styling to their content.

Since starting to work on CMS based websites some five years ago I’ve always had a nagging doubt about the code they allow a user to produce. Frequently not accessible, validatable or sometimes even readable. The problem with these editors is you are giving someone the means to completely wreck the look of their website, a website they may have paid thousands of pounds to have designed and built. I believe that part of being a web designer is setting boundaries for users looking to edit their own content. Below is my ideal text editor for a CMS.

I would let users set titles as <h2><h6>. I would prevent them from using <h1> as that would be retained for the page heading and generally you only have one of those. Also I would only allow <h*> tags on a maximum amount of words – say 20, to try and stop users from misusing <h*> tags as a means to make text bigger.

I would convert any use of <b> or <i> tags to <strong> and <em> as they are more symantically correct.

I would remove any <font> tags – they have no place in modern web design.

I would remove any inline CSS as this is not content. A CMS should be about editing content not making design changes. That’s my job and it’s what your paying me for, just because you can set that text colour to red and the background to yellow doesn’t mean you should.

It would be great to be able to detect when someone has typed their content all in caps and either convert it to lowercase while informing them that all caps is unreadable. Again maybe set a tolerance of 10 words to allow for any acronyms.

Tables are a difficult subject. They can be legitimately used to display product data but they can also be a source of annoyance to us web designers, they don’t always play nice with CSS. I would like to be able to switch allowance of tables on or off based on the type of website – is it a shop or a blog? A shop might need to display product data for example.

Some customers will want the freedom to change the colour of text and font faces and no amount of trying to educate them will change their minds, but for the most part setting some ground rules like the ones suggested above will help users maintain their site to the standard it was authored at. Which will also help with accessibility.

Filed under: Web Design / Dev — Tags: , , — admin @ 4:57 pm

One Response

  1. Andrew says:

    The one thing I would do is to separate the editor from any built in editing capability.

    I started writing a semantic writing tool that added text in blocks. Each of those blocks had a defined purposes and generated the html separate from that. It stored the end result as object oriented code and as html so the underlying html code could be updated without the user being any the wiser.

    I was writing it to form part of my own CMS but I shelved it. There’s a demo of the writer on my website though and anyone is welcome to take the code.

Leave a Reply

(will not be published)