[uf-discuss] hCard improvement - more implied "n" handling
lists at allinthehead.com
Tue Jul 11 06:46:00 PDT 2006
On 11 Jul 2006, at 05:30, Tantek Çelik wrote:
> So the simple proposal is:
> If the implied "n" optimization (one or two words) doesn't apply
> and there is no "n" property, then treat the "fn" element as if it
> is "fn n"
> and look for explicit "n" subproperties inside the "fn" element.
Sounds sensible to me.
My only concern is that the more rules we add to make things easy,
the more rules each publisher has to learn.
An example of this is the existing implied-n, which makes it easier
to publish a simple name, but requires the publisher to learn the
five acceptable name formats. I'm not sure if that's surface-level
simplicity. Would genuine simplicity require n at all times?
> Brian informs me that this is quite easy to implement, and I think
> it will
> make the common n subproperty cases much easier to author correctly by
> Any objections to making this change?
> Scott, Drew, Assaf - any idea how hard this will be to implement in
There's only one way to find out .. and the short answer is it's hard
to implement for me. Not for finding the values, but for presenting
them in a predictable way to the next piece of software up the chain.
Saying that the sub properties of n are now permissible values for fn
if n is not present, means that I need to jump through hoops to make
that transparent in what I present back. But .. hard as in a couple-
of-hours hard, not as in days. I have a build of this working, which
I'm re-running through the hCard tests as we speak.
More information about the microformats-discuss