hcard-brainstorming-fr

From Microformats Wiki
Jump to navigation Jump to search

hCard Brainstorming

Cette page est pour brainstormer sur les différentes utilisation et les détails de hCard.

Auteurs

Contributeurs

Traduction en cours

Problèmes Etant Résolus

Quelques-uns des problèmes que hCard aide à résoudre :

  • devoir saisir les cartes de visite qui deviennent obsolètes (s'abonner à la place à la hCard syndiquée de quelqu'un).
  • "mise à jour de votre info de contact email" ennuyeuse à partir de différents services d'informations de contacts centralisés.

Exemples

  • Voir exemples hCard, qui fournit plusieurs exemples illustrés instructifs, tout comme des exemples de hCard 1:1 pour chaque exemple dans la RFC 2426.

Utiliser la RFC2806 avec hCard

La RFC 2806 définit le schéma téléphone "tel:", "fax:" et "modem:" pour gérer les communications téléphoniques avec des URIs de la même façon que "mailto:" est défini pour l'email. Cela fait partie de la liste des schémas enregistrés par IANA : Uniform Resource Identifier (URI) SCHEMES 

tel   telephone [RFC2806]
fax   fax       [RFC2806]
modem modem     [RFC2806]

Il est pratique d'écrire votre numéro de téléphone comme ceci. 

<a class="tel"      href="tel:+1-919-555-7878">+1-919-555-7878</a>

ou même : 

<a class="tel"      href="tel:+1-919-555-7878">Le téléphone de Monsieur Bloïc</a>

Vous pouvez ajouter du support pour le "tel:" vers votre bureau et vers votre navigateur

  • Pour Gnome, edit ~/.gnome/Gnome et ajoutez quelque chose à la section vers les gestionnaires URL. (Dan Connolly utilise ça pour recevoir galeon afin de lancer telnum à partir de sources telagent pour des URIs tel)
  • Dans Mozilla, Dizzy
  • Dans Internet Explorer, Asynchronous Pluggable Protocols

Sur le front CSS... Vous pourriez ajouter par exemple automagiquement une icône. J'ai mis la propriété !important pour ceux qui veulent l'ajouter à leurs propres feuilles de style dans leurs navigateurs, ainsi ils connaissent les types de liens au moment de naviguer. 

a[href^="tel:"]:before {
    content: '\260f  ' !important;
    padding-left: 20px !important; }

a[href^="mailto:"]:before {
    content: '\2709  ' !important;
    padding-left: 20px !important; }

Encoder des attributs "modernes"

Depuis que la vCard a été initialisée, différentes technologies interactives et schémas d'adressage ont été largement adoptés. Bien qu'il n'y ait pas de propriétés spécifiques pour ces technologies / schémas d'adressage, elles peuvent être capturées sous des URLs ou des adresses email.

Ceci a été désormais couché pour la plupart. Voir :

http://microformats.org/wiki/hcard-examples-fr#Nouveaux_Types_d.27Information_de_Contact

Reste à régler :

  • les adresses iChat mac.com , stocker simplement "@mac.com" email addresses, par ex.
    • <a class="email" href="mailto:loic@mac.com">...
  • MSN Instant Messenger, vous pouvez stocker de simples adresses email "@hotmail.com" ou "@msn.com" ou "@passport.com" email addresses.
  • Internet Relay Chat (IRC), utilisez "irc:" URLs.

Styles CSS

Non seulement vous pouvez créer une sémantique avec les valeurs hCard, mais vous pouvez tout aussi bien ajouter des styles CSS. Vous êtes libre de styler les termes avec les valeurs de hCard, mais ici vous pouvez lister quelques idées sur la façon de styler les termes.


Si vous voulez encoder des données hCard, mais ne voulez PAS l'afficher dans le code HTML, alors vous pouvez cacher ce tag dans la CSS avec le code suivant : 

<span style="display: none">Donnée Cachée</span>

Les applications de transformation trouveront encore les données et les utiliseront au moment de convertir les hCards en vCards.

Auto-Découverte

vCard auto extraction

Il existe actuellement un débat sur la meilleure façon d'ajouter un lien d'autodécouverte vers votre HTML pour extraire la vCard.

Sur la page avec l'encodage hCar, le meilleur lien serait comme suit :

<link rel="alternate" type="text/directory" href="..." /> cette page HTML est une vue alternative de la vCard.

Le type approprié et enregistré pour les entités vCard est “text/directory”, comme défini dans la RFC 2425 Internet “A MIME Content-Type for Directory Information”. RFC 2426, “vCard MIME Directory Profile”, spécifie le profil vCard pour les entités “text/directory” entities, que le profil champ header MIME/HTTP “Content-Type” indiquerait avec un paramètre “profile” quelle valeur est “VCARD”.

