From Microformats Wiki
Revision as of 00:12, 30 June 2009 by BenWard (talk | contribs) (Draft: HTML Design Principals. We've been directly citing XHTML and XML benefits for years, which is inaccurate given that we actually operate mostly in HTML now. Proposed update to principals.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Note: the HTML Design Principles are written primarily within the context of developing hCard and hCalendar, thus it may help to understand these principles in the context of the hCard design methodology (i.e. read that first).

XHTML is built on XML, and thus XHTML based formats can be used not only for convenient display presentation, but also for general purpose data exchange. In many ways, XHTML based formats exemplify the best of both HTML and XML worlds. However, when building XHTML based formats, it helps to have a guiding set of principles.

HTML is a language not build just for the visual display of documents, but also for the semantic description of data within documents. HTML provides a basic layer of semantic description, and mechanisms for enriching semantic content for lightweight data exchange. When building HTML based formats, it helps to have a guiding set of principals and best practice:

  1. Reuse the schema (names, objects, properties, values, types, hierarchies, constraints) as much as possible from pre-existing, established, well-supported standards by reference. Avoid restating constraints expressed in the source standard. Informative mentions are ok.
    1. For types with multiple components, use nested elements with class names equivalent to the names of the components.
    2. Plural components are made singular, and thus multiple nested elements are used to represent multiple text values that are comma-delimited.
  2. Use the most accurately precise semantic HTML building block for each object etc.
  3. Otherwise use a generic structural element (e.g. <span> or <div>), or the appropriate contextual element (e.g. an <li> inside a <ul> or <ol>).
  4. Use class names based on names from the original schema, unless the semantic HTML node precisely represents that part of the original schema. If names in the source schema are case-insensitive, then use an all lowercase equivalent. Components names implicit in prose (rather than explicit in the defined schema) should also use lowercase equivalents for ease of use. Spaces in component names become dash '-' characters.