dfn-design-pattern: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
No edit summary
m ()
Line 54: Line 54:

* [http://juicystudio.com/article/jargon-busting-with-the-definition-element.php Juicy Studios: Jargon Busting with the Definition Element]
* [http://juicystudio.com/article/jargon-busting-with-the-definition-element.php Juicy Studios: Jargon Busting with the Definition Element]
* [http://alistapart.com/articles/hattrick A List Apart: The Accessibility Hat Trick: Getting Abbreviations Right
* [http://alistapart.com/articles/hattrick A List Apart: The Accessibility Hat Trick: Getting Abbreviations Right]

==See Also==
==See Also==

Revision as of 11:55, 16 August 2007

Dfn design pattern

Important: this is currently a proposal: it is not a finalised design pattern.

This page is intended for discussion and exploration of a design pattern to complement the abbr design pattern while addressing the abbr design pattern issues, particularly the accessibility issues.


The abbr design pattern is used in several microformats to enclose standardised data such as the datetime design pattern in the title attribute. However some assistive technology will expose this data directly to the user, which is often undesirable. See also assistive technology abbr results.

This problem arises because the title attribute has a different semantic meaning when it is attached to an abbr or acronym than it does on other elements. Usually the title attribute is used to provide provide advisory information. But for abbr or acronym the title is used to provide an expanded form of the text contained between the opening and closing tags. This is why the abbr element was chosen to contain datetime information: the ISO format is an expanded form of the human-readable text contained within the element. Because screen readers can be configured to treat abbr and acronym elements as special cases, the title attribute is sometimes read aloud.


Rather than expand the abbr design pattern to any element (or to a semantically neutral element such as span), it would be better to use an element that has semantic value but which isn't treated as a special case by assistive technology.


The dfn element indicates the defining instance of the enclosed term. This element is not widely used but where it used, it is often used in a similar way to the abbr element. Although the title is not required for the dfn element, it is often used to provide expanded information.

The semantic meaning of dfn, as it is currently used, is potentially similar enough to abbr element to allow it to be used as an alternative:

<abbr class="dtstart" title="2007-08-16T22:00:00">10pm on August 16th</abbr>
<dfn class="dtstart" title="2007-08-16T22:00:00">10pm on August 16th</dfn>



The dfn is not intended for definitions; it is intended for defining instances. Does this mean that it must always be used for the first instance of a term (such as a date)?

Is the dfn element equally appropriate as the abbr for information such as datetimes and geo or is this stretching the semantic meaning of the element beyond a reasonable limit?


Existing microformats parsers (such as the Operator extension to Firefox) would need to be updated to handle this proposed alternative to the abbr design pattern. However, this is true of any proposed alternatives.


Microformats are intended to be easy to publish. The number of design patterns should be kept to a minimum. Every new design pattern is potentially a new barrier to entry for publishers.

Assistive Technology

The proposed dfn design pattern assumes that screen readers don't treat dfn as a special case like abbr or acronym. Is this actually the case? Please create a page for assistive technology dfn results and add the results of testing there.

Usage in the wild

This design pattern is built on the assumption that, although the dfn is not widely used, where it used, it is most often used in conjunction with the title attribute. Please document examples and references here:

See Also