On 6/17/07 12:55 PM, "Scott Reynen" <[EMAIL PROTECTED]> wrote:
> So we're left choosing > between two microformat principles that don't work well together in > practice. We could get them to work together by continuing that MFO > discussion, but then we'd be conflicting with yet another principle: > solve a specific problem. So which principle do we discard here? This is likely to be precisely why we may need to solve this problem by continuing the mfo discussion. If you look at the current known alternatives: 1. require parsers to update whenever new nestable microformats are introduced, and precisely define rules for handling known/common nesting cases (to at a minimum avoid wasting time on straw-man arguments). 2. add a new class name to indicate a encapsulation scope (e.g. "mfo") when embedding - = one new class name, only in cases where nesting occurs. 3. replicate/prefix property class names for each microformat e.g. audio-fn - = numerous new class names It is pretty clear that #3 is the worst from a complexity (most new class names) that would affect the most people (publishers) point of view. So we should seek to avoid #3 since that violates the principles the most. #2 adds some incremental authoring complexity in some cases. #1 is something that we can probably still do today since both the number of microformats is small (a good reason to keep the overall number small), and the number of parser implementations is small and parser implementers are both involved in the community and able to update their code quite quickly ( cc'ing microformats-dev accordingly). Therefore it is reasonable IMHO to: Pursue #1 in the short term until we have solved #2 in the medium term. Tantek _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
