hcalendar-issues
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. 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.
Issues
Please use this format:
- YYYY-MM-DD raised by AUTHORNAME
- Issue 1: Here is the first issue I have.
- Issue 2: Here is the second issue I have.
- 2005-07-21 raised by Neil Jensen
- should we create a vfreebusy class for HTML representations of freebusy data? Discussion here.
- 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="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about xFolk.
- 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-02-22 raised by Matt Raymond on the whatwg list:
- There is no copyright statement and no patent statement.
- ACCEPTED. I have updated ["hCalendar"] (and ["hCard"], and all other MicroFormats) with a standard copyright statement and patent statement.
- There is no copyright statement and no patent statement.
- 2005-02-18 raised by Matt Raymond 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.
- REJECTED (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
- 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).
- REJECTED (out of scope). Extension properties are outside the current scope of hCalendar.
- The use of for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.
- REJECTED (false statement). This is simply a false statement. See this article for an explanation of this use of : Human vs. ISO8601 dates problem solved
- You have to create a complex set of rules for all possible uses of legacy markup within which can easily be implemented incorrectly.
- 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.
- There are styling and tooltip issues that are unresolved.
- REJECTED (empty statements). See the ["hCalendarFAQ"] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
- hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.
- REJECTED (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.
- I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.
- ACCEPT-PARTIAL. 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.
- 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.
- 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.