- 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.
- See hcalendar-cheatsheet . Michael Leikam 2007-01-29
- ACCEPTED. to-do hCalendar should list all applicable properties in the hCalendar property list, similar to hCard. Tantek
- 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.
hCalendar resolved issues
Jump to navigation
Jump to search
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
resolved issues
hCalendar issues that are resolved but may have outstanding to-do items.
- shortlink
- http://tr.im/hcalri
As issues are resolved, they will be moved from the Issues list to this section.
As actions are taken according to the resolutions noted in the issues, they are moved to hcalendar-issues-closed.
resolved 2005
- 2005-02-18 raised by Matt Raymond on the whatwg list:
- ...
- ...
- ...
- ...
- ...
- ...
- I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.
- ACCEPT-PARTIAL FAQ. 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 A Touch of Class. And yes, class names can and should be used for user-defined semantics. hCalendar is one such user, and it is reasonable for users to use each others class names.
- Would it be more in the spirit of HTML to define these classes in a metadata profile, so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of microformats specifications in general? (If not, why not?)
- ACCEPTED. Yes, all microformats that introduce new classnames SHOULD include an XMDP profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
- Ok, but in order to refer to a profile, it needs a URI. Tantek writes in a message of Jul 21 "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?
- ACCEPTED. See profile-uris; this is moving from Tantek's to-do list, to both provide profiles and URLs (probably at gmpg.org) for those profiles for hCalendar etc.
- UPDATE: hCalendar profile: http://microformats.org/profile/hcalendar. to-do - add this to hcalendar-faq.
- Ok, but in order to refer to a profile, it needs a URI. Tantek writes in a message of Jul 21 "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?
- ACCEPTED. Yes, all microformats that introduce new classnames SHOULD include an XMDP profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
- 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?
- ACCEPTED. Another to-do for Tantek, write-up hcalendar-parsing that documents precisely how user agents are to parse hCalendar markup.
- 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-07-11 raised by Kragen
- The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, should be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about xFolk.
- REJECTED feature request. Lack of use case. We should not add new "ways of referencing the event URL" unless there are concrete real world example on the Web which requires it.
- ACCEPTED clarification. The processing model for "url" properties (e.g. hcard-parsing, hcalendar-parsing) should state what to do with all valid HTML4 elements that reference external URLs (like <iframe>), and all such valid HTML5 elements (like <embed> - Tantek 08:16, 26 August 2009 (UTC)
- The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, should be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about xFolk.
- 2005-07-27 raised by Paolo Massa
- I tried to add a hcalendar event in my blog but it rendered horribly. The problem was I already have a 'class="summary' in my normal HTML (it is the title of the posts) and my CSS displays it bigger and bold. In this way the summary of the event was as big as the titles of the posts, destroying readability. The problem is Overloading of class attributes, it might be the case that a blogger already use, for example, class="summary" for different purposes. What can be a solution? Providing in every microformat wiki page a CSS file that users can download and insert in their blog as additional CSS. This CSS file will "shield" attribute "inside" microformats from being interpreted as "normal" attributes. For example for the hCalendar microformats the relative CSS could be something like: Since the hCalendar microformat is the following,
.vevent .summary { text-decoration: none; font-size: 100%; }
... I hope to have been clear but I'm not so sure ;-)<span class="vevent"><a class="url" href="http://www.web2con.com/"><span class="summary">Web 2.0 Conference</span></a></span>
- ACCEPTED FAQ. to-do expand the current FAQ class interactions entry with contextual selector examples.
- I tried to add a hcalendar event in my blog but it rendered horribly. The problem was I already have a 'class="summary' in my normal HTML (it is the title of the posts) and my CSS displays it bigger and bold. In this way the summary of the event was as big as the titles of the posts, destroying readability. The problem is Overloading of class attributes, it might be the case that a blogger already use, for example, class="summary" for different purposes. What can be a solution? Providing in every microformat wiki page a CSS file that users can download and insert in their blog as additional CSS. This CSS file will "shield" attribute "inside" microformats from being interpreted as "normal" attributes. For example for the hCalendar microformats the relative CSS could be something like:
- 2005-09-29 raised by RyanKing
- How does one use ATTENDEE?
- ACCEPTED. Another to-do for Tantek - document how to use ATTENDEE with hCard.
- UPDATE: This has now been documented in hCalendar brainstorming: hCard attendees. The remaining to-do is to incorporate the SHOULD use hCard attendees suggestion into the hCalendar 1.0.1 specification.
- How does one use ATTENDEE?
- 2005-10-14 raised by MarkoMrdjenovic
- UID has to be present in iCal events if they want to be used in Microsoft Outlook. [Suggestion:] it should probably be added to the vevent tag as html attribute id. There is also the problem of converters - x2v has UID commented out. RFC recommends use of addr format for uids which is problematic in html id (does not validate). HenriBergius pointed out some calendaring software crashes when @ is in the UID, so some other form of identification should be used - along the lines of dtstart-dtend-hash(title,summary)-sample-org.
- ACCEPTED-PARTIAL. Yes, it appears RFC2445 requires UID. However, typical mentions of events by web authors do not provide anything equivalent to a UID, nor should we require authors to do so. Thus we must come up with an algorithm for implied UID, similar to some of the other properties. We REJECT the use of the html 'id' attributre as a substitute for UID as they are of different scopes and thus such a translation will likely be problematic. As part of this algorithm, we MUST disallow "@" signs since the issue points out that such UIDs crash some calendaring software.
- UPDATE: Which version(s) of Microsoft Outlook have this problem? Please document in icalendar-implementations.
- DTSTAMP also has to be present in iCal event for Microsoft Outlook. I think DTSTAMP should be user visible information so implementation with class="dtstamp" is fine. x2v already supports it so it should just be added to the standard and examples. The converters might also think of a way to force (create) dtstamp if it's not present. *#* [Suggestion:] why not set DTSTAMP to DTSTART if not explicitly defined? -- DimitriGlazkov
- ACCEPTED. We should come up with a way to encourage/synthesize/imply DTSTAMP property values.
- Here is an example from Midgard CMS (which will be easy to change according to bergie on irc):
- UID has to be present in iCal events if they want to be used in Microsoft Outlook. [Suggestion:] it should probably be added to the vevent tag as html attribute id. There is also the problem of converters - x2v has UID commented out. RFC recommends use of addr format for uids which is problematic in html id (does not validate). HenriBergius pointed out some calendaring software crashes when @ is in the UID, so some other form of identification should be used - along the lines of dtstart-dtend-hash(title,summary)-sample-org.
<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>
- For more discussion of this, please see hCalendar brainstorming: UID handling
resolved 2006
- 2006-01-04 raised by CGranade
- ...
- All examples in XHTML. XHTML should not be the only host to microformats, and thus it should not be the only example host language. Rather, examples in Atom, RSS, RDF, etc. should also be provided.
- ACCEPTED. This is definitely something to be added to *-examples pages for each microformat.
- 2006-02-17 raised by Mark Mansour - notes are summarized here
- 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. Tantek
- How are axis and headers going to be handled?
- ACCEPTED. This is documented in hcalendar-brainstorming but to-do MUST be moved to hCalendar proper as the editors and implementers have all agreed on it (months ago). Tantek
- 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?
- ACCEPTED FAQ. Searching the hCalendar spec for *either* "axis" or "headers" would have found the following example in the wild: Web Essentials 05 (original page http://we05.com/ is offline) has marked up their program schedule table with hCalendar (original page http://we05.com/program.cfm is offline), using the 'axis' and 'headers' attributes. to-do: write up in the hcalendar-faq.
- 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?
- The use of fragments is unclear. Fragment interpretation seems to be agent dependent. 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.
- 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).
<a name="myfrag">heading</a> <div class="vevent"> <div class="description">A nice event</div> <abbr class="dtstart" title="2005-10-05">October 5</abbr> </div>
- ACCEPTED. We should clarify to converters how to interpret a fragment id. The interpretations are all consistent. It points to the element that is to be converted. If that element is empty then so is the conversion. There is no issue here other than a need for more documentation. to-do: add said documentation to hCalendar-faq.
- 2006-03-07 raised by
- 2006-04-10 raised by
- 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.
- ACCEPTED update spec and faq. to-do add links/documentation on both hCalendar, with more in hcalendar-faq, on why did hCalendar simply re-use the VEVENT object (previous format) from iCalendar without first researching/documenting real-world publishing data, and lessons learned. I.e. were we to do an "event" microformat today, we would likely omit most VEVENT properties because they would very likely not meet the 80/20 real-world publishing of event data implied schema requirement of the process. In effect, most VEVENT properties were omitted in that they were not explicitly listed in the hCalendar spec. It may still reasonable to document event-examples, and any VEVENT properties that didn't show sufficient at least implicit usage could be listed in hCalendar as merely "reserved" terms that have seen little use.
- 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.
- 2006-04-13 raised by
- 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.
- ACCEPTED update spec and hCalendar-to-iCalendar processing conformance requirements accordingly.
- 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.
- 2006-08-14 raised by
- 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.01 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.
- ACCEPTED update spec. More important than easy parsing/validation is the fact that the extended format (with explicit hyphens and colons) is both more readable and more listenable (per experience with accessibility testing), and thus better suited for both in-line text inclusion, and title attribute inclusion, both of which should be human readable and listenable.
- Update hCalendar 1.0 to make it a SHOULD for authors to use hyphens/colons for dates and times respectively, make it a MUST for processors to accept both formats for compatibility.
- In hCalendar 1.0.1 make it a SHOULD for authors to use hyphens/colons for dates and times respectively, and deprecate dates/times without separators. Keep it as a MUST for processors to accept both formats for compatibility.
- In hCalendar 1.1 make it a MUST for authors to use hyphens/colons for dates and times respectively, and obsolete dates/times without separators. Note for hCalendar 1.0.x compat that processors MUST accept both formats.
- ACCEPTED update spec. More important than easy parsing/validation is the fact that the extended format (with explicit hyphens and colons) is both more readable and more listenable (per experience with accessibility testing), and thus better suited for both in-line text inclusion, and title attribute inclusion, both of which should be human readable and listenable.
- 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.01 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.
resolved 2007
- 2007-01-07 raised by
- 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 repeatedabbris 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:
- Looking for a mechanism for specifying a dtstart without using
<dt id="D20070120">
<abbr class="dtstart" title="20070120">
Saturday, 20 January 2007
</abbr>
</dt>
<dd>
<span class="vevent">
<object class="include" data="#D20070120"></object>
[Details of first event]
</span>
<span class="vevent">
<object class="include" data="#D20070120"></object>
[Details of second event]
</span>
</dd>
object .include to display:none Andy Mabbett 04:10, 16 Jan 2007 (PST)
- Thanks Andy!
- This use of
objectis 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:
abbras the only way, I can seeabbrused 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
abbrthe only option? - Should the spec be written up more formally? should hCalendar be more relaxed? My take is that
abbris 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 wantabbrto disambiguate a displayed date and this is not really the same as an abbreviation. UA's should be liberal when looking for aclass="dtstart", after all they do know that they are within an event markup as they have met theclass="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)
- ACCEPTED FAQ. Two FAQs to add. 1. Yes, elements other than abbr can and should be used for marking up dates and times when they are more semantically appropriate, and especially when they minimize duplicating data. 2. object is a variant of the include-pattern and thus can be used for the requested functionality. The table cell headers attribute can also be used.
- resolved issue Update: see dtend-issue for current summary and details, and apparent consensus on this issue 2007-01-20 raised by
- Where
DTENDis 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 theabbrelement.- 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
dtendis 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)
- Include a note in the standard that contradictory markup such as
- ACCEPTED BRAINSTORM SPECUPDATE. In practice (e.g. http://barcamp.org ) it appears all too often (thus easy) to make the mistake of assuming a dtend value is inclusive, and thus the last day of many events is truncated by a day. I am proposing a solution on hcalendar-brainstorming in an attempt to help this move forward. In short, introduce the syntactic sugar "dtlast", which treats date values as *inclusive* for the last day of an event. Semantically "dtlast" is merely an override for any "dtend" property setting on that hCalendar event, with the aforementioned slight difference in handling. More details on hCalendar brainstorming: dtlast. Tantek 07:48, 1 Sep 2008 (PDT)
- REOPENING based on new data. It seems the number of instances that dtend is being used to indicate an inclusive end date has only increased in the past year, and by knowledgable authors as well. Adding a new property just for inclusive end dates may very well only confuse the matter. We need to seriously consider changing "dtend" to *be* inclusive for "date" values only, keeping its current functionality for datetime values (suggested by Webf2 above). This is probably worthy of documenting on its own page, something like dtend-issue. - Tantek 05:40, 26 August 2009 (UTC)
- RESOLVED SPECUPDATE. Per the apparent consensus documented on dtend-issue, I am declaring this issue resolved. dtend will be inclusive in hCalendar. Tantek 00:59, 1 October 2009 (UTC)
- 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]
- Where
resolved 2008
- 2008-01-17 raised by
- In some instances, see Yahoo Economic Calendar, the content in dtstart is split into two td (same issue for summary), which requires to either tag the date as dtstart or the time as dtstart. The reason is that due to the structure of HTML tables, it is not possible to mark up each part of the dtstart as value and wrap them all in an element of class dstart.
- The include-pattern could solve this, but the solution isn't pretty. TobyInk 03:33, 1 Mar 2008 (PST)
- In some instances, see Yahoo Economic Calendar, the content in dtstart is split into two td (same issue for summary), which requires to either tag the date as dtstart or the time as dtstart. The reason is that due to the structure of HTML tables, it is not possible to mark up each part of the dtstart as value and wrap them all in an element of class dstart.
<tr>
<td id="mydate006">2007-01-02</td>
<td class="dtstart">
<a href="#mydate006" class="include" style="display:none"></a>
<abbr title="T" style="display:none">time </abbr>13:00:00
</td>
</tr>
An alternative would be to use hidden metadata, although that goes against microformats principles. TobyInk 03:33, 1 Mar 2008 (PST)
<tr>
<td class="dtstart">2007-01-02<abbr style="display:none" title="T13:00:00"></abbr></td>
<td>13:00:00</td>
</tr>
- ACCEPTED example and faq. This real world example can now be readily solved with the
headersattribute and the value class pattern (without needing the include-pattern) and we should document it as such. E.g.
- ACCEPTED example and faq. This real world example can now be readily solved with the
<tr class="vevent">
<td id="d0825"><abbr class="value" title="2009-08-25">Aug 25</abbr></td>
<td headers="d0825" class="dtstart"><span class="value">8:30 AM</span></td>
<td class="summary"><a href=http://biz.yahoo.com/c/terms/durord.html>Durable Orders</a></td>
</tr>
- 2008-06-25 raised by
- HTML 5 introduces a
<time>element. Without wishing to push people into using HTML 5 prematurely, we could define a parsing procedure for dealing with these elements when they are encountered in microformats.- Bleeding-edge publishers who are already using HTML 5 could then choose to use this new semantic element with microformats. Publishers with accessbility concerns over the current datetime design pattern would be given some alternative ways of resolving their issue. (i.e. continue using HTML 4, but use the
<time>element invalidly; create a custom DTD based on HTML 4, but including<time>; or switch fully to HTML 5.) — TobyInk- Whilst providing an alternative to publishers concerned about accessibility is one way to solve this issue, it doesn't solve the issue for publishers who mandate (or are mandated) to use existing doctypes, or who operate on such a scale that sticking to existing specifications is an important part of ensuring their sites remain reliable in existing browsers. — BenWard
- The BBC can't use HTML5. It won't validate, it doesn't adhere to their standards and guidelines or their browser support levels. It simply isn't an option for them (and many other companies). — Phae
- If they are willing to consider amending their guidelines to allow RDFa, which is also invalid HTML 4.01/XHTML 1.0/XHTML 1.1, surely they *could* choose to amend their own guidelines to allow <time>. — Henri Sivonen
- Adopting
<time>does not require fully switching to HTML 5. Validation can be achieved through using a custom DTD. In terms of browser support, I think I've yet to encounter a browser that doesn't treat unknown tags as effectively being the same as<span>. — TobyInk- I guess it depends on what the purpose of validating markup is. That may validate to an SGML DTD, but it's not conforming HTML 4.01 (it's not valid HTML 4.01) and for what it's worth the HTML 4.01 specification specifically warns against extending text/html in this manner: http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.1 — Benjamin Hawkes-Lewis
- We are specifically advised by the W3C QA Group that custom DTDs are a bad idea. http://www.alistapart.com/articles/customdtds2/ — Paul Wilkins
- One of the W3C's clearest explanations of the reasons not to use custom DTDs is from their Style activity. The gist is that although DTDs can define the syntax for new elements and attributes, the meaning of the new elements and attributes has to be defined by standards and consensus, and they must be supported by browsers. This is not particularly applicable in this case, because the meaning of
<time>has been defined (albeit only in draft form so far) by the W3C HTML working group and they are supported by current browsers (right now the "support" is just that they ignore the unknown element and display its contents, but true support is probably around the corner). TobyInk 15:15, 17 Jul 2008 (PDT)
- A core principle of microformats is that they should work with the technologies available and in use *now* (HTML5 isn't widely supported and isn't even a w3c recommendation yet). — Phae
- I'd be wary of using a hybrid of HTML 4.01, RDFa, and HTML5 when neither RDFa nor HTML5 have been finalized yet, and when HTML5 is going to determine how browsers actually parse all text/html. What if HTML5 ends up specifying something in a way that is incompatible with the hybrid? — Benjamin Hawkes-Lewis
- ACCEPTED spec and faq. hCalendar 1.0.1 should define how hCalendar processors should process the <time> element, and this should be added to the hcalendar-faq as well as referenced by the HTML5 page. In addition the above discussion about custom DTDs should be added to an faq somewhere, as it is a very useful reference.
- Bleeding-edge publishers who are already using HTML 5 could then choose to use this new semantic element with microformats. Publishers with accessbility concerns over the current datetime design pattern would be given some alternative ways of resolving their issue. (i.e. continue using HTML 4, but use the
- HTML 5 introduces a
- 2008-12-22 raised by
- What if the event started few weeks ago, and has still not finished but has no known end date ? Writing only a dtstart would not be the reality as we do not know when this will end, but we know that it will end one day. Writing a dtend where dtend equals a date is also not the reality as we do not know when this event will finish. We can encounter this sort of problem with hresume where the last job experience has a start date, but has no end date. it would be good to use a special keyword that would mean "today" (where today always equals the system date now()) or "still going" such as
<abbr class="dtend" title="today">up to now</abbr> or <abbr class="dtend" title="still-going">now</abbr>
- ACCEPTED faq. This should be documented in both hcalendar-faq in the general case of an ongoing event, and in the specific case for hresume-faq - the author should either pick an estimated date and use that, or in the case of a job, generate the current date dynamically (perhaps server-side) and parenthetically indicate the ongoing nature.
- I've read that the dtend should be one day after the end of the event as the dtend is exclusive. But what if I use a short date representation, such as "2008" for year 2008, or "200802" for february 2008 ? Should I make the dtend finish one year, or one month later, as dtend is still exclusive ? This would be very confusing in my opinion.
- ACCEPTED add to dtend issue. The problem of dtend having to be one day after the expected end of the event is a known issue and will be considered as such.
- Last issue, what about an event that don't have a start time neither a end time, but that will last approximately the whole day. There is only a dtstart without time included ("20080428") and no dtend ? Or with a dtend with the same date ? Or with a dtend the day after ? Or with a special notation such as :
<abbr class="dtstart dtend" title="1998-07">july 1998</abbr>- ACCEPTED faq. This should be added to the hcalendar-faq. An event with only a known start day (without time) that will last approximately the whole day should simply be marked up as starting and ending on that same day.
- To sum up, how would you write an event that has no duration but which is only a moment in the life (this recalls the first of my issues where there is an event with no known end date, which is different from an event which has no end date because it has no duration!).
- ACCEPTED faq. Add to hcalendar-faq. You can mark up an event which is only a moment (presuming a moment is less than a second) as having the same dtstart and dtend.
resolved 2009
- 2009-02 raised by
- Unclear whether YYYY or YYYY-MM is valid for dtstart or dtend
- ACCEPTED faq and spec. add to hcalendar-faq year or year-month only values are invalid for dtstart and dtend (iCalendar requires specifying at least the day for the dtstart, and if dtend is specified, it too must specify at least the day). The hCalendar 1.0.1 spec should state how processors should handle partial dates (year only or year-month only) for dtstart and/or dtend. Perhaps imply beginning of the partial date (e.g. first of the month, first month of the year) given for dtstart, and end of the partial date (e.g. end of the month, last month of the year) give for dtend. If this appears to be of sufficient utility, it may be worth adding to hCalendar 1.1.
- Rationale for partial dates:
- Identity theft- Wikipedia for example has guidelines on Living Persons to protect against identity theft. Over 3000 Marriage, Birth and death dates and emitted by wikipedia, and a high percentage for living persons include year only for birth date.
- Unavailable precision Example: the birth date of Augustus Caesar is precisely known for the Roman calendar used at the time, however because of the frequency and chaos with which adjustments to that calendar were made prior to the adoption of the Julian calendar, the exact gregorian equivalent required for ISO8601 is impossible to know with precision. The best historians agree on is plus or minus 2 days, and it is said that it is unlikely there will ever be better precision. This is an example where we are using YYYY-MM, and it is quite common on in the 3500 genealogy pages emitting dstart/ dtends at genealogy.wikia.com, where it is frequently the case that family histories have only partial dates. -JMesserly 19:15, 6 April 2009 (UTC)
- REJECTED duplicate. See hcalendar-issues-closed#historical-dates.
- Unclear whether YYYY or YYYY-MM is valid for dtstart or dtend
- Specification references to
abbrpattern need to be removed/updated. See: /hcalendar#Human_vs._Machine_readable — the spec currently reads “This specification recommends that such<abbr>elements be used for the following iCalendar properties: DTSTART, DTEND, DURATION, RDATE, RRULE. That is no-longer appropriate. In fact, I think it should be made clearer that those properties may be marked up using the abbr, or value-class patterns, but that it isn't required. The current language basically masks the fact that you might publish 2009-07-14 literally, and may be some reason why people believe that they have to use the abbr pattern. Further, this language is incompatible with publishing HTML5 with thetimeelement.- Proposed resolution: Remove all ‘endorsement’ language regarding specific optimization patterns from the spec. The properties concerned should link to appropriate patterns and suggest uses ‘may’ use them to control the presentation of dates. --BenWard 17:39, 14 July 2009 (UTC)
- ACCEPTED update spec. hCalendar 1.0.1 will state that authors MUST use the value-class-pattern accordingly, and should only use abbr pattern when the author determines that the expanded title value is both human and machine readable and listenable, deprecating other uses of the abbr pattern. hCalendar 1.0.1 will also state that implementations MUST support the value-class-pattern.
- Proposed resolution: Remove all ‘endorsement’ language regarding specific optimization patterns from the spec. The properties concerned should link to appropriate patterns and suggest uses ‘may’ use them to control the presentation of dates. --BenWard 17:39, 14 July 2009 (UTC)
- All properties that are appropriate for use with the value-class-pattern must opt in to using it.. See: machine-data for the current reference for which properties have value-class-patterns support. Revisions of specifications should be updated to opt-in to value-class where appropriate.
- ACCEPTED update spec. See resolution to previous issue regarding #abbr-to-value-class.
resolved issue
- DURATION format. Is there a specification of the format used for durations? In example 4 (http://microformats.org/wiki/hcalendar-examples), the duration value is "PT1H". I guess "1H" is one hour, but what does "PT" mean? And this example doesn't work anyway; neither Google calendar nor Yahoo! calendar recognize this duration.
- Part 1 ACCEPTED FAQ, SPECUPDATE. The format for durations is from iCalendar RFC2445 which gets it from ISO8601. to-do this should be documented in hcalendar-faq, and explicitly referenced in an update to the hCalendar spec itself. Tantek 01:19, 1 October 2009 (UTC)
- Part 2 REJECTED, NEED STEPS TO DEMONSTRATE. What steps were taken which led to the conclusion that "neither Google calendar nor Yahoo! calendar recognize this duration" ? Without more information, this aspect of the issue will have to be closed, insufficient information. Tantek 01:19, 1 October 2009 (UTC)