Il n'est pas clair si l'attribut HTML/XHTML “type” permet des valeurs avec les paramètres. Le 2004-05-23, Björn Höhrmann a envoyé au HTML Working Group une demande de clarification sur la problématique.

Quand on est sur une page différente, référencer cette page encodée dans le href ne serait pas une vue alternative de la page en cours. Par conséquent rel="alternate" peut ne pas être approprié. Le problème de la valeur rel à utiliser est plus grand que les liens vers les vCards.

hCard vers les relations hCard

Il existe plusieurs type de relations hCard vers hCard, ce qui veut dire, une hCard hyperliant vers une autre hCard qui bénéficierait des valeurs rel explicites décrites dans la relation spécifique.

mini hCard vers hCard étendue

Peut-être que le type le plus commun du lien de hCard vers hCard, par ex. d'une page personnelle ou blog vers la page de contact de la personne/à propos, peut-être constituée de seulement un nom et un URL, qui pointe vers une hCard étendue. Exemples dans la junge :

Dans cette instance, les valeurs rel possibles pourraient comprendre :

  • rel="expanded"
  • rel="definitive" - le problème avec ça est que la hCard étendue n'est pas nécessairement une version définitive.
  • rel="canonical" - de la même façon, la hCard étendue n'est pas nécesairement un URL canonique. Ce peut simplement être *une* version étendue, pas *la* version étendue.

Les valeurs rel qui suivent ont été suggérées, mais ne sont vraiment pas une bonne idée du fait qu'elle sous-tendent une dépendance pour ajouter une nouvelle valeur rel pour n'importe quel nouveau microformat qui pourrait avoir une mini version pointant vers une version plus étendue :

  • rel="author"
  • rel='contact'
  • rel="contactinfo"
  • rel='hcard'
  • rel='person'

Voici quelques valeurs plus génériques qui ont été suggérées et qui peut-être font encore moins de sens :

  • rel='microformat' - ceci ne fait aucun sens quand vous imaginez un monde où presque chaque page contiendra des microformats.
  • rel='about' - qu'est-ce que "about" à à faire à propos d'une personne ou même de la paternité d'auteur ?
  • rel="profile" - devrait être réservé pour signifier qu'il y a ici un profil XMDP pour la page en cours.
  • rel='PIM' - pas sûr de la manière dont cela puisse faire quelque sens.

mini hCard vers site distant

Selon les instructions trouvées dans hCard-exemples pour baliser les personnes dans les blogrolls, vous pourriez avoir une hCard de votre site pour une autre personne qui lie ensuite vers le site web de cette autre personne. Devrait-il y avoir une valeur rel qui indique cette "mini-hcard" pour la relation "person" ?

mini hCards et liens hCard étendus à proximité

Quelques auteurs incluent des mini-hCards sur leurs pages personnelles (cad dans leurs billets de blogs) et à cette heure ces mini-hcards ne pointent pas vraiment vers des versions étendues. Néanmoins, parfois elles sont un lien séparé mais à proximité sur la même page comme "à propos" ou "contact" qui lie vraiment vers une hCard étendue.

Par ex. sur FactoryCity, les billets de blogs ont des mini-hcards pour "published by", e.g. (espace blanc ajouté pour la lisibilité) : 

Published by 
<span class="vcard author">
 <a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
  Chris Messina
 </a>
</span>

Sur ces même pages de blogs, il y a un lien étiqueté "Contact Information" qui lie vers http://factoryjoe.com/blog/hcard/ qui a une hCard avec plus d'information comme le numéro de téléphone, l'anniversaire, etc.


Auto-Découverte pour XFN

Un auteur aura généralement son information XFN sur une page spécifique, plutôt que sur toutes les pages. En particulier, une page spécifique à partir de la page d'accueil de son blog et par conséquent ce serait utile d'avoir une valeur rel explicit pour aider à l'auto-découverte de l'information XFN.

Ceci fût suggéré par Jens Alfke le 20050606 durant le dîner des blogueurs WWDC.

améliorations geo

Ces améliorations s'appliquent tant à geo qu'à hCard.

J'ai (Tantek) vu des exemples où il existe une présentation visible/cliquable d'un point sur une crte, et le désir d'inclure l'information lisible par une machine geo avec le même élément, par ex. quelque chose comme : 

<abbr class="geo" title="machine-readable-geo-info">
 point lisible par un humain/cliquable sur une carte
