On Jan 4, 2007, at 8:52 AM, Brian Suda wrote:
On 1/4/07, Breton Slivka <[EMAIL PROTECTED]> wrote:
<div class="vcard">
<span class="fn">Abraham Lincoln</span>
<div class="org">United States</div>
<div class="adr">
<div class="street-address">1600 Pennsylvania Ave.</div>
<span class="locality">Washington</span>
,
<span class="region">DC</span>
<abbr class="dod" title="18650415">April 15, 1865</abbr>
</div>
Then, someone can correct me if this is incorrect, when a client
written to deal with DoD encounters class="dod", it can import it
with an "x-" prefix (for vendor specific properties, as allowed by
vcard, I think) rather than try and do fancy things with notes. (see
note above about client author disagreements).
--- i'll keep this breif because we are toeing that fine-line between
discuss and dev lists. If you want to chat more about this, we can
take this to the dev list.
The problem with random x- prefixes is that a parse can NOT determine
if the value 'dod' is meant to convey semantics (date of death) or
that is purely a CSS style.
For instance:
<div class="vcard">
<span class="fn president blue-box call-out alert">Abraham Lincoln</
span>
</div>
what becomes 'x-???' in vcard and what doesn't?
BEGIN:VCARD
FN:Abraham Lincoln
X-PRESIDENT:Abraham Lincoln
X-BLUE-BOX:Abraham Lincoln
X-CALL-OUT:Abraham Lincoln
X-ALERT:Abraham Lincoln
END:VCARD
Because of this, there has not been any attempt to add in the 'X-'
parameters into the parsing rules.
If you (or anyone) is still interested, feel free to email the dev-
list.
Thanks,
-brian
Since I don't have access to the dev list, and only have a passing
interest in this, I will simply quickly clarify the point I was
attempting to make in the first post.
x- extensions being vendor specific, the decision of which classes
become x-___ would be vendor specific, and only if a specific
application really *really* needs it. Since such extensions are
unlikely to become globally adapted, the problem of global
application doesn't come into it. 1 website, 1 vendor, 1
application. The problem of adapting extensions to the format as a
standard is too big to take so lightly though, so I wouldn't
reccomend it beyond specific non standard applications. Applications
still need to work together for the most part, and allowing this just
opens a big complicated can of worms.
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
