[whatwg] Calendar feedback

We got basically one organic request for calendar markup over the past few 
years, so I'm concluding this is not a priority. As noted below, hCalendar 
addresses the use case to some extent, which is probably enough to deal 
with this level of demand. Some further comments below, though not much.

On Wed, 2 Feb 2005, Matthew Raymond wrote:
>
> I like the idea of a calendar in Web Applications 1.0, but I really hate 
> the way they're currently implemented. For one thing, if the |class| 
> attribute contains the name of a calendar attribute, how do you style 
> the element? What happens if you use |class| to style something, and the 
> class happens to be the name of a calendar attribute? Does it style that 
> attribute.
> 
> Nope, I prefer to stick with good old-fashioned elements. Here's an 
> example of what I'd like to see, minus the fallback content:
> 
> | <calendar>
> |   <cevent id="e036f260-39b4-11d9-ad3f-fc68600c1802">
> |     <csummary value="That thing we did that was so fun."></csummary>
> |     <cattr type="status" value="CONFIRMED"></cattr>
> |     <cattr type="class" value="PRIVATE"></cattr>
> |     <cattr type="categories" value="Work"></cattr>
> |     <cattr type="x-mozilla-alarm-default-length" value="0"></cattr>
> |     <cattr type="dtstamp" value="2005-02-02T21:00Z"></cattr>
> |     <cdatetime start="2005-02-30T19:00Z" end="2005-02-30T21:00Z">
> |     </cdatetime>
> |   </cevent>
> | </calendar>
> 
> Basic stuff like the summary and the start and end dates are defined 
> specifically. The rest of the calendar event attributes are defined with 
> <cattr type="attribute-name">. A WA1-compliant UA would then assign the 
> |value| attribute as the value of the calendar event attribute. If 
> |value| is not specified, the child contents are used. The <cdatetime> 
> element is a special case in that it requires <datetime> elements to be 
> in the child contents if |value| is undefined.
> 
> All contents inside <calendar> that are not calendar-related elements or 
> the contents of calendar-related elements are ignored. As a result, the 
> following would provide proper fallback content:
> 
> | <calendar>
> |   <table>
> |     <caption>Upcoming Events</caption>
> |     <tr>
> |       <th>Summary</th>
> |       <th>Status</th>
> |       <th>Class</th>
> |       <th>Categories</th>
> |       <th>Start Date</th>
> |       <th>End Date</th>
> |     </tr>
> |     <cevent id="e036f260-39b4-11d9-ad3f-fc68600c1802">
> |     <tr>
> |       <td><csummary>
> |         That thing we did that was so fun.
> |       </calsummary></td>
> |       <td><cattr type="status">CONFIRMED</cattr></td>
> |       <td><cattr type="class">PRIVATE</cattr></td>
> |       <td><cattr type="categories">Work</cattr></td>
> |       <cattr type="x-mozilla-alarm-default-length" value="0"></cattr>
> |       <cattr type="dtstamp">
> |         <datetime value="2005-02-02T21:00Z"></datetime>
> |       </cattr>
> |       <cdatetime>
> |         <td><datetime value="2005-02-30T21:00Z">
> |           02/30/05 7:00 PM
> |         </datetime></td>
> |         <td><datetime value="2005-02-30T21:00Z">
> |           02/30/05 9:00 PM
> |         </datetime></td>
> |       </cdatetime>
> |     </tr>
> |     </cevent>
> |   </table>
> | </calendar>
> 
> The above should render in legacy user agents as a table, with values 
> unimportant to presentation not rendered. Yet, for a WA1 UA, it yields 
> the same calendar as the first example.
> 
> Note that in both examples, if the |type| of a <cattr> element is 
> unknown to the user agent, the value can simply be ignored. The <cattr> 
> would have a set of standardized |type| values that all user agents 
> would support, then individual user agent vendors could implement 
> extensions, with the recommended nomenclature being something like this:
> 
>    x-[company or organization]-[attribute name]
> 
> This should give us a reasonable amount of flexibility and extensibility 
> without creating a complicated markup scheme. If necessary, <cdatetime> 
> and <csummary> could be rolled into <cattr>, but I'd prefer to have 
> these separate, since they're likely to always be used.

