[uf-dev] nested @class="value" properties

Benjamin West bewest at gmail.com
Thu Feb 1 19:18:16 PST 2007


Derrick has a good point with his recursive interpretation.  From a
usability perspective, it is the most consistent model.  The value of
the fragment is "foo bar".  With @value treated recursively, when the
other examples are evaluated, the result is still "foo bar", making
this option the most consistent authoring experience.

On 2/1/07, Benjamin West <bewest at gmail.com> wrote:
> This is really an include-pattern issue, isn't it?  Should it be added
> to the wiki at <http://microformats.org/wiki/include-pattern-issues>?
>
> The idea behind include is that this block:
> ---------
> >   <div class="property">
> >       <span class="type">type</span>
> >       <span class="value">
> >           <span class="value">foo</span>
> >           quux
> >           <span class="value">bar</span>
> >       </span>
> >   </div>
> >
>
> Should be identical to...
>
> >   <div id="ref">
> >        <span class="value">foo</span>
> >        quux
> >        <span class="value">bar</span>
> >   </div>
> >
>
> this block:
> --------------
> >   <div class="property">
> >       <span class="type">type</span>
> >       <span class="value">
> >           <object class="include" data="#ref" />
> >       </span>
> >   </div>
> -------------
> From <http://microformats.org/wiki/include-pattern>:
> "the object include completely replaced by the subtree that it references"
>
> So that much is clear.  However, what about the #ref element and it's
> children?  Should a parser produce the same result for #ref as when
> it's included?  If the results are different, this could place extra
> burden on authors.  What does XSLT do if you ask for all the text
> nodes with class="value" for a property?  That would be what works
> currently.
>
> Ben
>


More information about the microformats-dev mailing list