This chapter is from the book
This chapter is from the book
This chapter is from the book
Content Management
When a Web site needs to be updated by nontechnical users, gets larger, or includes content that needs to be reused, cataloged, searched, or shared, the typical solution is content management software. Content management software is one of the most common Web applications that any Web development team will encounter. This is because it is a common solution to business users' request for more control over a site.
Unfortunately, content management applications often insist on producing their own markup or require a fair amount of effort to shoehorn into a Web standards-based world. Fortunately, this is often not as hard as it seems initially, at least with a decent content application. Honestly, the hard part is often determining where to look for the right pieces of code that actually generate output.
There are countless content management systems (CMS) of varying degrees of flexibility and Web standards compliance. The flexibility, from a standards perspective, depends on the nuances of the software's capabilities as well as the implementation, which is the responsibility of the Web team.
Baseline Content Management
The better CMS solutions allow a team to generate the UI code they want—as opposed to what the tool wants. There are a number of ways Web standards can assist with a content management solution:
- Abstracting content's presentation away from the content store
- Employing fewer CMS templates through effective use of CSS
- Reusing content, because its markup will not be presentation-specific
- Simplifying content authors' jobs, through fewer presentation aspects being required of them
- Expanding the ability of redesigns with less CMS team involvement
Content Management and Clean Content
The simple process of storing content in a central content repository, with clean markup, is in and of itself a good way to facilitate content reuse, because the markup will be simple and can be styled with CSS on different portions of pages based on context. Beyond that, here are some common best practices and scenarios involved in professional content management and design with CSS:
- Design with CSS based on context. For example, an article description can be rendered as an <h1> level header set in a large maroon font on the article page, but a smaller black font on the archive page, because the CSS can control that difference.
- Store content in as plain a format as possible. Use as few CSS classes as you can, and minimal if any presentation-specific element attributes.
- Stick to semantic markup alone, leaving the content marked up in a meaningful and portable format that can be styled and reused at will. Recall that expert CSS coders can apply different styles based on contextual position in the site template via an ID or class.
- Teach content authors only basic HTML structure tags. Ideally, content authors will need to learn few if any CSS classes. They just need to know that the first-level header in the content area is an <h1>. Or, that making a plain bulleted list will result in little icons for bullets, and the header in the related content region on the right is dark blue. Design can all be applied via CSS and not stored in the CMS content repository. Content authors can concentrate on content, not design.
- Context on a given page is a useful tool, but context within a site can be equally important. A common design scenario these days involves different sections of a site having different color themes extended from the primary brand. Content itself, stored in a database, does not need to know these things, and should be portable between site sections. CSS can be driven from a <body> tag class or ID set by site section, which can toggle different color themes down through all semantic tags for that portion of the site.
Content Management Output and Modules
Content management tools can pose a challenge when it comes to figuring out how to control the output and produce standards-based code. The hard part is often determining where to start and whether the output can be controlled. Typically, a CMS outputs pages formatted with code sourced from one of several areas:
- Built-in modules that produce output based on proprietary features or out-of-the-box functionality
- Page-level templates used to display different types of pages
- Browser-based word processor-type editors (used by content authors)
The most challenging portions of a CMS application in terms of outputting valid standards-based code are often the built-in features over which a team has little to no control. The features to watch out for include what someone claimed to be the great thing about a tool since supposedly the tool can be installed and you have a Web site out of the box.
Risky portions can include
- Administrative modules embedded on public pages
- Traffic-tracking code or built-in scripts
- Advertising modules
- Anything that generates menus
- Special controls that might produce lists of content (like a News or product archive)
- Search results
A powerful tool will let a Web team have access to the code that produces this output or insert custom modules that can replace or extend built-in functionality. Ideally, there are built-in templates or snippets of code that can be updated. Be especially wary of tools that claim to allow customization of the look and feel through some sort of control panel, unless it actually exposes code that can be modified.
Content Management Templates
Most CMS tools associate pages with templates, each of which is a reusable layout. Authors pick the correct template for the section or type of page. The more templates, the more the content authors need to keep track of—and the more confusing site maintenance becomes. Intelligent use of CSS and Web standards can actually mean fewer templates.
Templates are typically driven by the grid of the page, and this typically means different markup. In the Web standards and CSS world, this isn't necessarily the case.
Imagine a three-column layout such as what follows here (FIGURE 4.7):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Template One</title>
<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body class="typeA">
<div id="wrapper">
<ul id="nav">
<li><a href="...">Navigation 1</a></li>
<li><a href="...">Navigation 2</a></li>
<li><a href="...">Navigation 3</a></li>
<li><a href="...">Navigation 4</a></li>
</ul>
<div id="content">
<h1>Content Area</h1>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Nam sit amet nulla. Ut ut urna ac lectus</p>
<p>Ut ut urna ac lectus tincidunt sollicitudin. Sed rutrum
interdum lorem. Integer aliquam pellentesque
neque.</p>
<p>Curabitur a neque a libero gravida dignissim. Sed
eget tellus.</p>
</div>
<div id="related">
<h2>Related Links</h2>
<p>Related Links and Content</p>
<ul>
<li><a href="">Section 1</a></li>
<li><a href="">Section 1</a></li>
</ul>
</div>
</div>
</body>
</html>
)
Figure 4.7 A three-column CMS template.
The above document sample has three <div> elements with IDs: nav, content, and related (or #nav, #content, and #related, in CSS selector terms). These can be easily styled with CSS to be three columns. The content inside of the #content and #related <div> elements might be created by a content author and is here represented by "Lorem ipsum" and the "Related Links and Content" text respectively. Furthermore, the related column link might even be generated dynamically server-side, based on content relationships, and there may be cases where this column is not needed.
Note the class on the <body> element. A content author might need to select this template in order to queue up a page with the appropriate number of columns. Program logic can tweak the <body> class of the document to restructure the page into navigation and a single column of content so multiple templates do not need to be created in the CMS tool, and so a content author does not need to select a different template (FIGURE 4.8).
)
Figure 4.8 With little change to the CSS, the same CMS template can do two columns.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Template Two</title>
<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body class="typeB">
<div id="wrapper">
<ul id="nav">
<li><a href="...">Navigation 1</a></li>
<li><a href="...">Navigation 2</a></li>
<li><a href="...">Navigation 3</a></li>
<li><a href="...">Navigation 4</a></li>
</ul>
<div id="content">
<h1>Content Area</h1>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Nam sit amet nulla. Ut ut urna ac lectus</p>
<p>Ut ut urna ac lectus tincidunt sollicitudin. Sed rutrum
interdum lorem. Integer aliquam pellentesque
neque.</p>
<p>Curabitur a neque a libero gravida dignissim. Sed
eget tellus.</p>
</div>
<div id="related">
</div>
</div>
</body>
</html>
The #related <div> is collapsed and no content is output. At the CMS level, changing the <body> class to typeB switches the page layout without changes to the markup and means one less template than might otherwise be required. This also preserves the separation of markup from presentation. Here is the style sheet required:
body { font: normal .9em Georgia; }
body.typeB #related { display:none; }
body.typeB #content { width: 600px; }
#nav { list-style-type: none; width: 100px; float: left;
margin: 30px 0 0 5px; padding: 0; }
#content { width: 400px; float: left; margin-left: 10px;
border: 1px solid red; padding: 3px; }
#related { width: 150px; float: left;
border: 1px solid red; margin-left: 10px;
padding: 3px; }
Content management tools are just another software mechanism to deliver a Web site. They are a fact of life in larger organizations, and most are full-featured development platforms that can be leveraged to allow standards-based output, which can only help make a site more accessible or compliant. Whether the tool features raw output or content being transformed from XML with XSLT (eXtensible Stylesheet Language Transformations), the output should be clean and thought through. As a complement, effective use of Web standards can also reduce the number of CMS templates and make it easier to author content.
WYSIWYG for Content Authors
When working in Web content environments, most nontechnical content authors use some form of lower-end WYSIWYG software tool to help facilitate content entry. These tools can range from browser-based editors to tools like Adobe Contribute for simple site maintenance. They are not development platforms such as Adobe Dreamweaver or Microsoft Expression Web, and have far fewer features. Just like any other software, these tools have configuration options and varying degrees of Web standards compliance.
As a general rule, the strongest editor setup for content authors is one where as many formatting features as possible are disabled, because the formatting features rely on code that a Web team won't be able to control. Effective support for CSS is the key.
Browser-Based Editing
Browser-based editors have been around for a while. Microsoft first introduced an ActiveX-based editing component in Internet Explorer 4. Since then, native JavaScript support has been added and editors are usually script-based, Java-based, Flash-based, or ActiveX-based. Script-based components for browser-based editing are showing up with support in most modern Web browsers, including Safari and Opera. For widest compatibility, one of these should be chosen.
Unfortunately, out of the box these browser-based editors are not very robust. Internet Explorer outputs <font> tags and Mozilla generates inline styles. They render exactly what the browser can render, but the editor features must largely be built from the few hooks that are available in the browser's DOM. That being the case, it is exceptionally hard work to churn out a custom editor, although they are getting better every day. You can find a modern editor to create valid code and support CSS.
Editor Configuration
Web developers should take steps to prevent these browser-based editors from jeopardizing all the hard work that has gone into defining styles and coding standards for their sites. They may have to go so far as to integrate new user steps, or even new software.
Considerations include
- Perform reviews of the WYSIWYG editor's code output under a variety of situations. It's not unusual for these editors to generate invalid code; however, the marketplace is maturing, and many can output valid HTML or even XHTML with configuration changes.
- Some editor tools include a source-code view. This may need to be disabled or enabled depending on the skill levels of the authors. Some tools include a permission model, which can enable the source code view for some users and not for others.
- Features that control presentation should be limited. Disable features that control font face, font colors, and background colors. These should be controlled only from CSS.
- The editor should be able to apply CSS classes. A good editor will support association of a CSS file with the editor. Some will require developers to configure which items appear in the CSS class menus. The best will support context and only allow application of some classes based upon the CSS rules, such as not allowing a rule p.error to be applied to a <span>.
- Support for CSS class application should include some facility to apply CSS to specific elements. That is, it should be just as easy to apply a class to a <ul> as an <li> nested inside via a selection process of some form. A common way to enable this is a simple click to select DOM tree in the status bar (body > div > ul > li > a).
- CSS files that are associated with an editor may need to be an extract of the main CSS files because the rules may be too complex to be interpreted, and full context rules, such as <p> elements inside of #content as opposed to #related, might not be supported or possible. Depending on the editing context, multiple CSS files may be another solution.
- The editor should support basic XHTML semantic tags such as the built-in headers (1–6), paragraph formatting, at least two types of lists, blockquote, preformatted text, and addresses.
- A good editor will also strip garbage and invalid tags from content pasted from the clipboard, or have multiple options for cleaning pasted content. Often, content copied from word processors or Web pages will retain its formatting information when pasted into WYSIWYG editors. This information, when introduced into valid code, often invalidates it, and can modify styles that should be applied only from outside the content via the CSS.
- You may want to tell content authors that if their editing application won't strip invalid tags from incoming content, they should strip the formatting by pasting that content into a plain text editor prior to pasting into the WYSIWYG editor.
- Ideally, locate a browser-based editor that can support as many browsers as possible and achieve the above feature sets. It is not uncommon to find WYSIWYG editors configured only for IE; however, today editors are available for Windows and Mac OSX in just about every browser.
Following the above rules and evaluation criteria can mean the difference between creating a reliable, standards-complaint site and having a content editor program destroy a lot of hard work. The quality and performance of any editor program you've already got in production should be evaluated against these standards and modified to produce code that is as close to valid as possible.
Third Parties
Larger Web sites often need to propagate a certain look and feel to third-party sites or business applications hosted elsewhere, such as an Investor Relations site or perhaps a job board. These sites can be branded to look like the main site, and users are intended to not know that they have navigated to another site altogether.
Web standards-based approaches are ideal for such scenarios because not only can the artwork and scripts be hosted on the main corporate servers, but so can all the CSS files, or at least the CSS that controls the main look, feel, and corporate brand standards. In these cases, a company can have third parties link to some or all of the CSS files, and tweak them as necessary over time, with the changes showing up without hosting the third-party applications.
In such cases, you will probably need to provide the third parties with documentation of the correct style classes and image headers for certain design touches. You should also supply sample code, with example templates that represent how the pages and designs should be built.
Just like any organization or software platform, however, third parties are going to have varying degrees of ability to accommodate a Web standards approach. For example, their platform may not be compatible with a corporate style sheet. In these cases, compromise may be necessary. Again, this may mean simple extracts of CSS files or creating different markup templates for the exceptions. In the long run, however, a transition plan should be considered and discussed with third-party vendors who can't keep up with the rest of the industry.