</abbr>

Mais pour faire ça nous devons spécifier une syntaxe pour placer tant la latitude et la longitude dans l'attribut title comme l'info-geo-lisible-par-la-machine.

Heureusement, il existe déjà une syntaxe pour cela, dans la RFC vCard 2426 3.4.2 : 

   Type value: A single structured value consisting of two float values
   separated by the SEMI-COLON character (ASCII decimal 59).

   Type special notes: This type specifies information related to the
   global position of the object associated with the vCard. The value
   specifies latitude and longitude, in that order (i.e., "LAT LON"
   ordering).

...

   Exemple type :

        GEO:37.386013;-122.082932

Par conséquent : 

<abbr class="geo" title="37.386013;-122.082932">
 Mountain View, CA
</abbr>

Je pense qu'il n'y a vraiment pas à se casser la tête, parce que les règles pour parser "geo" sotn simplément modifiées en :

latitude longitude raccourci

Si une propriété "geo" manque des sous-propriétés explicites "latitude" et "longitude", alors la propriété "geo" est traitée comme toute autre propriété de chaîne (à savoir les règles suivantes pour parser <abbr title>, <img alt> etc.), où cette chaîne de valeur a la même syntaxe littérale spécifiée dans RFC 2426 section 3.4.2 : une valeur unique structurée constitué de deux valeurs flottantes séparées par le caractère POINT VIRGULE (ASCII decimal 59), spécificant la latitude et la longitude, dans cet ordre d'apparition.

liens geo

En outre, les personnes peuvent publier des Google Maps comme ça :

<a href="http://maps.google.com/maps?q=37.386013+-122.082932">ce spot</a>

(N.B. J'ai essayé et échoué pour obtenir Yahoo Maps et local pour faire quelque chose d'inteligent tant avec "37.386013;-122.082932" que "37.386013 -122.082932").

Est-ce que ça vaut la peine de permettre à cela d'être un geo ?

Je soulève ça pour m'assurer que ce sera considéré.

Néanmoins, mon premier sentiment est NON pour deux raisons :

  1. Aucun exemple de ce type n'a été documenté ou vu à cette heure (je n'en ai certainement vu aucun).
  2. Cela sous-tendrait des exigences supplémentaires de parsage qui vont surtout aller pour être spécifiques à un site/domaine, et encoder une syntaxe de paramètre de requête particulière dans un format semble être une mauvaise idée (contre le principe de décentralisation).

Ceci pourrait être mitigé si les services de cartographie acceptait simplement la syntaxe littérale vCard GEO "37.386013;-122.082932", par ex. http://maps.google.com/maps?q=37.386013;-122.082932 (qui ne fonctionne pas à cette heure) puis nous pourrions produire une règle simple comme pour les hyperliens, parser l'attribut href pour une valeur geo à la fin du href, délimitée avant la valeur par a "=" (ou peut-être "/" pour des services qui utilisent des URLs plus amicales).

  • considérer aussi <a href="http://www.rhaworth.myby.co.uk/oscoor_a.htm?SJ870099_region:GB_scale:25000" title="52.6866;-2.1937">SJ870099</a> qui est largement utilisé (à cette heure sans attribut geo-title) (Wikipedia, et al). Peut-être que nous devrions aussi supporter title="various maps of 52.6866;-2.1937" de façon que l'attribut title puisse être utilisé comme il était initialement destiné.

altitude

Quelques types ont demandé "altitude" comme une extension pour GEO. Actuellement, nous rejetons toutes les extensions propriété/valeur vers hCard/vCard.

radius/zoom

Kevin Marks a demandé "radius" ou "zoom" comme une extension pour GEO. Actuellement nous rejetons toutes les extensions propriétés/valeurs vers hCard/vCard.

ISO 19136

When it comes to anything geospatial, any unadorned / simple encoding must remain upwardly-compatible with the more sophisticated GML schema (Geography Markup Language ) which is also known as ISO 19136. This is so that all the fundamental nuances underpinning geocoding ( different datums, different projections, elevation, etc etc ) can ultimately ( or sooner ? ) be completely accounted for.

If you don't know/supply your Coordinate Reference System CRS identifier, your location could fall 100s of metres away from the position intended ie plot in the wrong location on a map. Appendix B of draft ISO/DIS 6709 highlights the variation among three commonly used systems.

ISO/DIS 6709

Draft International Standard ISO/DIS 6709 specifies the standard representation of geographic point location by coordinates. Section 6.3 notes the elements required required for geographic point location:

