(Difference between revisions)

Jump to: navigation, search
(2006: hCal mark-up)
(2008: Lack of method for marking up vague dates and eras)
Line 264: Line 264:
<div class="description">
<div class="description">
*# A pertinent point from the [http://microformats.org/wiki?title=hcalendar-issues&oldid=16115 22 Feb 2007 version] of hcalendar issues. Worth keeping and addressing.
*# A pertinent point from the [http://microformats.org/wiki?title=hcalendar-issues&oldid=16115 22 Feb 2007 version] of hcalendar issues. Worth keeping and addressing.
=== 2008 ===
<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-01-16</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# Lack of method for marking up vague dates and eras; see [[history-examples#The_Problem|vague-date examples]].

Revision as of 11:59, 16 January 2008

hCalendar issues

These are externally raised issues about hCalendar with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

IMPORTANT: Please read the hCalendar FAQ before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek

See related hcard-issues.


Closed Issues

Resolved issues that have no further actions to take. These will likely be moved to a separate page like hcalendar-issues-closed.

Resolved Issues

Issues that are resolved but may have outstanding to-do items.

  • 2006-02-17 raised by Mark Mansour - notes are summarized here
    1. Should vcalendar be a class? Section 4.4 of RFC2445 says: "The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together." Also the vcalendar class would allow properties on the calendar itself such as METHOD and CALSCALE (I don't think VERSION and PRODID are particularly relevant).
      • ACCEPTED SPECUPDATE/FAQ. Is this a case of fixing something that isn't broken? Note that "iCalendar object" != "vcalendar". This is a bit confusing so read RFC 2445 carefully in that regard. In addition, the hCalendar spec should say *precisely* how to generate VCALENDAR properties in their absence.
    2. How are axis and headers going to be handled?
      • ACCEPTED. This is documented in hcalendar-brainstorming but MUST be moved to hCalendar proper as the editors and implementers have all agreed on it (months ago). Add this as a to-do for Tantek.
    3. There has been talk that table axis and headers should be used to capture calendar information in a more compact format, but no example are available. Does anyone have examples or should we try to invent some?
    4. Should embeded components be allowed? RyanKing has already noted that vJournal overlaps blog-posts (although not yet accepted), but should the components to-do, free/busy, timezone, alarms be allowed? They all considered as just as relevant by the ical spec as events are (my interpretation).
      • ACCEPTED SPECUPDATE/FAQ. Another to-do for Tantek. Explicitly specify which additional iCalendar objects (in addition to VEVENT) are permitted in hCalendar. Current additional candidates: VTODO (many examples of this info on the web), VFREEBUSY (already at least one site publishing this info), VALARM (maybe, seems harmless enough, but without a compelling real world use case we should probably omit it). Currently dropping: VTIMEZONE (terrible construct), VJOURNAL (obsoleted by hAtom).
    5. Validation of the hCalendar tests. The hCalendar tests have been available for a while now, but only Brian Suda and I have made contributions to their content. Does anyone else have thoughts and should we try to make these the beginning of 'official' hCalendar tests?
      • ACCEPT PARTIAL. We probably need an hCalendar validator before we can declare any set of tests to be official.
    6. The use of fragments is unclear. Fragment interpretation seems to be agent dependant. Fragments usually denote a heading or marker, like a goto statement for HTML. Unfortunately it may jump in the middle of elements (rather to the beginning of an element). How should this be handled. i.e.
<a name="myfrag">heading</a>
<div class="vevent">
  <div class="description">A nice event</div>
  <abbr class="dtstart" title="2005-10-05">October 5

</div> </pre>

  <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>
    <abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>


Please add new issues to the bottom of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.


.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 ;-)


    1. I'd love to see a Property List, similar to what is seen in the hCard spec, that lists all the available properties and sub-properties in a nice, compact list. This saves a lot of time and is really useful for quickly and easily getting acquainted with the possibilities of vCalendar.
    1. When someone looks at the hCalendar pages, one sees no collection of real-world publishing of event data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the process nor the hCalendar pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.
  • open issue! 2006-04-13 raised by Tantek
    1. Need to add a section on "Property Exceptions" like that in hCard to document how to publish / handle the METHOD property and potentially others. I.e. typically publishers may omit the METHOD property, however, converters whose function is to convert hCalendar to iCalendar for consumption/subscription by a calendar aggregator, should probably insert a default METHOD:PUBLISH on the VCALENDAR object in the resultant .ics stream.
    1. Although ISO 8601 allows both basic (sans delimiters) and extended formats, the extended format (where hyphens and colons are explicitly added) is broadly preferred for the web. While RFC 2445 specifies that the basic form be used in in iCalendar date / time fields, the W3C has published a technical note (submitted by Reuters), which recommends that the extended (delimited) format be used, and the HTML 4.0 spec uses the extended format. Further, RFC 3339 defines a ISO 8601 profile for dates and time representations on the internet that future specs SHOULD use; recommending a fully delimited representation (see sec. 5.6). Lastly, it should be noted that the xsd:date and xsd:dateTime types are specified as being the ISO 8601 extended format. So, given that hCalendar is based on iCalendar, it is understandable that it allows both formats, however this is clearly a case in which it would be very reasonable to require users to upconvert the format into the least ambiguous and most easily parsed/ validated representation. Think of the children.
    1. How are Julian dates to be displayed? So far as I am aware, ISO8601 has no facility for marking up Julian dates, so should the form
      <abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> 
      be used? If so, that should be indicated, via an example.


  • open issue! 2007-01-07 raised by Webf
    1. Looking for a mechanism for specifying a dtstart without using <abbr>. Would be used where there are a number of events (as in the Webfeet events lists) where you do not want to have the visible date repeated
      • abbr is the correct - and only - element to use, unless you wish to display the raw ISO-formatted date-time to the user. Use it with the include-pattern, thus:

	<dt id="D20070120">
		<abbr class="dtstart" title="20070120">
		Saturday, 20 January 2007
		<span class="vevent">
		<object class="include" data="#D20070120"></object>
		[Details of first event]

		<span class="vevent">
		<object class="include" data="#D20070120"></object>
		[Details of second event]

