include-pattern-feedback: Difference between revisions
(Updated feedback page to address issues. In future, we need to keep tighter separation between something being feedback and an issue itself.) |
|||
Line 3: | Line 3: | ||
Feedback about [[include-pattern]]. | Feedback about [[include-pattern]]. | ||
== Objects and Browser Behavior == | == {{OpenIssue}} Objects and Browser Behavior == | ||
<strong>This is still open: To close it we need to version numbers of the affected browsers to add to the main documentation. The issue itself is how handled by using the hyperlink pattern.</strong> | |||
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.) | 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. | 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. | ||
-- AndyBaio 29 Jun 2006 | -- AndyBaio 29 Jun 2006 | ||
=={{OpenIssue}} Safari 2.x OBJECT element handling== | |||
<strong>This issue needs clarification of the ‘major issues’ referred to, Safari version numbers involved, whether they are still present in later builds of Safari 2, or in builds of Safari 3</strong>. | |||
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]. | 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]. | ||
Line 51: | Line 31: | ||
--[[User:WizardIsHungry|Jon Williams]] 10:21, 7 Feb 2007 (PST) | --[[User:WizardIsHungry|Jon Williams]] 10:21, 7 Feb 2007 (PST) | ||
== Hyperlink Include - issues for keyboard users (including Screen Reader users) == | =={{ClosedIssue}} Hyperlink Include - issues for keyboard users (including Screen Reader users) == | ||
<strong>Issue is now resolved, main documentation requires inner text for hyperlinks, disallows hiding of links with negative margins.</strong> | |||
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). | 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). | ||
Line 59: | Line 41: | ||
-- [[User:PatrickLauke|Patrick H. Lauke]] 28 Apr 2007 | -- [[User:PatrickLauke|Patrick H. Lauke]] 28 Apr 2007 | ||
== Hyperlink Include - Screen Reader Testing == | =={{ClosedIssue}} Hyperlink Include - Screen Reader Testing == | ||
<strong>The documentation has been updated to reflect this research</strong> | |||
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. | 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. | ||
Line 65: | Line 49: | ||
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. | 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 from Yahoo! Accessibility === | === Test Results from Yahoo! Accessibility Stakeholders Group === | ||
Tests by Mike Davies and members of the Yahoo! Accessibility Stakeholders group can be found at [http://yuiblog.com/blog/2008/01/23/empty-links/ Empty Links and Screen Readers]. | Tests by Mike Davies and members of the Yahoo! Accessibility Stakeholders group can be found at [http://yuiblog.com/blog/2008/01/23/empty-links/ Empty Links and Screen Readers]. | ||
Line 84: | Line 68: | ||
* Page has no links | * Page has no links | ||
* 31 dash include | * 31 dash include | ||
Was keyboard access fully tested (see above)? This test is not conclusive, as JAWS 7.0's behavior 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 | Was keyboard access fully tested (see above)? This test is not conclusive, as JAWS 7.0's behavior 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 | ||
Line 90: | Line 73: | ||
The example above has been incorrectly stated, to be honest. Conclusion was just a conclusion for that verbal test, not overall. Therefore, removed "Conclusion" line so it's not misleading! I concur with additional tests are vital (by as many people/softwares/scenarios as possible!). [[User:Phae|Phae]] 04:10, 2 May 2007 (PDT) | The example above has been incorrectly stated, to be honest. Conclusion was just a conclusion for that verbal test, not overall. Therefore, removed "Conclusion" line so it's not misleading! I concur with additional tests are vital (by as many people/softwares/scenarios as possible!). [[User:Phae|Phae]] 04:10, 2 May 2007 (PDT) | ||
== | =={{ClosedIssue}} Proprietary attribute == | ||
<s> | <s> | ||
HTML tidy on the [http://allinthehead.com/demo/include.html test page] gives: | HTML tidy on the [http://allinthehead.com/demo/include.html test page] gives: | ||
Line 106: | Line 89: | ||
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. | 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 == | =={{ClosedIssue}} Unclear status == | ||
<strong>Resolved by explicitly stating that the include-pattern is a design pattern in the introduction, and the documentation itself now makes reference to which specifications the pattern applies to (and that specifications must explicitly cite the include-pattern, that it doesn't apply to everything.</strong> | |||
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) | 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) | ||
Line 114: | Line 99: | ||
***ACCEPTED. Will further clarify relationship between patterns and formats. [[User:Tantek|Tantek]] 16:48, 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== | =={{ClosedIssue}} Parsing for include-pattern== | ||
<strong>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.</strong> -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'' | ''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'' | ||
Line 139: | Line 124: | ||
[[User:Bob Jonkman|Bob Jonkman]] 21:15, 2 Jan 2007 (PST)# | [[User:Bob Jonkman|Bob Jonkman]] 21:15, 2 Jan 2007 (PST)# | ||
==Concatenating values== | =={{ClosedIssue}} Concatenating values== | ||
<strong>This issue proposes a fragment URL structure that is incompatible with hyperlinks, and so cannot be integrated with the current include pattern mechanisms.</strong> | |||
I feel that there should be a way to "include" data from two places, in one microformat property. For instance: | I feel that there should be a way to "include" data from two places, in one microformat property. For instance: | ||
Line 180: | Line 167: | ||
: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) | :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) | ||
=={{ClosedIssue}} Script for client-side processing of include-pattern== | |||
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 | |||
:For clarification, it is true that the spec *does* call for a microformat include to be ignored (content-neutral) when its data isn't being accessed. My Ajax suggestion is valid for those of us extracting microformat data client-side, but feel free to use it from an XHR callback instead of a window load event. Also, it would seem that without adjusting the DOM by cloning the repeated nodes, implementers would have to roll their own smart traversal functions rather than using built-in or well-defined CSS, XPath, E4X, etc. My feedback is that it's usually easier/faster to complete the tree than leave it sparse and memory-efficient, but it would be nice if the spec could leave enough wiggle room for both alternatives. | |||
:-- [[User:RichHall|RichHall]] 12:47, 17 Dec 2007 (PST) | |||
==Related Pages== | ==Related Pages== | ||
{{include-pattern-related-pages}} | {{include-pattern-related-pages}} |
Revision as of 03:23, 12 February 2008
Include Pattern Feedback
Feedback about include-pattern.
open issue! Objects and Browser Behavior
This is still open: To close it we need to version numbers of the affected browsers to add to the main documentation. The issue itself is how handled by using the hyperlink pattern.
Over at Yahoo! Local, we were using the object include pattern for all our 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.
-- AndyBaio 29 Jun 2006
open issue! Safari 2.x OBJECT element handling
This issue needs clarification of the ‘major issues’ referred to, Safari version numbers involved, whether they are still present in later builds of Safari 2, or in builds of Safari 3.
My hResume page seen here caused Safari 2.0 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 WSG mail archive.
It seems that while the object element may be more semantically appropriate it is not may not be usable in lieu of the issues raised in Safari.
--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.
-- 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!
--Jon Williams 10:21, 7 Feb 2007 (PST)
closed issue Hyperlink Include - issues for keyboard users (including Screen Reader users)
Issue is now resolved, main documentation requires inner text for hyperlinks, disallows hiding of links with negative margins.
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.
-- Patrick H. Lauke 28 Apr 2007
closed issue Hyperlink Include - Screen Reader Testing
The documentation has been updated to reflect this research
Some 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 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 from Yahoo! Accessibility Stakeholders Group
Tests by Mike Davies and members of the Yahoo! Accessibility Stakeholders group can be found at Empty Links and Screen Readers.
The conclusion is that the most accessible link is one that contains link text. Different techniques of hiding links, from no link text, through to hiding by CSS can cause an accessibility barrier to screen reader users. Each screen reader presented its user with a different set of problems and barriers.
The article contains tables describing the behaviors of different screen readers in a number of scenarios.
(added by: VinceVeselosky 05:46, 24 Jan 2008 (PST) )
Test Results: JAWS 7.0 with Firefox 1.5/Win
Tested by Frances Berriman 2006-07-21.
Purpose of this test was to ascertain what JAWS 7.0 would verbally announce to a user visiting the test case.
- 31 dash include dash Mozilla Firefox
- Page has no links
- 31 dash include
Was keyboard access fully tested (see above)? This test is not conclusive, as JAWS 7.0's behavior may well differ from other access technology. Further testing with a wider range of readers is strongly recommended. -- Patrick H. Lauke 28 Apr 2007
The example above has been incorrectly stated, to be honest. Conclusion was just a conclusion for that verbal test, not overall. Therefore, removed "Conclusion" line so it's not misleading! I concur with additional tests are vital (by as many people/softwares/scenarios as possible!). Phae 04:10, 2 May 2007 (PDT)
closed issue Proprietary attribute
HTML tidy on the test page gives:
- Warning: <a> proprietary attribute "data"
The W3C validator is similarly unimpressed.
AndyMabbett 14:22, 22 Oct 2006 (PDT)
Use href
To clarify, links on the test page should be changed to use the
href
attribute as described at include-pattern (without href
attributes, the elements probably won't register as hyperlinks, but anchors). Set title=""
to fix empty link behavior for many assistive devices. --RichHall 23:31, 22 Oct 2006 (PDT)
Test page corrected
2006-10-25: This error has been corrected on the test page. Any tests should probably be re-run in light of this.
closed issue Unclear status
Resolved by explicitly stating that the include-pattern is a design pattern in the introduction, and the documentation itself now makes reference to which specifications the pattern applies to (and that specifications must explicitly cite the include-pattern, that it doesn't apply to everything.
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. 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 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. AndyMabbett 16:40, 18 Oct 2006 (PDT)
- ACCEPTED. Will further clarify relationship between patterns and formats. Tantek 16:48, 18 Oct 2006 (PDT)
- And that is not clear, either from the main Wiki page or include-pattern. AndyMabbett 16:40, 18 Oct 2006 (PDT)
closed issue Parsing for include-pattern
Note: this issue is obsolete. On a 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 IRC discussion with Mike Kaply (author of the Operator extension for Firefox) we discussed the difficulty of parsing for an include-pattern in hResume. Mike asks:
I'm really wondering why the
object
stuff doesn't point back to the entire vCard. I don't understand why the spec has it point to individual items.
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 object
.
Currently, to overcome this a parser needs to follow this logic:
- IF I don't find an
fn
, look for anobject
. IF there is anobject
, do agetelementbyid
on thatID
, but yet there was nothing about thatobject
that said that the content I was looking for in the other card was anfn
- IF I don't find an
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
<object>
has "include" plus the element that needs to be included. For example:
<object class="include fn" data="#vcard-name">myname</object>
Additionally, I pointed out that using the <object>
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.
Bob Jonkman 21:15, 2 Jan 2007 (PST)#
closed issue Concatenating values
This issue proposes a fragment URL structure that is incompatible with hyperlinks, and so cannot be integrated with the current include pattern mechanisms.
I feel that there should be a way to "include" data from two places, in one microformat property. For instance:
<span id="summaryA" class="summary">Kidderminster Branch Indoor Meeting</span>
<span id="summaryB>Janaury</span>
and later
<object data="#summaryB+#summaryA" class="include"></object>
would give a summary of:
- January Kidderminster Branch Indoor Meeting
It may even be possible to include extra data:
<span id="summaryC>Fred Smith</span>
<object data="#summaryA+ with +#summaryC" class="include"></object>
to give:
- Kidderminster Branch Indoor Meeting with Fred Smith
Andy Mabbett 14:33, 8 Jan 2007 (PST)
Why not use
<span class="value"><object data="#summaryA" class="include"></object> with <object data="#summaryB" class="include"></object></span>
to build
- Kidderminster Branch Indoor Meeting with Fred Smith
Derrick Pallas 11:15, 31 Jan 2007 (PST)
- Neat solution! Can anyone say whether current parsers accept this? 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. Derrick Pallas 12:35, 31 Jan 2007 (PST)
closed issue Script for client-side processing of include-pattern
Can you use the hyperlink option with DHMTL/Ajax to perform replacements in advanced browsers? (Simon Willison's getElementsBySelector()
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 ); } })
--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" of 2007-01-03 or remove the IRC quote completely.
-- User:JiriKopsa 18 Mar 2007
- For clarification, it is true that the spec *does* call for a microformat include to be ignored (content-neutral) when its data isn't being accessed. My Ajax suggestion is valid for those of us extracting microformat data client-side, but feel free to use it from an XHR callback instead of a window load event. Also, it would seem that without adjusting the DOM by cloning the repeated nodes, implementers would have to roll their own smart traversal functions rather than using built-in or well-defined CSS, XPath, E4X, etc. My feedback is that it's usually easier/faster to complete the tree than leave it sparse and memory-efficient, but it would be nice if the spec could leave enough wiggle room for both alternatives.
- -- RichHall 12:47, 17 Dec 2007 (PST)
Related Pages
- the include pattern
- include-pattern examples in the wild - an on-going list of websites which use the include pattern.
- include-pattern FAQ - if you have any questions about the include pattern, check here, and if you don't find answers, add your questions!
- include-pattern feedback- general feedback (as opposed to specific issues).
- include-pattern issues - specific issues with the include pattern.
- include-pattern strawman - alternative proposals