hcalendar-issues-fr

(Difference between revisions)

Jump to: navigation, search
m (Reverted edit of Nu9N0r, changed back to last version by ChristopheDucamp)
Current revision (20:05, 8 January 2009) (view source)
m (Reverted edits by LivirIcnoc (Talk) to last version by Brian)
 
(7 intermediate revisions not shown.)
Line 1: Line 1:
-
= Problématiques hCalendar =
+
<h1> Problématiques hCalendar </h1>
-
Ce sont des problématiques externes sur [[hcalendar-fr|hCalendar]] avec différents degrés de mérite. De ce fait, quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici si elles sont exprimées à nouveau), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut être amener à provoquer des modifications ou des explications améliorées dans la spécification. Les problématiques proposées peuvent (et le seront probablement) être éditées et récrites pour plus de concision, de clarté, de rationnalité et aussi neutre en point de vue que possible. Formulez bien vos problématiques. — [http://tantek.com/log/ Tantek]
+
Ce sont des problématiques externes sur [[hcalendar-fr|hCalendar]] avec différents degrés de mérite. De ce fait, quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici si elles sont exprimées à nouveau), et d'autres qui contiennent des discussions plus longues.  
-
Voir [[hcard-issues-fr|problématiques hCard en rapport]].
+
'''IMPORTANT''' : Lisez SVP les [[hcalendar-faq-fr|FAQ hCalendar]] ''avant'' de donner toute réaction ou soulever quelque problématique parce que vos réactions/quetions peuvent déjà avoir été résolues/fait l'objet d'une réponse.
 +
