value-class-pattern-fr

<entry-title>Modèle de Classe Value</entry-title>

Le modèle de classe "value" provient de l'extraction de valeur dans la hCard.

Les auteurs croient que le modèle-de-classe-value est désormais complet et prêt à l'emploi pour le balisage. Les implémenteurs sont encouragés à mettre leurs sites à jour et fournir un feedback. Remarque, le comportement précis du parsage pourrait être modifié en réponse aux feedbacks des implémenteurs, mais les méthodes sont stables. Vous devriez suivre cette page pour les mises à jour.

Voir aussi, l'annonce sur le blog (à traduire).

Editeurs

Ben Ward

Tantek Çelik

URL raccourcie

http://tr.im/ClasseValue

Traduction en cours

Christophe Ducamp

Parfois, seule une partie d'un élément de contenu doit être utilisée comme la valeur d'une propriété d'un microformat. Ceci peut arriver quand une propriété a des sous-propriétés optionnelles, telles que tel: type et tel: value dans la hCard. D'autres fois, la structure la plus appropriée pour une propriété peut inclure d'autre contenu.

A ces fins, le nom spécial de classe value est utilisé pour marquer l'extraction pertinente de la donnée provenant d'un élément de contenu plus grand.

Exemples Simples

Voici le marquage pour un numéro de téléphone de domicile :

fragment vCard :

TEL;TYPE=HOME:+1.415.555.1212

fragment hCard :

 <span class="tel">
   <span class="type">Home</span>:
   <span class="value">+1.415.555.1212</span>
 </span>

Dans ce cas, la value de tel est +1.415.555.1212, et non pas Home: +1.415.555.1212.

Parfois, la valeur pour une propriété microformats doit être découpée en plusieurs morceaux dans le contenu de l'élément représentant cette propriété. Plusieurs éléments avec un nom de classe "value" (les éléments value) peuvent être utilisés pour extraire et concaténer ces morceaux en une valeur unique pour les propriétés microformats qui attendent des chaînes simples ou des valeurs tel.

Un autre exemple, cette fois-ci utilisant un numéro de téléphone localisée (France) :

 <span class="tel">
   <span class="type">Home</span>:
   <span class="value">+33</span> (0) <span class="value">1 42 31 23 23</span>
 </span>

Dans ce cas, la data valide pour le numéro de téléphone est +33142312323, mais la façon dont le numéro de téléphone est présenté en France inclura le (0), pour un appel local. Ce qui veut dire, qu'à partir de n'importe où dans le monde vous pouvez composer +441423123123, ou à partir de la France vous pouvez composer 0142312323. La publication locale communément utilisée interfère avec la donnée, parce que composer +330142312323 est un numéro invalide.

Dans le marquage, deux classes value ciblent la partie de la chaîne du numéro de téléphone qui produit un numéro international valide, tout en permettant une présentation conventionnelle.

Un autre exemple, ajouter un nom de lieu à des coordonnées geo :

 <p>Je flâne dans Montmartre rue Junot
    <span class="geo">
      48° 53' 16.3206", 2° 20' 5.9712"
      (<span class="value">48.887867;2.3349922</span>)
   </span>
  </p>

Alors que la chaîne complète est un point geo, c'est seulement les coordonnées encodées en décimales qui doivent être consommées par un analyseur de microformats, ainsi la classe value l'isole de la forme en degrés, que l'auteur a inclus pour plus de complétude.

Analyse Basique

1. L'exemple de classe value ne s'applique uniquement qu'aux propriétés qui sont de simples chaînes, des valeurs énumérées, des numéros de téléphone et des datetimes. L'exemple de classe value n'affecte pas l'analyse des propriétés de type email, URL, URI, UID.
2. Là où un élément avec un tel nom de propriété de classe microformat a un descendant avec un nom de classe value (un élément "value"), les parseurs devraient utiliser la portion suivante de cet élément :
   1. si l'élément value est un élément img ou un élément area, utiliser alors la valeur d'attribut du alt de l'élément.
   2. si l'élément value est un élément abbr, utiliser alors la valeur d'attribut du title de l'élément.
   3. pour tout autre élément, utiliser son texte à l'intérieur.
