[uf-new] Revisiting grouping problem solution proposal: hset
cgriego at gmail.com
Thu May 24 11:38:49 PDT 2007
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 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.
On 5/24/07, Brian Suda <brian.suda at gmail.com> wrote:
> On 5/23/07, Manu Sporny <msporny at digitalbazaar.com> 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.
More information about the microformats-new