Les problématiques proposées peuvent (et le seront probablement) éditées et récrites pour une meilleure concision, clarté, rationalité et rester sur un point de vue aussi neutre que possible. Formulez bien vos problématiques. — [http://tantek.com/ Tantek]
 +
Ajoutez SVP vos nouvelles problématiques en '''haut''' de la liste. Relancer SVP vers les problématiques résolues/rejetées avec de nouvelles information plutôt que de soumettre à nouveau de telles problématiques. Les ajouts de problématiques en doublon seront réinitialisés.
 +
Voir [[hcard-issues-fr|problématiques hCard en rapport]].
 +
__TOC__
== Problématiques ==
== Problématiques ==
 +
Ajoutez de nouvelles problématiques '''en haut''' de la liste :
-
Utilisez svp ce format :
+
* {{OpenIssue-fr}} 2007-05-12 Un point pertinent extrait de la [http://microformats.org/wiki?title=hcalendar-issues&oldid=16115 version du 22 février 2007] des problématiques hCalendar. Vaut la peine d'être conservé et résolu :  
-
* <nowiki>{{OpenIssue-fr}}</nowiki> AAAA-MM-JJ soulevée par NOMAUTEUR
+
:* {{OpenIssue-fr}} 2007-01-20 soulevée par [[User:AndyMabbett|Andy Mabbett]]
-
*# ''Problématique 1 : Voici la première problématique que j'ai .''
+
:: Là où <code>DTEND</code> est une date, et non une date-time, il est requis que ce soit le jour après la fin de l'événement, par conséquent : <code><nowiki>
-
*# ''Problématique 2 : Voici la seconde problématique que j'ai .''
+
<abbr class="dtend" title="2007-04-30">29 avril 2007</abbr></nowiki></code>. Néanmoins, "29 Avril 2007" n'est '''''pas''''' une abréviation de 2007-04-30 ; c'est une abréviation de 2007-04-29. Le balisage comme montré est sémantiquement incorrect et sujet probablement à problèmes pour les utilisateurs ou agents utilisateurs qui utilisent l'attribut 'title', et non la valeur texte, de l'élément <code>abbr</code>.
-
 
+
::[[User:Webf2|Webf2]] 23:23, 11 May 2007 (PDT)
-
Et ajoutez de nouvelles problématiques '''en haut''' de la liste :  
+
::*La date ISO 2007-04-30 est directement équivalente à 2007-04-30 00:00:00, ce qui est la raison pour laquelle elle est utilisée à l'heure de fin d'un événement arrivant le 2007-04-29. Dans ce contexte plus complet vous pouvez alors visualiser cela comme une abréviation de 'la fin du 29 avril 2007'. Les auteurs peu à l'aise avec ça pourrait utiliser <nowiki><abbr class="dtend" title="2007-04-29 23:59:59">29 avril 2007</abbr></nowiki>, ou être plus spécifique avec leurs horaires.
-
 
+
:::[[User:CiaranMc|Ciaran McNulty]] 09:21, 12 May 2007 [GMT]
 +
::* This certainly risks confusion. The abbr title includes different information than the content; different when read by a 'normal' user who does not know about the exclusive-end-date.
 +
:::* Le problème va se passer avec les dates (plutôt que les dates-times). L'attente utilisateur est différente qi vous parler de "3 heures", ce qui est vraiment un point dans le temps, et de 29 avril, quelque chose qui dure 24 heures. Pas de problème pour dire qu'une heure de fin est 'exclusive', mais une date de fin peut être et est généralement inclusive.
 +
:::* Utiliser un <code>dtend</code> plus précis est simplement un contournement, vous pourriez ne pas vouloir dire la seconde à laquelle un événement se finit  (comme dans  2007-04-29 23:59:59). Vous pourriez facilement vouloir dire que cela tourne du Mercredi au Vendredi sans vous engager sur des horaires préciss - ou que l'événement soit parfois sur ce vendredi mais vous ne savez pas quand.
 +
::: Les options possibles pourraient être :
 +
:::* Inclure une note dans le standard qui aille en marquage contradictoire tel que
 +
:::: <code><nowiki><abbr class="dtend" title="2007-04-30">29 avril 2007</abbr></nowiki></code>
 +
:::: mauvais en pratique et devrait être évité
 +
:::* Faire un break avec l'usage ical que le fait que les dates de fin soient exclusives.
 +
:::* Clarifier le sens :
 +
:::: <code><nowiki><abbr class="dtend" title="value=date:value=inclusive:2007-04-29">29 Avril 2007</abbr></nowiki></code>
 +
:::: <code><nowiki><abbr class="dtend" title="value=exclusive:2007-04-30">29 avril  2007</abbr></nowiki></code>
 +
:::: ou peut-être
 +
:::: <code><nowiki><abbr class="dtend;value=date:value=inclusive" title="2007-04-29">29 avril 2007</abbr></nowiki></code>
 +
::: [[User:Webf2|Webf2]] 00:25, 13 May 2007 (PDT)
* {{OpenIssue-fr}} 2007-01-07 soulevée par [[User:Webf|Webf]]
* {{OpenIssue-fr}} 2007-01-07 soulevée par [[User:Webf|Webf]]
-
*# A la recherche d'un mécanisme pour spécifier un dtstart sans utiliser <nowiki><abbr></nowiki>. Ce serait utilisé où il existe un certain nombre d'événements (comme dans les [http://www.webfeet.org/events.html listes d'événéments de Webfeet]) où vous ne voulez pas avoir la date visible répétée.
+
*# "A la recherche d'un mécanisme pour spécifier un dtstart sans utiliser <nowiki><abbr></nowiki>. Ce serait utilisé où il existe un certain nombre d'événements (comme dans les [http://www.webfeet.org/events.html listes d'événéments de Webfeet]) où vous ne voulez pas avoir la date visible répétée."
*#* <code>abbr</code> est le seul élément correct à utiliser, à moins que vous ne souhaitiez afficher le date-time brut ISO-formaté pour l'utilisateur. Utilisez-le avec l'[[include-pattern-fr|include-pattern]], ce qui donne :
*#* <code>abbr</code> est le seul élément correct à utiliser, à moins que vous ne souhaitiez afficher le date-time brut ISO-formaté pour l'utilisateur. Utilisez-le avec l'[[include-pattern-fr|include-pattern]], ce qui donne :
Line 49: Line 68:
* {{OpenIssue-fr}} 2006-10-21 soulevée par [[User:AndyMabbett|AndyMabbett]]  
* {{OpenIssue-fr}} 2006-10-21 soulevée par [[User:AndyMabbett|AndyMabbett]]  
-
*# il devrait y avoir quelque moyen de dire que l'URL d'une hCard ou d'un événement hCalendar est l'URL de la page elle-même, sans avoir à inclure un lien redondant et dommageable en accessibilité vers cette page, sur la page elle-même.
+
*# "Il devrait y avoir quelque moyen de dire que l'URL d'une hCard ou d'un événement hCalendar est l'URL de la page elle-même, sans avoir à inclure un lien redondant et dommageable en accessibilité vers cette page, sur la page elle-même."
* {{OpenIssue-fr}} 2006-09-22 soulevée par [[User:AndyMabbett|AndyMabbett]]  
* {{OpenIssue-fr}} 2006-09-22 soulevée par [[User:AndyMabbett|AndyMabbett]]  
-
*# Commment sont affichées les dates Julian ? A la limite de ce que je connais, ISO8601 n'a pas de facilité pour baliser les dates Julina, ainsi la forme <pre><nowiki><abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> </nowiki></pre> serait utilisée ? Si oui, ce devrait être indiqué par un exemple.  
+
*# "Commment sont affichées les dates Julian ? A la limite de ce que je connais, ISO8601 n'a pas de facilité pour baliser les dates Julian, ainsi la forme <pre><nowiki><abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> </nowiki></pre> serait utilisée ? Si oui, ce devrait être indiqué par un exemple."
* {{OpenIssue-fr}} 2006-08-14 soulevée par [[User:Elias|Elias Sinderson]]
* {{OpenIssue-fr}} 2006-08-14 soulevée par [[User:Elias|Elias Sinderson]]
Line 141: Line 160:
* 2005-07-11 soulevée par Kragen
* 2005-07-11 soulevée par Kragen
-
*# ''The specification of class="url" as &lt;a href="..."> should be a "should", not a "must".  Other ways of referencing the event URL, such as &lt;iframe src="..."> and &lt;embed src="...">, shoul be mentionedAt present X2V doesn't appear to handle them.  This came up in a discussion about [[xfolk-fr|xFolk]].''
+
*# ''La spécification class="url" telle que &lt;a href="..."> devrait être un "should", et non un "must".  D'autres moyens de référencer l'URL event, comme &lt;iframe src="..."> et &lt;embed src="...">, devraient être mentionnéesA ce jour X2V ne semble pas les gérer. Ceci provient d'une discussion à propos de [[xfolk-fr|xFolk]].''
-
*#* REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.
+
*#* REJETEE. Manque de cas d'utilisation. Nous ne devrions pas ajouter de "moyens supplémentaires de référencer l'URL event" à moins que vous ne puissiez présenter un exemple concret du vrai monde sur le web qui l'exige.
-
 
+
-
* 2005-06-21 raised by Hixie
+
-
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCalendars must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
+
 +
* 2005-06-21 soulevée par Hixie
 +
*# ''Issue H-1 : Cette spécification manque d'une section agent utilisateur. Il n'y a basiquement rien qui dise comment les hCalendars doivent être parsés, comment gérer les erreurs et ainsi de suite. Elle est définie en termes de DOM ? Est-elle définie en termes de sérialisation ? Comment gérer le contenu inattendu ou le contenu manquant ?
*#* ACCEPTEE. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing-fr]] that documents precisely how user agents are to parse [[hcalendar-fr|hCalendar]] markup.
*#* ACCEPTEE. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing-fr]] that documents precisely how user agents are to parse [[hcalendar-fr|hCalendar]] markup.
-
* 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
+
* 2005-02-22 soulevée par Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html sur la liste whatwg]:
-
*# ''There is no copyright statement and no patent statement.''
+
*# Il n'y pas de déclaration de copyright et pas de déclaration de brevets.''
-
*#* ACCEPTEE. I have updated [[hcalendar-fr|hCalendar]] (and [[hcard-fr|hCard]], and all other MicroFormats) with a standard copyright statement and patent statement.
+
*#* ACCEPTEE. J'ai mis à jour [[hcalendar-fr|hCalendar]] (et [[hcard-fr|hCard]], et tous les autres microformats) avec une déclaration de copyright standard et une déclarationd e brevet.
* 2005-02-18 soulevée par Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
* 2005-02-18 soulevée par Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
-
*# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
+
*# Il n'y a pas moyen pour quelqu'un de lire le marquage pour dire si un nom de classe est le nom d'un attribut ou simplement le nom d'une classe utilisée pour la mise en forme.''
-
*#* REJETEE (strawman, poor assumption).  There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
+
*#* REJETEE (strawman, hypohtèse pauvre).  Il n'y a pas besoin de différencier dans le cas général. Dans le cas spécifique, un vocabulaire est défini à l'intérieur d'un contexte.
*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
-
*#* REJETEE (out of scope).  Extension properties are outside the current scope of hCalendar.
+
*#* REJETEE (hors du sujet).  Les propriétés extension sont en dehors du champ actuel de hCalendar.
-
*# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
+
*# ''L'utilisation de <abbr> pour les dates est incorrect. "August 5th, 2004" n'est pas l'abréviation de 2004-09-05. En fait, le contraire est plus proche de la vérité.''
-
*#* REJETEE (false statement).  This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
+
*#* REJETEE (déclaration fausse).  Ceci est simplement une déclaration fausse. Voir cet article pour une explication de cet usage d'<abbr> : [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
-
*# ''You have to create a complex set of rules for all possible uses of legacy markup within <span class="vcalendar"> which can easily be implemented incorrectly.''
+
*# ''Vous devez créer un ensemble complexe de règles pour toutes les utilisations possibles d'un marquage légal dans <span class="vcalendar"> qui puisse être facilement implémenté incorrectement.''
-
*#* REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
+
*#* REJETE (déclarations fausses, strawman). Pas de marquage légal. Pas besoin de créer des règles pour toutes les utilisations possibles de marquage légal. pas besoin de créer un ensemble de règles complexes.
-
*# ''There are styling and tooltip issues that are unresolved.''
+
*# ''Il existe des problématiques de stylisation et de tooltip qui restent non résolues.''
-
*#* REJETEE (empty statements).  Voir [[hcalendar-faq-fr|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
+
*#* REJETEE (déclarations vides).  Voir [[hcalendar-faq-fr|hCalendar FAQ]] pour les réponses aux questions concernant la stylisation et les tooltips. Autrement, soulevez svp des problématiques spécifiques avec des exemples valides et clairs.
-
*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
+
*# ''hCalendar/hCard est plus compliqué pour les webmestres à lire et comprendre et plus compliqué pour les développeurs à mettre en place.''
-
*#* REJETEE (empty statements, invalid comparator).  Please state specific examples which show the perceived complexity.  The comparison "more complicated" requires two items, no second item was provided.
+
*#* REJETEE (déclarations invalides, comparateur invalide).  Please state specific examples which show the perceived complexity.  The comparison "more complicated" requires two items, no second item was provided.
*#  ''I dislike the entire system of using class names as markup.  Class names should be reserved for user-defined semantics.''
*#  ''I dislike the entire system of using class names as markup.  Class names should be reserved for user-defined semantics.''
*#* ACCEPTEE-PARTIELLEMENT.  When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements.  This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class].  And yes, class names can and should be used for user-defined semantics. [[hcalendar-fr|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
*#* ACCEPTEE-PARTIELLEMENT.  When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements.  This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class].  And yes, class names can and should be used for user-defined semantics. [[hcalendar-fr|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
Line 176: Line 194:
* {{OpenIssue-fr}} 2006-04-13 soulevée par Tantek
* {{OpenIssue-fr}} 2006-04-13 soulevée par Tantek
*# ''Besoin d'ajouter une section sur "Exceptions de Propriétés" comme dans [[hcard-fr|hCard]] pour documenter comment publier / gérer la propriété '''METHOD''' et potentiellement d'autres.  Par ex, généralement les auteurs peuvent omettre la propriété METHOD, néanmoins les convertisseurs dont la fonction est de convertir [[hcalendar-fr|hCalendar]] vers iCalendar pour la consommation / abonnnement par un agrégateur de calendrier, devrait probablement insérer un '''METHOD:PUBLISH''' par défaut sur l'objet '''VCALENDAR''' dans le flux résultant .ics.''
*# ''Besoin d'ajouter une section sur "Exceptions de Propriétés" comme dans [[hcard-fr|hCard]] pour documenter comment publier / gérer la propriété '''METHOD''' et potentiellement d'autres.  Par ex, généralement les auteurs peuvent omettre la propriété METHOD, néanmoins les convertisseurs dont la fonction est de convertir [[hcalendar-fr|hCalendar]] vers iCalendar pour la consommation / abonnnement par un agrégateur de calendrier, devrait probablement insérer un '''METHOD:PUBLISH''' par défaut sur l'objet '''VCALENDAR''' dans le flux résultant .ics.''
 +
 +
== Gabarit ==
 +
 +
Utilisez svp ce format :
 +
* <nowiki>{{OpenIssue-fr}}</nowiki> AAAA-MM-JJ soulevée par NOMAUTEUR
 +
*# ''Problématique 1 : Voici la première problématique que j'ai .''
 +
*# ''Problématique 2 : Voici la seconde problématique que j'ai .''
 +
== Pages en rapport ==
== Pages en rapport ==
{{hcalendar-related-pages-fr}}
{{hcalendar-related-pages-fr}}

Current revision

Problématiques hCalendar

Ce sont des problématiques externes sur hCalendar avec différents degrés de mérite. De ce fait, quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici si elles sont exprimées à nouveau), et d'autres qui contiennent des discussions plus longues.