On Fri, 18 Feb 2005, Matthew Raymond wrote:
> 
> While I like [that] idea, it seems to introduce too many tags, so I've 
> simplified things a bit. The element <cattr> will now be called <vattr> 
> and will be used in place of <cdatetime> and <csummary>. This may seem 
> to general, but if you look at a vCalendar example, it's pretty straight 
> forward. Here's a vCalendar from the hCalendar spec 
> (http://developers.technorati.com/wiki/hCalendar):
> 
> | BEGIN:VCALENDAR
> | PRODID:-//XYZproduct//EN
> | VERSION:2.0
> | BEGIN:VEVENT
> | URL:http://www.web2con.com/
> | DTSTART:20041005
> | DTEND:20041007
> | SUMMARY:Web 2.0 Conference
> | END:VEVENT
> | END:VCALENDAR
> 
> Now here's how I propose we handle the same information in WA1 markup:
> 
> | <vcalendar>
> |   <vattr name="prodid" value="-//XYZproduct//EN"
> |   <vattr name="version" value="2.0"></vattr>
> |   <vevent>
> |     <vattr name="url" value="http://www.web2con.com/"></vattr>
> |     <vattr name="dtstart" value="2004-10-05"></vattr>
> |     <vattr name="dtend" value="2004-10-07"></vattr>
> |     <vattr name="summary" value="Web 2.0 Conference"></vattr>
> |   </vevent>
> | </vcalendar>
> 
> It's fairly simple, and it can be transformed directly into a vCalendar 
> and back. The idea is quite similar for vCards. Let's look at and 
> example from the hCard spec 
> (http://developers.technorati.com/wiki/hCard):
> 
> | BEGIN:VCARD
> | VERSION:3.0
> | N:?elik;Tantek
> | FN:Tantek ?elik
> | URL:http://tantek.com
> | END:VCARD
> 
> This translates into the following markup:
> 
> | <vcard>
> |   <vattr name="version" value="3.0"></vattr>
> |   <vattr name="n" value="?elik;Tantek"></vattr>
> |   <vattr name="fn" value="Tantek ?elik"></vattr>
> |   <vattr name="url" value="http://tantek.com"></vattr>
> | </vcard>
> 
> As you can see, the markup structure mirrors the vCard structure and 
> contains the same attribute names and information. It would be trivial 
> to parse this information and convert it to vCard format.
> 
> Here's the same two examples with fallback content:
> 
> | <vcalendar>
> |   <table>
> |     <caption>Upcoming Events</caption>
> |     <tr>
> |       <th>URL</th>
> |       <th>Start Date</th>
> |       <th>End Date</th>
> |       <th>Summary</th>
> |     </tr>
> |     <vevent>
> |     <tr>
> |       <td><vattr name="url">http://www.web2con.com/</vattr></td>
> |       <td><vattr name="dtstart">2004-10-05</vattr></td>
> |       <td><vattr name="dtend">2004-10-07</vattr></td>
> |       <td><vattr name="summary">Web 2.0 Conference</vattr></td>
> |     </tr>
> |     </vevent>
> |   </table>
> | </vcalendar>
> 
> | <vcard>
> |   <vattr name="version" value="3.0"></vattr>
> |   <vattr name="n" value="?elik;Tantek"></vattr>
> |   <div id="tc" class="vcard">
> |     <p><vattr name="fn">Tantek ?elik</vattr></p>
> |     <a href="http://tantek.com">
> |      <vattr name="url">http://tantek.com</vattr>
> |     </a>
> |     <button type="button" onclick="return addContact('tc')">
> |       Add to contact list...
> |     </button>
> |   </div>
> | </vcard>

On Fri, 18 Feb 2005, Brad Neuberg wrote:
>
> Have you seen Tantek's work with hCalendar, which is basicly the iCal 
> standard translated into XHTML? It's very clean and seems like a nice 
> ancillary standard that could be included with WA:
>
> http://developers.technorati.com/wiki/hCalendar

On Mon, 21 Feb 2005, Matthew Raymond wrote:
> 
> There are several problems with hCalendar (and in turn, vCard):
> 
> 1) 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.

I don't really see why we need to distinguish them. Classes should all 
fall into the first category, and can all be used for the second.


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

Why not?


> 3) Other than Ian's <calendar> addition, there's no actual semantic 
> markup for calendars or business cards.

