hcalendar-issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (entry-title, TOC)
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(18 intermediate revisions by 5 users not shown)
Line 1: Line 1:
<entry-title>hCalendar issues</entry-title>
{{DISPLAYTITLE:hCalendar issues}}
__TOC__
__TOC__
These are externally raised issues about [[hcalendar|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.   
These are externally raised issues about [[hcalendar|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.   
Line 20: Line 20:
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.
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.


=== issues 2005 ===
=== issues 20010 ===
* 2005-07-11 raised by 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 mentioned.  At present X2V doesn't appear to handle them.  This came up in a discussion about [[xfolk|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.
 
* 2005-07-21 raised by Neil Jensen
*# ''should we create a vfreebusy class for HTML representations of freebusy data? Discussion [http://microformats.org/wiki/hcalendar-brainstorming#Free.2FBusy_information on hCalendar brainstorming].  Additional background: [http://www.ifreebusy.com/cyclical/blog/calendar/3.html here].''
 
* 2005-07-27 raised by Paolo Massa
*# ''I tried to add a hcalendar event in my blog but it rendered orribly. 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:
 
.vevent .summary {
 
//remove all the previously set properties, for example:
 
text-decoration: none;
 
font-size: 100%;
 
...
 
}
 
Since the hCalendar microformat is the following,
 
<span class="vevent">
 
<a class="url" href="http://www.web2con.com/">
 
<span class="summary">Web 2.0 Conference</span>:
 
...
 
I hope to have been clear but I'm not so sure ;-)''
 
 
 
=== issues 2006 ===
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2006-03-07</span> raised by <span class="author vcard"><span class="fn">[[User:Ragdoll|Justin McDowell]]</span></span></span>
<div class="entry-content">
*# 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]] . [[User:Leikam|Michael Leikam]] 2007-01-29
</div>
</div>
 
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2006-04-10</span> raised by <span class="author vcard"><span class="fn">[[User:ScottReynen|Scott Reynen]]</span></span></span>
<div class="entry-content">
*# When someone looks at the [[hcalendar|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.
</div>
</div>
 
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2006-04-13</span> raised by <span class="author vcard"><span class="fn">Tantek</span></span></span>
<div class="entry-content">
*# Need to add a section on "Property Exceptions" like that in [[hcard|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|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.
</div>
</div>
 
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2006-08-14</span> raised by <span class="author vcard"><span class="fn">[[User:Elias|Elias Sinderson]]</span></span></span>
<div class="entry-content">
*# 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 [http://www.w3.org/TR/NOTE-datetime note] (submitted by Reuters), which recommends that the extended (delimited) format be used, and the [http://www.w3.org/TR/html401/types.html#h-6.11 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 [http://www.w3.org/TR/xmlschema-2/#date xsd:date] and [http://www.w3.org/TR/xmlschema-2/#dateTime 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.
</div>
</div>
 
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2006-09-22</span> raised by <span class="author vcard"><span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span></span>
<div class="entry-content">
*# 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 <pre><nowiki><abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> </nowiki></pre> be used? If so, that should be indicated, via an example.
</div>
</div>
 
=== issues 2007 ===
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2007-01-07</span> raised by <span class="author vcard"><span class="fn">[[User:Webf|Webf]]</span></span></span>
<div class="entry-content">
*# ''Looking for a mechanism for specifying a dtstart without using <code><nowiki><abbr></nowiki></code>. Would be used where there are a number of events (as in the [http://www.webfeet.org/events.html Webfeet events lists]) where you do not want to have the visible date repeated''
*#* <code>abbr</code> 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:
 
<code>
<pre>
<nowiki>
<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>
</nowiki>
</pre>
</code>
 
: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 <code>object .include</code> to <code>display:none</code> [[User:AndyMabbett|Andy Mabbett]] 04:10, 16 Jan 2007 (PST)
 
:Thanks Andy!
:* This use of <code>object</code> is a proposal at this stage? It does not seem to be mentioned in the [[hCalendar|hCalendar]] page and only marked 'under consideration' in [[include-pattern#Specifications_Using|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: <code>abbr</code> as the ''only'' way, I can see <code>abbr</code> used within the [[hCalendar|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 <code>abbr</code> the ''only'' option?
:** Should the spec be written up more formally? should hCalendar be more relaxed? My take is that <code>abbr</code> is OK but it would be wrong for it to be mandatory. Think that screen readers may be reading the expanded content (as with <code><nowiki><abbr title="Web Accessibility Initiative">WAI</abbr></nowiki></code>). The underlying issue is that [[hCalendar|hCalendar]] seems to want <code>abbr</code> to <em>disambiguate</em> a displayed date and this is not really the same as an abbreviation. UA's should be liberal when looking for a <code>class="dtstart"</code>, after all they <em>do</em> know that they are within an event markup as they have met the <code>class="vevent"</code>....
:*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. :-) [[User:Webf|Webf]] 13:23, 21 Jan 2007 (PST)
</div>
</div>
 
<div class="hentry">
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2007-05-12</span> raised by <span class="author vcard"><span class="fn">Anon</span></span></span>
{{OpenIssue}}  
<div class="entry-content">
<span class="entry-summary author vcard">
*# 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.
  <span class="published">2010-MM-DD</span>  
</div>
  raised by <span class="fn">[[User:Toby|Toby]]</span>
</div>
</span>
 
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2007-01-20</span> raised by <span class="author vcard"><span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span></span>
<div class="entry-content">
*# <span id="dtend-date-plus1">Where <code>DTEND</code> is a date</span>, and not a date-time, it is required to be the day after the end of the event, thus: <code><nowiki><abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>. 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 <code>abbr</code> element.
*#*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 <nowiki><abbr class="dtend" title="2007-04-29 23:59:59">29 April 2007</abbr></nowiki>, or be more specific with their times. - [[User:CiaranMc|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. [[User:Matthew|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 <code>dtend</code> 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 <code><nowiki><abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code> is bad practice and should be avoided
*#** Make a break with the ical usage that end dates are exclusive.
*#** Make the meaning clear: <div><code><nowiki><abbr class="dtend" title="value=date:value=inclusive:2007-04-29">29 April 2007</abbr></nowiki></code></div> <div><code><nowiki><abbr class="dtend" title="value=exclusive:2007-04-30">29 April 2007</abbr></nowiki></code></div> <div>or maybe</div> <div><code><nowiki><abbr class="dtend;value=date:value=inclusive" title="2007-04-29">29 April 2007</abbr></nowiki></code> [[User:Webf2|Webf2]] 00:25, 13 May 2007 (PDT)</div>
*#* 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 "[[hcalendar-brainstorming#dtlast|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|hCalendar brainstorming: dtlast]]. [[User:Tantek|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. This is probably worth of documenting on its own page, something like [[dtend-issue]]. - [[User:Tantek|Tantek]] 05:40, 26 August 2009 (UTC)
</div>
</div>
 
=== issues 2008 ===
 
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2008-01-16</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span></span>
<div class="entry-content">
*# Lack of method for marking up vague dates and eras; see [[history-examples#The_Problem|vague-date examples]].
</div>
</div>
 
 
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2008-01-17</span> raised by <span class="author vcard"><span class="fn">[[User:Guillaume Lebleu|Guillaume]]</span></span></span>
<div class="entry-content">
*# In some instances, see [http://biz.yahoo.com/c/e.html 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 dstart. 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. [[User:TobyInk|TobyInk]] 03:33, 1 Mar 2008 (PST)
<pre>
<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>
</pre>
An alternative would be to use hidden metadata, although that goes against uF principles. [[User:TobyInk|TobyInk]] 03:33, 1 Mar 2008 (PST)
<pre>
<tr>
  <td class="dtstart">2007-01-02<abbr style="display:none" title="T13:00:00"></abbr></td>
  <td>13:00:00</td>
</tr>
</pre>
</div>
</div>
 
 
<div class="hentry" id="html5-time-element">
* {{OpenIssue}} <span class="entry-title"><span class="published">2008-06-25</span> raised by <span class="author vcard"><span class="fn">[[User:TobyInk|TobyInk]]</span></span></span>
<div class="entry-content">
HTML 5 introduces a <code>&lt;[http://www.w3.org/html/wg/html5/#the-time time]></code> 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 <code>&lt;time></code> element invalidly; create a custom DTD based on HTML 4, but including <code>&lt;time></code>; or switch fully to HTML 5.) — [[User:TobyInk|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 <code>&lt;time></code> 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'm yet to encounter a browser that doesn't treat unknown tags as effectively being the same as <code>&lt;span></code>. — [[User:TobyInk|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 [http://www.w3.org/Style/customdtd 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 <code>&lt;time></code> ''has'' been defined (albeit only in draft form so far) by the [http://www.w3.org/html/wg/ 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). [[User:TobyInk|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
* There is no way to define BC (before Christ) dates, is there? There should be! [[User:Thamis|Thamis]] 03:58, 30 Sep 2008 (PDT)
</div>
</div>
 
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2008-12-22</span> raised by <span class="author vcard"><span class="fn">Ploc</span></span></span>
<div class="entry-content">
*# 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 hresum 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
<pre><abbr class="dtend" title="today">up to now</abbr></pre> or <pre><abbr class="dtend" title="still-going">now</abbr></pre>
*# 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.
*# 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 :
<pre><abbr class="dtstart dtend" title="1998-07">july 1998</abbr></pre>
*# 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 oy 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 !).
</div>
</div>
 
=== 2009 ===
<div class="hentry">
* {{OpenIssue}} <span class="entry-title"><span class="published">2009-02</span> raised by <span class="author vcard"><span class="fn"> JMesserly </span></span></span>
<div class="entry-content">
*# Unclear whether YYYY or YYYY-MM  is valid for dtstart or dtend
*#*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 [http://genealogy.wikia.com/index.php?title=Special:WhatLinksHere/Template:Info_table_person&from=70556&back=0&limit=500 genealogy.wikia.com], where it is frequently the case that family histories have only partial dates. -[[User:JMesserly|JMesserly]] 19:15, 6 April 2009 (UTC)
</div>
</div>
 
 
<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-07-14</span> raised by <span class="fn">[[User:BenWard|BenWard]]</span></span>
<div class="entry-content discussion issues">
<div class="entry-content discussion issues">
* <strong class="entry-title">Specification references to <code>abbr</code> pattern need to be removed/updated</strong>. See: [http://microformats.org/wiki/hcalendar#Human_vs._Machine_readable /hcalendar#Human_vs._Machine_readable] — the spec currently reads “This specification recommends that such <code>&lt;abbr></code> elements be used for the following iCalendar properties: DTSTART, DTEND, DURATION, RDATE, RRULE</code>. 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 <samp>2009-07-14</samp> 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 the <code>time</code> element.
* <strong class="entry-title">non-ending events</strong>. How to deal with events that do not end, or even as such occur, just "applied" to a person. Such as in hResume, an award, under experience, would use hCalendar. it does not have an end nor does it continue, I am awarded a certain status and now have that status or recognition of ability. It is awarded on a certain date but it does not end, I do not lose ability, but nor does the awarding continue, I am not re-awarded every single day, so the solution of "to present" for an ongoing event etc, is not really suitable.  
** 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. --[[User:BenWard|BenWard]] 17:39, 14 July 2009 (UTC)
</div>
</div>


<div class="hentry">
Some new  way to do this could be added to hCal that is not linked to vCal so that online extractors of hCal (and not vCal) would not automatically represent events with no end date as ending "present" (as with madgex hres to word) unless otherwise specified that this is intended.
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-07-14</span> raised by <span class="fn">[[User:BenWard|BenWard]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">All properties that are appropriate for use with the [[value-class-pattern]] must opt in to using it.</strong>.  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.
</div>
</div>
</div>
</div>


== Template ==
== Template ==
{{issues-format}}
{{issues-format}}


== Related Pages ==
== Related Pages ==
{{hcalendar-related-pages}}
{{hcalendar-related-pages}}

Latest revision as of 16:24, 18 July 2020

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 and the hCalendar resolved issues 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

For matters relating to the iCalendar specification itself, see icalendar-errata and icalendar-suggestions.

See related hcard-issues.

closed issues

See: hcalendar-issues-closed.

resolved issues

Issues that are resolved but may have outstanding to-do items. See: hcalendar-issues-resolved.

Issues

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.

issues 20010

open issue! 

2010-MM-DD 
raised by Toby

  • non-ending events. How to deal with events that do not end, or even as such occur, just "applied" to a person. Such as in hResume, an award, under experience, would use hCalendar. it does not have an end nor does it continue, I am awarded a certain status and now have that status or recognition of ability. It is awarded on a certain date but it does not end, I do not lose ability, but nor does the awarding continue, I am not re-awarded every single day, so the solution of "to present" for an ongoing event etc, is not really suitable.

Some new way to do this could be added to hCal that is not linked to vCal so that online extractors of hCal (and not vCal) would not automatically represent events with no end date as ending "present" (as with madgex hres to word) unless otherwise specified that this is intended.

Template

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">
{{OpenIssue}} 
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
</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
</div>
</div>

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.

Retrieved from "http://microformats.org/wiki/index.php?title=hcalendar-issues&oldid=69812"