IMPORTANT : Lisez SVP les FAQ hCalendar avant de donner toute réaction ou soulever quelque problématique parce que vos réactions/quetions peuvent déjà avoir été résolues/fait l'objet d'une réponse.

Les problématiques proposées peuvent (et le seront probablement) éditées et récrites pour une meilleure concision, clarté, rationalité et rester sur un point de vue aussi neutre que possible. Formulez bien vos problématiques. — Tantek

Ajoutez SVP vos nouvelles problématiques en haut de la liste. Relancer SVP vers les problématiques résolues/rejetées avec de nouvelles information plutôt que de soumettre à nouveau de telles problématiques. Les ajouts de problématiques en doublon seront réinitialisés.

Voir problématiques hCard en rapport.

Contents


Problématiques

Ajoutez de nouvelles problématiques en haut de la liste :

  • problématique ouverte ! 2007-01-20 soulevée par Andy Mabbett
Là où DTEND est une date, et non une date-time, il est requis que ce soit le jour après la fin de l'événement, par conséquent : <abbr class="dtend" title="2007-04-30">29 avril 2007</abbr>. Néanmoins, "29 Avril 2007" n'est pas une abréviation de 2007-04-30 ; c'est une abréviation de 2007-04-29. Le balisage comme montré est sémantiquement incorrect et sujet probablement à problèmes pour les utilisateurs ou agents utilisateurs qui utilisent l'attribut 'title', et non la valeur texte, de l'élément abbr.
Webf2 23:23, 11 May 2007 (PDT)
  • La date ISO 2007-04-30 est directement équivalente à 2007-04-30 00:00:00, ce qui est la raison pour laquelle elle est utilisée à l'heure de fin d'un événement arrivant le 2007-04-29. Dans ce contexte plus complet vous pouvez alors visualiser cela comme une abréviation de 'la fin du 29 avril 2007'. Les auteurs peu à l'aise avec ça pourrait utiliser <abbr class="dtend" title="2007-04-29 23:59:59">29 avril 2007</abbr>, ou être plus spécifique avec leurs horaires.
