Template:semantic-html-design-principles: Difference between revisions
Jump to navigation
Jump to search
(draft with some updates based on the XHTML version, make it more generic than the hCard/hCalendar original work) |
(briefer) |
||
| Line 6: | Line 6: | ||
# Otherwise use a generic structural element (e.g. <code><span></code> or <code><div></code>), or the appropriate contextual element (e.g. an <code><li></code> inside a <code><ul></code> or <code><ol></code>). | # Otherwise use a generic structural element (e.g. <code><span></code> or <code><div></code>), or the appropriate contextual element (e.g. an <code><li></code> inside a <code><ul></code> or <code><ol></code>). | ||
# Use class names based on names from the original schema, unless the semantic HTML building block 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. | # Use class names based on names from the original schema, unless the semantic HTML building block 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. | ||
# Finally, if the format of the data according to the original schema is too long but still human readable/listenable, use <code><abbr></code> instead of a generic structural element, and place the literal longer data into the 'title' attribute (where abbr expansions go), and the | # Finally, if the format of the data according to the original schema is too long but still human readable/listenable, use <code><abbr></code> instead of a generic structural element, and place the literal longer data into the 'title' attribute (where abbr expansions go), and the briefer equivalent into the contents of the element itself. If however, the format of the literal longer data data is not human-friendly, instead of <code><abbr></code>, use the [[value-class-pattern]] or [[HTML5]] <code><time>/<data></code> elements as most semantically appropriate. | ||
Latest revision as of 22:35, 27 July 2012
- Reuse the schema (names, objects, properties, values, types, hierarchies, constraints) as much as possible from pre-existing, established, well-supported microformats.
- When new schema are needed, reuse the schema (names, objects, properties, values, types, hierarchies, constraints) as much as possible from pre-existing, established, well-supported other formats/standards by incorporation, following the microformats naming-principles. Re-do constraints expressed in the source standard from the perspective of microformats design principles and designed primarily for web authoring. Informatively mention source standard for reference purposes.
- For types with multiple components, use nested elements with class names equivalent to the names of the components.
- Plural components are made singular, and thus multiple nested elements are used to represent multiple text values that are comma-delimited.
- Use the most accurately precise semantic HTML building block for each object etc.
- 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>). - Use class names based on names from the original schema, unless the semantic HTML building block 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.
- Finally, if the format of the data according to the original schema is too long but still human readable/listenable, use
<abbr>instead of a generic structural element, and place the literal longer data into the 'title' attribute (where abbr expansions go), and the briefer equivalent into the contents of the element itself. If however, the format of the literal longer data data is not human-friendly, instead of<abbr>, use the value-class-pattern or HTML5<time>/<data>elements as most semantically appropriate.