How so? The Microformats hCalendar class just makes it so, no?


> 4) What happens if I use a class inside <calendar> when I don't want the 
> element I use it on to be a property of the calendar? What happens if 
> the class is used both inside and outside <calendar>?

I recommend raising these issues with the Microformats crowd.


> 5) What do I do if I want to add styling to a group of calendar events, 
> especially if the calendar contains dynamic content? Styling a long list 
> of IDs through the use of dynamically generated CSS doesn't sound all 
> that appealing.

I don't see why we couldn't support both, but again, that's a 
Microformats issue.


> 6) What do you do if you don't want the calendar or card to show up on 
> legacy user agents, or what if you don't want specific properties to 
> show up? hCalendar and hCard require you to use CSS to hide markup in 
> legacy user agents.

That doesn't seem like a problem.


> 7) The use of <abbr> for dates is incorrect. "August 5th, 2004" is not 
> the abbreviation of 2004-09-05. In fact, the opposite is closer to the 
> truth. So, what would be a semantically correct method for storing 
> separate values for legacy UAs and WA1 UAs?

<time> solves this now.


> 8) If we're going to use title for separation of content for differing 
> user agents, what happens when we want tooltips on certain items for 
> legacy user agents? For that matter, how do we use those tooltips on WA1 
> user agents?

title="" seems like the right solution for tooltips.


> 9) What element is most appropriate in specific circumstances? Would the 
> use of <acronym> for DTSTART be just as good as <abbr>??? What happens 
> if a browser doesn't support either <acronym> or <abbr> with respect to 
> calendars?

<acronym> is gone.


> So, effectively, for hCard and hCalendar, you have to create a complex 
> set of rules for all possible uses of legacy markup within <calendar> 
> which can easily be implemented incorrectly, and even then you still 
> have styling and tooltip issues that are unresolved. By contrast, my 
> system had a clear separation between legacy markup and WA1 markup. My 
> system also works on a simple set of rules that don't change or overload 
> any existing elements, and it does so without adding complicated markup. 
> Compare the following:
> 
> | <calendar>
> |  <span class="vevent">
> |   <a class="url" href="http://www.web2con.com/">
> |    <abbr class="dtstart" title="20041005">October 5</abbr>-
> |    <abbr class="dtend" title="20041007">7</abbr>
> |    <span class="summary">Web 2.0 Conference</span>
> |   </a>
> |  </span>
> | </calendar>
> 
> | <vcalendar>
> |  <vevent>
> |   <a href="http://www.web2con.com/">
> |    <vattr name="url" value="http://www.web2con.com/"></vattr>
> |    <vattr name="dtstart" value="20041005">October 5</vattr>-
> |    <vattr name="dtend" value="20041007">7</vattr>
> |    <vattr name="summary">Web 2.0 Conference</vattr>
> |   </a>
> |  </vevent>
> | </vcalendar>
> 
> They're very similar, but only the first overloads |class| and |title|. 
> Only the hCalendar example uses multiple elements to define calendar 
> properties. Granted, you save an element, but at the cost of diluting 
> the meaning of <a>.
> 
> Not that I don't see the advantage and flexibility of the 
> hCard/hCalendar system. You can use multiple class names to declare 
> redundant attributes in a single element. You can also nest 
> calendar/card attributes. (Then again, you could theoretically do the 
> same with <vattr>.)
> 
> The problem is that, for all the creative ways you can use 
> hCalendar/hCard, it's more complicated for webmasters to read and 
> understand and more complicated for developers to implement. 
> Furthermore, I dislike the entire system of using class names as markup. 
> Class names should be reserved for user-defined semantics.

These are fair points, but given the low level of demand for this, I don't 
propose doing anything about it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 19 April 2008 21:10:55 UTC