Ciaran McNulty 09:21, 12 May 2007 [GMT]
  • This certainly risks confusion. The abbr title includes different information than the content; different when read by a 'normal' user who does not know about the exclusive-end-date.
  • Le problème va se passer avec les dates (plutôt que les dates-times). L'attente utilisateur est différente qi vous parler de "3 heures", ce qui est vraiment un point dans le temps, et de 29 avril, quelque chose qui dure 24 heures. Pas de problème pour dire qu'une heure de fin est 'exclusive', mais une date de fin peut être et est généralement inclusive.
  • Utiliser un dtend plus précis est simplement un contournement, vous pourriez ne pas vouloir dire la seconde à laquelle un événement se finit (comme dans 2007-04-29 23:59:59). Vous pourriez facilement vouloir dire que cela tourne du Mercredi au Vendredi sans vous engager sur des horaires préciss - ou que l'événement soit parfois sur ce vendredi mais vous ne savez pas quand.
Les options possibles pourraient être :
  • Inclure une note dans le standard qui aille en marquage contradictoire tel que
<abbr class="dtend" title="2007-04-30">29 avril 2007</abbr>
mauvais en pratique et devrait être évité
  • Faire un break avec l'usage ical que le fait que les dates de fin soient exclusives.
  • Clarifier le sens :