but please note that you should validate your HTML - it has over 3,000 errors! The high number of hCalendar microformats (>500) is causing parsers such as Firefox's Tails and Operator to respond very slowly. You should use CSS, not non-breaking spaces and multiple line-breaks, to layout your page - this will reduce it's size and enable parsers to work more quickly. You will need to style object .include to display:none Andy Mabbett 04:10, 16 Jan 2007 (PST)
Thanks Andy!
  • This use of object is a proposal at this stage? It does not seem to be mentioned in the hCalendar page and only marked 'under consideration' in Include Pattern
  • Re: '>500 entries', I would think that User Agents should be able to deal with this. The linked page displays a collection of events (not all pages will have so many :-) however I would expect a User Agent to worry mainly about the events visible on the screen (really, a small part of the whole page).
    • Brainstorming a little, I would hope that the UA could track an event I've inserted ino my calendar and notice any changes, such as the event being postponed/cancelled, pick up this info and update my calendar. Worth thinking what implications this might bring to the markup.
    • I'm thinking though that the primary effort with a UA would be making sure the 99.99% pages which do not include hCalendar markup are not slowed down!
  • Re: abbr as the only way, I can see abbr used within the hCalendar page and, yes, it looks a exceptionally neat way of rolling up some markup but I don't see it defined as a mandatory for marking up an event.
    • Am I missing some rationale? Why is abbr the only option?
    • Should the spec be written up more formally? should hCalendar be more relaxed? My take is that abbr is OK but it would be wrong for it to be mandatory. Think that screen readers may be reading the expanded content (as with <abbr title="Web Accessibility Initiative">WAI</abbr>). The underlying issue is that hCalendar seems to want abbr to disambiguate a displayed date and this is not really the same as an abbreviation. UA's should be liberal when looking for a class="dtstart", after all they do know that they are within an event markup as they have met the class="vevent"....
  • Feel free to move the above thoughts to a brainstorming area. I might come back to the other points later - but maybe better in a talk page. :-) Webf 13:23, 21 Jan 2007 (PST)

Where DTEND is a date, and not a date-time, it is required to be the day after the end of the event, thus: <abbr class="dtend" title="2007-04-30">29 April 2007</abbr>. However, "29 April 2007" is not an abbreviation of 2007-04-30; it is an abbreviation of 2007-04-29. The markup as shown is semantically incorrect and likely to cause problems for users and user-agents which read the title attribute, and not the text value, of the abbr element.
Webf2 23:23, 11 May 2007 (PDT)
  • The ISO date 2007-04-30 is directly equivalent to 2007-04-30 00:00:00, which is why it's used as the end time of an event occuring on 2007-04-29. In this fuller context then you can view it as an abbreviation of 'the end of 29 April 2007'. Authors uncomfortable with this could use <abbr class="dtend" title="2007-04-29 23:59:59">29 April 2007</abbr>, or be more specific with their times.
Ciaran McNulty 09:21, 12 May 2007 [GMT]
  • The ISO standard has 2007-04-29 24:00:00 expressly to mark the end of the day 2007-04-29 rather than the start of the day 2007-04-30. This seems far preferable to 23:59:59. Matthew 15:22, 17 Jul 2007 (PDT)
  • 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.
  • The trouble is going to be with dates (rather than date-times). User expectation is different if you are talking about "3 o'clock", which really is a point-in-time, and "29th April", something lasting 24 hours. No problem saying an end time is 'exclusive', but an end-date can be either and is typically inclusive.
  • Using a more precise dtend is just a workround, you might not really want to say to the second when an event ends (as in 2007-04-29 23:59:59). You might easily want to say it runs from the Wednesday to Friday without committing to precise times - or that the event is sometime on that Friday but you don't know when.
Possible options could be:
  • Include a note in the standard that contradictory markup such as
<abbr class="dtend" title="2007-04-30">29 April 2007</abbr>
is bad practice and should be avoided
  • Make a break with the ical usage that end dates are exclusive.
  • Make the meaning clear:
<abbr class="dtend" title="value=date:value=inclusive:2007-04-29">29 April 2007</abbr>
<abbr class="dtend" title="value=exclusive:2007-04-30">29 April 2007</abbr>
or maybe
<abbr class="dtend;value=date:value=inclusive" title="2007-04-29">29 April 2007</abbr>
Webf2 00:25, 13 May 2007 (PDT)
    1. Here is the first issue I have.
    2. Here is the second issue I have.
  • open issue! 2007-05-12 raised by Anon
    1. A pertinent point from the 22 Feb 2007 version of hcalendar issues. Worth keeping and addressing.



Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.

<div class="hentry">
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2

Related Pages

This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.

hcalendar-issues was last modified: Wednesday, December 31st, 1969