hcard-faq - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:25:56Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:25, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~ hCard FAQ ~~</entry-title>~~		{{DISPLAYTITLE: hCard FAQ }}

	This documents frequently asked questions and answers (FAQs) about [[hcard\|hCard]]. For FAQs regarding microformats in general, or across microformats, see the [[faq\|microformats FAQ]].		This documents frequently asked questions and answers (FAQs) about [[hcard\|hCard]]. For FAQs regarding microformats in general, or across microformats, see the [[faq\|microformats FAQ]].

Tantek: /* Can you mix properties and the root class name */ wikilink

2015-03-15T18:32:50Z

Can you mix properties and the root class name: wikilink

← Older revision		Revision as of 18:32, 15 March 2015
Line 294:		Line 294:
	Note the <code><span class="location vcard"></code> which specifies that the location of the outer [[hCalendar]] event is an entire [[hCard]] nested inside.		Note the <code><span class="location vcard"></code> which specifies that the location of the outer [[hCalendar]] event is an entire [[hCard]] nested inside.

	See also: ~~http://microformats.org/wiki/~~faq#Can_you_mix_properties_and_the_root_class_name		See also: [[faq#Can_you_mix_properties_and_the_root_class_name]]

	=== Can you mix a property and its sub-properties ===		=== Can you mix a property and its sub-properties ===

Tantek: /* Can you mix properties and the root class name */ see also the general FAQ answer to the question

2015-03-15T18:31:45Z

Can you mix properties and the root class name: see also the general FAQ answer to the question

← Older revision		Revision as of 18:31, 15 March 2015
Line 293:		Line 293:

	Note the <code><span class="location vcard"></code> which specifies that the location of the outer [[hCalendar]] event is an entire [[hCard]] nested inside.		Note the <code><span class="location vcard"></code> which specifies that the location of the outer [[hCalendar]] event is an entire [[hCard]] nested inside.

			See also: http://microformats.org/wiki/faq#Can_you_mix_properties_and_the_root_class_name

	=== Can you mix a property and its sub-properties ===		=== Can you mix a property and its sub-properties ===

Tantek: /* Can you mix properties and the root class name */ give correct version from incorrect question, and add example of when it works for nesting microformats

2013-04-01T22:08:20Z

Can you mix properties and the root class name: give correct version from incorrect question, and add example of when it works for nesting microformats

@@ Line 275: / Line 275: @@
 * WRONG: <code>&lt;span class="vcard fn"></code>
 * RIGHT: <code>&lt;span class="vcard">&lt;span class="fn"></code>
 === Can you mix a property and its sub-properties ===

Tantek: /* Can you mix properties and the root class name */ give correct version from incorrect question

2013-04-01T21:59:16Z

Can you mix properties and the root class name: give correct version from incorrect question

