microformats-2-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m ([fr : →‎distinguer les propriétés des autres classes: first draft translation])
m (#REDIRECT microformats2-fr)
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
<entry-title>microformats 2.0</entry-title>
#REDIRECT [[microformats2-fr]]
 
Bienvenue sur le développement en cours des microformats 2.0.
 
== Résumé ==
Microformats 2.0 améliore la facilité d'utilisation et d'exécution <em>tant</em> pour les auteurs (éditeurs) que les développeurs (les éxécuteurs d'analyses), avec les simplifications suivantes :
 
# '''quels noms de classes''' sont utilisés pour les microformats (ceux qui démarrent avec 'h-' 'p-' 'u-' 'dt-', 'e-')
# '''ensembles plats de propriétés''' pour tous les microformats (la data hiérarchique utilise des microformats imbriqués) qui sont tous '''optionnels''' et '''pluriels''' (les applications ayant besoin d'une sémantique unique peuvent utiliser la première instance)
# '''vocabulaires indépendants de la syntaxe''' - les deux précédentes simplifications permettent une analyse générique (par conséquent une sortie automatique  JSON/XML/RDF) et un développement de syntaxe indépendant des vocabulaires
# '''marquage plus simple pour les cas-d'usages communs''' - les cas-d'usages commun ont été même encore plus simplifiés avec des règles génériques d'analyse et quelques propriétés génériques implicites : name, url, photo.
 
=== exemples simples de microformats ===
Voici quelques exemples simples de microformats 2.0 qui démontrent la plupart des changements (les exemples analysés JSON sont une expérience draft - feedback bienvenu !)
 
Simple référence à une personne :
<source lang=html4strict>
<span class="h-card">Frances Berriman</span>
</source>
 
JSON analysé :
<source lang=javascript>
[{
  "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>
[{
  "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>
 
Plus de détails sur la façon dont les cas simples fonctionnent dans [[microformats-2-implied-properties]].
 
Notes :
# "type" utilise la totalité du nom de classe racine du microformat 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 la proposition d'attribut [[html5-profile]], ou peut-être à la place un attribut 'vocab'  (plus intuitif que le 'profile' surencombré).
 
== vocabulaires v2 ==
Statut : '''<span id="draft_v2_vocabularies">draft</span>'''. SVP critique et feedback bienvenus sur  [[irc-fr|IRC]].
 
=== h-adr ===
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 ===
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-honorific-suffix</code>'''
* '''<code>p-nickname</code>'''
* '''<code>u-email</code>'''
* '''<code>u-logo</code>'''
* '''<code>u-photo</code>'''
* '''<code>u-url</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>p-organization-name</code>'''
* '''<code>p-organization-unit</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]])
* ...
 
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>vcard</code>
properties: (parsed as '''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>category</code>
* <code>adr</code> - parser comme '''<code>p-adr h-adr</code>''' incluant la 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 racine compat <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parse as '''dt-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* ...
 
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 ===
profile/itemtype : <nowiki>http://microformats.org/profile/h-entry</nowiki>
 
propriétés :
* '''<code>p-name</code>'''
* '''<code>p-entry-summary</code>'''
* '''<code>e-entry-content</code>'''
* '''<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>'''
 
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-entry" est trouvé, ne pas chercher un "hentry" sur le même élément.
 
nom de classe racine compatible :
* <code>hentry</code>
properties: (parsed as '''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>
* <code>published</code> - parser sous '''dt-'''
* <code>updated</code> - parser sous '''dt-'''
* <code>author</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>
* ...
 
 
=== h-event ===
profile/itemtype : <nowiki>http://microformats.org/profile/h-event</nowiki>
 
propriétés :
* '''<code>p-name</code>'''
* '''<code>dt-start</code>'''
* '''<code>dt-end</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>'''
* ...
 
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>vevent</code>
propriétés : (parsed as '''p-''' plein texte à moins qu'autre chose ne soit spécifié)
* <code>summary</code> - parse as '''<code>p-name</code>'''
* <code>dtstart</code> - parse as '''<code>dt-start</code>'''
* <code>dtend</code> - parse as '''<code>dt-end</code>'''
* <code>description</code>
* <code>url</code> - parse as '''u-'''
* <code>category</code>
* <code>location</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 ===
profile/itemtype: <nowiki>http://microformats.org/profile/h-geo</nowiki>
 
properties:
* '''<code>p-latitude</code>'''
* '''<code>p-longitude</code>'''
* '''<code>p-altitude</code>''' - new in [[vCard4]] ([[RFC6350]] from 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>
 
 
=== 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 de profil HTML4, l'itemtype microdata, et les attributs vocab/typeof 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).
 
=== 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.
 
== 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>
  from <time class="dt-start">2012-06-30</time>
  to <time class="dt-end">2012-07-01</time> at
  <span class="p-location h-card">
    <a class="p-name u-url" href="http://urbanairship.com/">
      Urban Airship
    </a>,
    <span class="p-street-address">334 NW 11th Ave.</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>
[{
  "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>
 
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>.
 
== A Propos de ce Brainstorm ==
Ce brainstorm est actuellement écrit en format narratif/exploratoire, ce qui veut dire, en remerciant le succès qu'ont eu 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 se conclure avec le design actuel microformats 2.0 en guise de conclusion.
 
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.0.
 
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.0. Les raisons sont documentés, parfois associées à des alternatives envisagées (et les raisons de rejet de ces alternatives).
 
Quand le brainstorm microformats 2.0 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 ===
The second most important constituency in the microformats community are the developers, programmers, tool-makers.
 
A non-trivial number of them have been sufficiently frustrated with some general issues with microformats that they've done the significant extra work to support very different and less friendly alternatives (microdata, RDFa). Based on this real-world data (market behavior), it behooves us to address these general issues with microformats for this constituency.
 
==== exigences de parsage pour les microformats existants ====
COMMUNITY and TOOLS (that) USE MICROFORMATS
* parser / parsing
* structured
* getting the data out
* json - 1:1 mapping
 
[[parsing]] microformats currently requires
# a list of root class names of each microformat to be parsed
# a list of properties for each specific microformats, along with knowledge of the type of each property in order to parse their data from potentially different portions of the HTML markup
# some number of format-specific specific rules (markup/content optimizations)
 
This has meant that whenever a new microformat is drafted/specificied/adopted, parsers need to updated to handle it correctly, at a minimum to parse them when inside other microformats and avoid errantly implying properties from one to the other (containment, [[mfo]] problem).
 
==== conventions de nommage pour analyse générique ====
I think there is a fairly simple solution to #1 and #2 from the above list, and we can make progress towards minimizing #3.  In short:
 
'''Proposal: a set of naming conventions for microformat root class names and properties that make it obvious when:'''
* a class name represents a microformat root class name
* a class name represents a microformat property name
* a class name represents a microformat property that needs special parsing (specific type of property).
 
In particular - derived from the real world examples of existing proven microformats (rather than any abstraction of what a schema should have)
* '''"h-*" for root class names''', e.g. "h-card", "h-event", "h-entry"
** The 'h-' prefix is based on the existing microformats naming pattern of starting with 'h'.
* '''"p-*" for simple (text) properties''', e.g. "p-fn", "p-summary"
** vocabulary generic parsing, element text in general, treat certain HTML element/attribute combination as special and use those first, e.g. img/alt, abbr/title.
** The 'p-' prefix is based on the word "property" starting with 'p'.
* '''"u-*" for URL properties''', e.g. "u-url", "u-photo", "u-logo"
** special parsing required: prefer a/href, img/src, object/data etc. attributes to element contents.
** The 'u-' prefix is based on URL/URI starting with the letter 'u', which is the type of most of these related properties.
* '''"dt-*" for datetime properties''', e.g. "dt-start", "dt-end", "dt-bday"
** special parsing required: [[value-class-pattern]], in particular separate date time value parsing for better human readabillity / DRY balance.
** The 'dt-' prefix is based on "date time" having the initials "dt" and the preponderance of existing date time properties starting with "dt", e.g. dtstart, dtend, dtstamp, dtreviewed.
* '''"e-*" for properties''' where the entire contained element hierarchy is the value, e.g. "e-content" (formerly "entry-content") for [[hAtom]]. The 'e-' prefix can also be mnemonically remembered as "element tree", "embedded markup", or "encapsulated markup".
** special parsing required: follow the [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#serializing-html-fragments HTML spec: Serializing HTML Fragments algorithm] to create a serialization.
 
This provides a simpler transition/education story for existing microformats authors/publishers:
* "h*" to "h-*", "dt*" to "dt-*", url-like properties to "u-*", entire embedded markup to "e-*", and "p-*" for all "plain text" properties.
 
See [[microformats-2-prefixes]] for further thoughts and discussions on these and other class prefixes.
 
Example: taking that simple heading hCard example forward:
 
<source lang=html4strict>
<h1 class="h-card">Chris Messina</h1>
</source>
 
As part of microformats 2.0 we would immediately define root class names and property names for all existing microformats and drafts consistent with this naming convention, and require support thereof from all new implementations, as well as strongly encouraging existing implementations to adopt the simplified microformats 2.0 syntax and mechanism. Question: which microformats deserve explicit backward compatibility?
 
As a community we would continue to use the microformats [[process]] both for researching and determining the need for new microformats, and for naming new microformat property names for maximum re-use and interoperability of a shared vocabulary.
 
If it turns out we need a new property type in the future, we can use one of the remaining single-letter-prefixes to add it to microformats 2.0. This would require updating of parsers of course, but in practice the number of different types of properties has grown very slowly, and we know from other schema/programming languages that there's always some small limited number of scalar/atomic property types that you need, and using those you can create compound types/objects that represent richer / more complicated types of data. See [[microformats-2-prefixes]] for documentation of existing single-letter class name prefixes in practice.
 
=== 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.0 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.0 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)
 
Proprietary extensions to formats have typically been shortlived experimental failures with one big recent exception.
 
Proprietary or experimental CSS3 property implementations have been very successful.
 
There has been much use of border radius properties and animations/transitions which use CSS properties with vendor-specific prefixes like:
 
* -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 "onering" 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 ===
Need more tools and interfaces that:
* publish
* copy/paste
* right-click on a microformat
* share
* search results
 
discussed some existing like: [[H2VX]] converts hCard to vCard, hCalendar to iCalendar
 
how would we re-implement Live Clipboard today, making it easier for publishers and developers?
 
=== VOIR AUSSI ===
* [[microformats-2]]
* [[microformats-2-brainstorming]] - moving more experimental / undeveloped / and rejected thoughts ideas here to simplify/progress *this* page further.
* [[microformats-2-prefixes]]
* [[microformats-2-faq]]

Latest revision as of 04:23, 6 September 2012

Redirect to:

Retrieved from "http://microformats.org/wiki/index.php?title=microformats-2-fr&oldid=47246"