Chris Griego wrote: > With my proposal for hSet: > > <h1><span id="internal-event" class="hset vcalendar">Internal</span> > and <span id="with-client-event" class="hset > vcalendar">With-Client</span> Events</h1> > <ol> > <li class="with-client-event vevent"><span class="summary">FOO Sales > Pitch</span> [...]</li> > <li class="internal-event vevent"><span class="summary">Company > Picnic</span> [...]</li> > <li class="with-client-event vevent"><span class="summary">BAR Photo > Shoot</span> [...]</li> > </ol>
Chris, What you have proposed is definitely a work-able solution. I've added it as option #7 in the brainstorming section of the page: http://microformats.org/wiki/grouping-brainstorming#Option_7:_id-class_grouping There are a few things working against your proposal that I can see (the option #3 problem solution proposal doesn't have any of these issues): 1. It uses IDs - something Microformats want to avoid. 2. It splits the specification of a set into two parts. 3. It is impossible to define two top-level sets. 4. It mixes identifiers and class names. 5. It is more complex and requires a greater cognitive load on the XHTML author. Here's a bit more detail: Problem: It uses IDs - something Microformats want to avoid (opinion) --------------------------------------------------------------------- I believe you were absolutely correct in your first argument against using IDs for relationships and grouping. We have avoided using IDs for Microformats thus far and there is no reason that this Microformat needs to start using them. The use of classes allow us to define multiple microformats per XHTML element. We should stay away from using IDs unless there is no other alternative. Option #3 provides an alternative to using IDs. Problem: It splits the specification of a set into two parts ------------------------------------------------------------ You have split the specification of a set into two parts - the CLASS part and the ID part. Option #3 does not split the specification into two parts. This is purely an argument to use a simpler Microformat option if it exists (which it does: option #3). Problem: It is impossible to define two top-level sets ------------------------------------------------------ You cannot define two top-level groups for a single element. For example, a movie series can be a collection of hImage, hVideo and hAudio markup as well as being the root element for other sets such as a "best of" series. In other words, your solution can only create one set relationship per XHTML element on the page. Option #3 allows multiple specifications of set relationships on a per XHTML element basis. It can do this because it doesn't use ID and instead uses class. Option #3 is more flexible than your proposal because it allows the creation of multiple relationships per XHTML element. Problem: It mixes identifiers and class names (opinion) ------------------------------------------------------- It mixes two page-level XHTML name spaces that should probably be kept separate: ID and CLASS. I don't see any reason we should mix these two name spaces when we don't have to... Problem: It requires a greater cognitive load on the XHTML author ----------------------------------------------------------------- When authoring Microformats, it is hard enough to remember all the markup. The nice thing is that almost all markup tends to be pretty localized - when placing semantic hints in the XHTML, you only have to place them in one location. The problem solution that you have proposed places the mark-up in two locations. It is also not obvious to anybody reading the XHTML (yes, people still do this) that the Microformat described in the class is actually part of a relationship/set/grouping of some kind. For these reasons, I believe that Option #3 is still our best bet because it is the simpler solution. Please debunk as necessary... -- manu _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new