Re: [whatwg] HTML4's profile="" attribute's absence in HTML5

Ian Hickson wrote:
>> 1) Conflicts *do* occur, as soon as you consider extensions that happen 
>> outside the microformats process (and that process seems to exclude 
>> private extensions, such as for intranet applications).
> Conflicts do not occur on the kind of scale that requires dedicated 
> markup.

Not sure what you mean by "dedicated markup".

At the end of the day, this just seems to be another example of the 
"extensibility based on namespaces" dispute. Some believe in it, some 
don't. You obviously don't.

The question here is: what does the *working group* think?

>> 2) As a matter of fact, <> states
>> "In hcalendar-issues, it is ACCEPTED that each microformat should have a
>> profile URI, like the XFN profile ("
>> So it seems you are in disagreement with the microformats community as well.
> Actually the removal of profile="" was done in conjunction with the 
> Microformats community. I do not know whether that page represents 
> consensus in that community or not. I have asked for clarififcation.


Here's another quote:

"microformats use unscoped class names

misconception: Microformats definitions use unqualified/scoped class 
attribute strings as semantic tags.

This is incorrect on two counts.

First, microformats make use of profile URLs to define class name 
semantics. Thus it is entirely possible (though both unlikely, and 
undesirable) for someone to redefine class names with their own 
definitions in their own profile URL.

Second, compound microformats (e.g. hCard, hCalendar, hReview) use a 
fairly uniquely chosen string for the "root element" (e.g. vcard, 
vcalendar, vevent, hreview) and then generic terms only inside that root 
element. Thus use of any generic terms are scoped (some might even say 
"namespaced") within the fairly uniquely chosen "root element" class 
name." -- 

>> That being said; I agree that the profile attribute is not a good 
>> solution, as it is of limited use only. Thus, instead of removing it we 
>> should think about fixing it, or using something that works instead 
> Before we think about using something that "works", we have to determine 
> why what we have now doesn't "work". It isn't at all clear to me that we 
> have any kind of practical problem here.

OK, more input:

- <>

- problems nesting different microformat syntaxes (will have to dig out 
a URL)

So, from my POV, microformats can be a nice approach for some common 
formats (and that's why I support hCard myself in my code), but they do 
not scale well.

BR, Julian

Received on Wednesday, 7 May 2008 20:15:17 UTC