<abbr class="dtend" title="value=date:value=inclusive:2007-04-29">29 Avril 2007</abbr>
<abbr class="dtend" title="value=exclusive:2007-04-30">29 avril 2007</abbr>
ou peut-être
<abbr class="dtend;value=date:value=inclusive" title="2007-04-29">29 avril 2007</abbr>
Webf2 00:25, 13 May 2007 (PDT)


	<dt id="D20070120">
		<abbr class="dtstart" title="20070120">
		Samedi 20 janvier 2007
		</abbr>
	</dt>
	<dd>
		<span class="vevent">
		<object class="include" data="#D20070120"></object>
		[Détails du premier événement]
		</span>

		<span class="vevent">
		<object class="include" data="#D20070120"></object>
		[Détails du second événement]
		</span>
	</dd>

mais notez svp que vous devriez valider votre HTML - il a plus de 3000 erreurs ! le nombre élevé de nombre de microformats hCalendar (>500) amène les parseurs comme Tails de Firefox et Operator à répondre très lentement. Vous devriez utiliser CSS, des espaces non cassés et de nombreux sauts de lignes pour metter en page votre page - ceci réduira sa taille et permettra aux parseurs de travailler plus rapidement. Vous aurez besoin de styler object .include en display:none Andy Mabbett 04:10, 16 Jan 2007 (PST)

