Once you are off with a CMS and people start to edit pages, all sorts of code grows inside the database. Copy-paste leftovers from MS Word and code handwritten by tech enthusiast clutter your clean and simple HTML template and after 2 weeks your design is no longer what it used to be.
Sounds familiar?
To avoid all these problems we can use a well-known CSS combo: dependency and specificity, to mark all these little coding errors with big borders in orange or red, depending on the severity. Editors really don’t like these boxes and will do whatever it takes to get them out.
To see how it works you need a human editor with HTML3 and <FONT> tag knowledge, a CMS that can detect if an editor is logged on (any CMS does that), and the stylesheet we are going to create.
Editors in charge
You or a designer crafted the headers very carefully, and they really look great in the new design. Pixel-perfect!
Unfortunately the editor in charge thinks that headers should be bigger and bolder. He looks at the design and goes into the CMS to make same basic changes, adding FONT, B and any other element he knows about. This is additional markup that can mess up your entire website and really shound’t be in there.
There is actually not much you can do about it if you stick to using a rich text editor (RTE) and don’t want to break down the document into distinct fields (and validate these fields). But… you can make people aware of these things. And I will show you can do this using a few lines of code and a stylesheet.
Let’s have a look at an example stylesheet:
/* stylesheet headers */
h1 { }
h2{
font-size: 1.05em /* not too big */
font-weight: normal; /* instead of bold */ }
h3 { }
What happens if the editor incorrectly adds a <FONT> tag, and a B element?
What happens here? If you are unlucky, the rest of the page is rendered with the wrong font-size and your headers appear bold.
To avoid all these things you can work your way through all the little errors and add them into the additional stylesheet like this:
/* stylesheet debug */
font, b, i{
display: block; /* make it stand out on the page*/
border:2px solid red; /* here is your problem !! */
font-size: 8px; /* very small unreadable print*/
}
h2 strong {
font-weight: normal;
display: block; /* make it stand out on the page*/
border:2px solid orange; /* orange means: not nice, but is ok */
}
Don’t want DIV elements inside the #content area, because they should use paragraph element?
#content div {
display: block; /* make it stand out on the page*/
border:2px solid red; /* here is your problem !! */
font-size: 8px; /* very small unreadable print*/
}
These are simple examples but they show how the idea works. Once you know your template and what can happen when things go wrong, you can dig a little deeper and apply strict rules to where an element can and is allowed to appear.
For example, I have seen some editors use BLOCKQUOTE to indent paragraphs. This is a common mistake and will not be allowed, so I added this to the rules:
.productpage #content blockquote{ /* error markup in here */ }
I am not allowing BLOCKQUOTE elements in the content block on a productpage. (note: You need to be able to distinguish different page types from each other).
When should you show these errors?
Obviously, we shouldn’t show these errors to the visitors. That is where the need to detect the login comes in. ALl you have to do is test if the person viewing the website is logged in as an author and based on that test, add the debug stylesheet or not.
This is the XSLT code I am using in Umbraco:
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxml="urn:schemas-microsoft-com:xslt"
xmlns:umbraco.library="urn:umbraco.library"
exclude-result-prefixes="msxml umbraco.library">
<xsl:output method="html"/>
<xsl:param name="currentPage"/>
<xsl:template match="/">
<xsl:if test="umbraco.library:RequestCookies('UserContext') != ''">
<link media="all" href="/css/debug.css" id="debug" rel="stylesheet" type="text/css"/>
</xsl:if>
</xsl:template>
</xsl:stylesheet>
This is an XSLT macro, using the default Umbraco library to detect the cookie with the authentication flag. If it is found and not empty, add the debug stylesheet in the HTML header of the page.
The next step is to determine if you are going show the errors in a life environment to make sure editors have to care about it, or that you will leave it out and only use it for your quality review.
I always show the big errors and surround them with a red border. Using font tags to override my CSS rules is unacceptable so these will be shown in the life environment.
All you have to do is split the severe errors from the others and put them in a separate sylesheet. Then hardcode the reference to the stylesheet into the template. That way the severe errors will always be shown and editors will have to check their pages in preview mode before actually publishing.
I am not sure if this technique is useful for other webmasters, but if you do plan to use, let me know.
I am currently using it on my Umbraco installation and in the beginning it cause a lot of support because the editors will call you. After a while they will know and they have learned to use standard based markup. After that support calls will go down again.