3. Là où il y a plusieurs descendants d'une propriété avec un nom de classe de value (plusieurs éléments value)
   1. si la propriété microformats attend une chaîne simple, une valeur énumérée ou un numéro de téléphone, alors les valeurs extraites des éléments value devraient être concaténées sans insérer de caractères supplémentaires ou d'espace-blanc.
   2. si la propriété microformats attend une valeur datetime, voir la section Date Time Parsing.
4. Les descendants avec la classe value ne doivent pas être parsées plus profond qu'à un niveau. Ce qui veut dire, là où il y a un élément foo avec la classe value

qui a un descendant bar avec la classe value, le contenu de foo est pris comme la value. L'imbrication d'éléments supplémentaires avec la classe value ne peut pas être utilisé pour isoler plus en profondeur une value de propriété.

par ex.

 <p class="description">
  <span class="value">
    <em class="value">Puppies Rule!</em>
    <strong>But kittens are better!</strong>
 </span>
</p>

Dans cet exemple, description a un enfant ‘value’, et cet enfant a une ‘value’ petitenfant. Néanmoins, l'analyse des classes value s'arrête au premier niveau, ainsi la data pour description est : <em class="value">Puppies Rule!</em><strong>But kittens are better!</strong>, pas simplement Puppies Rule!.

Values Date et time

Quelques propriétés microformats attendent une valeur datetime ISO8601, par ex. hCalendar dtstart et dtend ou hAtom published.

Les auteurs peuvent utiliser le modèle de classe value pour spécifier séparément la date et l'heure, qui sont alors combinés pour spécifier une valeur unique datetime.

Exemple :

<p>La rencontre "afterwork" aura lieu 
    <span class="dtstart">
        <abbr class="value" title="2009-05-19">ce Mardi</abbr> 
     à <span class="value">19:30</span>
    </span>
</p>

Produit :

DTSTART:2009-05-19T19:30:00

L'absence d'une timezone indique une datetime "flottante", qui est une datetime indépendant de tout fuseau horaire particulier. Des exemples de datetimes flottantes pourraient être une alarme de réveil que vous paramétrez pour sonner à 8h00, ou un jour de travail ordinaire comme 9h00-17h00.

Analyse Date et heure

Pour toutes les propriétés date et heure (comme définies dans leurs spécifications respectives microformats), les règles suivantes s'appliquent en plus de celles (et dans certains cas les remplacent) des règles de modèles de parsage de classe value vues au-dessus.

Quand un élément "value" est trouvé, parsez une valeur à partir de l'élément comme suit :

• si l'élément est un élément img ou un élément area, utiliser alors la valeur d'attribut alt de l'élément.
• si l'élément est un élément abbr, utiliser alors la valeur d'attribut title de l'élément.
• pour tout autre élément, utiliser son texte à l'intérieur.
• si la valeur a à la ois une date spécifiée ISO8601 et une heure spécifique, utilisez ceux-ci et arrêtez de chercher des éléments "value".
• si la valeur a *seulement* une date spécifique, spécifiquement, correspondant aux modèles de dates suivants ISO8601 (c.a.d. tels que documentés dans le résumé Wikipedia de ISO8601)
  • AAAA-MM-JJ
  • AAAA-JJJ
  • alors utiliser cela comme la valeur de date. Pour les besoins du modèle de classe value, les tirets "-" séparants les années, mois, jour et/ou jour ordinal sont requis.
  • ignorer tous les éléments complémentaires "value" qui spécifient la date.
• si la valeur a *seulement* une heure spécifique (avec ou sans fuseau horaire), parsez la pour une valeur time comme suit :
  • HH:MM:SS-XX:YY
  • HH:MM:SS+XX:YY
  • HH:MM:SS-XXYY
  • HH:MM:SS+XXYY
  • HH:MM:SSZ
  • HH:MM:SS
  • HH:MM-XX:YY
  • HH:MM+XX:YY
  • HH:MM-XXYY
  • HH:MM+XXYY
  • HH:MMZ
  • HH:MM
  • HH sont les "heures" en 24 heures dans le temps, de 00 à 24, avec un 0 optionnel placé devant pour les valeurs inférieures à 10.
  • MM sont les minutes de 00 à 59
  • SS sont les secondes optionnelles de 00 à 59 (60 pour une seconde). Si omis, inférez 00.
  • XX est le décalage horaire du fuseau, de 00 à 12.
  • YY est le décalage en minutes du fuseau horaire, de 00 à 59, même si en pratique ne sont utilisés que des décalages de 00, 15, 30, 45 minutes dans les fuseaux horaires globaux.
  • Z est le 'Z' littéral pour indiquer GMT.
  • Pour les besoins du modèle de classe value, les deux points ":" séparant heure, minutes et secondes sont requis.
  • Néanmoins les deux points ":" séparant les heures et minutes de tout décalage horaire sont "optionnels" et non recommandés afin de faire en sorte qu'une indication de fuseau horaire ne soit pas confondue avec un horaire.
  • (NOTE : considérez un suffixe non sensible à la casse { }"am"|{ }"a.m." pour traiter une valeur HH value de 12 sous 00, ou un suffixe non sensible à la casse { }"pm"|{ }"p.m." pour ajouter 12 à la valeur HH inférieure à 12 - selon l'article de Wikipedia sur l'horloge de 12 heures)
  • ignorez tous les autres éléments "value" qui spécifient l'heure.
