microformats-2-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m ([fr: translation of original page - to be studied and continued.])
m (#REDIRECT microformats2-fr)
 
(10 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 comptabilité arrière, 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)
 
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-geo" is found, don't look for an "geo" on the same element.
compat root class name:
* <code>geo</code>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>latitude</code>
* <code>longitude</code>
 
 
=== v2 vocab notes ===
Notes:
* All v2 vocabularies are defined as flat lists of properties of an object/item, and thus can be used in microformats-2 syntax as shown, or in microdata items, or RDFa. The microformats-2 property parsing prefixes "p-", "u-", "dt-", "e-" are omitted when using defined properties in microdata itemprop and RDFa property as those syntaxes have their own element-specific parsing rules.
* Profile URLs are provided for use with the HTML4 profile attribute, microdata itemtype, and RDFa vocab/typeof attributes (though the latter requires slicing off the trailing segment of the profile for the typeof attribute, and leaving the rest in vocab).
 
=== v2 vocab to-do ===
To do:
* actual profile documents at <nowiki>http://microformats.org/profile/h-*</nowiki> URLs mentioned above.
* Provide any necessary microdata-specific language as needed (e.g. to be comparably understandable to the [http://www.whatwg.org/specs/web-apps/current-work/#vcard sample vCard4/hCard1 microdata vocabulary]. Also provide any necessary RDFa-specific language as needed. Both preferably in a generic vocabulary-independent way.
 
== combinaison de microformats ==
Since microformats 2 uses simple flat sets of properties for each microformat, multiple microformats are combined to indicate additional structure.
 
=== h-event location h-card ===
Events commonly have venue information with additional structure, like address information. For example:
 
<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>
 
The nested h-card used to structure the p-location of the h-event is represented as a structured value for "location" in the JSON, which has an additional key, "value" that represents the plain text version parsed from the p-location.
 
Parsed JSON:
<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 :
* The 'location' value reflects the visible text of its element, including spaces and punctuation, as well as the state abbreviation 'OR'. The 'h-card' property values are only what is marked up, and thus include structure values without extra punctuation, and the state takes the expanded form from the <code>title</code> attribute of its <code>&lt;abbr&gt;</code> element.
 
== About This Brainstorm ==
This brainstorm is currently written in narrative / exploratory format, that is, acknowledging the success that microformats have had, why so, and then a walk through of known issues with microformats in general along with iteration of ways to address said issues, ending up with the current microformats 2.0 design as a conclusion.
 
The proposals build on each other resulting in a solution that addresses the vast majority of general issues. The proposed changes merit a major version number increment, hence microformats 2.0.
 
This mathematical proof/derivation style is used to explicitly encourage understanding (and double-checking) of the rational steps taken in the development of microformats 2.0. Reasons are documented, sometimes along with alternatives considered (and reasons for rejection of those alternatives).
 
When the microformats 2.0 brainstorm has evolved sufficiently to demonstrate some degree of stability, usability, and implementability, it will be rewritten in a more declarative specification style, and this narrative/derivation will be archived to a background development page for historical purposes.
 
— [[User:Tantek|Tantek]]
 
== Origines ==
 
2004: In early February microformats were introduced as a concept at eTech, and in September [[hcard-fr|hCard]] and [[hcalendar-fr|hCalendar]] were proposed at FOO Camp.
 
2010:
* 34% of webdevs use microformats ([http://www.webdirections.org/sotw10/markup/#semantics 2010 State of Web Development survey])
* 1.88 billion hCards (per [[Yahoo]] SearchMonkey)
* 36 million hCalendar events (ibid)
 
* XFN -> Social Graph API -> Web as Social Network / Address Book
 
== Résolution de Problématiques ==
=== AUTEURS et ÉDITEURS ===
Authors and publishers are perhaps the most important constituency in the microformats community. There are more of them than there are developers, programmers, parsers, etc. and they're the ones that solved the chicken-egg problem by publishing microformats even before tools were available for consuming them.
 
Therefore we must first address author/publisher general issues with 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?'''
 
Currently the simplest hCard:
<source lang=html4strict>
<span class="vcard">
  <span class="fn">
    Chris Messina
  </span>
</span>
</source>
 
requires 2 elements (nested, with perhaps at least one being pre-existing), and 2 class names.
 
Web authors/designers are used to the simplicity of most HTML tags, e.g. to mark up a heading:
 
<source lang=html4strict>
<h1>Chris Messina</h1>
</source>
 
requires just 1 element.
 
[http://zeldman.com/ Jeffrey Zeldman] pointed out this apparent perceived incremental complexity (2 elements vs 1) during a microformats workshop in 2009 in New York City.
 
'''How can we make microformats just as easy?'''
 
'''Proposal: allow root class name only.'''
 
This would enable:
 
<source lang=html4strict>
<h1 class="vcard">Chris Messina</h1>
</source>
 
requiring only 1 class name for the simplest case.
 
 
==== renommage pour utilisabilité ====
Otherwise known as, choosing one form of consistency over another.
 
'''Can we do even better?'''
 
One of the most common questions asked about hCard is:
 
[[hcard-faq#Why_does_hCard_use_vcard_as_the_root_class_name|Why does hCard use vcard as the root class name?]]
 
This slight inconsistency between the name of the format and the name of the root class name consistently causes confusion in a large percentage of newcomers to microformats.
* See [[issues#hcard-vs-vcard-name]] for details/links.
 
Though in microformats we believe very strongly in the [[principle]] of [[reuse]], we have to admit that in this case experience/evidence has shown that this may be a case where we re-used something too far beyond it's original meaning. Thus:
 
'''Proposal: use root class name "hcard" instead of "vcard" for future hCards.'''
 
This would result in:
 
<source lang=html4strict>
<h1 class="hcard">Chris Messina</h1>
</source>
 
making the simple case even simpler:
 
Just 1 additional class name, named the same as the format you're adding.  Think hCard, markup class="hcard".
 
At a minimum for compatibility we should document that parsers should accept "hcard" as an alternative to "vcard" as the root class name for hCard 1.0, and similarly for hCalendar 1.0: "hcalendar" in addition to "vcalendar", "hevent" in addition to "vevent".
 
However, for [[microformats-2-fr|microformats 2]] we are going to distinguish root class names further by using an "h-" prefix (e.g. "h-card"). Read on to understand why.
 
==== simplifier pour n'avoir besoin que d'un seul élément ====
It's very important for the simple case to be as simple as possible, to enable the maximum number of people to get started with minimum effort. (The idea of using a single class name for a microformat was proposed by Ryan Cannon in 2006 specifically [[hcard-implied|for hCard]], and rediscovered by [[User:Tantek|Tantek]] in 2010 and subsequently generalized to all microformats.)
 
From there on, it's ok to require incremental effort for incremental return.
 
E.g. to add any additional information about a person, add explicit property names.
 
'''How does this simple root-only case work?'''
 
* root class name reflects name of the microformat
* every microformat must require at most 1 property (preferably 0)
** admit that requiring a field in an application just results in noise (the 90210 problem - apps which require zip code get lots of false 90210 entries), and specify that any application use cases which appear to "require" specific properties must instead define how to imply sensible defaults for them.
* when only a root class name is specified, imply the entire text contents of the element as the value of the primary property of the microformat. e.g.
** "hcard" implies "fn"
** hcalendar event - "hevent" - implies "summary"
** "hreview" implies "summary"
** "hentry" implies "entry-summary" (perhaps collapse into "summary" - in practice they're not sufficiently semantically distinct to require separate property names)
** '''OR''' instead of making the one implied property be vocabulary specific, introduce a new generic (applicable to all vocabularies) 'p-name' property (subsuming hCard's 'fn'). See [[microformats-2-brainstorming#further_simplifications|microformats 2 brainstorming: further simplifications]] for latest thoughts along these lines, including the following specific mark-up implied generic properties across all microformats (based on existing published markup use-cases)
*** 'p-name'
*** 'u-url'
*** 'u-photo'
 
==== ensembles plats de propriétés ====
'''What more can we simplify about microformats?'''
 
Numerous individuals have provided the feedback that whenever there is more than one level of hierarchy in a microformat, many (most?) developers get confused - in particular Kavi Goel of Google / Rich Snippets provided this feedback at a microformats dinner.  Thus depending on multiple levels of hierarchy is likely resulting in a loss of authorability, perhaps even accuracy as confusion undoubtedly leads to more errors. Thus:
 
'''Proposal: simplify all microformats to flat sets of properties. '''
 
What this means:
* all microformats are simply an object with a set of properties with values.
* no more subproperties- drop the notion of subproperties.
* use composition of multiple microformats for any further hierarchy, e.g. the "location" of an hCalendar event can be an hCard, or the "agent" of one hCard can be another hCard.
 
For example for hCard this would mean the following specific changes to keep relevant functionality:
* drop "n", promote all "n" subproperties to full properties
** given-name, family-name, additional-name, honorific-prefix, honorific-suffix
* treat "geo" as a nested microformat
* treat "adr" as a nested microformat (what to do about adr's "type"?)
* treat "org" as a flat string and drop "organization-name" and "organization-unit" (in practice rarely used, also not revealed or ignored in contact management user interfaces - e.g. Address Book)
 
Example: add a middle initial to the previous example Chris Messina's name, and markup each name component:
 
<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:
# use of an explicit span with "fn" to markup his entire formatted name
# use of the abbr element to explicitly indicate the semantic that "R." is merely an abbreviation for his additional-name.
 
==== distinguer les propriétés des autres classes ====
Current microformats properties re-use generic terms like "summary", "photo", "updated" both for ease of use and understanding.
 
However, through longer term experience, we've seen sites that accidentally drop (or break) their microformats support (e.g. Upcoming.org, Facebook) because web authors sometimes rewrite all their class names, and either are unaware that microformats were in the page, or couldn't easily distinguish microformats property class names from other site-specific class names.
 
This issue has been reported by a number of web authors.
* See: [[issues#class-collisions]]
 
Thus microformats 2 uses ''prefixes'' for property class names, e.g.:
* '''p-summary''' instead of ''summary''
* '''u-photo''' instead of ''photo''
* '''dt-updated''' instead of ''updated''
 
Such prefixing of all microformats class names was first suggested by Scott Isaacs of Microsoft to Tantek on a visit to Microsoft sometime in 2006/2007, but specifically aimed at making microformats easier to parse. At the time the suggestion was rejected since microformats were focused on web authors rather than parsers.
 
However, since experience has shown that distinguishing property class names is an issue for '''both web authors and parser developers''', this is a key change that microformats 2 is adopting. See the next section for details.
 
=== 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"