Template:semantic-html-design-principles - Revision history

Tantek: briefer

2012-07-27T22:35:05Z

briefer

← Older revision		Revision as of 22:35, 27 July 2012
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 ~~more brief and human readable~~ equivalent into 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.		# 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.

Tantek: draft with some updates based on the XHTML version, make it more generic than the hCard/hCalendar original work

2012-07-27T22:34:03Z

draft with some updates based on the XHTML version, make it more generic than the hCard/hCalendar original work

New page

# 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|semantic HTML]] building block for each object etc.
# 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.
# 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 more brief and human readable equivalent into 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.