• si la valeur a *seulement* un timezone spécifique, parsez-la comme suit
  • -XX:YY
  • +XX:YY
  • -XXYY
  • +XXYY
  • Z
  • ignorez tous les autres éléments "value" qui spécifient la timezone.

Si en parsant les éléments "value", au moins une date spécifique est trouvée, alors la "value" est par dessus-tout valide, et le parseur assemble la valeur datetime en concaténant la date spécifique, "T" et l'horaire spécifique (si l'heure a été spécifiée, avec 00 secondes implicite si aucune seconde n'est fournie), et une timezone spécifique (si la timezone et l'horaire spécifique ont été spécifiés).

• AAAA-MM-JJ - aucun horaire spécifié
• AAAA-MM-JJTHH:MM:SS - heure spécifiée mais pas de timezone. C'est une heure flottante.
• AAAA-MM-JJTHH:MM:SS-XXYY ou
• AAAA-MM-JJTHH:MM:SSZ ou
• AAAA-MM-JJTHH:MM:SS+XXYY - à la fois l'heure et la timezone ont été spécifiées

dérivation et tests

Le comportement des valeurs date et time dans le modèle de classe value a été intialement brainstormé sur la page value-excerption-pattern-brainstorming et dérivé à partir de cette analyse et des retours. Pour les curieux, les détails historiques peuvent être trouvés là, avec des idées complémentaires pour les extensions.

Les tests de séparation et concaténation de date et time sont disponibles : value-excerption-dt-separation-test

Parser une valeur provenant d'un attribut title

Le nom de classe value-title permet à l'auteur d'indiquer la donnée value pour une propriété parent contenue dans l'attribut title d'un élément, plutôt que dans le texte à l'intérieur.

Ceci peut s'utiliser pour fournir un synonyme dans le contenu, ou utilisé pour publier tranquillement des formes alternatives d'information pour le parsage de microformats, sans impacter sur la consommation du contenu.

Par exemple, vous pouvez utiliser des localisations ponctuelles avec des dates :

<p>Ce fût  
 <span class='dtstart'>
  <span class='value-title' title='2008'>l'année dernière</span>
 </span>
  que je pris conscience que mon addiction au tabac pourrait coûter très cher à la Sécurité Sociale.
</p>

Les règles de parsage pour value-title sont les mêmes que celles pour value au-dessus, avec le changement qui suit :

• Là où une propriété microformats a un élément enfant avec le nom de classe de value-title, le contenu de l'attribut title de cet élément doit être parsé, plutôt que la portion de l'élément qui devrait être parsé pour un nom de classe de value.

Utiliser value-title pour publier des données-machines

L'usage initial de value-title est utilisé pour publier des formes alternatives, parsables des valeurs de propriétés dans un contexte visible sans l'utilisation de l'élément abbr dont la sémantique supporte déjà l'interprétation de l'attribut 'title' comme une forme plus étendue, plus précise du contenu.

L'expérience a montré qu'il existe quelques cas dans les microformats où un certain nombre d'auteurs veulent inclure une valeur précise et parsable pour une propriété mais ne veulent pas qu'elle soit visible dans leurs pages, ni même sous forme de petite bulle.

