HTML Sitemap
A HTML sitemap is simply a hierarchical list of links on a web page that helps web visitors review in a quick glance a site’s index of pages, which helps promote site usability.  A well built HTML sitemap will highlight pages of a site with great importance and diminish 2nd or 3rd tier pages, making it easy to search an entire website from one web page.  See an example of a HTML sitemap.

Resource: HTML Sitemaps Guide

Image Credit: eVisibility

XML Sitemap
XML sitemaps are created for search engines to inform them about URLs that are available on a website to be crawled.  For large sites or sites that have accessibility issues, can make it difficult for search engines to index all of its pages.  By submitting a XML sitemap, it will help search engines find all of those pages that can be nested a few directories deep.  See an example of a XML sitemap.

Resource: SEOmoz – XML Sitemaps: Guideline on their Use

ROR Sitemap
A XML variant, ROR sitemaps are used to describe any object on a website.  They are much more robust than XML because it supports multiple formats including URLs, products, articles, company bios, events, etc.

To create a ROR sitemap try ROR Sitemap Generator or Cumbrowski’s Free ROR Sitemap Generator.

Video Sitemap
A Video sitemap contains links to a videos landing page, along with information that is essential for indexing the video to make it searchable for sites like Google Video. To submit a video sitemap to Google there are certain fields that are required including the video url, the video and video player location, a video thumbnail, and a video title and description.  Google can crawl the following formats; .mpg, .mpeg, .mp4, .mov, .wmv, .asf, .avi, .ra, .ram, .rm, .flv.

Geo Sitemap
Google recognizes Geo Sitemaps that enable you to publish geo-content that can be searchable in Google Maps and Google Earth.  Geo-content can be in KML or GeoRSS format.  Be sure to add the attribution tag which appears in the Google search results for your content.

News Sitemap
News sitemaps allow webmasters to have more control over their content that gets submitted to Google News.   You can also add additional information about your news, like article title, publication date, and keywords.  Using a news sitemap is perfect for websites that are new, have dynamic content, or large sites that can be hard to find content.  Keep in mind that Google only allows you to submit content from the last three days.

Mobile Sitemap
Mobile sitemaps allow you to submit a list of URLs with content specifically designed for mobile devices and is used in the search engine’s mobile index.  Searching the mobile web is different than the regular web, for instance it only displays sites that are “mobile friendly.”  Using well-formed markup like WML, cHTML, XHTML Basic or XHTML MP formats will ensure your content gets crawled.  See an example of a Mobile Sitemap.

Recommended Sitemap Resources

Google Sitemap Generator
Allows you to create XML, News, Mobile, Geo, HTML, Text, ROR, and Video sitemaps. Unlike 3rd party sitemap generators, the Google Sitemap Generator will monitor your website content and update automatically.

AuditMyPC – XML Sitemap Generator
Create unlimited XML and HTML sitemaps.  You must have Sun’s Java Runtime installed in order to create a sitemap.

XML Sitemaps.com
Allows you to create XML, ROR, Text and HTML sitemaps, up to 500 pages (Free Version) or Unlimited pages for the paid version.  Paid version cost $19.99.

Google XML  Sitemaps for WordPress
This wordpress plug-in is by far the best sitemap generator.  Nathan Rice has a great post on the Ultimate Guide to WordPress SEO that goes into great detail of the plugin and the process.

I realize some of my ideas may go beyond the so-called “scope” of the original intentions of CSS and HTML/XHTML. But my hope, like all “standardistas,” is to get a focused set of standards for all browsers to comply with (does such a Utopia exist?) and for these standards to give more power to semantic markup and provide more advantages to CSS.

I’ll begin with HTML first, since semantic markup is the most important:

1. Custom Elements

I’ve read some of the working draft for HTML 5 and I must say that I’m impressed with some of the ideas that have been added. It’s going to give more meaning to HTML code, which is precisely what web developers need! However, I did cringe at the proposed “header” and “footer” elements. I understand their purpose, but aren’t the words header and footer presentational? For instance, what if at first I designed the footer to be at the bottom of the document. In the markup, perhaps it is. But later (for some odd reason) the client decides he/she wants that info to be moved to the top? Would this still be considered the “footer?” I’m sure there are several sides to the argument, but I’ve also read accounts where people like Andy Clarke have proposed the same. Footers should be “siteinfo” and headers should be “branding” or “masthead.” In contrast, Dan Cederholm and Andy Budd still use “header” and “footer” on their personal sites. But regardless of who uses what, I still feel these names are presentational and HTML is for content not for its appearance or layout.

