hlisting-issues

hListing Issues

These are externally raised issues about hListing with broadly varying degrees of merit. Thus some issues are 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 (or in this case create ;) ) the hListing 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.

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.

Issues

• open issue! 2007-07-21 raised by User:RobManson
  1. The only discussion I could find relating to payment method for hListing was in the tag section. Wouldn't rel-payment be a natural fit with hListing?

• open issue! 2008-04-07 raised by User:Eazytiger
  1. When hListing is used for eCommerce products, is there any provision for product variations (eg. sizes) that will affect the price? I'm not aware of a precedent for variations in another microformat.

• open issue! 2008-08-26 raised by TobyInk
  1. The example given in the spec includes an invalid hCard. (Missing fn.)

• open issue! 2009-03-10 raised by JayMyers
  1. Per the discussions raised in the hProduct issues list, are there any provisions for providing transactional details like "shipping" or "buy/payment" attributes?

Template

Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.

<div class="hentry">
{{OpenIssue}} 
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>