hcard-feedback-fr

hCard réactions

Les réactions générales à propos de hCard peuvent être fournies ici, et le(s) éditeur(s) feront de leur mieux pour essayer de se plier et d'accomoder à de telles réactions. Plus la réaction est spécifique, plus il y aura de chance qu'elle soit prise en compte. Pour les problématiques spécifiques avec la spécification (à l'inverse des problèmes généraux et réactions), utilisez svp la page hCard problématiques.

IMPORTANT : Lisez SVP avant la page hCard FAQ en donnant toute réaction ou pour soulever toutes les problématiques car vos réactions/problématiques peuvent avoir été déjà résolues ou traitées.

La réaction peut (et sera probablement) éditée et récrite pour une meilleure concision, clarté rationnalité et sous un point de vue aussi neutre que possible. Utilisez le gabarit fourni et ajoutez votre réaction à la fin de la section Réaction. Ecrivez bien votre réaction. — Tantek

Réactions

• 2006-11-15 soulevée par Lachy dans #whatwg (un canal IRC sur freenode à propos de The WHATWG).
  1. Je pense que la totalité de la spécification hCard a besoin d'être restructurée.
  2. C'est incroyablement difficile de travailler avec ce que chaque nom de classe signifie et comment les utiliser correctement.

• 2006-11-15 soulevée par hsivonen dans #whatwg.
  1. Sans connaître iCalendar ou vCard, c'est vraiment non-évident de voir ce à quoi s'adapteront les hCards ou les hCalendars. La partie normative est extrêmement courte et ne semble pas établir suffisamment clairement un mapping entre les microformats et les RFCs.
     • Ceci (et la seconde réaction de Lachy au point ci-dessus) devrait être résolu en clarifiant le mapping avec un meilleur usage du hCard profile qui mappe vraiment clairement les noms de classes vers les propriétés vCard properties et les sections de la spécification vCard qui les définit. - Tantek

• 2006-11-15 soulevée par Hixie dans #whatwg (et accord par Lachy et hsivonen).
  1. La spec hCard se lit basiquement comme un brainstorm, pas une spec normative.

• 2006-11-17 soulevée par Lachlan Hunt.
  1. Principes de Design XHTML Sémantique : Cette section devrait partir. Les lignes de conduite sur la façon d'écrire une spécification de microformats n'appartiennent pas à la spec elle-même.
  2. Format - Plus d'Equivalents Sémantiques : Les explications sur la façon d'utiliser correctement chaque propriété devraient être données avec chacune et toutes les propriétés, pas simplement en lister quelques-unes en haut avant que les propriétés n'aient été définies.
  3. Singulier vs. Pluriel : Il est peut clair de ce que veut dire les propriétés singulière vs plurielle. Ordinairement, un pluriel est un mot qui fait référence à plusieurs objets, mais dans cette spec, il est utilisé pour désigner une propriété qui peut être utilisée plus d'une fois. Cela ne fait pas de sens parce que la propriété elle-même n'est pas un pluriel. A côté de cela, cette section devrait partir. Le nombre de fois où une propriété peut être utilisée devrait être listé avec chaque description individuelle de propriété.
  4. Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
  5. Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
  6. Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
     • Property name
     • Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
     • Definition. (e.g. either copy the definition directly from vCard or provide a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
     • Usage
       • Contexts in which this property may be used
       • Content model (e.g. list of sub properties, expected elements, text, or whatever)
       • Syntax of the value (i.e. plain text, number, URI, etc.)
       • Elements this property may be used on
     • How to interpret the value (may link to relevant section in Conformance Requirements)
  • I second all of the above. Andy Mabbett 07:15, 17 Nov 2006 (PST)

Gabarit

Utilisez svp ce format (copiez et collez ceci à la fin de la liste pour ajouter votre réaction ):

• AAAA-MM-JJ soulevée par VOTRENOM.
  1. Voici la première réaction générale que j'ai.
  2. Voici la seconde réaction générale que j'ai.

Pages apparentées

• hCard
• hCard anti-sèche - propriétés hCard
• hCard creator (réactions) - créez votre propre hCard.
• hCard publication - apprenez comment ajouter du balisage hCard à votre information de contact existante.
• hCard exemples - exemple d'usage de différentes classes dans la hCard.
• hCard exemples dans la jungle - une liste mise à jour de sites web qui utilisent les hCards.
• Profils utilisateurs supportant hCard - sites avec des profils utilisateurs marqués avec hCard - un exemple très commun.
• hCard FAQ - si vous avez quelque question à propos de hCard, regardez ici.
• implémentations hCard - les sites web ou outils qui génèrent ou parsent les hCards.
• hcard-implied-fr - une proposition pour créer une méthode alternative de baliser une hCard simple
• hCard parsage - détails des normes sur la manière de parser les hCards.
• hCards et pages - distinctions sémantiques entre différentes hCards sur une page, et comment identifier chacune
• hcard-interface-utilisateur - techniques et problématiques autour des interfaces-utilisateurs pour éditer, publier et afficher des hCards.
• hCard profile - le profil XMDP pour hCard
• hCard propriétés singulières - une explication de la liste des propriétés singulières dans hCard.
• hCard tests - une page wiki avec des véritables hCards embarquées pour essayer le parsage.
• hCard soutien - encourager d'autres à utiliser hCard
• hCard "to do" - travaux à faire

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.

• hCard brainstorming - brainstorms et autres explorations en rapport avec hCard. Voir aussi geo brainstorming.
  • hcard-parsing-brainstorming - brainstorming spécifique au parsage de hCard
  • geo brainstorming
• hCard réactions - feedback général (contrairement aux problématiques spécifiques).
• hCard problématiques - problématiques spécifiques à la spécification.
• vCard errata - corrections à la spécification vCard, sous jacentes à hCard.
• vCard suggestions - améliorations suggérées à la spécification vCard.