View source

You do not have permission to edit pages, for the following reason:
The action you have requested is limited to users in the group Users.
You can view and copy the source of this page:
''Cette page a démarré sur [[microformats2]]''
<entry-title>microformats 2</entry-title>

Bienvenue sur la page d'accueil des microformats 2. 

== Résumé ==
Microformats 2 améliore la facilité d'utilisation et d'exécution <em>tant</em> pour les auteurs (éditeurs) que les développeurs ([[microformats2-parsing-fr|parseurs]]), avec les simplifications suivantes : 

# '''préfixes pour les noms de classes''' utilisés pour les microformats, ceux qui démarrent avec 'h-' 'p-' 'u-' 'dt-', 'e-' = '''syntaxe indépendante des vocabulaires''' qui peut ensuite être développée séparément.
#* 'h-*' pour les noms de classes racine, par ex. 'h-card'
#* 'p-*' pour des propriétés simples (texte), par ex. 'p-name'
#* 'u-*' pour les propriétés d'URL, par ex. 'u-photo'
#* 'dt-*' pour les propriétés de datetime, par ex. 'dt-bday'
#* 'e-*' pour les propriétés de marquage embarqué, par ex.'e-note'. Voir [[microformats2-fr#conventions de dénomination pour analyse générique|conventions de nommage du préfixe]] pour en savoir plus

# '''ensembles plats des propriétés optionnelles''' pour tous les microformats (la data hiérarchique utilise des microformats imbriqués). Les propriétés sont toutes optionnelles et potentiellement à plusieurs valeurs (les applications ayant besoin d'une sémantique unique peuvent utiliser la première instance)
# '''marquage unique de classe pour les usages communs''' - pour les modèles de marquage simple, un seul nom de classe racine peut sous-entendre quelques propriétés génériques - name, url, photo, par exemple : 

=== exemples simples de microformats ===
Voici quelques exemples simples de microformats 2 qui démontrent la plupart des changements, avec le [[JSON-fr|JSON]] canonique : 
* Simple référence à une personne :
<source lang=html4strict>
<span class="h-card">Frances Berriman</span>
</source>

JSON analysé :
<source lang=javascript>
{
"items": [{  
"type": ["h-card"],
"properties": {
"name": ["Frances Berriman"] 
}
}]
}
</source>

----

* Simple référence à une personne hyperliée
<source lang=html4strict>
<a class="h-card" href="http://benward.me">Ben Ward</a>
</source>

JSON analysé :
<source lang=javascript>
{
"items": [{  
"type": ["h-card"],
"properties": {
"name": ["Ben Ward"],
"url": ["http://benward.me"]
}
}]
}
</source>

----

* Simple image de personne hyperliée
<source lang=html4strict>
<a class="h-card" href="http://rohit.khare.org/">
<img alt="Rohit Khare"
src="https://s3.amazonaws.com/twitter_production/profile_images/53307499/180px-Rohit-sq_bigger.jpg" />
</a>
</source>

JSON analysé :
<source lang=javascript>
[{ 
"type": ["h-card"],
"properties": {
"name": ["Rohit Khare"],
"url": ["http://rohit.khare.org"],
"photo": ["https://s3.amazonaws.com/twitter_production/profile_images/53307499/180px-Rohit-sq_bigger.jpg"]
}
}]
</source>

* Cas supplémentaires simples dans [[microformats-2-implied-properties]].

<source lang=html4strict>
<div class="h-card">
<img class="u-photo" alt="photo de Mitchell"
src="https://webfwd.org/content/about-experts/300.mitchellbaker/mentor_mbaker.jpg"/>
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/" 
>Mitchell Baker</a>
(<a class="u-url" 
href="https://twitter.com/MitchellBaker"
>@MitchellBaker</a>)
<span class="p-org">Mozilla Foundation</span>
<p class="p-note">
Mitchell is responsible for setting the direction and scope of the Mozilla Foundation and its activities.
</p>
<span class="p-category">Strategy</span>
<span class="p-category">Leadership</span>
</div>
</source>

JSON Parsé :
<source lang=javascript>
{ 
"items": [{ 
"type": ["h-card"],
"properties": {
"photo": ["https://webfwd.org/content/about-experts/300.mitchellbaker/mentor_mbaker.jpg"],
"name": ["Mitchell Baker"],
"url": [
"http://blog.lizardwrangler.com/",
"https://twitter.com/MitchellBaker"
],
"org": ["Mozilla Foundation"],
"note": ["Mitchell is responsible for setting the direction and scope of the Mozilla Foundation and its activities."]
"category": [
"Strategy",
"Leadership"
]
}
}]
}
</source>

----

Notes : 
# Le <code>"type"</code> JSON utilise la totalité du nom de classe racine du microformat (par ex. <code>"h-card"</code>) pour une identification cohérente.
# toutes les propriétés sont optionnelles et syntaxiquement plurielles avec des valeurs analysées fournies dans l'ordre du document ; les microformats spécifiques (et applications en découlant) peuvent mettre en oeuvre une sémantique spécifique/singulière pour la première valeur d'une propriété.
# les propriétés pourraient être explicitement liées en tant qu'URIs en utilisant [[rel-profile-fr|rel-profile]], la proposition d'attribut [[html5-profile]], ou peut-être à la place un attribut 'vocab'  (peut-être plus intuitif que le terme surchargé 'profile').

== vocabulaires v2 ==
Statut : '''<span id="draft_v2_vocabularies">draft</span>'''. SVP critique et feedback bienvenus sur [[irc-fr|IRC]].

=== h-adr ===
nom de classe racine : '''<code id="adr">h-adr</code>'''<br/>
profile/itemtype : <nowiki>http://microformats.org/profile/h-adr</nowiki>

propriétés :
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>'''
* '''<code>p-street-address</code>'''
* '''<code>p-locality</code>'''
* '''<code>p-region</code>'''
* '''<code>p-postal-code</code>'''
* '''<code>p-country-name</code>'''
* '''<code>p-label</code>''' - nouveau dans [[vCard4]] ([[RFC6350]])
* '''<code>p-geo</code>''' (ou '''<code>u-geo</code>''' avec un RFC 5870 geo: URL) - nouveau dans [[vCard4]] ([[RFC6350]])
* '''<code>p-latitude</code>''' - nouveau dans [[vCard4]] ([[RFC6350]] à partir de RFC 5870)
* '''<code>p-longitude</code>''' - nouveau dans [[vCard4]] ([[RFC6350]] à partir de RFC 5870)
* '''<code>p-altitude</code>''' - nouveau dans [[vCard4]] ([[RFC6350]] à partir de RFC 5870)

Pour une rétro-compatibilité, les parseurs de microformats 2 DEVRAIENT détecter le nom de classe racine et les noms de propriétés suivants. Un parseur microformats 2 peut utiliser les [[parsers-fr|parseurs]] microformats existants pour extraire ces propriétés. Si un "h-adr" est trouvé, ne pas chercher un "adr" sur le même élément.
nom de classe racine compatible :

* <code>adr</code>
propriétés : (parsée comme '''p-''' plein texte à moins qu'autre chose ne soit spécifié)
* <code>post-office-box</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>


=== h-card ===
nom de classe racine : '''<code>h-card</code>'''<br/>
profile/itemtype : <nowiki>http://microformats.org/profile/h-card</nowiki>

propriétés :
* '''<code>p-name</code>''' 
* '''<code>p-honorific-prefix</code>'''
* '''<code>p-given-name</code>'''
* '''<code>p-additional-name</code>'''
* '''<code>p-family-name</code>'''
* '''<code>p-sort-string</code>'''
* '''<code>p-honorific-suffix</code>'''
* '''<code>p-nickname</code>'''
* '''<code>u-email</code>'''
* '''<code>u-logo</code>'''
* '''<code>u-photo</code>'''
* '''<code>u-url</code>'''
* '''<code>u-uid</code>'''
* '''<code>p-category</code>'''
* '''<code>p-adr</code>'''
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>'''
* '''<code>p-street-address</code>'''
* '''<code>p-locality</code>'''
* '''<code>p-region</code>'''
* '''<code>p-postal-code</code>'''
* '''<code>p-country-name</code>'''
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' ou '''<code>u-geo</code>''' avec un RFC 5870 geo : URL, nouveau dans [[vCard4]] ([[RFC6350]])
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* '''<code>p-altitude</code>''' - nouveau dans [[vCard4]] ([[RFC6350]] à partir de RFC 5870)
* '''<code>p-tel</code>'''
* '''<code>p-note</code>'''
* '''<code>dt-bday</code>'''
* '''<code>p-org</code>'''
* '''<code>u-impp</code>''' per RFC 4770, new in [[vCard4]] ([[RFC6350]])
* '''<code>p-sex</code>''' nouveau dans [[vCard4]] ([[RFC6350]])
* '''<code>p-gender-identity</code>''' nouveau dans [[vCard4]] ([[RFC6350]])
* '''<code>dt-anniversary</code>''' nouveau dans [[vCard4]] ([[RFC6350]])
* ...

Propriétés réservées : (propriétés pas beaucoup utilisées (si ce n'est pas du tout) en pratique)
* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>'''
* '''<code>dt-rev</code>'''


