[uf-discuss] FACE and microformats?
Drew McLellan
lists at allinthehead.com
Tue Jun 13 04:43:20 PDT 2006
On 13 Jun 2006, at 11:57, Faruk Ates wrote:
> Hello everyone,
>
> First, I'm assuming here that you all know FACE: http://
> kurafire.net/projects/face — if not, please check that out so you
> know what I'm babbling about below.
>
> Now, I've been thinking about the next release version for a long
> while and one of the things I want to improve is the current
> implementation of id and class attributes, used to trigger and
> configure FACE, respectively.
To me it seems like the main flaw with the current implementation is
that you're assuming you have exclusivity of the entire class
attribute value string. As you know, that value is frequently a space
delimited string of values - so your script isn't being a very
friendly citizen. I see no reason why you shouldn't be able to have
your code look for a value within that string. It shouldn't be a
problem to modify your regexp to find this, for example:
class="vcard FACE:C:foobar:40:MO:50:50 boxout"
Sure, it's ugly, but the whole concept isn't exactly elegant :)
> My question to you fine people is: are there any good reasons why I
> shouldn't change this around so that the configuration is put on
> the title attribute instead?
>
> The only disadvantage I see is that without clearing the title
> attribute after fetching the data from it would leave the tooltip
> with totally un-tooltip-like data (it would be something like
> title="C:foobar:40:MO:50:50" for instance).
My reservation with this is that it precludes valid use of the title
attribute. Plus, in no way is your data block a title. I'd struggle
to argue that it's a classification, but if you squint it's more a
classification than a title. The possibility of a user-agent
rendering this data (which is entirely possible) is rather too much
to bear.
So I'd say keep it in the class, but make it play nice.
drew.
More information about the microformats-discuss
mailing list