In this International Standard, geographic point location shall be represented by five elements:

  • a coordinate reference system identification;
  • coordinate representing “x” horizontal position such as latitude;
  • coordinate representing “y” horizontal position such as longitude;
  • for three-dimensional point locations, a value representing vertical position through either height or depth;
  • metadata associated with geographic point location(s) (ISO 19115)

Annex H details the ISO standard for text string representation of point location.

H.6 Format

H.6.1 Elements shall be combined in a point location string in the following sequence:

a) Latitude

b) Longitude

c) if represented, height or depth

d) Coordinate Reference System identifier


H.6.2 The number of digits for latitude, longitude and height (depth) shall indicate the precision of available data.


H.6.3 There shall be no separator between the elements for latitude, longitude, height (depth) and CRS. NOTE The use of designators "+", "-" and "CRS" preceding the value part of each element permits the recognition of the start of each element and the termination of the previous one.


H.6.4 The point location string shall be terminated. The terminator character shall be a solidus (/), unless otherwise specified in the documentation associated with interchange.

It differs from the notation of vCard, for example.


If ISO6709 is used, it is likely to be able to write as follows. 

examples
<abbr class="geo" title="+40-075CRSxxxx/">
 Point represented as Degrees
</abbr>

<abbr class="geo" title="+401213.1-0750015.1+2.79CRSxxxx/">
 Point represented as Degrees, minutes, seconds and decimal seconds, with +2.79 a height or depth as defined through the CRS.
</abbr>

ISO 19115

ISO 19115:2003 defines the schema required for describing geographic information and services. It provides information about the identification, the extent, the quality, the spatial and temporal schema, spatial reference, and distribution of digital geographic data.

Geospatial Metadata

Geospatial metadata 'place category features' would enable map mashups of microformatted information, for example, show me a map of the nearest place of worship and associated disabled carparks. http://www.linz.govt.nz/resources/esa-appl-schema-v1-9-5/esa-46.html#1804

Problématiques avec les Applications vCard

Voir vcard-implémentations.

Questions Ouvertes

Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile. 

...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
...

-- Brian Suda

Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example: 

<a href="http://mywebsite.com/" class="fn n">
    <span class="given-name">John</span>
    <span class="other-names">Q.</span>
    <span class="family-name">Public</span>
</a>

When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN: 

John Q. Public

    John
    Q.
    Public

Either the white-space is preserved or it is not. Which should the transforming applications render?

-- Brian Suda

A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.

-- Tantek

Many of the Questions and Answers are relevant to both ["hCal"] and hCard.

Q: Would it be appropriate to wrap the name of the vCard owner with ? This may give the hCard some added semantic value in the XHTML document. 

<span class="agent"> 
 <span class="vcard">
  <span class="email">
   <a class="internet" href="mailto:jfriday@host.com">
    <dfn>
       <span class="fn">Joe Friday</span>
    </dfn>
   </a>
  </span>
  <span class="tel">+1-919-555-7878</span>
  <span class="title">Area Administrator, Assistant</span>
 </span>
</span>

-- Ben Ward

Applications

Les Applications qui sont conscientes des hCards ou qui peuvent convertir les hCards en formats vCard.

favelet(s) de copie hCards

  • Je pense qu'un Favelet fonctionnerait bien ici. Quand vous trouvez une page qui est compatible hCard, vous cliquez sur le favlet et vous obtenez vous-même une vCard. C'est fait ! Voir X2V dans la section des implémentations de la spec hCard.

Icônes distribuées de commentateurs

  • Voir using hCards in your blog pour un exemple de hCards utilisées pour les auteurs des commentaires (commentateurs). Le système utilisé là, "Gravatars", est un site centralisé qui sert les icônes de commentateurs qui exige un login, etc.

Et si nous donnions à chaque commentateur l'option d'héberger sa propre icône ?

Une implémentation d'icône de commentateur distribué pourrait fonctionner comme ça :

  1. Vu l'URL d'un commentateur, chercher un élément <address> avec le nom de classe "vcard" sur l'URL du commentateut. L'élément <address> est supposé être l'information de contact pour la page. (voir hCard FAQ pour plus d'infos), aussi cela fait du sens.
  2. Puis, chercher le premier élément dans cette hCard qui ait un nom de classe de "logo".
  3. En espérant que cet élément soit un <img>, et si oui, utiliser son src pour recevoir l'icone du commentateur.
  4. Basta. Vous avez des icônes de commentateurs distribuées !

Prévention du Spam

hCard utilise les liens mailto: et par conséquent, il hérite automatiquement des inconvénients des liens mailto: : Ces liens peuvent être facilement détectés par les spiders d'email (utilisé par les spammeurs).

