include-pattern

(Difference between revisions)

Jump to: navigation, search
m (Accessibility concerns: noted specific section of Joe's article regarding Headings and links read out of context)
(changed dup content text to title text instead, used a POSHier id value for example, heading cleanup, noted versions needed for object issues)
Line 6: Line 6:
: Ben Ward
: Ben Ward
-
== Background ==
+
== background ==
[[hresume|hResume]] needed the ability to include a name from one hCard at the top of a resume — the person's contact details — into into the separate hCards used in the same person's employment history. Repeating so much data would be inconvenient to publishers, irritating to consumers and would not have matched the existing publishing techniques used in Resumes and Curriculum Vitæ. The include pattern is a mechanism to reference data from the same page, avoiding repetition.
[[hresume|hResume]] needed the ability to include a name from one hCard at the top of a resume — the person's contact details — into into the separate hCards used in the same person's employment history. Repeating so much data would be inconvenient to publishers, irritating to consumers and would not have matched the existing publishing techniques used in Resumes and Curriculum Vitæ. The include pattern is a mechanism to reference data from the same page, avoiding repetition.
-
== Scope ==
+
== scope ==
The include pattern is strictly limited to the scope of the current page. It cannot be used to include content from other URLs.
The include pattern is strictly limited to the scope of the current page. It cannot be used to include content from other URLs.
-
==Quick Reference==
+
== quick reference==
The include-pattern is a mechanism to include content from one microformat into another microformat elsewhere in the same document, using hyperlinks (recommended) or OBJECT. For example:
The include-pattern is a mechanism to include content from one microformat into another microformat elsewhere in the same document, using hyperlinks (recommended) or OBJECT. For example:
Line 23: Line 23:
In specs which cite the include-pattern, either of the above code snippets will cause a microformats parser to replace the A or OBJECT element with class name "include" with the content fragment with ID "author". Full examples follow.
In specs which cite the include-pattern, either of the above code snippets will cause a microformats parser to replace the A or OBJECT element with class name "include" with the content fragment with ID "author". Full examples follow.
-
==Include Pattern in General==
+
== in general==
To reference includes, use an include element with class name "include" and a document fragment identifier. The content to be included should have an ID attribute set, and that ID should be referenced from the HREF or DATA attribute at the point of inclusion.
To reference includes, use an include element with class name "include" and a document fragment identifier. The content to be included should have an ID attribute set, and that ID should be referenced from the HREF or DATA attribute at the point of inclusion.
Line 37: Line 37:
These methods of property indirection via a hyperlink element can apply to any/all properties in class-based microformats, but should only be used where a microformat explicitly states that the include-pattern is a dependency. For example, [[XOXO]] does not reference the include-pattern at this time, so sub-trees cannot be included by reference in XOXO. [[hResume]] and [[hReview]] do reference the include pattern.
These methods of property indirection via a hyperlink element can apply to any/all properties in class-based microformats, but should only be used where a microformat explicitly states that the include-pattern is a dependency. For example, [[XOXO]] does not reference the include-pattern at this time, so sub-trees cannot be included by reference in XOXO. [[hResume]] and [[hReview]] do reference the include pattern.
-
===HYPERLINK include===
+
=== Hyperlink ===
The recommended way to reference includes within microformats is to use a hyperlink.
The recommended way to reference includes within microformats is to use a hyperlink.
-
====HYPERLINK include example====
+
==== Hyperlink example====
Here is an [[hcard|hCard]] from the beginning of a resume, shown here as a verbose hCard.
Here is an [[hcard|hCard]] from the beginning of a resume, shown here as a verbose hCard.
Line 47: Line 47:
<pre><nowiki>
<pre><nowiki>
<span class="vcard">
<span class="vcard">
-
  <span class="fn n" id="j">
+
  <span class="fn n" id="jl-name">
   <span class="given-name">James</span> <span class="family-name">Levine</span>
   <span class="given-name">James</span> <span class="family-name">Levine</span>
  </span>
  </span>
Line 57: Line 57:
<pre><nowiki>
<pre><nowiki>
<span class="vcard">
<span class="vcard">
-
  <a href="#j" class="include">Ben Ward</a>
+
  <a href="#jl-name" class="include" title="James Levine"></a>
  <span class="org">SimplyHired</span>
  <span class="org">SimplyHired</span>
  <span class="title">Microformat Brainstormer</span>
  <span class="title">Microformat Brainstormer</span>
Line 67: Line 67:
<pre><nowiki>
<pre><nowiki>
<span class="vcard">
<span class="vcard">
-
  <span class="fn n" id="j">
+
  <span class="fn n" id="jl-name">
   <span class="given-name">James</span> <span class="family-name">Levine</span>
   <span class="given-name">James</span> <span class="family-name">Levine</span>
  </span>
  </span>
Line 75: Line 75:
</nowiki></pre>  
</nowiki></pre>  
-
====HYPERLINK include notes and issues====
+
==== notes and issues ====
 +
 
 +
Note: The <code>id</code> attribute value in the example "jl-name" was chosen for demonstration purposes.  The text of the value has no semantic per the include-pattern other than to connect the source of the include to the destination.  Authors {{should}} use good {{POSH}} techniques to choose <code>id</code> and <code>class</code> names.
Using the hyperlink include pattern causes no known issues in any web browser.  
Using the hyperlink include pattern causes no known issues in any web browser.  
Line 81: Line 83:
Authors {{should}} supply content text or at least <code>title</code> attribute text for the hyperlink itself. This can require repeating a small piece of information (such as a person's name in an hCard), or including generic text suitable for the context of the page.  
Authors {{should}} supply content text or at least <code>title</code> attribute text for the hyperlink itself. This can require repeating a small piece of information (such as a person's name in an hCard), or including generic text suitable for the context of the page.  
-
===== Accessibility concerns =====
+
===== accessibility =====
-
There are two points of view on this. The first is that the user experience of Assistive Technology can(might?) be severely degraded by the presence of hyperlinks which do not contain text ('''citation needed''').  The second is that the first claim is only a side effect of some Assistive Technologies extracting the hyperlinks in a document and presenting them as a list, and that such technologies / features have no right to do so, and therefore it is not your problem to worry about. See [http://joeclark.org/appearances/atmedia2007/#context Joe Clark: When accessibility is not your problem: Headings and links read out of context], in particular:
+
There are two points of view on this. <span id="Accessibility_concerns">The first is that the user experience of Assistive Technology can(might?) be severely degraded by the presence of hyperlinks which do not contain text ('''citation needed''').</span> The second is that the first claim is only a side effect of some Assistive Technologies extracting the hyperlinks in a document and presenting them as a list, and that such technologies / features have no right to do so, and therefore it is not your problem to worry about. See [http://joeclark.org/appearances/atmedia2007/#context Joe Clark: When accessibility is not your problem: Headings and links read out of context], in particular:
<blockquote><p>As writers, we are not authorizing you or Jaws to pull out our link text and remix it. Why don’t you rearrange the sentences, too?</p></blockquote>
<blockquote><p>As writers, we are not authorizing you or Jaws to pull out our link text and remix it. Why don’t you rearrange the sentences, too?</p></blockquote>
-
=== OBJECT include ===
+
=== Object ===
-
The OBJECT include pattern is semantically superior to the hyperlink include; it is being used to embed content into the page. OBJECT was the original developed include pattern. However, there are serious browser compatibility issues that can affect some implementation scenarios.
+
The Object Include Pattern is semantically superior to the Hyperlink Include; it is being used to embed content into the page. The <code>object</code> element based include was the original developed include pattern. However, there are serious browser compatibility issues that can affect some implementation scenarios and thus the above Hyperlink Include Pattern was developed and is now preferred.
-
====OBJECT include example====
+
==== Object example ====
Here is the same [[hcard|hCard]] from the beginning of the resume in the previous example.
Here is the same [[hcard|hCard]] from the beginning of the resume in the previous example.
Line 95: Line 97:
<pre><nowiki>
<pre><nowiki>
<span class="vcard">
<span class="vcard">
-
  <span class="fn n" id="j">
+
  <span class="fn n" id="jl-name">
   <span class="given-name">James</span> <span class="family-name">Levine</span>
   <span class="given-name">James</span> <span class="family-name">Levine</span>
  </span>
  </span>
Line 105: Line 107:
<pre><nowiki>
<pre><nowiki>
<span class="vcard">
<span class="vcard">
-
  <object data="#j" class="include"></object>
+
  <object data="#jl-name" class="include"></object>
  <span class="org">SimplyHired</span>
  <span class="org">SimplyHired</span>
  <span class="title">Microformat Brainstormer</span>
  <span class="title">Microformat Brainstormer</span>
Line 111: Line 113:
</nowiki></pre>  
</nowiki></pre>  
-
A microformat parser must treat the second hCard as follows, with the OBJECT include element completely replaced by the sub-tree that it referenced:
+
A microformat parser must treat the second hCard as follows, with the <code>object</code> include element completely replaced by the sub-tree that it referenced:
<pre><nowiki>
<pre><nowiki>
<span class="vcard">
<span class="vcard">
-
  <span class="fn n" id="j">
+
  <span class="fn n" id="jl-name">
   <span class="given-name">James</span> <span class="family-name">Levine</span>
   <span class="given-name">James</span> <span class="family-name">Levine</span>
  </span>
  </span>
Line 125: Line 127:
This method of hCard property indirection via an object element can apply to any/all properties in class-based microformats.
This method of hCard property indirection via an object element can apply to any/all properties in class-based microformats.
-
===OBJECT include notes and issues===
+
=== notes and issues===
 +
* Unlike the hyperlink pattern, the Object Include Pattern does not require any textual fallback. This makes it invisible to Assistive Technology with no adverse affect.
 +
* Apple's Safari (WebKit-based) browser has some rendering issues with this use of <code>object</code>: You should set a width and height of "0" for the include elements to resolve this ('''version(s) affected needed''').
 +
* Bugs have been reported in some web browsers (Internet Explorer, Safari, Firefox) that <code>object</code> elements referencing fragments of the same document erroneously cause the browser to make additional HTTP requests ('''version(s) affected needed'''). For scenarios where HTTP requests are a sensitive performance measure, this makes the hyperlink pattern inappropriate.
 +
* Versions of Microsoft Internet Explorer with ActiveX controls disabled will throw a warning prompt upon finding an <code>object</code> element ('''version(s) affected needed''').
-
* Unlike the hyperlink pattern, the OBJECT pattern does not require any textual fallback. This makes it invisible to Assistive Technology with no adverse affect.
+
== acknowledgements ==
-
* Apple's Safari (WebKit-based) browser has some rendering issues with this use of OBJECT: You should set a width and height of "0" for the include elements to resolve this.
+
-
* Bugs have been reported in some web browsers (Internet Explorer, Safari, Firefox) that OBJECT elements referencing fragments of the same document erroneously cause the browser to make additional HTTP requests. For scenarios where HTTP requests are a sensitive performance measure, this makes the hyperlink pattern inappropriate.
+
-
* Versions of Microsoft Internet Explorer with ActiveX controls disabled will throw a warning prompt upon finding an OBJECT element.
+
-
 
+
-
 
+
-
== Acknowledgements ==
+
Thanks to discussions and brainstorms with a bunch of folks: [http://theryanking.com/ Ryan King], James Levine, the whole crowd at the [http://mashupcamp.com/index.cgi?HAtomFinalization Microformats specifications working session] at MashupCamp, [http://suda.co.uk/ Brian Suda], [http://randomchaos.com/ Scott Reynen], [http://allinthehead.com/ Drew McLellan].
Thanks to discussions and brainstorms with a bunch of folks: [http://theryanking.com/ Ryan King], James Levine, the whole crowd at the [http://mashupcamp.com/index.cgi?HAtomFinalization Microformats specifications working session] at MashupCamp, [http://suda.co.uk/ Brian Suda], [http://randomchaos.com/ Scott Reynen], [http://allinthehead.com/ Drew McLellan].
-
== Specifications Using ==
+
== specifications using ==
* [[hresume|hResume]]
* [[hresume|hResume]]
* [[hreview|hReview]]
* [[hreview|hReview]]
-
=== Considering ===
+
=== considering ===
 +
All class-based microformats {{should}} consider using and explicitly normatively stating support for the include pattern.
* [[hatom|hAtom]]
* [[hatom|hAtom]]
* [[hcalendar|hCalendar]]
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[hcard|hCard]]
-
* [[currency]]
 
-
* [[measure]]
 
-
== Implementations ==
+
== implementations ==
* X2V implements the [[include-pattern]] when parsing [[hcard|hCards]] and [[hcalendar|hCalendars]] for both object.include and a.include.
* X2V implements the [[include-pattern]] when parsing [[hcard|hCards]] and [[hcalendar|hCalendars]] for both object.include and a.include.
-
== References ==
+
== references ==
-
=== Normative ===
+
=== normative ===
* HTML 4.01
* HTML 4.01
-
* XHTML 1.0
 
-
=== Informative ===
+
=== informative ===
* [[hcard|hCard]]
* [[hcard|hCard]]
 +
* [[hresume|hResume]]
 +
* XHTML 1.0
-
==Related Pages==
+
== related pages==
{{include-pattern-related-pages}}
{{include-pattern-related-pages}}
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

Revision as of 21:52, 6 November 2007

Include Pattern

Contents

Initially developed as part of resume-brainstorming, the include pattern is a mechanism to include a portion of data from one area of a page into another area of the same page. The following is documentation for re-use of the pattern in other microformats, and for publishers working with it.

Editors
Tantek Çelik
Ben Ward

background

hResume needed the ability to include a name from one hCard at the top of a resume — the person's contact details — into into the separate hCards used in the same person's employment history. Repeating so much data would be inconvenient to publishers, irritating to consumers and would not have matched the existing publishing techniques used in Resumes and Curriculum Vitæ. The include pattern is a mechanism to reference data from the same page, avoiding repetition.

scope

The include pattern is strictly limited to the scope of the current page. It cannot be used to include content from other URLs.

quick reference

The include-pattern is a mechanism to include content from one microformat into another microformat elsewhere in the same document, using hyperlinks (recommended) or OBJECT. For example:

<a class="include" href="#author">Ben Ward</a>
<object class="include" data="#author"></object>

In specs which cite the include-pattern, either of the above code snippets will cause a microformats parser to replace the A or OBJECT element with class name "include" with the content fragment with ID "author". Full examples follow.

in general

To reference includes, use an include element with class name "include" and a document fragment identifier. The content to be included should have an ID attribute set, and that ID should be referenced from the HREF or DATA attribute at the point of inclusion.

The include element with class name "include" indicates a reference to a sub-tree elsewhere in the document which must be included in-place by microformat parsers. That is, the element with class "include" is _replaced_ in the DOM by the referenced sub-tree.

To prevent infinite loops, if a class="include" refers to itself or to an ancestor in the parse tree, then it is ignored and has no effect on the parser.

Per the scope, the OBJECT 'data' attribute and hyperlink 'href' attribute MUST be local ID references when used as include pattern instances. External references (requiring a consuming application to load an external resource) are not supported by this method.

There are two HTML elements available to reference includes, hyperlink/Anchor and OBJECT. They are documented below.

These methods of property indirection via a hyperlink element can apply to any/all properties in class-based microformats, but should only be used where a microformat explicitly states that the include-pattern is a dependency. For example, XOXO does not reference the include-pattern at this time, so sub-trees cannot be included by reference in XOXO. hResume and hReview do reference the include pattern.

Hyperlink

The recommended way to reference includes within microformats is to use a hyperlink.

Hyperlink example

Here is an hCard from the beginning of a resume, shown here as a verbose hCard.

<span class="vcard">
 <span class="fn n" id="jl-name">
  <span class="given-name">James</span> <span class="family-name">Levine</span>
 </span>
</span>

Elsewhere on the page, a second hCard re-uses the "fn n" content from the first hCard:

<span class="vcard">
 <a href="#jl-name" class="include" title="James Levine"></a>
 <span class="org">SimplyHired</span>
 <span class="title">Microformat Brainstormer</span>
</span>

A microformat parser must treat the second hCard as follows, with the hyperlink include element completely replaced (including inner-text) by the sub-tree that was referenced:

<span class="vcard">
 <span class="fn n" id="jl-name">
  <span class="given-name">James</span> <span class="family-name">Levine</span>
 </span>
 <span class="org">SimplyHired</span>
 <span class="title">Microformat Brainstormer</span>
</span>

notes and issues

Note: The id attribute value in the example "jl-name" was chosen for demonstration purposes. The text of the value has no semantic per the include-pattern other than to connect the source of the include to the destination. Authors SHOULD use good Template:POSH techniques to choose id and class names.

Using the hyperlink include pattern causes no known issues in any web browser.

Authors SHOULD supply content text or at least title attribute text for the hyperlink itself. This can require repeating a small piece of information (such as a person's name in an hCard), or including generic text suitable for the context of the page.

accessibility

There are two points of view on this. The first is that the user experience of Assistive Technology can(might?) be severely degraded by the presence of hyperlinks which do not contain text (citation needed). The second is that the first claim is only a side effect of some Assistive Technologies extracting the hyperlinks in a document and presenting them as a list, and that such technologies / features have no right to do so, and therefore it is not your problem to worry about. See Joe Clark: When accessibility is not your problem: Headings and links read out of context, in particular:

As writers, we are not authorizing you or Jaws to pull out our link text and remix it. Why don’t you rearrange the sentences, too?

Object

The Object Include Pattern is semantically superior to the Hyperlink Include; it is being used to embed content into the page. The object element based include was the original developed include pattern. However, there are serious browser compatibility issues that can affect some implementation scenarios and thus the above Hyperlink Include Pattern was developed and is now preferred.

Object example

Here is the same hCard from the beginning of the resume in the previous example.

<span class="vcard">
 <span class="fn n" id="jl-name">
  <span class="given-name">James</span> <span class="family-name">Levine</span>
 </span>
</span>

Elsewhere on the page, a second hCard re-uses the "fn n" content from the first hCard:

<span class="vcard">
 <object data="#jl-name" class="include"></object>
 <span class="org">SimplyHired</span>
 <span class="title">Microformat Brainstormer</span>
</span>

A microformat parser must treat the second hCard as follows, with the object include element completely replaced by the sub-tree that it referenced:

<span class="vcard">
 <span class="fn n" id="jl-name">
  <span class="given-name">James</span> <span class="family-name">Levine</span>
 </span>
 <span class="org">SimplyHired</span>
 <span class="title">Microformat Brainstormer</span>
</span>

This method of hCard property indirection via an object element can apply to any/all properties in class-based microformats.

notes and issues

acknowledgements

Thanks to discussions and brainstorms with a bunch of folks: Ryan King, James Levine, the whole crowd at the Microformats specifications working session at MashupCamp, Brian Suda, Scott Reynen, Drew McLellan.

specifications using

considering

All class-based microformats SHOULD consider using and explicitly normatively stating support for the include pattern.

implementations

references

normative

informative

related pages

include-pattern was last modified: Wednesday, December 31st, 1969

Views