Pour une rétro-compatibilité, les parseurs de microformats 2 DEVRAIENT détecter le nom de classe racine et les noms de propriétés. Un parseur microformats 2 peut utiliser les [[parsers-fr|parseurs]] microformats existants pour extraire ces propriétés. 
Si une "h-card" est trouvée, ne pas chercher une "vcard" sur le même élément.
nom de classe racine compatible : '''<code id="vcard">vcard</code>'''<br/>
propriétés : (parsés comme '''p-''' plein texte à moins qu'autre chose ne soit spécifié)
* <code>fn</code> - parser comme '''<code>p-name</code>'''
* <code>honorific-prefix</code>
* <code>given-name</code>
* <code>additional-name</code>
* <code>family-name</code>
* <code>honorific-suffix</code>
* <code>nickname</code>
* <code>email</code> - parser comme '''u-'''
* <code>logo</code> - parser comme '''u-'''
* <code>photo</code> - parser comme '''u-'''
* <code>url</code> - parser comme '''u-'''
* <code>uid</code> - parser comme '''u-'''
* <code>category</code>
* <code>adr</code> - parser comme '''<code>p-adr h-adr</code>''' incluant la classe racine compat <code>adr</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>
* <code>label</code>
* <code>geo</code> - parser sous '''<code>p-geo h-geo</code>''' incluant la classe racine compat <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parser comme '''dt-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* ...


Réservé : (les propriétés pour rétro-compatibilité que les parseurs <em>peuvent</em> implémenter, s'ils le font, ils <em>doivent</em> 
l'implémenter de cette façon : 
* <code>tz</code>
* <code>rev</code> - parser comme '''dt-'''
...

Note : L'usage de 'value' dans 'tel' devrait être automatiquement géré par le support du  [[value-class-pattern-fr|modèle-classe-value]]. Et à cette heure, la sous-propriété 'type' de 'tel' est abandonnée/ignorée. S'il y a un besoin documenté démontré pour des types de tel supplémentaires (par ex. fax), nous pouvons introduire si besoin de nouvelles propriétés plates (par ex. p-tel-fax).

=== h-entry ===
nom de classe racine : '''<code>h-entry</code>'''<br/>
profile/itemtype : <nowiki>http://microformats.org/profile/h-entry</nowiki>

propriétés :
* '''<code>p-name</code>''' (précédemment p-entry-title, voir problématiques)
* '''<code>p-summary</code>'''  (précédemment p-entry-summary, voir problématiques)
* '''<code>e-content</code>''' (précédemment e-entry-content, voir problématiques)
* '''<code>dt-published</code>'''
* '''<code>dt-updated</code>'''
* '''<code>p-author</code>'''
* '''<code>p-category</code>'''
* '''<code>u-url</code>'''
* '''<code>u-uid</code>'''
* '''<code>p-geo</code>'''
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''

Ceci est une mise à jour de [[hatom-fr|hAtom]]

Brainstorming :

Les propriétés suivantes sont des ajouts proposés à h-entry au-dessus de ce quehAtom (ou Atom) 
fournit, basé sur différentes conventions de marquage existant de prévisualisation de lien :
* '''<code>u-photo</code>'''
* '''<code>u-audio</code>''' - envisager des règles spéciales d'analyse u- pour <code>&lt;audio></code>
* '''<code>u-video</code>''' - envisager des règles spéciales d'analyse u- pour <code>&lt;video></code>
* '''<code>u-in-reply-to</code>''' - pour les liens vers les autres posts auxquels ce post est une réponse à (commentaire, etc.)

Rétro-compatibilité : 

(*)les implémentations spécifiques-hAtom qui exécutent des affichages ou traductions personnalisées (par ex. vers Atom XML) <em>devraient</em> préférer <code>p-name</code> à <code>p-entry-title</code>, et utiliser le(s) valeur(s) <code>p-entry-title</code> value(s) 
comme un recour s'il n'y a pas de <code>p-name</code>.
Pour une rétro-compatibilité hAtom, les parseurs de microformats 2 DEVRAIENT détecter le nom de classe racine et les noms de propriétés. Un parseur microformats 2 peut utiliser les [[parsers-fr|parseurs]] microformats existants pour extraire ces propriétés. Si un "h-entry" est trouvé, ne pas chercher un "hentry" sur le même élément.

nom de classe racine compatible : <code id="hentry">hentry</code><br/>
propriétés : (parsés comme '''p-''' plein texte à moins qu'autre chose ne soit spécifié)
* <code>entry-title</code> - parser sous '''<code>p-name</code>'''
* <code>entry-summary</code>
* <code>entry-content</code> - parser sous '''e-'''
* <code>published</code> - parser sous '''dt-'''
* <code>updated</code> - parser sous '''dt-'''
* <code>author</code> - incluant la racine compatible <code>vcard</code> en l'absence de <code>h-card</code>
* <code>category</code>
* <code>geo</code> - parser sous '''<code>p-geo h-geo</code>''' incluant la racine compat <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* ...


<span id="h-entry-faq">FAQ:</span>
<div class="discussion">
* '''Quel est le <code>p-name</code> d'une [http://indiewebcamp.com/note-fr note] ?'''
** Quelques options, de la plus simple à la plus détaillée.
*** '''le même que la propriété p-content/e-content'''.
*** '''le même que l'élément <code>title</code>''' sur la page permalien du post. Au moment de publier une note sur sa propre page post permalien, les contenus de la note sont probablement abrégés pour le titre de la page. La même abréviation peut être utilisée pour le p-name.
*** '''première phrase de la propriété p-content/e-content'''. Ce peut être mieux pour les objectifs de [http://indiewebcamp.com/syndication-fr syndication] et de [[link-preview-fr|prévisualisation-de-lien]] pour fournir juste la première phrase de la note comme le <code>p-name</code>. De la même façon, si seulement une portion du contenu est syndiquée vers d'autres sites, cette portion peut être marquée comme le <code>p-summary</code>.
* ...
</div>

Problématiques résolues 
* 2012-245 Résolu. Voir [http://krijnhoetmer.nl/irc-logs/microformats/20120830#l-120 2012-243 discussion/consensus IRC] pour :
** Utiliser '''<code>p-summary</code> au lieu de <code>p-entry-summary</code>'''. La sémantique historique de "entry-summary" n'est pas différente de "summary" dans tout sens signifiant (ou discernable). Réduire les deux simplifiera plus encore les vocabulaires généraux de microformats2. En microformats2, entry-summary n'existe plus.
** utiliser '''<code>e-content</code> au lieu de <code>e-entry-content</code>'''. Même objectif et avantage. En microformats2, entry-content n'existe plus.
** '''laisser tomber <code>p-entry-title</code>'''. Non nécessaire et sous-résumé par "p-name". Devrait envisager de migrer vers une rétro-compatibilité seulement si les cas sont présentés - des usages connus de publication sont attendus pour être mis à jour sous peu.

=== h-event ===
nom de classe racine : '''<code>h-event</code>'''(*)
profile/itemtype : <nowiki>http://microformats.org/profile/h-event</nowiki>

propriétés :
* '''<code>p-name</code>'''
* '''<code>p-summary</code>'''(*)
* '''<code>dt-start</code>'''
* '''<code>dt-end</code>'''
* '''<code>dt-duration</code>'''
* '''<code>p-description</code>'''
* '''<code>u-url</code>'''
* '''<code>p-category</code>'''
* '''<code>p-location</code>'''
* '''<code>p-geo</code>'''
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* ...

Ceci est une mise à jour de [[hcalendar-fr|hCalendar]]

(*)les implémentations spécifiques hCalendar qui exécutent des affichages ou traductions (par ex. vers iCalendar .ics) {{should-fr}} préférer <code>p-name</code> sur <code>p-summary</code>, et utiliser la(es) valeur(s) <code>p-summary</code> 
comme recours s'il n'a pas de <code>p-name</code>.

Pour une rétro-compatibilité, les parseurs de microformats 2 DEVRAIENT détecter le nom de classe racine et les noms de propriétés. Un parseur microformats 2 peut utiliser les [[parsers-fr|parseurs]] microformats existants pour extraire ces propriétés. Si un "h-event" est trouvé, ne pas chercher un "vevent" sur le même élément.

nom de classe racine compatible : <code id="vevent">vevent</code>
propriétés : (parser comme '''p-''' plein texte à moins qu'autre chose ne soit spécifié)
* <code>summary</code> - parser comme '''<code>p-name</code>'''
* <code>dtstart</code> - parser comme '''<code>dt-start</code>'''
* <code>dtend</code> - parser comme '''<code>dt-end</code>'''
* <code>duration</code> - parser comme '''<code>dt-duration</code>'''
* <code>description</code>
* <code>url</code> - parse as '''u-'''
* <code>category</code>
* <code>location</code> - comprendant la racine compatible <code>vcard</code> en l'absence de <code>h-card</code>, et la racine compatible <code>adr</code> en l'absence de <code>h-adr</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* ...

=== h-geo ===
nom de classe racine : '''<code id="geo">h-geo</code>'''<br/>
profile/itemtype : <nowiki>http://microformats.org/profile/h-geo</nowiki>

propriétés :
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* '''<code>p-altitude</code>''' - nouveau dans [[vCard4]] ([[RFC6350]] à partir de RFC 5870)

Pour une rétro-compatibilité, les parseurs de microformats 2 DEVRAIENT détecter le nom de classe racine et les noms de propriétés. Un parseur microformats 2 peut utiliser les [[parsers-fr|parseurs]] microformats existants pour extraire ces propriétés. Si un "h-geo" est trouvé, ne pas chercher un "geo" sur le même élément.
* <code>geo</code>
propriétés : (parsé sous '''p-''' plein texte à moins qu'autre chose ne soit spécifié)
* <code>latitude</code>
* <code>longitude</code>

=== h-item ===
nom de classe racine : '''<code>h-item</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-item</nowiki>

propriétés :
* '''<code>p-name</code>'''
* '''<code>u-photo</code>'''
* '''<code>u-url</code>'''

Note : en pratique, du fait des règles de propriété implicite dans microforamats", il est attendu que la plupart des usages de "h-item" 
n'obligeront pas du tout à quelques propriétés explicites (parce que les parseurs microformats2 inféreront les propriétés 
name, photo, et url à partir de la structure de l'élément avec "h-item" et ses contenu/éléments s'il y en a).

=== h-product ===
nom de classe racine : '''<code>h-product</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-product</nowiki>

propriétés :
* '''<code>p-name</code>''' - nom du produit
* '''<code>u-photo</code>''' - photo of the product
* '''<code>p-brand</code>''' - manufacturer, can also be a nested <code>h-card</code>
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer 
* '''<code>e-description</code>'''
* '''<code>u-url</code>''' - URL of the product
* '''<code>u-identifier</code>''' - includes type (e.g. mpn, upc, isbn, issn, sn, vin, sku etc.) and value.
* '''<code>p-review</code>''' - a review of the product, can also be a nested <code>h-review</code>
* '''<code>p-price</code>''' - retail price of the product

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-product" is found, don't look for an "hproduct" on the same element.

compat root class name: <code id="hproduct">hproduct</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>photo</code>  - parse as '''u-'''
* <code>brand</code>
* <code>category</code>
* <code>description</code>
* <code>identifier</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>review</code> - including compat root class <code>hreview</code> in the absence of <code>h-review</code>
* <code>price</code>

Note: [[hproduct-fr|hProduct]] a au moins une propriété expérimentale qui a une adoption du vrai monde du fait du support de la recherche hProduct par [[Google]] et [[Bing]]. Actuellement ceci est : price

=== h-recipe ===
nom de classe racine : '''<code>h-recipe</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-recipe</nowiki>

propriétés :
* '''<code>p-name</code>''' - le nom de la recettes
* '''<code>p-ingredient</code>''' - describes one or more ingredients used in the recipe.
* '''<code>p-yield</code>''' - Specifies the quantity produced by the recipe, like how many persons it satisfyies 
* '''<code>e-instructions</code>''' - the method of the recipe.
* '''<code>dt-duration</code>''' - the time it takes to prepare the meal described by the recipe.
* '''<code>u-photo</code>''' - an accompanying image

Propriétés expérimentales avec large adoption
* '''<code>p-summary</code>'''  - provides a short summary or introduction 
* '''<code>p-author</code>''' - the person who wrote the recipe with <code>h-card</code>
* '''<code>dt-published</code>''' - the date the recipe was published
* '''<code>p-nutrition</code>''' - nutritional information like calories, fat, dietary fiber etc.
* ...

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-recipe" is found, don't look for an "hrecipe" on the same element.

compat root class name: <code id="hrecipe">hrecipe</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>ingredient</code>
* <code>yield</code>
* <code>instructions</code> - parse as '''e-'''
* <code>duration</code> - parse as '''dt-'''
* <code>photo</code>  - parse as '''u-'''
* <code>summary</code>
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>nutrition</code>

Note: [[hRecipe]] has a number of experimental properties which have real world adoption due to [[Google]] recipe search support of hRecipe. These are: summary, author, published and nutrition


=== h-resume ===
nom de classe racine : '''<code>h-resume</code>'''<br/>
profile/itemtype : <nowiki>http://microformats.org/profile/h-resume</nowiki>

propriétés :
* '''<code>p-summary</code>''' - aperçu des qualifications et objectifs
* '''<code>p-contact</code>''' - info actuelle de contact dans une <code>h-card</code>
* '''<code>p-education</code>''' - un événement <code>h-calendar</code> d'éduction, années, imbriqué dans la <code>h-card</code> de l'école, lieu.
* '''<code>p-experience</code>''' - un événement <code>h-calendar</code> de job ou toute autre expérience professionnelle, années imbriqué dans la <code>h-card</code> de l'organisation, lieu, titre du job.
* '''<code>p-skill</code>''' - un talent ou une capacité, incluant en option le niveau et/ou la durée de l'expérience
* '''<code>p-affiliation</code>''' - une affiliation avec une <code>h-card</code> organisation

Pour une rétro-compatibilité, les parseurs microformats 2 {{should-fr}} détecter les noms et de classes racines et propriétés. Un parseur microformats peut utiliser les [[parsers-fr|parseurs]] microformats existants pour extraire ces propriétés. Si un "h-resume" est trouvé, 
ne pas chercher un "hresume" sur le même élément.

nom de classe racine compatible : <code>hresume</code><br/>
propriétés : (parsées comme '''p-''' plein texte à mons qu'autre chose ne soit spécifié)
* <code>summary</code>
* <code>contact</code> - incluant la racine compatible <code>vcard</code> en l'absence de <code>h-card</code>
* <code>education</code> - incluant la racine compatible <code>vevent</code> en l'absence de <code>h-event</code>
* <code>experience</code> - incluant la racine compatible <code>vevent</code> en l'absence de <code>h-event</code>
* <code>skill</code>
* <code>affiliation</code> - incluant la racine compatible <code>vcard</code> en l'absence de <code>h-card</code>

Note : skill a une [[hresume-skill-brainstorm|expansion proposée en 'competency']] avec un 'summary' explicite, une notation 
et/ou des composants de durée. Basé sur l'adoption existante dans le vrai monde, nous devrions envisager un vocabulaire h-competency avec les propriétés p-summary, p-rating, et dt-duration.

=== h-review ===
root class name: '''<code>h-review</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-review</nowiki>

properties:
* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing been reviewed i.e. business or person (h-card), event (h-event), place (h-adr or h-geo), product (h-product), website, url, or other item (h-item).
* '''<code>p-reviewer</code>''' - person who authored the review 
* '''<code>dt-reviewed</code>''' - date time of when the review was written
* '''<code>p-rating</code>''' - value from 1-5 indicating a rating for the item (5 best).
* '''<code>p-best</code>'''  - define best rating value. can be numerically lower than worst.
* '''<code>p-worst</code>'''  - define worst rating value. can be numerically higher than best. 
* '''<code>e-description</code>''' - the full text written evaluation and opinion of the reviewer
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer 
* '''<code>u-url</code>''' - URL of the review

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-review" is found, don't look for an "hreview" on the same element.

compat root class name: <code id="hreview">hreview</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> parse as '''<code>p-name</code>'''
* <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
* <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
* <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>reviewer</code>  - including compat root vcard in the absence of h-card
* <code>dtreviewed</code> - parse as '''dt-'''
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>description</code> - parse as '''e-'''
* <code>rel=tag</code> - parse as '''p-category'''
* <code>rel="self bookmark"</code> - parse as '''u-url'''. note that <code>rel</code> attribute value is treated as a space separated set, thus any presence of "self" and "bookmark" within such a set in a rel value is accepted.

Note: The [[hReview]] format has three properties which make use of <code>rel</code> attribute, these are <code>tag</code>, permalink (via the <code>self</code> and <code>bookmark</code> values) and <code>license</code>. Microformats 2 parsers {{should}} map these URLs into the page scoped rel collection.

=== h-review-aggregate ===
root class name: '''<code>h-review-aggregate</code>'''<br/>
profile/itemtype: <nowiki>http://microformats.org/profile/h-review-aggregate</nowiki>

properties:
* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing been reviewed i.e. business or person (h-card), event (h-event), place (h-adr or h-geo), product (h-product), website, url, or other item (h-item).
* '''<code>p-rating</code>''' - value from 1-5 indicating average rating for the item (5 best).
* '''<code>p-best</code>'''  - define best rating value. can be numerically lower than worst.
* '''<code>p-worst</code>'''  - define worst rating value. can be numerically higher than best. 
* '''<code>p-count</code>'''  - number of reviews aggregated.
* '''<code>p-votes</code>'''  - number of reviewers who have rated the product, thus contributing to the average rating.
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>u-url</code>''' - URL of the review

For backward compatibility, microformats 2 parsers {{should}} detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-review-aggregate" is found, don't look for an "hreview-aggregate" on the same element.

compat root class name: <code id="hreview-aggregate">hreview-aggregate</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>summary</code> parse as '''<code>p-name</code>'''
* <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
* <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
* <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>count</code>
* <code>votes</code>
* <code>rel=tag</code> - parse as '''p-category'''
* <code>rel="self bookmark"</code> - parse as '''u-url'''. note that <code>rel</code> attribute value is treated as a space separated set, thus any presence of "self" and "bookmark" within such a set in a rel value is accepted.

=== v2 notes vocab ===
Notes : 
* Tous les vocabulaires v2 sont définis comme des listes à plat de propriétés d'un objet/item, et par conséquent, peuvent être utilisées dans la syntaxe  microformats-2 comme présenté, ou dans items microdata, ou RDFa. Les préfixes de parsage de propriétés microformats-2 "p-", "u-", "dt-", "e-" sont omis au moment d'utiliser les propriétés définis dans l'itemprop de microdata et propriété RDFa car ces syntaxes ont leurs propres règles de parsage spécifiques à l'élément.
* Les URLs Profile sont fournies pour utilisation avec l'attribut <code>profile</code> HTML4, l'attribut microdata <code>itemtype</code> et les attributs RDFa <code>vocab</code> &amp; <code>typeof</code> de RDFa (bien que ce dernier exige de trancher le segment derrière du profil pour l'attribut typeof, et laissant le reste en vocab).
* Les propriétés microformats 2 peuvent aussi être explicitement liées comme des URIs en utilisant [[rel-profile-fr|rel-profile]], la proposition d'attribut [[html5-profile]], ou un attribut HTML5 'vocab'. Si les définitions liées d'URI sont importantes pour vous, exprimez-vous SVP sur [[rel-profile]], [[html5-profile]] ou contribuez sur un drafts [[html5-vocab]].
=== v2 vocab to-do ===
à faire : 
* actualiser les documents profile sur <nowiki>http://microformats.org/profile/h-*</nowiki> URLs mentionnés ci-dessus.
* Fournir tout langage nécessaire spécifique au microdata (par ex être compréhensible en comparaison pour le [http://www.whatwg.org/specs/web-apps/current-work/#vcard vocabulaire microdata échantillon vCard4/hCard1]. Fournir aussi tout langage-spécifique-RDFa comme requis. A la fois et de préférence dans un vocabulaire-générique-indépendant.
* écrire un guide de portage cartographiant propriété v1 -> propriété v2
** cas-d'usage : simple chercher/remplacer dans les gabarits (par ex. au cas où l'auteur web ne se souvient plus des vocabulaires existants des microformats et où il les a utilisés).
** conseiller d'utiliser *les deux* dans les gabarits existants (par ex. dans le cas où CSS repose sur les microformats existants)
* écrire un tutoriel simple pour créer/démarrer avec une syntaxe microformats-2 pour le nouveau contenu.


== combinaison de microformats ==
Parce que microformats 2 utilise de simples ensembles plats de propriétés pour chaque microformat, plusieurs microformats sont combinés pour indiquer de la structure additionnelle.

=== h-event location h-card ===
Les événements ont généralement une information sur le lieu avec de la structure additionnelle, comme l'information d'adresse. Par exemple : 

<source lang=html4strict>
<div class="h-event">
<a class="p-name u-url" href="http://indiewebcamp.com/2012">
IndieWebCamp 2012
</a>
du <time class="dt-start">2012-06-30</time> 
au <time class="dt-end">2012-07-01</time> chez  
<span class="p-location h-card">
<a class="p-name p-org u-url" href="http://geoloqi.com/">
Geoloqi
</a>, 
<span class="p-street-address">920 SW 3rd Ave. Suite 400</span>, 
<span class="p-locality">Portland</span>, 
<abbr class="p-region" title="Oregon">OR</abbr>
</span>
</div>
</source>


La h-card imbriquée utilisée pour structurer le p-location du h-event est representée comme une valeur structurée pour "location" dans le JSON, qui a une clé additionnelle, "value" qui représente la version plein texte analysée à partir du p-location.

JSON analysé :
<source lang=javascript>
{ 
"items": [{
"type": ["h-event"],
"properties": {
"name": ["IndieWebCamp 2012"],
"url": ["http://indiewebcamp.com/2012"],
"start": ["2012-06-30"],
"end": ["2012-07-01"],
"location": [{
"value": "Urban Airship, 334 NW 11th Ave., Portland, OR",
"type": ["h-card"],
"properties": {
"name": ["Urban Airship"],
"url": ["http://urbanairship.com/"],
"street-address": ["334 NW 11th Ave."],
"locality": ["Portland"],
"region": ["Oregon"]
}
}]
}
}]
}
</source>


Questions :
<div class="discussion">
* Should the nested hCard be present also as a top-level item in the JSON? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
** My current (2012-243) leaning is no. - [[User:Tantek|Tantek]] 18:53, 30 August 2012 (UTC)
** If so, how do we avoid expansion of the JSON geometrically proportional to the depth of microformat nesting? (Or do we not worry about it?)
* Should there be a canonical hierarchical JSON and a canonical flattened JSON? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
** My current (2012-243) leaning is no, we stick with one canonical JSON for uf2 which is hierarchical. - [[User:Tantek|Tantek]] 18:53, 30 August 2012 (UTC)
** If so, should the flattened JSON have references from properties to nested microformats that have been pushed to the top level per flattening? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
*** If so, what convention does/do JSON follow for such synthetic local reference identifiers? - [[User:Tantek|Tantek]] 02:02, 19 June 2012 (UTC)
</div>

Notes :
* La valeur 'location' renvoie le texte visible de son élément, y compris les espaces et la ponctuation, tout comme l'abréviation de l'état 'OR'. Les valeurs de propriété 'h-card' sont les seules qui sont marquées, et par conséquent contiennent des valeurs de structure sans ponctuation supplémentaire, et l'état prend la forme étendue à partir de l'attribut <code>title</code> de son élément <code>&lt;abbr&gt;</code>.
=== h-card org h-card ===
Les personnes publient souvent de l'information générale à propos de leurs sociétés plutôt 
que quelque chose spécifique sur eux, auquel cas, ils peuvent désirer encapsuler cela dans un microformat composé. Par exemple, voici 
un exemple simple de hCard avec une propriété org :

[http://blog.lizardwrangler.com Mitchell Baker] (Mozilla Foundation)

avec la source :
<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/" 
>Mitchell Baker</a> 
(<span class="p-org">Mozilla Foundation</span>)
</div>
</source>

JSON analysé :
<source lang=javascript>
{
"items": [{ 
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": ["Mozilla Foundation"]
}
}]
}
</source>

Parfois de telles affiliations à une organisation sont hyperliés vers le site web de l'organisation :

[http://blog.lizardwrangler.com Mitchell Baker] ([http://mozilla.org/ Mozilla Foundation])

Vous pouvez marquer cela avec une h-card embarquée : 
<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/" 
>Mitchell Baker</a> 
(<a class="p-org h-card" 
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

JSON analysé :
<source lang=javascript>
{
"items": [{ 
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}
}]
}
</source>

Note : la h-card embarquée a des propriétés 'name' et 'url' implicites, tout comme devrait le faire toute autre h-card avec un seul nom de classe racine sur un <code>&lt;a href&gt;</code>.


'''POUR PARSEURS UNIQUEMNENT :'''

La 'h-card' embarquée pourrait être marquée tout aussi bien avec un 'h-org', qui l'ajoute à l'array type du microformat imbriqué, 
le tout comme partie de la propriété spécifiée par le 'p-org'.

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/" 
>Mitchell Baker</a> 
(<a class="p-org h-card h-org" 
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

JSON PARSE :
<source lang=javascript>
{
"items": [{ 
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card", "h-org"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}
}]
}
</source>


'''POUR PARSEURS UNIQUEMNENT : '''

Without a property class name like 'p-org' holding all the nested objects together, we need to introduce another array for nested children (similar to the existing DOM element notion of children) of a microformat that are not attached to a specific property:

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/" 
>Mitchell Baker</a> 
(<a class="h-org h-card" 
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

JSON Parsé :
<source lang=javascript>
{
"items": [{ 
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"]
},
"children": [{
"type": ["h-card","h-org"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}  
}]
}]
}
</source>

Du fait qu'il n'y ait pas de nom de classe de propriété sur l'élément avec les classes 'h-card' et 'h-org', 
le microformat représentant cet élément est rassemblé à l'intérieur de l'array enfant.

Un tel microformat embarqué sous-tend quelque relation (confinement, étant en rapport), mais n'est pas aussi utile que si le microformat imbriqué était une propriété spécifique 
de son parent.

Pour cette raison, il est recommandé que les auteurs ne devraient pas publier de microformats imbriqués sans un nom de classe de propriété, 
et au lieu de cela, au moment d'imbriquer les microformats, les auteurs devraient toujours spécifier un nom de classe propriété comme 'p-org') 
sur le même élément que le(s) nom(s) de classe racine du(es) microformat(s) imbriqué(s) (comme 'h-card' et/ou 'h-org').

'''POUR PARSEURS UNIQUEMNENT : '''

Ou l'objet imbriqué pourrait n'être marqué qu'avec 'h-card'. Source : 

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/" 
>Mitchell Baker</a> 
(<a class="h-card" 
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

JSON Parsé :
<source lang=javascript>
{
"items": [{ 
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"]
},
"children": [{
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}  
}]
}]
}
</source>

'''À faire : ajouter un exemple de h-event h-card et JSON, selon des exemples de publication du vrai monde comme [http://www.swingtime.co.uk/List/ClSouth.html Swing Time: Classes in Southern England].'''

== publication ==
=== marquage minimal ===
Le meilleur moyen d'utiliser microformats-2 est d'ajouter aussi peu de syntaxe que possible. Ceci rend votre code plus propre, améliore sa capacité de maintenance, et par conséquent la qualité et la longévité de vos microformats.

Un grand avantage de microformats-2 sur les précédents microformats (et d'autres) est la capacité d'ajouter un nom de classe à un élément existant pour créer un item structuré.

Voir les [[microformats-2-fr#exemples_simples_de_microformats_2|exemples simples en haut]] pour un démarrage, par ex. 

Des hCards simples qui fonctionnent simplement en ajoutant <code>class="h-card"</code> :
<source lang=html4strict>
<span class="h-card">Frances Berriman</span>

<a class="h-card" href="http://benward.me">Ben Ward</a>

<img class="h-card" alt="Sally Ride" 
src="http://upload.wikimedia.org/wikipedia/commons/a/a4/Ride-s.jpg"/>

<a class="h-card" href="http://tantek.com">
<img alt="Tantek Çelik" src="http://ttk.me/logo.jpg"/>
</a>
</source>

* Truc : A l'intérieur d'une balise ouverte, placez <em>en premier</em> l'attribut <code>class</code>, puis tous les attributs de contenu texte humain (par ex. <code>alt</code>), puis les attributs d'URL 
(par ex. <code>href</code> <code>src</code>), et en dernier les autres attributs (par ex. <code>style</code>). Le fait de placer l'attribut class en premier le relie plus fortement 
à l'élément name/tag en lui-même, ce qui fait que c'est plus trivial et par conséquent plus facile à mettre à jour.

=== rétro-compatibilité ===
Si vous dépendez des [[implementations-fr|implémentations]] actuelles, pendant qu'elles sont mises à jour pour supporter [[microformats-2-fr|microformats-2]], vous pouvez inclure à la fois le marquage microformats existant et le marquage microformats-2.

En résumé : utilisez simultanément les deux ensembles de noms de classes.

En faisant ainsi, utilisez-les sur le même élément, avec en premier le nom de classe microformats-2, suivi immédiatement du nom de classe existant microformats.

Voici les hCards microformats-2 du dessus avec le marquage actuel [[hCard-fr|hCard]], qui peut exiger d'ajouter un élément conteneur (par ex. un <code>&lt;span&gt;</code>) pour séparer l'élément nom de classe racine 
des éléments explicites de propriétés de noms de classes :

<source lang=html4strict>
<span class="h-card vcard">
<span class="p-name fn">Frances Berriman</span>
</span>

<span class="h-card vcard">
<a class="p-name fn u-url url" href="http://benward.me">Ben Ward</a>
</span>

<span class="h-card vcard">
<img class="p-name fn u-photo photo" alt="Sally Ride" src="http://upload.wikimedia.org/wikipedia/commons/a/a4/Ride-s.jpg"/>
</span>

<span class="h-card vcard">
<a class="u-url url" href="http://tantek.com">
<img class="p-name fn u-photo photo" alt="Tantek Çelik" src="http://ttk.me/logo.jpg"/>
</a>
</span>
</source>


Trucs :
* Utilisez d'abord le nom de classe microformats-2, par ex.
** <code>class="h-card vcard"</code>
** <code>class="u-url url"</code>
* et mettez-les ensemble au moment d'utiliser un élément pour plusieurs propriétés, par ex. : 
** <code>class="p-name fn u-url url"</code>
** <code>class="p-name fn u-photo photo"</code>
* placer les classes microformats après les classes pour CSS (parce que les auteurs de pages interagiront probablement plus sur leurs propres classes), par ex. comme utilisé sur les pages 
[[events-fr|events]] individuelles des microforamts 
** <code>class="event-page h-event vevent"</code> 

Les préfixes (h-, p-, etc.) des noms de classes microformats2 fournissent une reconnaissance plus facile, et quand ils sont suivis du nom de classe existant nommé de manière similaire, ils sont plus facilement reconnus en tant que tels et par conséquent maintenus ensemble quand la marquage est maintenu au fil du temps.
	
FAQ en rapport : [[microformats2-faq#when_using_both_h-card_and_vcard_which_should_be_first_and_why|When using both h-card and vcard which should be first and why?]]

== Exemples dans la jungle ==
Ajoutez SVP de nouveaux exemples dans la jungle de microformats2 en haut de cette liste. Quand cette liste sera trop grosse, nous pouvons la migrer sur une page séparée comme [[microformats-2-examples-in-wild-fr|microformats-2-exemples-dans-la-jungle]].

* ...
* [http://www.w3.org/conf/ W3Conf 2013] utilise h-event pour l'événement principal et h-card pour pour tous les speakers et participants connus. Les h-cards font particulièrement bon usage des propriétés implicites name, url, et photo.	
* [http://wordpress.org/extend/themes/sempress SemPress] est un thème WordPress qui supporte h-card, h-feed/h-entry et h-as-*
* [http://the-pastry-box-project.net/ The Pastry Box Project] utilise un marquage h-card et h-entry sur sa page d'accueil et ses pages de réflexion
* Tom Morris utilise h-card et [[XFN]] pour marquer sa [http://tommorris.org/pages/blogroll blogroll].
* Aaron Parecki utilise h-card pour marquer à la fois la paternité d'auteur et les références dans les permaliens de ses notes, par ex. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] utilise h-card, h-event, et h-entry sur sa page d'accueil, tout comme h-entry sur tous les permaliens de ses posts, par ex. [http://tantek.com/2012/243/t1/name-beats-title-modern-use-dubline-core-wrong-uf2 2012-243 post], avec [[rel-prev]]/[[rel-next]] (si applicable) pour indiquer les posts avant/après, et avec [[rel-author-fr|rel-author]] ves sa page d'accueil avec une hCard canonique pour indiquer la paternité d'auteur.
* [http://waterpigs.co.uk/ Barnaby Walters] utilise un marquage h-card, h-entry et XFN sur [http://waterpigs.co.uk/notes page de notes].	
** 2013-01-25 Barnaby Walters : <cite>[http://waterpigs.co.uk/articles/experimental-markup Experimental Markup]</cite> - décrit comme il utilise les voculaires microformats2 : 
<code>h-adr</code>, <code>h-card</code>, <code>h-entry</code>, <code>h-event</code>, <code>h-geo</code>, <code>h-review</code> et des vocabulaires expérimentaux <code>h-feed</code> 
(embarqué pour des histoires de mise à jour) , objets [[activity-streams]] <code>h-as-article</code>, <code>h-as-collection</code>, <code>h-as-note</code>, <code>h-as-update</code>, 
tout comme des propriétés expérimentales : <code>u-alternate</code> et <code>u-as-downstream-duplicate</code> (liens vers copies POSSE), et <code>u-in-reply-to</code> (liens vers le contenu 
aquel les posts sont des réponses).  
* [http://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] présentation avec marquage h-event et h-card pour les personnes et organisations.
* [http://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (extrait de Personal Democracy Forum 2012 #pdf12 #pdf2012) a un marquage h-calendar et h-card [[microformats-2-fr|microformats-2]]
* WebMaker par Mozilla a un marquage h-calendar et h-card [[microformats-2-fr|microformats-2]] sur la recherche d'événement (par ex. [https://webmaker.org/en-US/events/near/?lat=45.5234515&lng=-122.6762071 search near Portland Oregon]0 et pages événements (par ex. [https://webmaker.org/en-US/events/192f56eb9/ IndieWebCamp 2012]).[https://twitter.com/microformats/status/212207925643587585]
* WebFWD par Mozilla a un marquage h-calendar et h-card [[microformats-2-fr|microformats-2]] sur les pages [https://webfwd.org/about/experts/ experts] et [https://webfwd.org/about/team/ team]
* [http://indiewebcamp.com IndieWebCamp] a un marquage h-event [[microformats-2-fr|microformats-2]] avec des h-cards imbriquées pour les organisateurs et le lieu.
* La page [https://wiki.mozilla.org/Events Mozilla Events] a un marquage h-event [[microformats-2-fr|microformats-2]] avec les participants marqués avec h-card.

== Implémentations ==
Outils de Blogging :
* '''Storytlr''' parse la 'target' à partir des [http://indiewebcamp.com/pingback-fr pingbacks] pour le [https://github.com/storytlr/storytlr/blob/master/protected/application/public/controllers/PingbackController.php#L63 h-entry avec les propriétés et la h-card embarquée] pour l'information afin d'afficher automatiquement la [http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html section commentaires sur un post].

Les parseurs et autres implémentations de microformats2, généralement open source :
Javascript : 
* '''microformat-node''' parseur Node.js microformats2 
** github open source: https://github.com/glennjones/microformat-node
** test suite: https://github.com/microformats/tests
** blog post: http://glennjones.net/2013/01/brand-new-microformats-2-parser/
** live : http://microformat2-node.jit.su/
*'''microformat-shiv'''  - cross browser javascript microformats 2 parser qui peut s'utiliser aussi dans les extensions navigaterus.
** http://microformatshiv.com/
** github open source: https://github.com/glennjones/microformat-shiv
PHP :
* '''<span id="php-mf2">php-mf2</span>''' - PHP microformats2 parser
** github open source : https://github.com/indieweb/php-mf2
** Packagist : https://packagist.org/packages/mf2/mf2
** live : avec une entrée textarea sur : http://waterpigs.co.uk/php-mf2/
Ruby :
* '''G5/microformats2''' Ruby microformats2 parser
** github open source: https://github.com/G5/microformats2

== Présentations ==
Présentations à propos de microformats2 :
* 2013-01-24 <cite>[http://waterpigs.co.uk/presentations/microformats-2/ Microformats 2]</cite> présentation par [[User:Barnabywalters|Barnaby Walters]] à l'[[events/2013-01-24-exeter-web-meetup|Exeter Web Meetup]] à Devon, UK.
* 2012-09-21 <cite>[http://tantek.com/presentations/2012/09/microformats2/ microformats2 &amp; bits of HTML5: The Evolution Of Web Data]</cite> présentation par [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) à [[events/2012-09-21-refreshlx|RefreshLX]] à Lisbonne, Portugal.
* 2012-07-21 <cite>[http://tantek.com/presentations/2012/07/html5-uf2/ HTML5 and microformats2: The Evolution Of Web Data]</cite> présentation par [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) [[events/2012-07-21-cascadesf|Innovators of the Web conference]] à San Francisco, CA.
* 2012-07-14 <cite>[http://tantek.com/presentations/2012/07/html5-microformats2/ HTML5 and microformats2: The Evolution Of Web Data]</cite> présentation par [[User:Tantek|Tantek Çelik]] ([http://twitter.com/t @t]) lors de l'[[events/2012-07-14-open-web-camp-4|Open Web Camp IV]] à San Jose, CA.

== Testimoniaux ==
* <blockquote class="twitter-tweet">To prove the web standards community can come up with better standards than the SE’s, compare this: http://microformats.org/wiki/microformats-2 with schema . org &mdash; Joost de Valk (@yoast) [https://twitter.com/yoast/status/298907685452124160 2013-02-05 13:35]</blockquote>
* <blockquote class="twitter-tweet">... I’m hoping SE’s will pick up microformats2. It’s SO much cleaner. &mdash; Joost de Valk (@yoast) [https://twitter.com/yoast/status/298911287117758464 2013-02-05 13:49]</blockquote>
* <blockquote class="twitter-tweet">... But damn Microformats2 are sexy. &mdash; Joost de Valk (@yoast) [https://twitter.com/yoast/status/298912179292344320 2013-02-05 13:53]</blockquote>

== À Propos de ce Brainstorm ==
Le reste de cette page est un brainstorming actuellement écrit en format narratif/exploratoire, ce qui veut dire, remercier le succès rencontré par les microformats, pourquoi c'est ainsi, et puis une promenade à travers les problématiques connues des microformats en général associée à l'itération de chemins pour résoudre les dites problématiques, pour finir en guise de conclusion avec le design actuel microformats 2

Les propositions se construisent les unes sur les autres pour aboutir à une solution qui résout la vaste majorité des problématiques générales. Les modifications proposées méritent une incrémentation de version majeure, d'où microformats 2

Ce style mathématique de preuve/dérivation est utilisé pour encourager explicitement la compréhension (et la double-vérification) des étapes rationnelles dans le développement de microformats 2. Les raisons sont documentées, parfois associées à des alternatives envisagées (et les raisons de rejet de ces alternatives).

Quand le brainstorm microformats 2 aura suffisamment évolué pour démontrer quelque degré de stabilité, d'utilisabilité, et de capacité à être implémenté, il sera ré-écrit dans un style de spécification plus déclaratif, et cette dérivation/narration sera archivé vers une page de développement à des fins historiques.

— [[User:Tantek|Tantek]]

== Origines ==

2004 : tout début février les microformats ont été présentés en tant que concept à eTech, et en septembre [[hcard-fr|hCard]] et [[hcalendar-fr|hCalendar]] ont été proposés au FOO Camp.

2010 :
* 34% des développeurs web utilisent les microformats ([http://www.webdirections.org/sotw10/markup/#semantics 2010 State of Web Development survey])
* 1.88 milliards de hCards (selon [[Yahoo]] SearchMonkey)
* 36 millions d'événements hCalendar (idem)

* XFN -> API du Graphe Social -> Web comme un Réseau Social / Carnet d'Adresses

== Résolution de Problématiques ==
=== AUTEURS et ÉDITEURS ===
Les auteurs et éditeurs sont peut-être la circonscription la plus importante dans la communauté des microformats. Il sont bien plus nombreux que les développeurs, programmeurs, parseurs, etc. et ce sont eux qui ont résolu le problème de la poule et de l'oeuf en publiant des microformats même avant que les outils ne soient disponibles pour les consommer.

Par conséquent, nous devons en priorité résoudre les problèmes généraux des auteurs/éditeurs avec les microformats. 

==== pouvons-nous faire le cas le plus simple encore plus simple ====
Problématique : '''How can we make it easier for authors to publish microformats?'''

Actuellement la hCard la plus simple : 
<source lang=html4strict>
<span class="vcard">
<span class="fn">
Chris Messina
</span>
</span>
</source>

requiert 2 éléments (imbriqués, avec peut-être au moins un déjà pré-existant) et 2 noms de classes.

Les auteurs et designers web sont habitués à la simplicité de la plupart des balises HTML, par ex pour marquer un en-tête : 

<source lang=html4strict>
<h1>Chris Messina</h1>
</source>

cela requiert 1 seul élément.

[http://zeldman.com/ Jeffrey Zeldman] relevait cette complexité incrémentale apparente (2 éléments vs 1) durant un atelier microformats en 2009 à NYC.

'''How can we make microformats just as easy?'''

'''Proposal: allow root class name only.'''

Ceci permettrait : 

<source lang=html4strict>
<h1 class="vcard">Chris Messina</h1>
</source>

n'exigeant qu'un seul nom de classe pour le cas le plus simple.


==== renommage pour utilisabilité ====
Autrement connu sous, choisir une forme de cohérence sur une autre.

'''Pouvons-nous faire même encore mieux ?'''

L'une des questions les plus communément posée à propos de hCard est : 

[[hcard-faq-fr#Pourquoi_hCard_utilise_vcard_comme_le_nom_de_classe_racine|Pourquoi hCard utilise vcard comme nom de classe racine ?]]

Cette légère incompatibilité entre le nom du format et le nom de classe racine prête naturellement à confusion pour un grand nombre de nouveaux venus sur les microformats.
* Voir [[issues#hcard-vs-vcard-name]] pour les détails/liens.

Même si dans les microformats, nous croyons fermement au [[principle-fr|principe]] de [[reuse-fr|réutilisation]], nous devons admettre que dans ce cas, l'expérience/évidence a montré que ceci peut être un cas où nous avons réutilisé quelque chose bien au delà de son sens original. Par conséquent : 

'''Proposition : utiliser le nom de classe racine "hcard" au lieu de "vcard" pour les futures hCards.'''

Ceci donnerait : 

<source lang=html4strict>
<h1 class="hcard">Chris Messina</h1>
</source>

rendant le cas simple même encore plus simple : 

Juste 1 nom de classe additionnel, nommé du même nom que le format que vous ajoutez. Pensez hCard, marquez class="hcard".

Pour un minimum de compatibilité, nous devrions documenter que les parseurs devraient accepter "hcard" comme alternative à "vcard" comme le nom de classe racine pour hCard 1.0, et de la même manière pour hCalendar 1.0 : "hcalendar" en plus de "vcalendar", "hevent" en plus de "vevent".

Néanmoins, pour [[microformats-2-fr|microformats 2]] nous allons distinguer les noms de classes racine plus en profondeur en utilisant un préfixe "h-" (par ex. "h-card"). Continuez à lire pour comprendre pourquoi.

==== simplifier pour n'avoir besoin que d'un seul élément ====
Il est très important pour le simple cas d'être aussi simple que possible, de permettre aux maximum de personnes de démarrer avec un effort minimal. (L'idée d'utiliser un nom de classe unique pour un microformat a été proposée par Ryan Cannon en 2006 spécifiquement [[hcard-implied-fr|pour hCard]], et redécouverte par [[User:Tantek|Tantek]] en 2010 et généralisée par la suite pour tous les microformats.)

À partir de là, c'est bien d'obliger à un effort incrémental pour un retour incrémental. 
Ce qui veut dire ajouter toute information additionnelle à propos d'une personne, ajouter des noms de propriété explicites.

'''Comment fonctionne ce cas d'unique racine ?'''

* le nom de classe racine reflète le nom du microformat
* chaque microformat doit avoir besoin tout au plus d'une propriété (de préférence 0)
** admettons qu'avoir besoin d'un champ dans une application résulte simplement dans du bruit (le problème 90210 - des apps qui ont besoin du code postal reçoivent beaucoup d'entrées 90210), et spécifier que n'importe quel cas d'usage d'application qui semble "avoir besoin" de propriétés spécifiques doit au lieu de cela définir comment signifier des valeurs sensibles par défaut pour elles.
* si un seul nom de classe est spécifié, signifier les contenus entiers texte de l'élément comme la valeur de la propriété de base du microformat à savoir : 
** "hcard" insinue "fn"
** hcalendar event - "hevent" - insinue "summary"
** "hreview" insinue "summary"
** "hentry" insinue "entry-summary" (à réduire peut-être en "summary" - en pratique ils ne sont pas suffisamment distincts sémantiquement pour avoir besoin de noms de propriété séparés)
** '''OU''' au lieu de produire l'unique propriété implicite à avoir un vocab spécifique, introduire une nouvelle propriété générique 'p-name' (applicable à tous les vocabulaires) (subsuming hCard's 'fn'). Voir [[microformats-2-brainstorming#further_simplifications|microformats 2 brainstorming: further simplifications]] pour les dernières idées le long de ces lignes, comprenant les propriétés génériques suivantes spécifiques de marquage pour tous les microformats (basées sur des cas d'usages de marquage existants et publiés)
*** 'p-name'
*** 'u-url'
*** 'u-photo'

==== ensembles plats de propriétés ====
'''Que pouvons-nous simplifier encore plus sur les microformats?'''

Bon nombre d'individus ont fourni le feedback qu'à chaque fois qu'il y a plus d'un niveau de hiérarchie dans un microformat, beaucoup (la plupart ?) des développeurs s'embrouillent - en particulier Kavi Goel de Google / Rich Snippets a fournir ce feedback durant un dîner microformats. Par conséquent, en fonction des multiples niveaux cela résulte probablement dans une perte d'auteurs, peut-être même de précision tout comme la confusion mène indubitablement à plus d'erreurs. Par conséquent : 

'''Proposition : simplifier tous les microformats vers des ensembles plats de propriétés. '''

Ce qui veut dire : 
* tous les microformats sont simplement un objet avec un ensemble de propriétés avec des valeurs.
* plus de sous-propriétés - laisser tomber la notion de sous-propriétés.
* utiliser la composition de multiple microformats pour toute hiérarchie plus profonde, par ex. le "location" d'un événement hCalendar peut être une hCard, ou l' "agent" d'une hCard peut être une autre hCard.

Par exemple pour hCard, cela voudrait dire que les modifications spécifiques suivantes soient maintenues pour une fonctionnalité pertinente :
* abandonner "n", promouvoir toutes les sous-propriétés "n" vers des propriétés complètes
** given-name, family-name, additional-name, honorific-prefix, honorific-suffix
* traiter "geo" comme un microformat imbriqué
* traiter "adr" comme un microformat imbriqué (que faire du "type" adr ?)
* traiter "org" comme une chaîne plate et laisser tomber "organization-name" et "organization-unit" (en pratique rarement utilisé, aussi non révélé ou ignoré dans les interfaces-utilisateurs de gestion de contact - par ex. Carnet d'Adresses)

Exemple : ajouter une initiale au milieu de l'exemple précédent du nom de Chris Messina, et marquer chaque composant de nom:

<source lang=html4strict>
<h1 class="hcard">
<span class="fn">
<span class="given-name">Chris</span>
<abbr class="additional-name">R.</abbr>
<span class="family-name">Messina</span>
</span>
</h1>
</source>

Note :
# usage d'un span explicite avec "fn" pour marquer le nom entier formaté
# usage de l'élément abbr pour indiquer explicitement la sémantique que "R." est simplement une abréviation pour son nom-additionnel.

==== distinguer les propriétés des autres classes ====
Les propriétés actuelles des microformats ré-utilisent des termes génériques comme "summary", "photo", "updated" à la fois tant pour la facilité d’usage que la compréhension.

Néanmoins, à travers une expérience à plus long terme, nous avons vu des sites qui ont abandonné accidentellement (ou rompu) leurs supports des microformats (par ex. Upcoming.org, Facebook) parce que les auteurs web écrivent à nouveau tous leurs noms de classes, et ne sont soit pas conscients que les microformats étaient dans la page, ou ne pouvaient pas facilement distinguer les noms de classe des propriétés des autres noms de classes spécifiques au site.

Ce problème a été rapporté par un certain nombre d’auteurs web.
* Voir : [[issues#class-collisions]]

Par conséquent microformats 2 utilise des ''préfixes'' pour les noms de classes des propriétés, par ex. : 
* '''p-summary''' au lieu de ''summary''
* '''u-photo''' au lieu de ''photo'' 
* '''dt-updated''' au lieu de ''updated''

Préfixer ainsi tous les noms de classes de microformats fût suggéré initialement par Scott Isaacs de Microsoft à Tantek durant une visite chez  Microsoft en 2006/2007, mais destiné spécifiquement pour faire en sorte que les  microformats soient plus faciles à parser. À cette date, la suggestion avait été rejetée parce que les microformats étaient plus focalisés sur les auteurs web que les parseurs.

Néanmoins, parce que l’expérience a montré que les noms de classes distinctifs est une problématique tant ‘’’pour les auteurs web que les développeurs de parseurs''', c’est un changement-clé que microformats-2 adopte. Voir la prochaine section pour les détails.

=== COMMUNAUTÉ et OUTILS ===
La seconde circonscription la plus importante dans la communauté des microformats sont les développeurs, programmeurs et développeurs d’outils.

Un nombre non-trivial parmi eux ont été suffisamment frustrés avec quelques problématiques générales à l'égard des microformats qu’ils ont fait le travail supplémentaire et significatif en plus pour supporter chacune des alternatives moins chaleureuses (microdata, RDFa). Basé sur ces données du vrai-monde (comportement du marché), cela nous a amené à nous occuper de ces problématiques générales de microformats pour cette circonscription.

==== exigences de parsage pour les microformats existants ====
COMMUNAUTÉ  et OUTILS (qui) UTILISENT les MICROFORMATS 
* parseur / parsage
* structuré
* extraire/sortir la data
* json - représentation 1:1

[[parsing-fr|parser]] les microformats requiert 
# Une liste de noms de classes racines pour chaque microformat à parser
# Une liste de propriétés pour chaque microformat spécifique, associée à la connaissance du type de chaque propriété afin de parser leurs données provenant de différentes portions du marquage HTML
# Quelques règles spécifiques à certains formats spécifiques (optimisations marquage/contenu)

Ceci voulait dire qu’à chaque fois qu’un nouveau microformat est « drafté »/spécifié/adopté, les parseurs ont besoin d’être mis à jour pour le gérer correctement, à un minimum pour les parser quand ils sont à l’intérieur d’autres microformats et évitent des propriétés implicites errantes de l’un à l’autre (confinement, problème [[mfo-fr|mfo]]).

==== conventions de dénomination pour analyse générique ====
Je pense qu’il existe une solution suffisamment simple pour les points #1 et #2 de la liste du dessus, et nous pouvons progresser vers la minimisation du point #3.  En résumé :

'''Proposition : un ensemble de conventions de dénomination pour les noms de classes racines microformats et propriétés qui les rendent évidentes quand :’’’
* Un nom de classe représente un nom de classe racine microformat
* Un nom de classe représente un nom de propriété microformat
* Un nom de classe représente une propriété microformat qui a besoin d’un parsage spécial (type spécifique de propriété).

En particulier - dérivé d’exemples du vrai monde de microformats avérés existants (plutôt que toute abstraction de ce que pourrait avoir un schéma)
* '''"h-*" pour les noms de classes racines''', par ex. "h-card", "h-event", "h-entry"
** Le préfixe 'h-' est basé sur le modèle de nommage existant des microformats de démarrer par 'h'.
* '''"p-*" pour les simples propriétés (texte) ''', par ex. "p-fn", "p-summary"
** Un parsage générique de vocabulaire, l’élément texte en général, traiter certaine combinaison d’attribut/élément HTML comme spécial et utiliser ceux-ci en premier, par ex. img/alt, abbr/title.
** Le préfixe 'p-' est basé sur le mot "property" démarrant par 'p'.
* '''"u-*" pour les propriétés URL''', par ex. "u-url", "u-photo", "u-logo"
** parsage spécial requis : préférer les attributs a/href, img/src, object/data etc. aux éléments de contenus
** Le ‘préfixe u-‘ est basé sur URL/URI commençant par la lettre 'u', qui est le type de la plupart de ces propriétés en rapport.
* '''"dt-*" pour les propriétés datetime''', par ex. "dt-start", "dt-end", "dt-bday"
** parsage spécial requis : [[value-class-pattern-fr|modèle-classe-value]], en particulier séparer les valeurs date time en parsant pour un meilleur équilibre lisibilité-par les humains / DRY.
** Le préfixe 'dt-' est basé sur date time" ayant les initiales "dt" et la prépondérance de propriétés date time démarrant par "dt", par ex. dtstart, dtend, dtstamp, dtreviewed.
* '''"e-*" pour les propriétés de l'arbre de l'élément''' où la hiérarchie entière contenu de l’élément est la valeur, par ex. "e-content" (précédemment "entry-content") pour [[hatom-fr|hAtom]]. Le préfixe 'e-' peut être aussi souvenu de manière mnémonique comme "element tree", "embedded markup", ou "encapsulated markup".
** parsage spécial requis : suivez la [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#serializing-html-fragments spec HTML  : Serializing HTML Fragments algorithm] pour créer une sérialisation.


Ceci fournit une histoire plus simple de transition/éducation pour les auteurs/éditeurs existants de microformats :
* "h*" vers "h-*", "dt*" vers "dt-*", propriétés url vers "u-*", entire embedded markup vers "e-*", et "p-*" pour toutes les propriétés "plein texte"


Voir [[microformats-2-prefixes]] pour de plus amples idées et discussions sur ces autres préfixes de classes.

Exemple : pousser ce simple exemple de hCard en titre :

<source lang=html4strict>
<h1 class="h-card">Chris Messina</h1>
</source>

En tant que communauté, nous continuerions à utiliser le [[process-fr|processus]]  microformats à la fois pour chercher et déterminer le besoin de nouveaux microformats, et pour nommer les nouveaux noms de propriétés micformats pour un maximum de ré-utilisation et d’inter-opérabilité d’un vocabulaire partagé.

S'il advenait que nous ayons besoin d’un nouveau type de propriété dans le futur, nous pouvons utiliser l’une des uniques-lettres-préfixes pour l'ajouter à microformats 2. Ceci obligerait bien sûr à mettre à jour les parseurs, mais en pratique le nombre de différents types de propriétés a grandi très lentement, et nous savons à partir d’autres schémas/langages de programmation qu’il y a toujours un nombre limité et petit de types de propriétés scalaires/atomiques dont vous avez besoin, et en utilisant celles-ci, vous pouvez créer des types/objets composés qui représentent des types de données plus riches/plus compliqués. Voir [[microformats-2-prefixes]] pour une documentation des préfixes de noms de classes existants à une lettre-unique en pratique.

=== AVANTAGES ===
Ceci a de nombreux avantages :
* '''meilleure maintenabilité''' - bien plus évident pour les auteurs web/designers/éditeurs dont les noms de classes sont pour/provenant des microformats.
* '''aucune chance de collision''' - pour tous les objectifs pratiques avec des noms de classes existants et évitant de ce fait tout besoin d'ajouter des règles complexes de style CSS pour éviter des effets inattendus de mise en forme.
* '''parsage plus simple''' - les parseurs peuvent produire désormais une simple analyse de flux (ou un parcours dans l'ordre de l'arbre du DOM) et extraire '''tous''' les objets, propriétés et valeurs microformats, sans avoir à connaître quoi que ce soit sur les microformats spécifiques.
* '''séparation de syntaxe et vocabulaire''' - en résumant la syntaxe microformats 2 à quelque chose d'indépendant de tout vocabulaire, cela permet et encourage le développement de vocabulaires partagés qui peuvent fonctionner dans des syntaxes alternatives.

Plus d'exemples : voici le même exemple avec des composants de nom : 

<source lang=html4strict>
<h1 class="h-card">
<span class="p-fn">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</span>
</h1>
</source>

avec un hyperlien vers l'URL de Chris :

<source lang=html4strict>
<h1 class="h-card">
<a class="p-fn u-url" href="http://factoryjoe.com/">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</a>
</h1>
</source>

=== COMPATIBILITÉ ===

microformats 2 est rétro-compatible dans le sens où il permet aux auteurs de contenus de marquer tant avec les vieux noms de classes que les nouveaux pour une compatibilité avec les vieux outils.

Voici un exemple simple :

<source lang=html4strict>
<h1 class="h-card vcard">
<span class="fn">Chris Messina</span>
</h1>
</source>

Un parseur microformats 2 verrait le nom de classe "h-card" et laisserait entendre la propriété unique requise à partir des contenus, alors qu'un parseur microformats 1.0 trouverait le nom de classe "vcard" et puis chercherait le nom de classe "fn". Aucune duplication de donnée n'est requise. C'est une mise en application très importante du [[principle-fr|principe]] <abbr title="don't repeat yourself">DRY</abbr>.

Et l'exemple au-dessus hyperlié avec à la fois les ensembles de noms de classes : 

<source lang=html4strict>
<h1 class="h-card vcard">
<a class="p-fn u-url n fn url" href="http://factoryjoe.com/">
<span class="p-given-name given-name">Chris</span>
<abbr class="p-additional-name additional-name">R.</abbr>
<span class="p-family-name family-name">Messina</span>
</a>
</h1>
</source>


=== EXTENSIONS PROPRIÉTAIRES ===

(cette section fût seulement discutée verbalement et non écrite durant les discussions - saisie ici car elle est dans le sujet) 

Les extensions propriétaires vers des formats ont généralement été des échecs expérimentaux de courte durée avec une grosse exception récente.

Les implémentations propriétaires ou expérimentales de propriétés CSS3 ont eu beaucoup de succès.

Il y a eu beaucoup d'utilisation des propriétés border radius et animations/transitions qui utilisent les propriétés CSS avec des préfixes spécifiques aux vendeurs comme :

* -moz-border-radius
* -webkit-border-radius

etc.

Note that these are merely string '''prefixes''', not bound to any URL, and thus not namespaces in any practical sense of the word.  This is quite an important distinction, as avoiding the need to bind to a URL has made them easier to support and use.

This use of vendor specific CSS properties has in recent years allowed the larger web design/development/implementor communities to experiment and iterate on new CSS features while the features were being developed and standardized.

The benefits have been two-fold:
* designers have been able to make more attractive sites sooner (at least in some browsers)
* features have been market / real-world tested before being fully standardized, thus resulting in better features

Implementers have used/introduced "x-" prefixes for IETF MIME/content-types for experimental content-types, MIME parameter extensions, and HTTP header extensions, per RFC 2045 Section 6.3, RFC 3798 section 3.3, and [https://secure.wikimedia.org/wikipedia/en/wiki/List_of_HTTP_header_fields#Common_non-standard_headers Wikipedia: HTTP header fields - non-standard headers] (could use RFC reference instead) respectively, like:

* application/x-latex (per [https://secure.wikimedia.org/wikipedia/en/wiki/Internet_media_type#Type_x Wikipedia Internet media type: Type x])
* x-spam-score (in email headers)
* X-Pingback (per [http://en.wikipedia.org/wiki/Pingback Wikipedia:Pingback])

Some standard types started as experimental "x-" types, thus demonstrating this experiment first, standardize later approach has worked for at least some cases:

* image/x-png (standardized as image/png, both per [http://tools.ietf.org/html/rfc2083 RFC2083])

There have been times when specific sites have wanted to extend microformats beyond what the set of properties in the microformat, and currently lack any '''experimental''' way to do so - to try and see if a feature (or even a whole format) is interesting in the real world before bothering to pursue researching and walking it through the microformats process.  Thus:

'''Proposal:'''
* '*-x-' + '-' + meaningful name for root and property class names
** where "*" indicates the single-character-prefix as defined above
** where "x" indicates a literal 'x' for an experimental extension OR
** OR "x" indicates a vendor prefix (more than one character, e.g. like CSS vendor extension abbreviations, or some stock symbols, avoiding first words/phrases/abbreviations of microformats properties like dt-)
** e.g.
** "h-bigco-one-ring" - a hypothetical "bigco" vendor-specific "one-ring" microformat root class name.
** "p-goog-preptime" - to represent [http://www.google.com/support/webmasters/bin/answer.py?answer=173379 Google's "preptime" property extension] to [[hRecipe]] (aside: "duration" may be another property type to consider separate from "datetime" as it may be subject to different parsing rules.)
** "p-x-prep-time" - a possible experimental property name to be added to hRecipe upon consideration/documentation of real-world usage/uptake.

Background - this proposal is a composition of the following (at least somewhat) successful vendor extension syntaxes
* [http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords CSS 2.1 4.1.2.1 Vendor-specific extensions]
* IETF MIME/content-type "x-*" extensions per RFC 2045 Section 6.3. [http://en.wikipedia.org/wiki/Internet_media_type]
* IETF MIME experimental fields (e.g. x-spam-score)
* HTTP header extensions (e.g. x-pingback)
* note also [http://www.mnot.net/blog/2009/02/18/x- some critical thoughts from mnot]

=== UTILISATEURS ===
Besoin de plus d'outils et d'interfaces qui : 
* publient
* copient/collent
* clic-droit sur un microformat
* partagent
* recherchent des résultats

discuté de quelques outils existants comme : [[h2vx-fr|H2VX]] convertit hCard en vCard, hCalendar en iCalendar

Comment ré-implémenterions-nous Live Clipboard aujourd'hui, en le rendant plus facile pour les auteurs, éditeurs et développeurs ?

=== VOIR AUSSI ===
* [[microformats-2]]
* [[microformats-2-brainstorming]] - migré les idées plus expérimentales / non développées et rejetées ici pour simplifier/progresser plus en profondeur sur *cette* page.
* [[microformats-2-prefixes]]
* [[microformats-2-faq]]
* [[microformats2-parsing]]
Templates used on this page:
Template:should (protected)
Template:should-fr
Return to microformats2-fr.
Retrieved from "http://mt.microformats.org/wiki/microformats2-fr"
Views

Microformats Wiki

Toolbox

Hey! You're not logged in
