The ExSite HTML editor outputs generic HTML mark-up, without any special class or ID attributes. For this reason, it is best to assume that basic editorial content on your pages will not be explicitly flagged as belonging to a particular CSS class. Your site style sheets should define default style rules that are suitable for unclassified content. For example:
body,p,div,h1,h2,h3,h4,h5,h6,td,ol,ul,dl,dt,dd,li,caption,blockquote {
Font-Family : Arial, Helvetica, Verdana;
Color : black;
}
body,p,div,td,ol,ul,dl,dt,dd,li,caption,blockquote {
Font-Size : 10pt;
Text-align : justify;
}
If you need special style rules in certain content regions, then it is best to wrap sections of content in a div or similar block-level element with a special class, than to try and mark up all of the content with appropriate classes. For example, this is difficult to maintain:
<p class="footer">
© 2006 <a class="footer" href="http://exware.com">Exware Solutions</a>
</p>
This is similar, but easier to maintain, since the content within the DIVs uses generic mark-up.
<div class="footer">
<p>© 2006 <a href="http://exware.com">Exware Solutions</a></p>
</div>
This technique allows you to keep classified HTML in the template, whereas editorial content (which comes from editors who may have no understanding of HTML or CSS) can be plain HTML. For example, the above HTML could be templated as follows:
<div class="footer">
<!--content(footer)-->
</div>
Using this approach, the CSS rules are entirely contained in the template content, and the editorial content with generic mark-up can be easily composed in the HTML editor by someone with no understanding of how their content will be classified. By using different wrapper classes in different parts of the page, you can style different boxes or regions in totally different ways.
Different browsers treat linebreaks differently in the HTML editor. For instance, IE creates a paragraph break (</p><p>), but Mozilla browsers create linebreaks (<br>), except Firefox, which attempts to do either, depending on the context.
For this reason, you cannot expect the paragraph-break handling to be consistent. Some paragraphs could be marked up in <p> tags, whereas others could be freeform content with occasional double-linebreaks. Your stylesheets should take this into account (by using default CSS rules, as noted above).
One work-around technique is to include an overall <p>...</p> wrapper in the template. For example:
<p>
<!--content(body)-->
</p>
Then, even if editors use browsers that insert <br>s instead, the content will still be recognized as being enclosed in a <p>. However, since all content will be enclosed in <p> tags, it will result in some unusual constructs, such as headings embedded in paragraphs, and so on.
It is not unusual for some HTML design programs (or graphic designers) to use the same basic HTML element with different style classes to mark up content. For example:
<p class="heading">Welcome</p>
<p class="normal">Hello world!</p>
This practice is discouraged, for many of the reasons noted above. Furthermore, it must be noted that this content is completely dependent on its stylesheet, which is contrary to the principle of separating content from design. Without the stylesheet, it is not apparent that "Welcome" is a heading. If the content's template changes, or the content is copied into another site/template, or any number of other things happen, the apparent meaning of the content changes.
K.I.S.S. (Keep It Simple, Silly) is a good practice to follow at all times. If an item is a heading, mark it up using simple heading tags:
<h1>Welcome</h1>
<p>Hello world!</p>
Web applications on the other hand, are free to include any special class information or other markup in their content, because that content is fully formed and will not pass through the HTML editor in the future.
As a general rule, a main wrapper DIV (or SPAN if the application content is inline) enclosing the web application output is a good idea. For example:
<div class="SuperModule">
... remainder of SuperModule output
</div>
This allows a web designer to restyle generic HTML from the web application, if they choose to do so. Note that in this case, the web application should output the DIVs automatically, and not rely on the template to provide them.
If the web application output is complex (eg. complicated reports, forms, tables, etc.), then a single wrapper class may not be sufficient to differentiate all stylable elements from each other. In this case, it is acceptable to apply special class attributes to any elements that could be styled differently from the default for that element. It is then left up to particular template designers whether they want to actually include special styles for these web application elements.
The following CSS notation is common:
body { background-image: url(background.jpg); }
ExSite does not track files referenced in external stylesheets, so the URL "background.jpg" is not under control of the CMS in this case. If the publication parameters of the website or that image change in the future, the CMS will not automatically adjust, and the image may fail to load. Manual updates of the image location will be required to fix this.
If the CSS url(...) notation is used in a CSS file that is located in the same template as the referenced filename, then the template will still display correctly. However, it will cease to display correctly in several cases:
If the url(...) attributes are placed inside a <style> section in the regular HTML, however, the CMS will be able to operate on them. This allows you to do something like this:
<style>
body { background-image: url([[background.jpg]]); }
</style>
In this case, the background image will be tracked by the CMS, and the URL to the image will change automatically if the publishing parameters of the site or image change.
It can save you a few headaches if you separate out your url(...) attributes from your external stylesheets, and inline them into your template HTML in this way.
The speed with which content is found and loaded can vary depending on how you define the content and where you store it. From fastest to slowest, your options are:
The WYSIWYG editor is convenient for regular content updates, but it does not give the direct control over the HTML that you need for template detailing. Furthermore, many details of templates (including meta-tags, CSS and Javascript references, and missing content objects) are invisible in WYSIWYG mode. For these reasons, templating work is often most effectively done in plain-text mode.
Include the following standard meta tags in your template header/preamble, so that ExSite can make use of them if requested:
<title><!--$title--></title>
<meta name="description" content="<!--$description-->">
<meta name="keywords" content="<!--$keywords-->">
The comment-like tags allow ExSite to substitute relevant page-specific data into the meta tags when the page is actually constructed. This is especially important if Search Engine Optimization is important to you.
You can simply hard-code your local links, eg.
<a href="index.html">Home</a>
But you'll gain a little more flexibility if you re-code them using the templating notation:
<a href="{{index.html}}">Home</a>
This notation allows you to change the settings of the target page (eg. static to dynamic, public to members-only, etc.) without having to update your template to modify the target URL appropriately.
Say you want to use a 2-column layout on some pages, but only a 1-column layout on others. You could set this up using two different templates, one for each layout; or you could just use a single template, with two main content areas (we call them body and rightsidebar in this example):
<table><tr><td valign="top">
<!--content(body)-->
</td><td valign="top">
<!--content(rightsidebar)-->
</td></tr></table>
If a given page defines a rightsidebar object, the layout will appear to be two-column. If not, then the right column is empty and gets squashed by the main body, causing the layout to appear one-column.
If you have a template that defaults to two-column layout by defining content for the rightsidebar, then to revert to a single-column layout, all you need to do is define a rightsidebar object in the page, but leave it empty/blank. Your local copy will be used, causing the default rightsidebar to disappear.
Similar methods can be used for a variety of other optional layout objects, such as banners, footers, mastheads, and so on.
Automatic menu building is very handy when you add and remove pages on a regular basis. The examples below refer to the SimpleMenu plug-in, but similar results can be achieved using alternative menu plug-ins.
Insert a vertically-formatted (eg. side bar) menu:
<!--&SimpleMenu(vertical)-->
Insert a horizontally-formatted (eg. top bar) menu:
<!--&SimpleMenu(horizontal)-->
The default formatting is quite plain, but SimpleMenu allows you to dress up your menus with arbitrary HTML wrappers and spacers. To dress up your vertical menus, define the following content objects in your templates:
You can also dress up your horizontal menus by using the same content object names, but with "H" appended (ie. SimpleMenuTopH, SimpleMenuMidH, SimpleMenuBotH).
These HTML snippets can contain full CMS mark-up as well, which allows you to insert graphics into your menu layout.
"Dynamic" is slow for page rendering, but can sometimes be handy if you are tinkering with your templates or stylesheets on-line and don't want to have to republish everything after each minor change.
"Static" is much faster, and is highly recommended for production templates.
Use your favourite HTML editor, web design package, or hand-code your HTML and images, until you are happy with the results. This will generally be more efficient for repeated tinkering than the slower, high-latency network connections on the Web.
When your design is ready, use the "Import Template" function to load it up into ExSite.
Many dynamic content plug-ins produce simple, generic HTML and rely on stylesheets to dress it up. You can implement these special CSS classes in your web design to spiff up your dynamically-generated content.
You can also use the generic ExSite stylesheets as a short cut, since they predefine some styles that may be adequate for your purposes. For example:
<link REL="stylesheet" TYPE="text/css" HREF="/_ExSite/css/ExSite.css">
Some plug-ins have their own generic stylesheets that you can also utilize in a similar way, eg.:
<link REL="stylesheet" TYPE="text/css" HREF="/_Modules/Zine/zine.css">
Alternatively, you could import such files into your template, and modify them appropriately.