← Older revision		Revision as of 21:59, 1 April 2013
Line 264:		Line 264:

	=== Can you mix properties and the root class name ===		=== Can you mix properties and the root class name ===
			''<span id="nesting-properties">Can you put properties on the same element as the root class for a microformat? E.g. span class="vcard fn"?</span>''
			<!--
	;shortlink		;shortlink
	:http://tr.im/hcfnm		:http://tr.im/hcfnm
	~~''<span id="nesting~~-~~properties">Can you put properties on the same element as the root class for a microformat? E.g. class="vcard fn"?</span~~>''		-->
	* No, for several reasons:		* No, for several reasons:
	** It breaks the simple contextual CSS selector rule for finding and styling property values: .rootname .propertyname which will make it more difficult to write scoped CSS for the properties. For more on why this is important see the [[faq#Class_interactions\|microformats FAQ regarding class interactions]].		** It breaks the simple contextual CSS selector rule for finding and styling property values: .rootname .propertyname which will make it more difficult to write scoped CSS for the properties. For more on why this is important see the [[faq#Class_interactions\|microformats FAQ regarding class interactions]].
	** It will result in more confusion for parsers which may be parsing nested microformats.		** It will result in more confusion for parsers which may be parsing nested microformats.
			In this case in the question, you need two elements:
			* WRONG: <code><span class="vcard fn"></code>
			* RIGHT: <code><span class="vcard"><span class="fn"></code>

	=== Can you mix a property and its sub-properties ===		=== Can you mix a property and its sub-properties ===

Tantek: /* How is gender represented */ noted p-sex and p-gender-identity as part of h-card, removed extra MSDN/Google links, move old gender brainstorming to gender-brainstorming accordingly

2013-03-04T04:52:38Z

How is gender represented: noted p-sex and p-gender-identity as part of h-card, removed extra MSDN/Google links, move old gender brainstorming to gender-brainstorming accordingly

← Older revision		Revision as of 04:52, 4 March 2013
Line 151:		Line 151:
	=== How is gender represented ===		=== How is gender represented ===
	''How do you represent gender in hCard?''		''How do you represent gender in hCard?''
	* There is no GENDER property in [http://www.ietf.org/rfc/rfc2426.txt ~~vCard~~ RFC2426]. [[hcard\|hCard]] is following the schema from vCard for interoperability reasons. It is possible to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female:
			If you're using [[microformats2]]:
			* Use [[h-card]] and the properties <code>p-sex</code> and <code>p-gender-identity</code>.

			If you're using [[hCard]]:
			* There is no GENDER property in [http://www.ietf.org/rfc/rfc2426.txt vCard3 RFC2426]. [[hcard\|hCard]] is following the schema from vCard for interoperability reasons.

			It is possible to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female:
	<source lang=html4strict>		<source lang=html4strict>
	<span class="honorific-prefix">Mr.</span>		<span class="honorific-prefix">Mr.</span>
Line 162:		Line 169:
	This approach does have the limitation that "Mr." and "Ms." (or "Miss"/ "Mrs.") may conflict with a higher-ranking, gender-neutral honorific, such as "Dr." or "Rev." for the person, as it is unusual to refer to someone as "Mr. Dr." or "Mrs. Rev." for example. See [[hcard-issues]].		This approach does have the limitation that "Mr." and "Ms." (or "Miss"/ "Mrs.") may conflict with a higher-ranking, gender-neutral honorific, such as "Dr." or "Rev." for the person, as it is unusual to refer to someone as "Mr. Dr." or "Mrs. Rev." for example. See [[hcard-issues]].

	~~Note that there is~~ also a [~~http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/vcard_name.asp page on MSDN that mentions vCard and "gender"]. Not sure what to make of that. Note also~~ [~~http://www.google.com/search?q=vCard.Gender Google search for "vCard.Gender"].~~		See also the [[gender]] research page.

	~~Gender could be represented with a [[genealogy-formats\|genealogical microformat]], but that seems like overkill.~~

	~~Instead, you could use tags/categories to tag people's hCards with their~~ gender~~, "male", "female", or any other tag you feel is appropriate. See [http://en.wikipedia.org/wiki/Gender_identity gender identity] for more on the topic.~~

	~~See also [[vcard-suggestions#Gender~~]].

	=== Can a hCard contain extra elements ===		=== Can a hCard contain extra elements ===

Tantek: add How do you mark up city state and zip

2013-03-04T04:36:35Z

add How do you mark up city state and zip

@@ Line 135: / Line 135: @@
 * e.g.
 <source lang=html4strict><abbr class="honorific-suffix" title="Junior">Jr.</abbr></source>
 === How is gender represented ===

Tantek: /* How do you mark up a first or last name */ examples

2013-03-04T04:17:34Z

How do you mark up a first or last name: examples

← Older revision		Revision as of 04:17, 4 March 2013
Line 123:		Line 123:
	* "first" is a presentational culture-specific (non-l10n, non-18n) description (as is "last").		* "first" is a presentational culture-specific (non-l10n, non-18n) description (as is "last").
	* Hence vCard and hCard have <code>given-name</code> (and <code>family-name</code>), and [[h-card]] has <code>p-given-name</code> (and <code>p-family-name</code>).		* Hence vCard and hCard have <code>given-name</code> (and <code>family-name</code>), and [[h-card]] has <code>p-given-name</code> (and <code>p-family-name</code>).

			See [[hcard-authoring#The_Importance_of_Names\|hCard authoring: Importance of Names]] for examples.

	=== How do you mark up a middle name or initial ===		=== How do you mark up a middle name or initial ===

Tantek: /* What does FN stand for */ add How do you mark up a first or last name

2013-03-04T04:11:17Z

What does FN stand for: add How do you mark up a first or last name

← Older revision		Revision as of 04:11, 4 March 2013
Line 117:		Line 117:
	<blockquote>Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents.</blockquote>		<blockquote>Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents.</blockquote>
	* The reasoning behind this seems to be that, while N gives us a structured name, FN gives us the human-readable, formatted name which is assembled from its structured parts in a culturally dependant way.		* The reasoning behind this seems to be that, while N gives us a structured name, FN gives us the human-readable, formatted name which is assembled from its structured parts in a culturally dependant way.

			=== How do you mark up a first or last name ===
			''I don't see anything for first/last names.''

			* "first" is a presentational culture-specific (non-l10n, non-18n) description (as is "last").
			* Hence vCard and hCard have <code>given-name</code> (and <code>family-name</code>), and [[h-card]] has <code>p-given-name</code> (and <code>p-family-name</code>).

	=== How do you mark up a middle name or initial ===		=== How do you mark up a middle name or initial ===

Tantek: simplify unstructured location FAQ, label is now multivalued (by way of being a param on adr), and no one bothered to figure out / implement unstructured adr parsing, so drop all that.

2012-07-05T20:53:26Z

simplify unstructured location FAQ, label is now multivalued (by way of being a param on adr), and no one bothered to figure out / implement unstructured adr parsing, so drop all that.

← Older revision		Revision as of 20:53, 5 July 2012
Line 439:		Line 439:
	''If I have a location field which is unstructured, how do I mark that up? I might have a user typing "San Francisco" or "San Francisco, CA" or "USA", etc.''		''If I have a location field which is unstructured, how do I mark that up? I might have a user typing "San Francisco" or "San Francisco, CA" or "USA", etc.''

	* ~~Short answer:~~ use the "label" property ~~and also the "adr" property without subproperties (for now)~~. E.g.		* use the "label" property. E.g.
	<source lang=html4strict>		<source lang=html4strict>
	<span class="label ~~adr~~">San Francisco, CA</span>		<span class="label">San Francisco, CA</span>
	</source>		</source>

	* Longer:
	# The "label" property works well to markup an unstructured location, but keep in mind that only one can be provided (in practice, we have yet to find a service that publishes multiple* unstructured addresses for a person or organization - if they're going to go to the trouble of publishing multiple addresses, they usually also do the additional minimal work of structuring them).
	# Using the "adr" property (without any subproperties) at least indicates the semantic that there may be* address components in the data, and indicating even that semantic is better than indicating no semantic. While current hCard parsers will likely not extract any adr information from such markup (though they will get the unstructured "label", which is better than nothing), there is some [[hcard-brainstorming\|brainstorming]] going on regarding how to possibly try to extract structure from an unstructured "adr", and thus future parsers may be able to make more use of such markup.

	=== Partial Dates ''or'' A Gentleman Never Asks ===		=== Partial Dates ''or'' A Gentleman Never Asks ===