hcard-feedback: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
No edit summary
(resolved a few remaining issues that happened to be on the hCard feedback page)
 
(11 intermediate revisions by 6 users not shown)
Line 1: Line 1:
<h1> hCard feedback </h1>
<h1> hCard feedback </h1>
 
{{TOC-right}}
General feedback about [[hcard|hCard]] may be provided here, and the editor(s) will do their best to try to accomodate such feedback.  The more specific the feedback the better chance it will be handled.  For specific issues with the spec (as opposed to general problems and feedback), please use the [[hcard-issues|hCard issues]] page.
General feedback about [[hcard|hCard]] may be provided here, and the editor(s) will do their best to try to accomodate such feedback.  The more specific the feedback the better chance it will be handled.  For specific issues with the spec (as opposed to general problems and feedback), please use the [[hcard-issues|hCard issues]] page.


'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.
'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] and the [[hcard-issues-resolved|hCard resolved issues]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.
 
Feedback may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Use the provided template and add your feedback to the end of the Feedback section.  Write your feedback well. — [http://tantek.com/log/ Tantek]


__TOC__
Feedback may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Use the provided template and add your feedback to the end of the Feedback section.  Write your feedback well. — [[User:Tantek|Tantek]]


== Feedback ==
== Feedback ==
Please add feedback here, in datetime sequential order:


* 2006-11-15 raised by [http://lachy.id.au/ Lachy] in [irc://freenode/whatwg #whatwg] (an IRC channel on [http://freenode.net/ freenode] about [http://whatwg.org/ The WHATWG]).
=== 2009 ===
*# ''I think the whole [[hcard|hCard]] specification needs to be restructured.''
* All hCard feedback as of 2009-06-04 has been resolved, and resolved issues have been moved to the [[hcard-issues-resolved|hCard resolved issues]] page. [[User:Tantek|Tantek]] 02:37, 5 June 2009 (UTC)
*# ''It's incredibly difficult to work out what each class name means and how to use them properly.''
 
 
* 2006-11-15 raised by hsivonen in #whatwg.
*# ''Without knowing iCalendar or vCard, it is totally non-obvious to see what hCards or hCalendars would be conforming. The normative part is extremely short and doesn't seem to establish clear enough a mapping between the microformats and the RFCs.''
*#* This (and Lachy's 2nd feedback point above) should be addressed by clarifying the mapping with better use of the [[hcard-profile|hCard profile]] which does clearly map the class names to vCard properties and the sections of the vCard specification that defines them. - Tantek
 
 
* 2006-11-15 raised by Hixie in #whatwg (and agreed by [http://lachy.id.au/ Lachy] and hsivonen).
*# ''The [[hcard|hCard]] spec basically reads as a brainstorm, not a normative spec.''
 
 
* 2006-11-17 raised by [http://lachy.id.au/ Lachlan Hunt].
*# Semantic XHTML Design Princples: This section should go.  Guidelines for how to write a microformats specification do not belong in the spec itself.
*# Format - More Semantic Equivalents: Explanations of how to use each property correctly should be given with each and every property, not just list a few at the top before the properties have even been defined.
*# Singlular vs. Plural: It is unclear what is meant by singular vs. plural properties.  Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once.  It doesn't make sense because the property itself isn't a plural.  Besides, this section should go.  The number of times a property can be used should be listed with each individual property description.
*#  Plural Properties Singularized: What the...?  After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element.  Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup.  It should also use RFC 2119 terminology that describes exactly what a UA has to do.  Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
*# Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it.  For every single property, all of the following information should be listed
*#* Property name
*#* Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
*#* Definition. (e.g. either copy the definition directly from vCard or provide a short summary, and also a link to the relevant vCard section.  Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
*#* Usage
*#** Contexts in which this property may be used
*#** Content model (e.g. list of sub properties, expected elements, text, or whatever)
*#** Syntax of the value (i.e. plain text, number, URI, etc.)
*#** Elements this property may be used on
*#* How to interpret the value (may link to relevant section in Conformance Requirements)
**I second all of the above. [[User:AndyMabbett|Andy Mabbett]] 07:15, 17 Nov 2006 (PST)
 
 
 
* 2007-04-21 raised by [http://www.mnot.net/ Mark Nottingham].
Pages often list many addresses in the same locality, but hCard (and adr) are currently structured so that you have to repeat the entire global context for each address. For example,
 
<pre><nowiki>
<h2>Pizza Shops in Burlingame, California</h2>
<ul>
<li>Round Table - 231 Burlingame Avenue</li>
<li>Village Host - 303 Broadway</li>
<li>Pizza Hut - 43423 El Camino Real</li>
</ul>
</nowiki></pre>
 
As specified, there'd be a lot of repeated information here.
 
However, if adr allowed use of locality, region, postcode and country as ancestors of the more specific address tags, it would save a lot of bits -- and help adoption of these microformats in this kind of case (which is quite common).
 


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


== Related Pages ==
== Related Pages ==
{{hcard-related-pages}}
{{hcard-related-pages}}

Latest revision as of 02:37, 5 June 2009

hCard feedback

General feedback about hCard may be provided here, and the editor(s) will do their best to try to accomodate such feedback. The more specific the feedback the better chance it will be handled. For specific issues with the spec (as opposed to general problems and feedback), please use the hCard issues page.

IMPORTANT: Please read the hCard FAQ and the hCard resolved issues before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Feedback may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Use the provided template and add your feedback to the end of the Feedback section. Write your feedback well. — Tantek

Feedback

Please add feedback here, in datetime sequential order:

2009

  • All hCard feedback as of 2009-06-04 has been resolved, and resolved issues have been moved to the hCard resolved issues page. Tantek 02:37, 5 June 2009 (UTC)

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>

Related Pages

The hCard specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.

Retrieved from "http://microformats.org/wiki/index.php?title=hcard-feedback&oldid=38988"