Core Features

The core system offers an easy way to add tags to the header. This ease the handling of the header and allows us to ensure that the encoding appears first (before the title) which solves several issues with Internet Explorer (including a security issue in IE 6.x.)

Style Sheets

Having one place that handles the HTML header gives us a way to manage the style sheets in one place. This allows us to do two things to the style sheets:

Add them inline when small enough (i.e. less than 1 kb)
Compress them (remove all the possible new lines, spaces, etc.)

Also, all the style sheets can be compressed in a single file. This is not automatically the best idea though because each page is likely to have a slightly different set of style sheets and thus need a different file. On the other hand, we could try to force all the plug-ins to always define their style sheets whether they are needed or not reducing the need to exactly one compressed style sheet file.

See: Inline Data feature [optimization]

JavaScript

JavaScript code can also be compressed (minimized) and all put in a single file. Just like style sheets, this can be a problem if each page has a different set of JavaScript functions. Plus, a certain number of JavaScript source files should be loaded from stores that offer them at large.

For example, Google offers all the jquery.js versions from their fast servers. The huge advantage is that Google store is likely to be used by many websites and therefore the jquery.js file is likely going to appear in the cache of the browser even before the user hits one of our websites.

See: Inline Data feature [optimization]

m2osw store

We probably also want to make all the static CSS and JS files come from our m2osw.com domain (i.e. maybe something like css.m2osw.com and js.m2osw.com or cache.m2osw.com/css and cache.m2osw.com/js). This way, users who visit more than one website from one of our Snap! website will get these static files once. Obviously, in this case it is very important to use a version for each file.

See: Inline Data feature [optimization]

Page Title

The page title is saved in the HTML header using the title tag. The core feature may be used to add the name of the website to all the titles. Many sites today append " | <site name>" to the title of each page.

The title header feature may also check the maximum size of the title and other such limits.

Links

The HTML header can include many links. The link tag is used to indicate things such as the RSS feed of the website, the style sheets (which are managed differently though), the canonical URL, the alternate versions of the page such as translations, copyright page for the website, author page, the parent page, the top page (home in most cases), the next/previous pages, the first/last page of the current section, help page, search feature, etc.

All those links can be useful for SEO and thus it is a good idea to have them there. It is also quite helpful for people with disabilities.

Meta Tags

Finally, you want to support meta tags. This includes entries such as keywords and an abstract about the page. Although keywords are generally ignored by search engines, the other meta tags are often used. The description meta tag is used by Facebook when someone create a link to your page.

There are also location meta tags that can be useful for users who create websites for local businesses (i.e. address related meta tags) or to talk about places which they want to be able to place on a map.

Some people defined meta tags at first for bloggers, those are used to describe the author of a post. It includes all sorts of information such as the author name, address, bio, contact information, etc.

Canonical Meta Tag

The Canonical Meta Tag is defined as:

<meta name="canonical" content="<canonicalized url>"/>

It is automatically generated by the core system for several reasons. The main one is that whenever you reach a page on your site, that page is found because the core system canonicalizes the URL used to access the page. This means the core system already has the canonical version of the URL of each page. These are the URLs used as keys to access your pages in the Cassandra database. The good thing is that you do not need to use redirects for URLs that are compatible. For example, if you support http://w.example.com/ but really use http://www.example.com/ then the canonical URL is "http://www.example.com/". Not redirecting is okay because search engines will register the page as "http://www.example.com/" and not "http://w.example.com/" even though it also works (it gives you a duplicate of the page, but it is acceptable with the canonical URL specified.)

There are a few exceptions when creating new data some URLs are dynamic and those do not come with a canonical URL per se. Also, the key for a page may not be 100% equivalent to the canonical URL because some of the options may be important in the URL.