[whatwg] microformats incompatible with WebApps 1.0 ?

Ian Hickson ian at hixie.ch
Mon Dec 11 21:26:26 PST 2006


On Tue, 12 Dec 2006, Mike Schinkel wrote:
> 
> That said, it is a real problem.  I am coming to this issue because I 
> have the need to use a lot of semantic markup in a project I am working 
> on and I am already seeing where they are clashing, in the Microformat 
> adr being but one example:
> 
> <div class="adr">
> ...
>  <span class="region">CA</span>  
> 
> Now let's say I want to use something called "RegionData" where Regions 
> are heirarchical:
> 
> <div class="region-data">
>  <div class="region street" title="child-of-city">665 3rd St.; Suite
> 207</div>
> ...
> 
> Now, someone needs to use both:
> 
> <div class="region-data vcard">
>  <div class="region street" title="child-of-city">
> 	<div class="street-address">665 3rd St.</div>
> 	 <div class="extended-address">Suite 207</div>  
>  </div>  
>  <span class="region city locality" title="child-of-state">San
> Francisco</span>,
>  <span class="region state region"  title="child-of-country">CA</span>
> ...
> 
> How do I disambiguate between region-data's "region" and vcard's 
> "region?" Assume I created my RegionData with no knowledge that vcard 
> existed, because unless there is a central clearing house to avoid name 
> clashes, two different groups will end up creating conflicting 
> microformats with clashing names.

You're asking me to make an assumption that is false, and then to design 
the spec with that assumption in mind. That doesn't make sense.

You *are* aware of vCard, you can design your metadata structure with it 
in mind. If you are worried about clashes, then stick a prefix on your 
class names.

I honestly don't expect people to use both vCard and your format. They'll 
use whichever one does what they need it to do (typically the most popular 
one), and ignore the others. In the market place, out in the "real world", 
conflicts will be resolved by either the languages changing to adapt to 
each other, or by some of them being made obsolete and irrelevant by other 
more successful ones.

Anyway, as it stands, we *do* have a single clearing house (the Wiki, as 
defined by the spec). So if you want a clearing house, that's already 
taken care of.


> > Realistically, most authors wouldn't follow such a requirement.
> 
> Can you please indicate how you were able to arrive at those statistics 
> so quickly given that I just emailed this proposal to you minutes ago?

What statistics? I'm basing my assertion on years of experience with Web 
authors.


> You frequently say "people won't" but I contend that when it is simple 
> enough to understand and simple enough to implement where their doing so 
> doesn't take anything away from them but does give them value, they will 
> definitely do it.

There's no perceived value here. If they call their class "foo-name" it's 
for charaters more than "name", and they are otherwise identical as far as 
they can see. It doesn't matter how much real benefit there might be.

For example, there is a definite advantage to writing pages that are 
syntactically correct. Yet more than 90% of pages aren't syntactically 
correct. Why? There's no perceived value in syntactic correctness, and it 
requires more thought.


> > Nobody is going to stop you from using disambiguating prefixes if you 
> > want to use them; in the documents you need to worry about, and in the 
> > formats you want to work with, I encourage you to use them.
> 
> Then why not take just one more tiny step and encourage everyone to do 
> so?

You were asking for requirements before. If you just want encouragement, 
then write a blog post about the matter, or add a page to the wiki, or 
write a tutorial or opinion piece or whatever. It's out of scope for the 
specification.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'



More information about the whatwg mailing list