[whatwg] microformats incompatible with WebApps 1.0 ?
Michel Fortin
michel.fortin at michelf.com
Mon Dec 11 18:18:29 PST 2006
Le 11 déc. 2006 à 20:37, Ian Hickson a écrit :
> On Mon, 11 Dec 2006, Michel Fortin wrote:
>
>> I think we should keep both systems. Things worth registering in the
>> global namespace because they're common and not very likely to be
>> misused (like class names currently listed in the spec: example,
>> issue,
>> note, warning, error, search, copyright), could be registered
>> globally,
>> things which are more specialized would be registered more
>> restrictively
>> under a profile.
>
> But we know that "profile" doesn't work.
Maybe we could arrange profiles so that they work better instead of
scraping the concept altogether. Suggestion: we could allow the
profile attribute on any element? The profile would apply only to the
concerned element and its descendants. So this:
<head profile="http://microformats.org/wiki/hcard-profile">
...
<div class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
<div class="org">Technorati</div>
</div>
could become this:
<div profile="http://microformats.org/wiki/hcard-profile"
class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
<div class="org">Technorati</div>
</div>
That would solve the problem of having the profile far away from the
actual data, which makes it difficult to copy paste and harder to see
the link.
In addition, we could maintain a global registry of short names for
profiles, so that we could write this as a shortcut:
<div profile="hcard" class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
<div class="org">Technorati</div>
</div>
And since profiles can now be applied on individual elements, there's
no real need to keep the redundant "vcard" class name since it could
easily be implied by the profile being specified on that element:
<div profile="hcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
<div class="org">Technorati</div>
</div>
How is that?
>> What worries me most about the Wiki idea is that it'll make
>> conformance
>> to HTML5 a moving target that would need to be reevaluated each
>> time a
>> new class is added on the Wiki.
>
> How is this different from conformance to HTML5 + profile-specified
> extensions?
What's different is that you have to care about conformance only to
the profile you're using, and no other. When new profiles are
created, adding new classes and link types, you know they won't
bother you.
Michel Fortin
michel.fortin at michelf.com
http://www.michelf.com/
More information about the whatwg
mailing list