Microformats Wiki - User contributions [en]

include-pattern

2007-11-06T22:35:08Z

PatrickLauke: code fixup, and addition of keyboard access problem mention as a caveat to the "no known issues" bit...

<h1>Include Pattern</h1>
{{TOC-right}}
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|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:

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

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 [[include-pattern#Scope|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|hCard]] from the beginning of a resume, shown here as a verbose hCard.

<pre><nowiki>


James Levine


</nowiki></pre>

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

<pre><nowiki>

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

</nowiki></pre>

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:

<pre><nowiki>


James Levine

SimplyHired
Microformat Brainstormer

</nowiki></pre>

==== 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, apart from keyboard access problems noted below.

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 =====
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:
<blockquote>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?</blockquote>

However, this is current behaviour of current user agents. From the [http://microformats.org/about/ microformats about page]: <blockquote>microformats are: [...] adapted to current behaviors and usage patterns</blockquote>

As noted in the [http://microformats.org/wiki/include-pattern-feedback include-pattern feedback page], any hyperlink used with an <code>href</code> attribute ends up in the browser's tab cycle. This affects all keyboard users (both sighted users that can't/don't operate a mouse, or screen reader users in the extreme case). Even empty hyperlinks receive focus. This can be tested by modifying the code of the original [http://allinthehead.com/demo/include.html a@include test page] to visually follow the tabbing from one hyperlink to the next (using CSS or, for test purposes, subtly changing the <code>href</code>, tabbing through the page, and observing the change in the URL displayed in the browser's status bar).

=== Object ===

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 example ====

Here is the same [[hcard|hCard]] from the beginning of the resume in the previous example.

<pre><nowiki>


James Levine


</nowiki></pre>

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

<pre><nowiki>

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

</nowiki></pre>

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>


James Levine

SimplyHired
Microformat Brainstormer

</nowiki></pre>

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

=== 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 Object Include 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''').

== 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].

== specifications using ==
* [[hresume|hResume]]
* [[hreview|hReview]]

=== considering ===
All class-based microformats {{should}} consider using and explicitly normatively stating support for the include pattern.
* [[hatom|hAtom]]
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]

== implementations ==
* X2V implements the [[include-pattern]] when parsing [[hcard|hCards]] and [[hcalendar|hCalendars]] for both object.include and a.include.

== references ==

=== normative ===
* HTML 4.01

=== informative ===
* [[hcard|hCard]]
* [[hresume|hResume]]
* XHTML 1.0

== related pages==
{{include-pattern-related-pages}}
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

include-pattern

2007-11-06T22:16:12Z

PatrickLauke: providing the partial second viewpoint on the accessibility issue. keyboard access issue of empty hyperlinks still unresolved.

<h1>Include Pattern</h1>
{{TOC-right}}
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|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:

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

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 [[include-pattern#Scope|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|hCard]] from the beginning of a resume, shown here as a verbose hCard.

<pre><nowiki>


James Levine


</nowiki></pre>

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

<pre><nowiki>

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

</nowiki></pre>

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:

<pre><nowiki>


James Levine

SimplyHired
Microformat Brainstormer

</nowiki></pre>

==== 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.

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 =====
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:
<blockquote>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?</blockquote>

However, this is current behaviour of current user agents. From the [http://microformats.org/about/ microformats about page]: <blockquote>microformats are: [...] adapted to current behaviors and usage patterns</blockquote>

As noted in the [http://microformats.org/wiki/include-pattern-feedback include-pattern feedback page], any hyperlink used with an href attribute ends up in the browser's tab cycle. This affects all keyboard users (both sighted users that can't/don't operate a mouse, or screen reader users in the extreme case). Even empty hyperlinks receive focus. This can be tested by modifying the code of the original [http://allinthehead.com/demo/include.html a@include test page] to visually follow the tabbing from one hyperlink to the next (using CSS or, for test purposes, subtly changing the href, tabbing through the page, and observing the change in the URL displayed in the browser's status bar).

=== Object ===

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 example ====

Here is the same [[hcard|hCard]] from the beginning of the resume in the previous example.

<pre><nowiki>


James Levine


</nowiki></pre>

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

<pre><nowiki>

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

</nowiki></pre>

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>


James Levine

SimplyHired
Microformat Brainstormer

</nowiki></pre>

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

=== 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 Object Include 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''').

== 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].

== specifications using ==
* [[hresume|hResume]]
* [[hreview|hReview]]

=== considering ===
All class-based microformats {{should}} consider using and explicitly normatively stating support for the include pattern.
* [[hatom|hAtom]]
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]

== implementations ==
* X2V implements the [[include-pattern]] when parsing [[hcard|hCards]] and [[hcalendar|hCalendars]] for both object.include and a.include.

== references ==

=== normative ===
* HTML 4.01

=== informative ===
* [[hcard|hCard]]
* [[hresume|hResume]]
* XHTML 1.0

== related pages==
{{include-pattern-related-pages}}
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

abbr-design-pattern-issues

2007-06-11T17:55:06Z

PatrickLauke: i can't understand why, but there's oodles of spam links appearing on the page just before the "open issue". seeing if this fixes it.

<h1>abbr design pattern issues</h1>

These are externally raised issues about [[abbr-design-pattern]] with broadly varying degrees of merit. Thus some issues may be REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.



Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

Please add new issues to the '''top''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

__TOC__

== Issues ==
* See [[accessibility-issues#abbr-design-pattern]].

== Template ==
Please use this format (copy and paste this to the end of the list to add your issues):

* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items.

== Closed Issues ==
Resolved issues that have no further actions to take.
* ...

== See Also ==
* [[abbr-design-pattern]]
* [[accessibility-issues]]

assistive-technology-abbr-results

2007-05-03T19:35:08Z

PatrickLauke: /* Screenreaders */

<h1>assistive technology abbr results</h1>
This page is for document the precise results of using [[assistive-technology]] with real world examples in the wild of the abbr design pattern, as nearly always used by [[hcalendar|hCalendar]] (e.g. dtstart, dtend), often by [[hreview|hReview]] (e.g. dtreviewed, rating) and sometimes by [[hcard|hCard]] (e.g. bday, type subproperty).

__TOC__

Each [[assistive-technology]] listed here MUST link to a precise description of the tool/service on the [[assistive-technology]] page, including version number, when published, etc.

Each test result listed for each assistive technology MUST link to the real world example that was tested.

== Test Cases ==
The [http://www.webstandards.org/action/atf/ WasP Accessibility Task Force] is working on a set of extended test cases that will cover the following data formats and markup formats. Please add to the list so we can create a comprehensive result set.

===Data Formats===
Please provide hyperlinks to examples in the wild for each case that is to be tested. Test cases with example in the wild URLs merit more testing than those without. However, the purpose of these test cases is to find the best solution, whether or not it is currently being used.
* ISO 8601 date with punctuation (YYYY-MM-DD)
* ISO 8601 datetime with punctuation (YYYY-MM-DDTHH:MM:SS)
* ISO 8601 datetime with punctuation and no seconds (YYYY-MM-DDTHH:MM)
* ISO 8601 UTC datetime with punctuation (YYYY-MM-DDTHH:MM:SSZ)
* ISO 8601 pre-UTC datetime with punctuation (YYYY-MM-DDTHH:MM:SS+HH:MM)
* ISO 8601 pre-UTC datetime with punctuation and no timezone minutes (YYYY-MM-DDTHH:MM:SS+HH)
* ISO 8601 post-UTC datetime with punctuation (YYYY-MM-DDTHH:MM:SS-HH:MM)
* ISO 8601 post-UTC datetime with punctuation and no timezone minutes (YYYY-MM-DDTHH:MM:SS-HH)
* ISO 8601 datetime with punctuation but w/o timezone punctuation. ''The hypothesis is that something like "eleven o'clock plus oh seven hundred" may be more understandable than "eleven o'clock plus seven o'clock" (similarly for the hyphen, read as "dash").''
** pre-UTC (YYYY-MM-DDTHH:MM:SS+HHMM)
** post-UTC (YYYY-MM-DDTHH:MM:SS-HHMM)
* GEO Latitude/Longitude coordinates.

=== Rejected Data formats ===
Dates without punctuation as they have proved unusable. Proof is premise for [[http://www.webstandards.org/2007/04/27/haccessibility/ hAccessibility]] article on the Web Standards Project Buzz blog. Window Eyes and JAWS read un-punctuated dates as single number. [[http://www.webstandards.org/files/atf_microformats/jaws.mp3 JAWS 8 on IE7 citation (MP3 Audio)]] of "twenty million seventy-thousand three-hundred twelve" is reason enough for rejection.
* ISO 8601 date without dashes (YYYYMMDD)
* ISO 8601 datetime without dashes and colons (YYYYMMDDTHHMMSS)
* ISO 8601 datetime without dashes and colons and no seconds (YYYYMMDDTHHMM)
* ISO 8601 UTC datetime without dashes and colons (YYYYMMDDTHHMMSSZ)
* ISO 8601 pre-UTC datetime without dashes and colons (YYYYMMDDTHHMMSSZ+HHMM)
* ISO 8601 pre-UTC datetime without dashes and colons and no timezone minutes (YYYYMMDDTHHMMSSZ+HH)
* ISO 8601 post-UTC datetime without dashes and colons (YYYYMMDDTHHMMSSZ-HHMM)
* ISO 8601 post-UTC datetime without dashes and colons and no timezone minutes (YYYYMMDDTHHMMSSZ-HH)

===Markup Possibilities===
==== Valid HTML4 ====
* abbr-design-pattern (as currently recommended)
* Object with param value.
* Object with in-page data attribute.
* Span with title property.
* Nested spans with child title set to null.
* Nested abbr with child title set to null.
* Empty ins element with datetime attr (<code>13th<ins datetime="20070713"></ins></code>)
* Rarely used event handler. e.g. (<code>13th</code>)

==== Invalid HTML4 ====
Markup possibilities that are invalid in HTML4/XHTML1 are noted here to be clear that they were considered and rejected. Since microformats build on [[posh]], any technique that is invalid semantic (X)HTML is unacceptable for a microformats solution. There is no need to bother testing these.
* Span with RDF dc:date attribute.
* Span with RDF geo:position attribute.

===Screenreader Language Pronunciations===
* English
* Spanish (need volunteer native Spanish speaker screen reader user)
* ?

===Verbosity settings===

* Punctuation, speak none.
* Punctuation, speak some.
* Punctuation, speak all.
* Title attributes, speak none.
* Title attributes, speak some (abbr and acronym).
* Title attributes, speak all.

===Screenreaders===
* Freedom Scientific JAWS (multiple versions TBD)
* GW Micro Window Eyes (multiple versions TBD)
* Apple Voiceover (multiple versions TBD)
* Dolphin HAL (multiple versions TBD)

== Results ==

To be determined.

== See Also ==
* [[accessibility]]
* [[assistive-technology]]

accessibility-issues

2007-05-01T18:08:24Z

PatrickLauke: include pattern issues added

<h1>accessibility issues</h1>

These are externally raised issues about [[accessibility]] with broadly varying degrees of merit. Thus some issues may be REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[accessibility-faq|accessibility FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

Please add new issues to the '''top''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

__TOC__

== Issues ==

*{{OpenIssue}} [http://lists.w3.org/Archives/Public/w3c-wai-ig/2006OctDec/0022.html 2006-10-06 raised by John Foliot in w3c-wai-ig]
*# ''<blockquote>What we don't need (IMHO) is a web where everything is simply a <div> with some extraneous Microformats style association added to it. </blockquote>''

*{{OpenIssue}} [http://www.accessifyforum.com/viewtopic.php?t=6167&postdays=0&postorder=asc&start=0 2006-09-20 raised by Andy Mabbett in accessifyforum]
*# ''Use of 'abbr' in microformats''

===hCalendar===
hCalendar specific accessibility issues. These are separated from the [[hcalendar-issues|hCalendar issues]] in general so that they are not lost among other non-accessibility related issues.

* {{OpenIssue}} 2007-01-20 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''Where <code>DTEND</code> is a date, and not a date-time, it is required to be the day after the end of the event, thus: <code><nowiki>
<abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>. However, "29 April 2007" is '''''not''''' an abbreviation of 2007-04-30; it is an abbreviation of 2007-04-29. The markup as shown is semantically incorrect and likely to cause problems for users and user-agents which read the title attribute, and not the text value, of the <code>abbr</code> element.''

*{{OpenIssue}} 2006-12-11 raised by Andy Mabbett
*# ''The image in [[hcalendar-brainstorming#Photos and other attachments]] has inappropriate alt text, being just the file mname. [[User:AndyMabbett|Andy Mabbett]] 15:23, 6 Mar 2007 (PST)''

=== abbr-design-pattern ===
*{{OpenIssue}} 2007-04-27 raised by James Craig, Bruce Lawson.
*# ''Article and discussion about why some instances of the [http://www.webstandards.org/2007/04/27/haccessibility/ abbr-design-pattern may be bad for accessibility].''

=== include-design-pattern ===
*{{OpenIssue}} 2007-04-28 raised by [[User:PatrickLauke|PatrickLauke]]
*# although nominally empty, [http://microformats.org/wiki/include-pattern-feedback#Hyperlink_Include_-_issues_for_keyboard_users_.28including_Screen_Reader_users.29 hyperlink includes still present in tab cycle of major browsers], proving to be a problem for keyboard users (including users of screen readers)
*# [http://microformats.org/wiki/include-pattern-feedback#Test_Results:_JAWS_7.0_with_Firefox_1.5.2FWin JAWS 7.0] testing not conclusive to ascertain compatibility in other major screen readers.

===Accessibility of this wiki===
*{{OpenIssue}} 2006-11-26 raised by Andy Mabbett
*# ''Large blocks of italic text are inaccessible to many readers, including people with types of visual impairment, dyslexia, etc. [http://www.intranet.man.ac.uk/accessibility/Disabilities/dyslexia.html], [https://tritonlink.ucsd.edu/portal/site/tritonlink-preview/menuitem.b4448692267a11256ec5e210514b01ca?storyID=20896]. [http://accessites.org/], [http://tlt.psu.edu/suggestions/accessibility/font.html], [http://www.wd4a.co.uk/Guidelines.htm] [[User:AndyMabbett|Andy Mabbett]] 14:33, 26 Nov 2006 (PST)''

*{{OpenIssue}} 2006-12-11 raised by Andy Mabbett
*# ''[http://microformats.org/wiki?title=page-summary-formats&curid=2572&diff=0&oldid=11214&rcid=20591 Duplicating link text] breaches [http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-meaningful-links WAI-WCAG 1 guideline 13.1 Clearly identify the target of each link] and is unhelpful to users of assistive technologies and other agents, which provide links in a stand-alone, out-of-context list. [[User:AndyMabbett|Andy Mabbett]] 10:29, 11 Dec 2006 (PST)''

== Template ==
Please use this format (copy and paste this to the beginning of the list to add your issues):
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items.
* ...

== Closed Issues ==
Resolved issues that have no further actions to take.

*2006-11-26 raised by Andy Mabbett
*# ''Using emboldening and italics to differentiate types on, e.g. the cheatsheet pages [[hcard-cheatsheet]], is unhelpful to users of assistive technologies, text-only devices, etc. A number, letter or symbol should additionally be used. [[User:AndyMabbett|Andy Mabbett]] 14:33, 26 Nov 2006 (PST)''
*#*I think the emboldening is fine as it marks up the required properties. The italics are a bit of a problem but keep it simple at the moment. Additional characters can’t be used as they would break the class="property" template. Colours would be a way but are inaccessible to some users, so there is no real solution to that problem for now. [[User:JulianStahnke|Julian Stahnke]] 22:55, 26 Nov 2006 (GMT)
*#**"I think the emboldening is fine" - how would you understand emboldening in a text-only browser like Lynx, or in an aural browser? [[User:AndyMabbett|Andy Mabbett]] 15:17, 26 Nov 2006 (PST)
*#***Ups, I just assumed that it would use strong and em tags. Yeah, well, let’s think about it. [[User:JulianStahnke|Julian Stahnke]] 23:22, 26 Nov 2006 (GMT)
*#*Of course, one could add that stuff ''after'' the class="property" thing. That might look a little cluttered though. I’ll consider that for the next revision/next cheat sheet I do. [[User:JulianStahnke|Julian Stahnke]] 22:57, 26 Nov 2006 (GMT)
*#**All that's needed is:
::::<nowiki>* class="vcard" (1)</nowiki>
::instead of:
::::<nowiki>* class="vcard"</nowiki>
:::[[User:AndyMabbett|Andy Mabbett]] 15:24, 26 Nov 2006 (PST)
*#*'''Now resolved'''. Thanks to all who helped. [[User:AndyMabbett|Andy Mabbett]] 10:30, 11 Dec 2006 (PST)

== See Also ==
* [[accessibility]]
* [[microformats-issues]]

include-pattern-feedback

2007-04-28T18:18:14Z

PatrickLauke: adding proper attribution to my edits

= Include Pattern Feedback =

Feedback about [[include-pattern]].

== Objects and Browser Behavior ==

Over at Yahoo! Local, we were using the object include pattern for all our [[hreview|hReviews]] on business detail pages and review listings. That is, until we realized that Safari and Internet Explorer both try to embed the entire page with every OBJECT call. (Firefox correctly recognizes that it's a local object and doesn't reload anything.)

On a page with 20+ reviews, this means a substantial increase in load time and memory consumption. As a result of this (bad) browser behavior, we removed the objects entirely.

Any suggestions for workarounds or modifications to the pattern?

-- AndyBaio 29 Jun 2006

Can you use the hyperlink option with DHMTL/Ajax to perform replacements in advanced browsers? (Simon Willison's <code>[http://simon.incutio.com/archive/2003/03/25/getElementsBySelector getElementsBySelector()]</code> may be helpful)
<a href="#id" class="include" title=""></a>
with something like:
//Works only for linked include-pattern definition at microformats.org
//Requires Simon Willison's getElementsBySelector()
// and normal IE workaround for addEventListener()
addEventListener( window, 'load', function() {
var myIncludes = document.getElementsBySelector( 'a[href].include' ), a, e;
for( var i=0; a=myIncludes[i]; i++ ) if (a.href.charAt(0)=='#') {
e = document.getElementsBySelector( a.href )[0].cloneNode( true );
a.parentNode.replaceChild( e, a );
}
})
--[[User:RichHall|RichHall]] 00:51, 23 Oct 2006 (PDT)

It seems there is some confusion around this topic. I believe that the included data '''are not supposed to be actually included in the point of inclusion'''. I believe it is only meant to be a hint for the microformats parser; but the inclusion pattern should not affect how the page is rendered. If that is true, let's clear out this page:
* Remove the DHTML suggestion by Rich Hall.
* Change the IRC quote between Tantek and Kaply. Replace the quote ''"clone the dom node from the other vcard and replace the object with the corresponding nodes"'' with ''"look for objects in the vcard and check their corresponding nodes in the dom" [http://rbach.priv.at/Microformats-IRC/2007-01-03#T165941|IRC of 2007-01-03]'' or remove the IRC quote completely.

-- [[User:JiriKopsa]] 18 Mar 2007

My hResume page [http://robert.o-rourke.org seen here] caused Safari <ins>2.0</ins> some major issues. The page was jumping between object elements when a link was hovered eventually causing the browser to crash. You can follow the thread on the [http://www.mail-archive.com/listdad%40webstandardsgroup.org/msg06078.html WSG mail archive].

It seems that while the object element may be more semantically appropriate it <del>is not</del> <ins>may not be</ins> usable in lieu of the issues raised in Safari.

--[[User:SanchoTheFat|Robert O'Rourke]] 12:08, 3 Nov 2006 (PST)

Which version of Safari? Please be specific as many Safari OBJECT bugs were fixed in Safari 2.x.

-- [[User:Tantek|Tantek]] 13:39, 3 Nov 2006 (PST)

The issues with OBJECT in Internet Explorer & Safari and the lack of a good workaround example are a show stopper for me using this. I am now commenting it out. Hope someone can think of a workaround!

--[[User:WizardIsHungry|Jon Williams]] 10:21, 7 Feb 2007 (PST)

== Hyperlink Include - issues for keyboard users (including Screen Reader users) ==

Although invisible in visual user agents, and (according to the JAWS 7.0 test below) not spoken by screen readers (at least not by JAWS 7.0), empty links are still contained in the normal tab cycle. Users navigating via keyboard (or equivalent, e.g. switch access, puff/blow devices, etc) will still need to tab through the empty links (tested in Firefox 2.0, IE 6, IE 7; Opera 9.2 seems to remove empty links from tab cycle).

This can be verified by modifying the test page below, adding a regular link at the end of the 5 variations of empty links. It takes a user 6 tabs to arrive at the "real" link. It would therefore be advisable to rethink the approach, or scrap it completely.

-- [[User:PatrickLauke|Patrick H. Lauke]] 28 Apr 2007

== Hyperlink Include - Screen Reader Testing ==

Some [http://microformats.org/discuss/mail/microformats-discuss/2006-July/004693.html concerns have been raised] over the implications using empty hyperlinks may have on assistive devices such as screen readers. One concern is that an empty link may be read out, partially read out or result in some other confusing scenario for the user.

In response, a [http://allinthehead.com/demo/include.html test page] consisting of a number of empty hyperlinks in the style suggested by the pattern has been created. A 'good' result is that none of the links be read out.

=== Test Results: JAWS 7.0 with Firefox 1.5/Win ===

Tested by [[User:Phae|Frances Berriman]] 2006-07-21.

* 31 dash include dash Mozilla Firefox
* Page has no links
* 31 dash include

Conclusion: the hyperlink include pattern presented no usability issues for this screen reader.

Was keyboard access fully tested (see above)? This test is not conclusive, as JAWS 7.0's behaviour may well differ from other access technology. Further testing with a wider range of readers is strongly recommended. -- [[User:PatrickLauke|Patrick H. Lauke]] 28 Apr 2007

=== Proprietary attribute ===
HTML tidy on the [http://allinthehead.com/demo/include.html test page] gives:
:Warning: <a> proprietary attribute "data"

The [http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fallinthehead.com%2Fdemo%2Finclude.html W3C validator is similarly unimpressed].

[[User:AndyMabbett|AndyMabbett]] 14:22, 22 Oct 2006 (PDT)

==== Use href ====
To clarify, links on the [http://allinthehead.com/demo/include.html test page] should be changed to use the <code>href</code> attribute as described at [[include-pattern]] (without <code>href</code> attributes, the elements probably won't register as hyperlinks, but anchors). Set <code>title=""</code> to fix empty link behavior for many assistive devices. --[[User:RichHall|RichHall]] 23:31, 22 Oct 2006 (PDT)

==== Test page corrected ====
2006-10-25: This error has been corrected on the [http://allinthehead.com/demo/include.html test page]. Any tests should probably be re-run in light of this.

== Unclear status ==

It's not clear, either from the main Wiki page or [[include-pattern]], whether this is an agreed standard, a draft, or just a proposal. [[User:AndyMabbett|AndyMabbett]] 03:14, 18 Oct 2006 (PDT)

* [[include-pattern]] is not its own proposal, draft, or spec. It is a design pattern, as listed on the [[Main_Page|wiki home page]] that is included in other proposals, drafts. and specs. ''Recommend for adding to the [[include-pattern-faq]].
**And that is not clear, either from the main Wiki page or [[include-pattern]]. [[User:AndyMabbett|AndyMabbett]] 16:40, 18 Oct 2006 (PDT)
***ACCEPTED. Will further clarify relationship between patterns and formats. [[User:Tantek|Tantek]] 16:48, 18 Oct 2006 (PDT)

==Parsing for include-pattern==

''Note: this issue is obsolete. On a [http://rbach.priv.at/Microformats-IRC/2007-01-03#T165528 IRC conversation 2007-01-03], Mike Kaply admitted that he figured this out, which is to apply all includes first into the parse tree before looking for any properties. -Tantek''

''To be more specific, what finally occurred to me is that the object pattern is simply about grabbing nodes from another vcard and using them in this vcard. So the implementor responsibility is just to clone the dom node from the other vcard and replace the object with the corresponding nodes. Works great. (of course I also had to clone the entire vcard since I can't manipulate the DOM like that without changing the page) -mkaply''

In an [http://rbach.priv.at/Microformats-IRC/2007-01-02#T205847 IRC discussion] with [http://www.kaply.com/weblog/ Mike Kaply] (author of the [https://addons.mozilla.org/firefox/4106/ Operator] extension for Firefox) we discussed the difficulty of parsing for an [[include-pattern]] in [[hresume|hResume]]. Mike asks:
<blockquote>I'm really wondering why the <code>object</code> stuff doesn't point back to the entire vCard. I don't understand why the spec has it point to individual items.</blockquote>
The problem was thought to be a weakness in the specification, which doesn't specify what part of the data is in the content that is pointed to by the <code>object</code>.

Currently, to overcome this a parser needs to follow this logic:
::IF I don't find an <code>fn</code>, look for an <code>object</code>. IF there is an <code>object</code>, do a <code>getelementbyid</code> on that <code>ID</code>, but yet there was nothing about that <code>object</code> that said that the content I was looking for in the other card was an <code>fn</code>

Two things may help in overcoming this difficulty:

# Change the spec to have the include-pattern reference the entire vCard, with the intent that any data not found in this vCard use the other vCard
# Include the element of the reference, where the class attribute on <code><object></code> has "include" plus the element that needs to be included. For example:
<pre><nowiki><object
class="include fn" data="#vcard-name">myname</object> </nowiki></pre>

Additionally, I pointed out that using the <code><object></code> element to contain the reference makes Microsoft's Internet Explorer throw an error "Your current security settings prohibit ActiveX controls on this page. As a result, the page may not display correctly." Of course, there is no ActiveX content on an include-pattern.

[[User:Bob Jonkman|Bob Jonkman]] 21:15, 2 Jan 2007 (PST)#

==Concatenating values==

I feel that there should be a way to "include" data from two places, in one microformat property. For instance:

<pre><nowiki>Kidderminster Branch Indoor Meeting</nowiki></pre>
<pre><nowiki>Janaury</nowiki></pre>

and later

<pre><nowiki><object data="#summaryB+#summaryA" class="include"></object></nowiki></pre>

would give a summary of:

:'''January Kidderminster Branch Indoor Meeting'''

It may even be possible to include extra data:

<pre><nowiki>Fred Smith</nowiki></pre>

<pre><nowiki><object data="#summaryA+ with +#summaryC" class="include"></object></nowiki></pre>

to give:

:'''Kidderminster Branch Indoor Meeting with Fred Smith'''

[[User:AndyMabbett|Andy Mabbett]] 14:33, 8 Jan 2007 (PST)

Why not use

<pre><nowiki><object data="#summaryA" class="include"></object> with <object data="#summaryB" class="include"></object></nowiki></pre>

to build

:'''Kidderminster Branch Indoor Meeting with Fred Smith'''

[[User:DerrickPallas|Derrick Pallas]] 11:15, 31 Jan 2007 (PST)

:Neat solution! Can anyone say whether current parsers accept this? [[User:AndyMabbett|Andy Mabbett]] 12:18, 31 Jan 2007 (PST)

:Fully disclosure: My XSLT transformer supports this implicitly because it does include-pattern first, then pulls values. My only question would be what to do with nested @class="value" elements that could result from this. [[User:DerrickPallas|Derrick Pallas]] 12:35, 31 Jan 2007 (PST)

==Related Pages==
{{include-pattern-related-pages}}

User:PatrickLauke

2007-04-28T18:16:25Z

PatrickLauke:

* I feel right at home at http://www.splintered.co.uk
* My [[Special:Contributions/PatrickLauke|Contributions]]

include-pattern-feedback

2007-04-28T18:15:09Z

PatrickLauke:

= Include Pattern Feedback =

Feedback about [[include-pattern]].

== Objects and Browser Behavior ==

Over at Yahoo! Local, we were using the object include pattern for all our [[hreview|hReviews]] on business detail pages and review listings. That is, until we realized that Safari and Internet Explorer both try to embed the entire page with every OBJECT call. (Firefox correctly recognizes that it's a local object and doesn't reload anything.)

On a page with 20+ reviews, this means a substantial increase in load time and memory consumption. As a result of this (bad) browser behavior, we removed the objects entirely.

Any suggestions for workarounds or modifications to the pattern?

-- AndyBaio 29 Jun 2006

Can you use the hyperlink option with DHMTL/Ajax to perform replacements in advanced browsers? (Simon Willison's <code>[http://simon.incutio.com/archive/2003/03/25/getElementsBySelector getElementsBySelector()]</code> may be helpful)
<a href="#id" class="include" title=""></a>
with something like:
//Works only for linked include-pattern definition at microformats.org
//Requires Simon Willison's getElementsBySelector()
// and normal IE workaround for addEventListener()
addEventListener( window, 'load', function() {
var myIncludes = document.getElementsBySelector( 'a[href].include' ), a, e;
for( var i=0; a=myIncludes[i]; i++ ) if (a.href.charAt(0)=='#') {
e = document.getElementsBySelector( a.href )[0].cloneNode( true );
a.parentNode.replaceChild( e, a );
}
})
--[[User:RichHall|RichHall]] 00:51, 23 Oct 2006 (PDT)

It seems there is some confusion around this topic. I believe that the included data '''are not supposed to be actually included in the point of inclusion'''. I believe it is only meant to be a hint for the microformats parser; but the inclusion pattern should not affect how the page is rendered. If that is true, let's clear out this page:
* Remove the DHTML suggestion by Rich Hall.
* Change the IRC quote between Tantek and Kaply. Replace the quote ''"clone the dom node from the other vcard and replace the object with the corresponding nodes"'' with ''"look for objects in the vcard and check their corresponding nodes in the dom" [http://rbach.priv.at/Microformats-IRC/2007-01-03#T165941|IRC of 2007-01-03]'' or remove the IRC quote completely.

-- [[User:JiriKopsa]] 18 Mar 2007

My hResume page [http://robert.o-rourke.org seen here] caused Safari <ins>2.0</ins> some major issues. The page was jumping between object elements when a link was hovered eventually causing the browser to crash. You can follow the thread on the [http://www.mail-archive.com/listdad%40webstandardsgroup.org/msg06078.html WSG mail archive].

It seems that while the object element may be more semantically appropriate it <del>is not</del> <ins>may not be</ins> usable in lieu of the issues raised in Safari.

--[[User:SanchoTheFat|Robert O'Rourke]] 12:08, 3 Nov 2006 (PST)

Which version of Safari? Please be specific as many Safari OBJECT bugs were fixed in Safari 2.x.

-- [[User:Tantek|Tantek]] 13:39, 3 Nov 2006 (PST)

The issues with OBJECT in Internet Explorer & Safari and the lack of a good workaround example are a show stopper for me using this. I am now commenting it out. Hope someone can think of a workaround!

--[[User:WizardIsHungry|Jon Williams]] 10:21, 7 Feb 2007 (PST)

== Hyperlink Include - issues for keyboard users (including Screen Reader users) ==

Although invisible in visual user agents, and (according to the JAWS 7.0 test below) not spoken by screen readers (at least not by JAWS 7.0), empty links are still contained in the normal tab cycle. Users navigating via keyboard (or equivalent, e.g. switch access, puff/blow devices, etc) will still need to tab through the empty links (tested in Firefox 2.0, IE 6, IE 7; Opera 9.2 seems to remove empty links from tab cycle).

This can be verified by modifying the test page below, adding a regular link at the end of the 5 variations of empty links. It takes a user 6 tabs to arrive at the "real" link. It would therefore be advisable to rethink the approach, or scrap it completely.

-- [[User:PatrickLauke]] 28 Apr 2007

== Hyperlink Include - Screen Reader Testing ==

Some [http://microformats.org/discuss/mail/microformats-discuss/2006-July/004693.html concerns have been raised] over the implications using empty hyperlinks may have on assistive devices such as screen readers. One concern is that an empty link may be read out, partially read out or result in some other confusing scenario for the user.

In response, a [http://allinthehead.com/demo/include.html test page] consisting of a number of empty hyperlinks in the style suggested by the pattern has been created. A 'good' result is that none of the links be read out.

=== Test Results: JAWS 7.0 with Firefox 1.5/Win ===

Tested by [[User:Phae|Frances Berriman]] 2006-07-21.

* 31 dash include dash Mozilla Firefox
* Page has no links
* 31 dash include

Conclusion: the hyperlink include pattern presented no usability issues for this screen reader.

Was keyboard access fully tested (see above)? This test is not conclusive, as JAWS 7.0's behaviour may well differ from other access technology. Further testing with a wider range of readers is strongly recommended. -- [[User:PatrickLauke]] 28 Apr 2007

=== Proprietary attribute ===
HTML tidy on the [http://allinthehead.com/demo/include.html test page] gives:
:Warning: <a> proprietary attribute "data"

The [http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fallinthehead.com%2Fdemo%2Finclude.html W3C validator is similarly unimpressed].

[[User:AndyMabbett|AndyMabbett]] 14:22, 22 Oct 2006 (PDT)

==== Use href ====
To clarify, links on the [http://allinthehead.com/demo/include.html test page] should be changed to use the <code>href</code> attribute as described at [[include-pattern]] (without <code>href</code> attributes, the elements probably won't register as hyperlinks, but anchors). Set <code>title=""</code> to fix empty link behavior for many assistive devices. --[[User:RichHall|RichHall]] 23:31, 22 Oct 2006 (PDT)

==== Test page corrected ====
2006-10-25: This error has been corrected on the [http://allinthehead.com/demo/include.html test page]. Any tests should probably be re-run in light of this.

== Unclear status ==

It's not clear, either from the main Wiki page or [[include-pattern]], whether this is an agreed standard, a draft, or just a proposal. [[User:AndyMabbett|AndyMabbett]] 03:14, 18 Oct 2006 (PDT)

* [[include-pattern]] is not its own proposal, draft, or spec. It is a design pattern, as listed on the [[Main_Page|wiki home page]] that is included in other proposals, drafts. and specs. ''Recommend for adding to the [[include-pattern-faq]].
**And that is not clear, either from the main Wiki page or [[include-pattern]]. [[User:AndyMabbett|AndyMabbett]] 16:40, 18 Oct 2006 (PDT)
***ACCEPTED. Will further clarify relationship between patterns and formats. [[User:Tantek|Tantek]] 16:48, 18 Oct 2006 (PDT)

==Parsing for include-pattern==

''Note: this issue is obsolete. On a [http://rbach.priv.at/Microformats-IRC/2007-01-03#T165528 IRC conversation 2007-01-03], Mike Kaply admitted that he figured this out, which is to apply all includes first into the parse tree before looking for any properties. -Tantek''

''To be more specific, what finally occurred to me is that the object pattern is simply about grabbing nodes from another vcard and using them in this vcard. So the implementor responsibility is just to clone the dom node from the other vcard and replace the object with the corresponding nodes. Works great. (of course I also had to clone the entire vcard since I can't manipulate the DOM like that without changing the page) -mkaply''

In an [http://rbach.priv.at/Microformats-IRC/2007-01-02#T205847 IRC discussion] with [http://www.kaply.com/weblog/ Mike Kaply] (author of the [https://addons.mozilla.org/firefox/4106/ Operator] extension for Firefox) we discussed the difficulty of parsing for an [[include-pattern]] in [[hresume|hResume]]. Mike asks:
<blockquote>I'm really wondering why the <code>object</code> stuff doesn't point back to the entire vCard. I don't understand why the spec has it point to individual items.</blockquote>
The problem was thought to be a weakness in the specification, which doesn't specify what part of the data is in the content that is pointed to by the <code>object</code>.

Currently, to overcome this a parser needs to follow this logic:
::IF I don't find an <code>fn</code>, look for an <code>object</code>. IF there is an <code>object</code>, do a <code>getelementbyid</code> on that <code>ID</code>, but yet there was nothing about that <code>object</code> that said that the content I was looking for in the other card was an <code>fn</code>

Two things may help in overcoming this difficulty:

# Change the spec to have the include-pattern reference the entire vCard, with the intent that any data not found in this vCard use the other vCard
# Include the element of the reference, where the class attribute on <code><object></code> has "include" plus the element that needs to be included. For example:
<pre><nowiki><object
class="include fn" data="#vcard-name">myname</object> </nowiki></pre>

Additionally, I pointed out that using the <code><object></code> element to contain the reference makes Microsoft's Internet Explorer throw an error "Your current security settings prohibit ActiveX controls on this page. As a result, the page may not display correctly." Of course, there is no ActiveX content on an include-pattern.

[[User:Bob Jonkman|Bob Jonkman]] 21:15, 2 Jan 2007 (PST)#

==Concatenating values==

I feel that there should be a way to "include" data from two places, in one microformat property. For instance:

<pre><nowiki>Kidderminster Branch Indoor Meeting</nowiki></pre>
<pre><nowiki>Janaury</nowiki></pre>

and later

<pre><nowiki><object data="#summaryB+#summaryA" class="include"></object></nowiki></pre>

would give a summary of:

:'''January Kidderminster Branch Indoor Meeting'''

It may even be possible to include extra data:

<pre><nowiki>Fred Smith</nowiki></pre>

<pre><nowiki><object data="#summaryA+ with +#summaryC" class="include"></object></nowiki></pre>

to give:

:'''Kidderminster Branch Indoor Meeting with Fred Smith'''

[[User:AndyMabbett|Andy Mabbett]] 14:33, 8 Jan 2007 (PST)

Why not use

<pre><nowiki><object data="#summaryA" class="include"></object> with <object data="#summaryB" class="include"></object></nowiki></pre>

to build

:'''Kidderminster Branch Indoor Meeting with Fred Smith'''

[[User:DerrickPallas|Derrick Pallas]] 11:15, 31 Jan 2007 (PST)

:Neat solution! Can anyone say whether current parsers accept this? [[User:AndyMabbett|Andy Mabbett]] 12:18, 31 Jan 2007 (PST)

:Fully disclosure: My XSLT transformer supports this implicitly because it does include-pattern first, then pulls values. My only question would be what to do with nested @class="value" elements that could result from this. [[User:DerrickPallas|Derrick Pallas]] 12:35, 31 Jan 2007 (PST)

==Related Pages==
{{include-pattern-related-pages}}

include-pattern-feedback

2007-04-28T16:07:27Z

PatrickLauke: hyperlink include - keyboard problems

= Include Pattern Feedback =

Feedback about [[include-pattern]].

== Objects and Browser Behavior ==

Over at Yahoo! Local, we were using the object include pattern for all our [[hreview|hReviews]] on business detail pages and review listings. That is, until we realized that Safari and Internet Explorer both try to embed the entire page with every OBJECT call. (Firefox correctly recognizes that it's a local object and doesn't reload anything.)

On a page with 20+ reviews, this means a substantial increase in load time and memory consumption. As a result of this (bad) browser behavior, we removed the objects entirely.

Any suggestions for workarounds or modifications to the pattern?

-- AndyBaio 29 Jun 2006

Can you use the hyperlink option with DHMTL/Ajax to perform replacements in advanced browsers? (Simon Willison's <code>[http://simon.incutio.com/archive/2003/03/25/getElementsBySelector getElementsBySelector()]</code> may be helpful)
<a href="#id" class="include" title=""></a>
with something like:
//Works only for linked include-pattern definition at microformats.org
//Requires Simon Willison's getElementsBySelector()
// and normal IE workaround for addEventListener()
addEventListener( window, 'load', function() {
var myIncludes = document.getElementsBySelector( 'a[href].include' ), a, e;
for( var i=0; a=myIncludes[i]; i++ ) if (a.href.charAt(0)=='#') {
e = document.getElementsBySelector( a.href )[0].cloneNode( true );
a.parentNode.replaceChild( e, a );
}
})
--[[User:RichHall|RichHall]] 00:51, 23 Oct 2006 (PDT)

It seems there is some confusion around this topic. I believe that the included data '''are not supposed to be actually included in the point of inclusion'''. I believe it is only meant to be a hint for the microformats parser; but the inclusion pattern should not affect how the page is rendered. If that is true, let's clear out this page:
* Remove the DHTML suggestion by Rich Hall.
* Change the IRC quote between Tantek and Kaply. Replace the quote ''"clone the dom node from the other vcard and replace the object with the corresponding nodes"'' with ''"look for objects in the vcard and check their corresponding nodes in the dom" [http://rbach.priv.at/Microformats-IRC/2007-01-03#T165941|IRC of 2007-01-03]'' or remove the IRC quote completely.

-- [[User:JiriKopsa]] 18 Mar 2007

My hResume page [http://robert.o-rourke.org seen here] caused Safari <ins>2.0</ins> some major issues. The page was jumping between object elements when a link was hovered eventually causing the browser to crash. You can follow the thread on the [http://www.mail-archive.com/listdad%40webstandardsgroup.org/msg06078.html WSG mail archive].

It seems that while the object element may be more semantically appropriate it <del>is not</del> <ins>may not be</ins> usable in lieu of the issues raised in Safari.

--[[User:SanchoTheFat|Robert O'Rourke]] 12:08, 3 Nov 2006 (PST)

Which version of Safari? Please be specific as many Safari OBJECT bugs were fixed in Safari 2.x.

-- [[User:Tantek|Tantek]] 13:39, 3 Nov 2006 (PST)

The issues with OBJECT in Internet Explorer & Safari and the lack of a good workaround example are a show stopper for me using this. I am now commenting it out. Hope someone can think of a workaround!

--[[User:WizardIsHungry|Jon Williams]] 10:21, 7 Feb 2007 (PST)

== Hyperlink Include - issues for keyboard users (including Screen Reader users) ==

Although invisible in visual user agents, and (according to the JAWS 7.0 test below) not spoken by screen readers (at least not by JAWS 7.0), empty links are still contained in the normal tab cycle. Users navigating via keyboard (or equivalent, e.g. switch access, puff/blow devices, etc) will still need to tab through the empty links (tested in Firefox 2.0, IE 6, IE 7; Opera 9.2 seems to remove empty links from tab cycle).

This can be verified by modifying the test page below, adding a regular link at the end of the 5 variations of empty links. It takes a user 6 tabs to arrive at the "real" link. It would therefore be advisable to rethink the approach, or scrap it completely.

== Hyperlink Include - Screen Reader Testing ==

Some [http://microformats.org/discuss/mail/microformats-discuss/2006-July/004693.html concerns have been raised] over the implications using empty hyperlinks may have on assistive devices such as screen readers. One concern is that an empty link may be read out, partially read out or result in some other confusing scenario for the user.

In response, a [http://allinthehead.com/demo/include.html test page] consisting of a number of empty hyperlinks in the style suggested by the pattern has been created. A 'good' result is that none of the links be read out.

=== Test Results: JAWS 7.0 with Firefox 1.5/Win ===

Tested by [[User:Phae|Frances Berriman]] 2006-07-21.

* 31 dash include dash Mozilla Firefox
* Page has no links
* 31 dash include

Conclusion: the hyperlink include pattern presented no usability issues for this screen reader.

Further testing with a wider range of readers is strongly recommended.

=== Proprietary attribute ===
HTML tidy on the [http://allinthehead.com/demo/include.html test page] gives:
:Warning: <a> proprietary attribute "data"

The [http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fallinthehead.com%2Fdemo%2Finclude.html W3C validator is similarly unimpressed].

[[User:AndyMabbett|AndyMabbett]] 14:22, 22 Oct 2006 (PDT)

==== Use href ====
To clarify, links on the [http://allinthehead.com/demo/include.html test page] should be changed to use the <code>href</code> attribute as described at [[include-pattern]] (without <code>href</code> attributes, the elements probably won't register as hyperlinks, but anchors). Set <code>title=""</code> to fix empty link behavior for many assistive devices. --[[User:RichHall|RichHall]] 23:31, 22 Oct 2006 (PDT)

==== Test page corrected ====
2006-10-25: This error has been corrected on the [http://allinthehead.com/demo/include.html test page]. Any tests should probably be re-run in light of this.

== Unclear status ==

It's not clear, either from the main Wiki page or [[include-pattern]], whether this is an agreed standard, a draft, or just a proposal. [[User:AndyMabbett|AndyMabbett]] 03:14, 18 Oct 2006 (PDT)

* [[include-pattern]] is not its own proposal, draft, or spec. It is a design pattern, as listed on the [[Main_Page|wiki home page]] that is included in other proposals, drafts. and specs. ''Recommend for adding to the [[include-pattern-faq]].
**And that is not clear, either from the main Wiki page or [[include-pattern]]. [[User:AndyMabbett|AndyMabbett]] 16:40, 18 Oct 2006 (PDT)
***ACCEPTED. Will further clarify relationship between patterns and formats. [[User:Tantek|Tantek]] 16:48, 18 Oct 2006 (PDT)

==Parsing for include-pattern==

''Note: this issue is obsolete. On a [http://rbach.priv.at/Microformats-IRC/2007-01-03#T165528 IRC conversation 2007-01-03], Mike Kaply admitted that he figured this out, which is to apply all includes first into the parse tree before looking for any properties. -Tantek''

''To be more specific, what finally occurred to me is that the object pattern is simply about grabbing nodes from another vcard and using them in this vcard. So the implementor responsibility is just to clone the dom node from the other vcard and replace the object with the corresponding nodes. Works great. (of course I also had to clone the entire vcard since I can't manipulate the DOM like that without changing the page) -mkaply''

In an [http://rbach.priv.at/Microformats-IRC/2007-01-02#T205847 IRC discussion] with [http://www.kaply.com/weblog/ Mike Kaply] (author of the [https://addons.mozilla.org/firefox/4106/ Operator] extension for Firefox) we discussed the difficulty of parsing for an [[include-pattern]] in [[hresume|hResume]]. Mike asks:
<blockquote>I'm really wondering why the <code>object</code> stuff doesn't point back to the entire vCard. I don't understand why the spec has it point to individual items.</blockquote>
The problem was thought to be a weakness in the specification, which doesn't specify what part of the data is in the content that is pointed to by the <code>object</code>.

Currently, to overcome this a parser needs to follow this logic:
::IF I don't find an <code>fn</code>, look for an <code>object</code>. IF there is an <code>object</code>, do a <code>getelementbyid</code> on that <code>ID</code>, but yet there was nothing about that <code>object</code> that said that the content I was looking for in the other card was an <code>fn</code>

Two things may help in overcoming this difficulty:

# Change the spec to have the include-pattern reference the entire vCard, with the intent that any data not found in this vCard use the other vCard
# Include the element of the reference, where the class attribute on <code><object></code> has "include" plus the element that needs to be included. For example:
<pre><nowiki><object
class="include fn" data="#vcard-name">myname</object> </nowiki></pre>

Additionally, I pointed out that using the <code><object></code> element to contain the reference makes Microsoft's Internet Explorer throw an error "Your current security settings prohibit ActiveX controls on this page. As a result, the page may not display correctly." Of course, there is no ActiveX content on an include-pattern.

[[User:Bob Jonkman|Bob Jonkman]] 21:15, 2 Jan 2007 (PST)#

==Concatenating values==

I feel that there should be a way to "include" data from two places, in one microformat property. For instance:

<pre><nowiki>Kidderminster Branch Indoor Meeting</nowiki></pre>
<pre><nowiki>Janaury</nowiki></pre>

and later

<pre><nowiki><object data="#summaryB+#summaryA" class="include"></object></nowiki></pre>

would give a summary of:

:'''January Kidderminster Branch Indoor Meeting'''

It may even be possible to include extra data:

<pre><nowiki>Fred Smith</nowiki></pre>

<pre><nowiki><object data="#summaryA+ with +#summaryC" class="include"></object></nowiki></pre>

to give:

:'''Kidderminster Branch Indoor Meeting with Fred Smith'''

[[User:AndyMabbett|Andy Mabbett]] 14:33, 8 Jan 2007 (PST)

Why not use

<pre><nowiki><object data="#summaryA" class="include"></object> with <object data="#summaryB" class="include"></object></nowiki></pre>

to build

:'''Kidderminster Branch Indoor Meeting with Fred Smith'''

[[User:DerrickPallas|Derrick Pallas]] 11:15, 31 Jan 2007 (PST)

:Neat solution! Can anyone say whether current parsers accept this? [[User:AndyMabbett|Andy Mabbett]] 12:18, 31 Jan 2007 (PST)

:Fully disclosure: My XSLT transformer supports this implicitly because it does include-pattern first, then pulls values. My only question would be what to do with nested @class="value" elements that could result from this. [[User:DerrickPallas|Derrick Pallas]] 12:35, 31 Jan 2007 (PST)

==Related Pages==
{{include-pattern-related-pages}}