Les adresses email sont piochées comme toute autre lien crawlé par un moteur de recherche et les crawleurs de confiance peuvent être dissuadés d'ajouter de l'emphase tout en indexant ces liens en incluant rel="nofollow" (Voir rel-nofollow). Néanmoins, les adresses email utilisées pour le spam sont crawlées par les spiders d'email qui ignoreront probablement cet attribut.

Il existe des moyens d'empêcher la détection d'adresses email par les simples spiders d'email, tout en retenant une totale compatibilité avec les applications (X)HTML. Un moyen commun est d'"encoder" le "m" de "mail" et "@" avec des entités caractères, à ce stade c'est imprudent de suivre une convention de seulement encoder les caractères spécifiques parce que les spiders email peuvent aussi piocher ça :

Exemple de lien original : 

<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>

Exemple de lien "encodé" (avec l'ajout de rel-nofollow) : 

<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;exemple.com">john.smith&#064;exemple.com</a>

Les simples spiders email qui ne font pas le décodage d'entité caractère ne pourront par conséquent pas trouver votre adresse email.

Note : Peut-être qu'il y a ou aura des spiders email qui peuvent décoder les entités, ainsi cette technique n'aidera que pour les spiders email de mauvaise qualité.

(Voir aussi : http://rbach.priv.at/Misc/2005/EmailSpiderTest)

Autres méthodes de prévention à considérer

  • Using server-side code to implement character entities randomly
  • Displaying the address in a way thought to be only human readable (thus breaking the link):
    • Using an image instead of text (could still be machine readable using OCR)
    • Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
  • Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
  • Pointing to an email form or other URL instead of an email address

Tutoriels

  • How to hCard encode entries in Popular blog software.
  • Good reasons to publish your hCard
    • as a business, get people to put you in their address book so they'll find you later
    • as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.

Parsage

Voir la page séparée parser hCard.

additions aux Post vCard

Quelques personnes ont trouvé la vCard limitée en termes de données/propriétés/champs qu'elles voulaient exprimer dans l'information de contact. Quelques implémentations utilisent les extensions vCard pour exprimer de telles informations.

Cette section est pour la documentation de telles additions suggérées. Remarquez que nous aurons besoin d'évidence empirique d'exeples véritables venant du *vrai monde* sur le Web de personnes publiant cette information comme une partie de l'information de contact, avant de considérer de telles ajouts/extensions.

  • altitude. Extrait de hcard-problématiques.
    • Aucune évidence fournie que l'information de contact sur le Web publie cette information.


TODO

  • Le profil hCard a besoin de vérification et peut-être d'un URL pour retrouver le véritable XMDP, plutôt qu'un texte <pre> sur une page wiki.
  • Compléter la traduction des exemples extraits de la spec vCard dans hCard, et la placer sur une page séparé d'exemples de hCard.
  • Créer un exemple "riche" mais réaliste de hCard, disons par exemple un commercial, qui veut mettre tout un paquet d'information de contact sur son site web afin de pouvoir être trouvé/contacté facilement.
  • Fournir des exemples sur la manière d'encoder des comptes de messagerie instantanée. Imaginer quels seraient les URLS mailto: ou aim: dans hCard et comment cela apparaîtrait dans vCard. Et jeter un oeil sur ce que les applications vCard font aujourd'hui des adresses IM.

Références

Références Normatives

Références Informatives

Autres Implémentations/Idées

  • Representing vCard Objects in RDF/XML This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
  • It would also be possible to convert XFN and hCard to FoaF and back.


Noms de composants Ambigus

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

  1. If the name is one word, attempt optimisation implicite du pseudo
  2. If the name is two words, attempt optimisation implicite de n
  3. For three or more words
    1. Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
    2. Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

Suggestions Acceptées

Donnée d'encodage Company sous une Business Card (proposition)

(Acceptée : http://microformats.org/wiki/hcard-fr#Info_Contact_Organisation )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that Apple Address Book supports this semantic when importing vCards.

See the Technorati Contact Info for an example.

Optimisation implicite "FN et N" (proposition)

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

HISTORIQUE :

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSITION :

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.

Suggestions Rejetées

Suggestion: The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example: 

<span class="vcard">
...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...
</span>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

Pages en rapport

La spécification hCard est un chantier en cours. Au fur et à mesure que des aspects supplémentaires sont discutés, compris et écrits, ils seront rajoutés. Ces idées, problématiques et questions sont maintenues sur des pages distinctes.

Retrieved from "http://microformats.org/wiki/index.php?title=hcard-brainstorming-fr&oldid=13236"