Difference between revisions of "html5-fr"

From Microformats Wiki
html5-fr
Jump to navigation Jump to search
m ([sync'd with original page - 2 sections to be translated])
(No difference)

Revision as of 08:31, 6 September 2009

<entry-title>Microformats en HTML 5</entry-title>

Cette page est destinée à documenter l'usage futur des microformats en HTML 5. Aucun des items documentés ne sont supportés à cette heure, et ils pourront changer pour un développement dans la communauté des microformats, ou selon les modifications dans la spécification HTML5. Cette page est destinée à suivre les améliorations offertes par HTML5 pour les microformats, et les problématiques que soulève HTML5. Elle peut être utilisée pour suivre les questions qui ont besoin d'être poussées dans le processus de développement du HTML5.

S'il y a des choses que les Microformats aimeraient marquer qui ne sont pas gérées explicitement par HTML5, faites-le savoir svp au WHATWG, de façon à ce que nous puissions améliorer HTML5. Voici comment le time came to be, for instance.

Nouvelles fonctionnalités dans le HTML5

  • élément time pour représenter les dates-heures. En HTML5, le format machine des dates-heures peut être représenté nativement. Il devrait être possible de remplacer le modèle de design date-time avec du HTML natif.
    • time prend un attribut optionnel pubdate, pour indiquer la date de publication d'un article. Synonyme avec le hAtom published, peut impliquer hAtom updated, peut impliquer hReview dtreviewed, peut impliquer hListing dtlisted
  • l'élément article pour des compositions majeures, indépendantes de contenu au sein d'une page. Peut-être synonyme avec hAtom hentry. Pourrait être parsé comme hentry dans des blocs explicites hfeed ?
  • la convention de nommage data- pour les attributs tag. la spécification draft specification déclare que tout attribut qui démarre avec "data-" sera traité comme une aire de stockage pour la donnée privée.
    • Notez que le truc data-* est explicitement 'non' pour les Microformats, au moins pas les microformats qui veulent toujours être gérés nativement par les navigateur. Ces attributs sont définis de telle sorte que les navigateurs ne feront jamais rien avec eux. Ils sont conçus pour les auteurs de scripts qui ont un espace dans lequel ils pourront jouer sans entrer en conflit avec tout ce que fait le navigateur.
  • microdata. HTML5 fournit un ensemble d'attributs et d'APIS DOM associées pour extraire les données des pages web.
    • l'attribut itemprop est une version plus spécifique de class, pour les noms de champ.
    • l'attribut subject permet le lien sémantique dans la page. Conceptuellemnet similaire à l'include-pattern.
    • l'attribut content sur l'élément meta peut être utilisé pour inclure de la donnée invisible. Conceptuellement similaire au modèle-de-classe-value.
    • l'attribut item identifie les blocs à marquer comme structure de données. Conceptuellement similaire au brainstorming mfo-examples ?

Compatibilité actuelle avec les microformats

Il ne semble pas y avoir de problématiques avec l'implémentation actuelle des microformats suivants dans le HTML5 :

Demandes

Problématiques

  • The rev attribute has been removed. In HTML5, rel and rev are no-longer paired, and the rel attribute nolonger describes the direction of a relationship. Microformats which use rev will need to use rel instead.
    • Or something like data-rev="vote-for"
      • As above, data- attributes are for application-context functionality, not shared vocabularies. Further, the HTML5 specification makes rel the correct attribute to use, regardless of direction, through the changed specification. --BenWard 17:53, 12 May 2009 (UTC)
  • The profile attribute has been removed. In HTML, the profile attribute from the head has been removed, with no direct replacement. This causes issues for GRDDL support. It's been suggested that profile URLs be represented in link elements instead, or even as a custom HTTP header. See grddl and profile-uris
  • Microdata itemprop duplicates class data. the new attribute itemprop is designed to hold some meaningful data about an element, but class already exists to hold this data. Unsure of reasons why itemprop required?
    • This is because microdata is designed to be generically parsable, even when the parser does not understand the vocabulary. As such, property names have to be on an explicit attribute, not shared with other, non-data classnames. --BenWard 21:12, 4 September 2009 (UTC)

see also