[microformats-discuss] UA requirements for microformats
Tantek Ç elik
tantek at cs.stanford.edu
Wed Jul 13 05:50:12 PDT 2005
On 7/13/05 5:23 AM, "Ian Hickson" <ian at hixie.ch> wrote:
> On Wed, 13 Jul 2005, Tantek Çelik wrote:
>>
>> By lowering the barrier to entry for publishers, from a purely economic
>> perspective, microformats gain a much more rapid adoption curve than
>> other efforts which ask the publisher to do a lot more.
>>
>> In fact, even just as I personally have been seeing it, their adoption
>> has outpaced my ability to keep up with it. Hence those of us early
>> pioneers in microformats build microformats.org to provide a place for
>> the community to grow itself, with guiding input as needed.
>
> The problem with the rapid adoption is that since the specs don't yet have
> exact UA conformance requirements (e.g. how to process an HTML document to
> turn it back into an iCalendar data structure) we're going to end up in
> the same tag soup mess that HTML UAs ended up in: UAs are going to have to
> be reverse-engineering each other to determine how to parse the data.
First, I agree we need to write up the exact UA conformance requirements. I
believe the microformats community (editors, authors, publishers) accepts
that responsibility.
Second, while I agree there is that danger of ending up in the same kind of
mess, I believe quite a few factors have changed in terms of the state of
modern web design which will avoid a number of the problems that HTML tag
soup ran into.
Third, the rapid adoption among publishers is being used to find problems
*quickly* in the specs, and iterate the specs (and the published data), and
not after years of work when there are legacy implementations that need to
be supported. In that way, we're seeking to *avoid* the reverse engineering
of legacy behaviors that HTML is now saddled with.
I'm not guaranteeing that this approach will for certain work, but I believe
it is our best bet at rapidly developing these specs which are in high
demand with minimum chance of having to deal with legacy.
> This IMHO is the single most important problem facing microformats today,
IMHO that's good news, because I believe this to be a solvable problem.
> 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?
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.
And as you think of additional issues, please add them to the issues pages
for those specs.
Your contributions and feedback are *greatly* appreciated Ian.
Thanks,
Tantek
More information about the microformats-discuss
mailing list