[microformats-discuss] UA requirements for microformats

[Tantek Ç elik]

On 7/13/05 6:08 AM, "Ian Hickson" <ian at hixie.ch> wrote:

> On Wed, 13 Jul 2005, Tantek Çelik wrote:
>> 
>> First, I agree we need to write up the exact UA conformance
>> requirements.  I believe the microformats community (editors, authors,
>> publishers) accepts that responsibility.
> 
> I know, I just thought I'd raise it again to remind y'all. ;-)

Feel free to remind us :)


>>> and is the second biggest problem stopping microformats being adopted
>>> in the HTML5 specs. (The primary reason is I haven't had the time to
>>> get around to working on those parts of the spec yet.)
>> 
>> Do the HTML5 specs have any sort of specific timeline?
> 
> WF2 was supposed to be in CFI last August, but will probably reach CFI
> this August. So that's roughly twice as long as predicted. (CFI = call for
> implementations, although of course WF2 is being implemented already.)
> 
> So if I say that WA1 (aka HTML5) should be ready for CFI in December 2006,
> it'll probably actually reach CFI in mid 2008.

Good to know.

> But of course implementations of _that_ have started already as well.

Yes.


> Maybe a more useful answer to your question would be to consider what
> order I'll be working on things. I expect the next few weeks to be spent
> on the Window interface (I just did window.history, I'm doing
> window.location now; I may do other window properties before moving on to
> other things). After that I expect I'll look at the Parsing chapter,
> followed probably by looking at events and the attribute event handlers
> and defining those. After that I expect I'll look at the new widgets, like
> <gauge> and <progress>. At this point I'll probably be looking at
> <calendar> and <vcard>. My ETA on that would be end of this year. My
> productivity is likely to soar after the damp of the Oslo summer is over.

Got it.


> However, it depends on demand. If suddenly there is a big demand for a
> spec for a calendar widget, then I'll jump straight to <calendar>.

Or, for folks who are impatient, point them upstream at hCalendar.  That way
we can make sure it works for them.


>> I hypothesize that by the time you get to working on those parts of the
>> spec (specifically hCard and hCalendar), that those specs will be frozen
>> enough for you to depend on them.
> 
> ...I could start working on those parts next week. ;-)

;)


> (Note that there is no guarentee that hCard and hCalendar will be used for
> the HTML5 vCard and iCalendar integration. Currently it seems to be the
> most mature option and I don't see any reason to make up our own, but if
> better proposals come along of course they would be considered too. I'm
> making this explicit because otherwise people say that I'm giving hCard
> and hCalendar preferential treatement and ignoring feedback, which is not
> my intention at all.)

Completely fair, and completely understood.

I'm more than willing to have hCard and hCalendar be measured by their
success in the market and level of maturity (especially since so much of
their maturity, e.g. the core schemas, is already far ahead of nearly any
other contact-info / event effort, short of vCard and iCalendar itself of
course).

Tantek