[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