Par exemple le datetimes complet ISO8601 peut être confus pour les lecteurs de la page (que ce soit sous forme de bulle ou quand c'est lu par un lecteur écran), et les valeurs énumérées telles que la sous-propriété type de la propriété tel de la hCard utilise des termes US-English, qui ne font pas partie de pages dans toute autre langue.

Le fait que ces scénarios se sont avérés être des obstacles pour un bon nombre d'auteurs, pour ces cas, et ceux-ci seulement, il existe une extension approfondie de l'extraction de valeur. Cette extension permet une forme parsable de la propriété pour être publiée 'en silence' et immédiatement adjacente avec le contenu visible local y afférent.

Voici un exemple, avec l'usage requis d'un premier élément enfant avec le nom de classe value-title :

<p class='tel' lang='fr-fr'>
  <span class='type'>
    <span class='value-title' title='cell'> </span>
      mobile
    </span>
  <span class='value'>+33 647 730 000</span>
</p>

La valeur cell est parsée pour la sous-propriété 'type', mais mobile est présenté à l'utilisateur.

Dans le cas de dates :

<p class='dtstart'>
  <span class='value-title' title='2009-06-12T09:28-0600'> </span>
  le 12 juin 2009, aux alentours de 9h30
</p>

Un analyseur de microformats lira le format datetime ISO8601 2009-06-12T09:28-0600, mais les utilisateurs ne verront que le 12 juin 2009, aux alentours de 9h30. Le test a montré que la datetime ISO8601 au-dessus n'est pas du tout présentée à quelque utilisateur.

Parsage donnée-machine value-title

Browsers collapse the value-title span down to a width of 0, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty span element.

We conducted thorough testing of these parsing behaviors to ensure accessibility.

Note: Whilst the value-title element is more gracefully written without whitespace inner-text (or as self-closing <foo /> element in XHTML), current tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <span class='value-title'> </span>, including a single whitespace character between the opening and closing tag, is the required pattern for authors, at this time.

Parsing this final value-title extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of DRY violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class value-title is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

• The ‘empty’ value-title element must be the first, non-whitespace child of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
• The ‘empty’ value-title element can only be used for specific properties. Microformat specifications must explicitly state which properties may be used with this extension of the value-class-pattern.
• Where an ‘empty’ value-title element is to be used as the single property value, it must be the only such value content. That is, the first instance of a conforming value-title element overrides all other value and value-title siblings and/or cousins.
• Tools written to perform Conformance Testing and/or Validation of microformats should attempt to compare the machine-data and human legible forms of the property data, and advise authors if the forms do not match.

Utilisation limitée de value-title

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats principes being compromised: visibility and DRY. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

1. First, try to directly specify microformats property values inline (the most visible, no duplication),
2. Then consider using the value-class pattern
   1. Including multiple value elements for date and time properties
3. and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, only the following types of properties should allow the value-title pattern.

• ISO8601 date, datetime, timezone, and duration values
• Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
• Co-ordinates (such as the geo 'latitude' and 'longitude' properties)
• Telephone number properties (e.g. the hCard 'tel' property)

The machine-data page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on value-class-pattern-tests.

In future use, specification authors may inherit use of value-title by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and DRY.

FAQ

This section is informative.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like value-class-faq).

• Why use an 'empty' element? Why not embed data in the class attribute?
  • The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states class is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
• Why use an 'empty' element? Why not make up a new attribute, like ‘data’?
  • Microformats exist and function in valid HTML4 and XHTML1. Those are the current standards for web development, and microformats exist for use now. In the future, perhaps future revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistant document structure (where machine-form and human-form data are siblings).
• The title attribute should only be used for content!
  • The title attribute _is_ used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.

You can also refer to the general Microformats FAQ and principles.

Exemples dans la jungle

Cette section est informative.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page (like value-class-examples-in-wild).

• George Brocklehurst's activity stream and blog use "value-title" for hAtom published property
• Ben Ward's home page uses:
  • "value-title" for hCard bday property
  • "value-title" for hAtom updated property
• microformats.org uses:
  • "value-title" for hAtom updated property in [microformats.org blog postss]]
  • date and time value separation for hCalendar dtstart property in microformats.org recent and upcoming events wiki page

Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.

Implémentations

Cette section est informative.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page (like value-class-implementations).

• Operator has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
• ... add your implementation(s) that parse or generate the value-class-pattern here, along with which features you support (hopefully all!) and note any limitations if any.

Pages en Rapport

Cette section est informative.

• value-excerption-pattern-issues
• hCard: Value Excepting
• value-excerption-pattern-brainstorming
• Machine Data in Microformats