I absolutely agree with Brian's sentiment here that the optional container class names that exist today have very different semantics. That's why I maintained them in my proposed option[1] while also trying to avoid the need for any form of namespacing or notation, dot or otherwise, in the class attribute.
Replacing the existing container class names are a non-problem, but I recognize that sparse grouping is a problem, which is why I see hSet's role more as an alternative to the include-pattern, which is a useful solution (that uses the ID attribute) in many situations, but clunky at best when dealing with sparse grouping. Case in point is that Martin's rev-based option is reinvention of the include-pattern with all of the same clunkiness. [1] http://microformats.org/wiki/grouping-brainstorming#Option_7:_id-class_grouping -- Chris Griego On 5/24/07, Brian Suda <[EMAIL PROTECTED]> wrote:
On 5/23/07, Manu Sporny <[EMAIL PROTECTED]> wrote: > Brian Suda wrote: > We are starting to "solve" this container problem over and over again. > We've already created redundant container/grouping/set mechanisms: --- no they are NOT redundant. They have different semantics. Microformats are MICRO and they solve a specific problem. If we create a generic SET object then what does it mean when you begin to have mixed content in that set? some events, some people, some XYZ format. This is no longer MICRO but attempts to "boil the ocean" which is something we want to avoid. > Where do we go from here? > > halbum for haudio > hpodcast for haudio > hfilm for hvideo > hmultimedia for haudio and hvideo combinations > htvseries for hvideo --- if need be, then yes. hpodcast has very different semantics than vcalendar. But i am pretty sure that microformats will stay micro, we are worrying about a problem that does not exist.
_______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
