[whatwg] Calendar feedback
Ian Hickson
ian at hixie.ch
Sat Apr 19 21:10:55 PDT 2008
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list