I really like most of the other elements like “menu,” “section,” “dialog,” “aside,” “datagrid,” etc. They really give more meaning to the markup in place of the generic div’s with id’s. This will definitely give more power to CSS and more meaning to the document at the same time. Specifically it allows you to separate your styles with semantic element names and giving them unique rules with really low specificity instead of making them arbitrary div’s. Simply put, this will give you more control with id’s when they’re needed.

But what I’m proposing is that instead of giving set element names that will always be debated on their semantic merit, why not give that power over to the developer? If a developer could declare his/her own elements in the head of the document, he/she could have more control. I envision it working something like this:

		<head>
			<elements type="elements/text">
				section : div;
				dialog : div;
				menu : ul;
				masthead : div;
				newelementname : baseelementbehavior;
			</elements>
		</head>

				

In this element named “elements” the code would be handled by the browser. It would read each line, separated by a semi-colon, and take note of the custom elements being declared and determine their base behavior off of the base element listed after the colon. For instance, the first custom item “section” would behave like a “div.” This would give ultimate control to the developer to make his/her document follow its purpose semantically. This will also open up the possibilities for more microformats! A developer could utilize this to create <tel> elements, <adr> elements, <product> elements, and more, replacing the annoying <div class=”product”> and more nested, loosely based “classitis.”

2. Definition List Item

I can’t recall where I saw the <di> element once, but I’ve been unable to relocate it through my web searches.XHTML 2′s working draft describes a definition list item, but I wonder why this element is still not supported well, if at all. And I didn’t see any proposed plans for it in the HTML 5 working drafts. I feel that this would be a good addition because it provides one more “hook” for styling and more meaning as well. The definition item would separate definition terms and their descriptions from others. If I was creating a list of definitions, each term and its description or descriptions should be separated logically from its siblings. Thus the <di> element would encase and separate each item.

3. CSS Snap Declaration

My third proposal is for a CSS 3 style declaration called “snap.” This can replace the need to use javascript to snap elements to non-parental elements. This “snapping” has been done via javascript on many old versions of dropdown menus. Now with CSS and better standards, the snap is no longer needed for menus. But the need for snap in other presentational ways is still warranted. What if I wanted to “snap” one element in the lower portion of the document to another element that was completely unrelated? I could simply add it to the style rule:

		#snapping-element {
			display: block;
			width: 300px;
			snap: #host-element;
			left: 0; top: 10px;
			…
		}
				

In this example, the element with the id “snapping-element” will be snapped to the element with the id of “host-element.” Host-element, however, probably should be positioned relative; and the snapping-element’s position will be based off host-element’s relative state. Much like how absolute works, except that absolute is limited to basing itself off of ancestral elements.

4. Column Hovers

Placing a hover on a table row is a cinch. But what if I wanted to create a triangulation effect for the rows and columns with a different hover state color? I can’t! I’ve seen others mention it in posts, but I haven’t seen any plans to integrate this into CSS. Why not? This would provide another layer of accessibility/legibility to users with a simple col:hover rule. Of course the colgroup elements must all be declared in order for this to work.

5. Javascript-type Psuedo-classes

My last proposal to CSS 3 is probably the most CSS-scope-defying of them all. What if there were more pseudo-classes available other than just visited, hover, active, focus, etc? Why not onclick? I realize focus is currently a bit of a Mozilla proprietary state, but it’s a really good one! If javascript already handles onmouseover (hover) and onblur and onfocus (focus), why not onclick?! Man would this be powerful! All javascript toggling could be handled in CSS! But this event catching is a bit more daring for CSS’s scope of just styling. But why not, eh?

Conclusion

Perhaps some of this has been mentioned before me. I’m not sure. If not, then I’m glad to be able to provide some recommendations. If so, I apologize for assuming credit, that’s not my intention. I do however feel that these would provide a lot more meaning to HTML 5 and more power and control for the visual and presentational experience to CSS 3.

Any comments, suggestions, critiques are happily welcomed. Just some food for thought.