Ceci est un peu confus aussi lisez calmement et avec attention la RFC 2445 à cet égard. En outre, la spec. hCalendar dirait *précisément* comment générer des propriétés VCALENDAR en son absence.

Ils ont tous imaginé cela comme aussi pertinent par la spec ical parce que les événements se déroulent (mon implémentation).

Spécifiez explicitement quels sont les objets iCalendar (en plus de VEVENT) qui sont permis dans hCalendar. Candidats actuels en plus : VTODO (plein d'exemples de cette information sur le web), VFREEBUSY (déjà au moins sur un site de publier cette info), VALARM (peut-être, me semble grossier, mais sans une exigence du vrai monde pour utiliser le cas que nous devrions probablement ometre). Actuellement en cours de dépose : (construction horrible), VJOURNAL (démodé par hAtom).

<a name="myfrag">Titre</a>
<div class="vevent">
  <div class="description">Un bel événement</div>
  <abbr class="dtstart" title="2005-10-05">5 octobre</abbr>
</div>
  <li class="vevent" id="2678c3f94af4a49f9ccbb69b92a82aba-midgardGuid">
    <abbr class="dtstart" title="2005-10-20T14:34:45Z">Torstai 20. Lokakuu 17:34</abbr> -
    <abbr class="dtend" title="2005-10-20T15:33:56Z">18:33</abbr>
    <a class="url" href="/bergie/another-calendar/82457028ba83407451edd8aaeaa40622.html">
        <span class="summary">From the other cal</span>
    </a>
    <abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>
  </li>

.vevent .summary {

//remove all the previously set properties, for example:

text-decoration: none;

font-size: 100%;

...

}

Since the hCalendar microformat is the following,

<a class="url" href="http://www.web2con.com/">

Web 2.0 Conference:

...

I hope to have been clear but I'm not so sure ;-)


Gabarit

Utilisez svp ce format :

  • {{OpenIssue-fr}} AAAA-MM-JJ soulevée par NOMAUTEUR
    1. Problématique 1 : Voici la première problématique que j'ai .
    2. Problématique 2 : Voici la seconde problématique que j'ai .


Pages en rapport

Cette spécification est un chantier en cours. Au fur et à mesure que les aspects additionnels sont discutés, compris et écrits, ils seront ajoutés. Ces idées et questions sont maintenues sur des pages séparées.

  • hCalendar Brainstorming - brainstormings et autres explorations en rapport avec hCalendar
  • hCalendar problématiques - problématiques avec la spécification

hcalendar-issues-fr was last modified: Thursday, January 8th, 2009

Views