HTML and CSS can be combined in a myriad of ways. Some of these will be friendly to ExSite's CMS assumptions, and others will make content management difficult or inconsistent. This document guides you through which practices will make your life easier.
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 editoral 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 occational 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: