[uf-discuss] Re: proposal: a.include

[Chris Messina]

You should look into the snippet format that Dreamweaver 8 (not MX,
which switched to XML) supported. It unfortunately used comments to
include a snippet (copying over the contents of the snippet file) but
there may be some wisdom to mine there.

Similarly, most HTML editors use some kind of transclusion for
external snippets -- skEdit, BBEdit, Homesite, etc. It'd be worth
looking at how they do things since this idea is not new and it seems
as though we're inventing solutions where there already exists plenty
of behavior to mine.

Chris

On 7/9/06, Tantek Çelik <tantek at cs.stanford.edu> wrote:
> On 7/9/06 3:04 AM, "Andreas Haugstrup" <solitude at solitude.dk> wrote:
>
> > On Thu, 06 Jul 2006 20:13:51 +0200, Ryan King <ryan at technorati.com> wrote:
> >
> >> That subject should have been "proposal: a.include".
> >>
> >> That's what I get for trying to be clever.
> >
> > Why not use rel="enclosure" since you'll be using anchor elements?
>
> Because it is not an "enclosure".  A rel enclosure (as defined by Atom, and
> reused by microformats.org) is an *embedded* *item* intended for *download*
> by the client.  That's not what the include-pattern is for.   An "include"
> is an *incorporated* *fragment* intended for being parsed/consumed inline
> with its surrounding markup.
>
>  http://microformats.org/wiki/include-pattern
>
> It's very important that we capture the specific semantic here, which is a
> content transclusion, otherwise known to most programmers as an "include".
> Hence why Ryan and I chose the term "include" for this in the first place.
>
> I actually prefer rel="include" over class="include" *if* we are only going
> to use the <a href> element in this case, since the thing the <a href>
> points to *is* an "include" for that portion of the document, and the rel
> attribute is more explicitly semantic than the class attribute.
>
> However, <object> doesn't have a 'rel' attribute, and assuming that we want
> to leave that semantically better option open to us as browser object
> support improves, I don't want to have *two* mechanisms (rel include *and*
> class name of include) to do the same thing.
>
> Thus I come to the same conclusion as Ryan as far as a.include.
>
> We should allow *both*:
>
>  <object data="#IDREF" class="include" type="text/html"></object>
>
> AND
>
>  <a href="#IDREF" class="include" type="text/html"></a>
>
> and let the content author decide which to use, while pointing out that the
> <object> is semantically better.  Thus continued pressure will be place upon
> browser manufacturers to improve their <object> support while existing large
> / high-traffic sites can opt to use the lighter-weight <a href> option.
>
> Ryan wrote:
>
> > (sidenote: I don't think the @type should be required after this change)
>
> I'm not sure about that.  OT1H the addition of the "type" attribute tries to
> communicate that the "include" is "just" HTML.  OTOH the "text/html" type is
> for a whole document, not just a fragment so it might not be correct to use
> "text/html" for the include-pattern.
>
> I don't think there is a registered (or even ad hoc) content-type for an
> HTML fragment.  Thus we either make one up, or use an "x-" type to
> communicate this semantic.  E.g.
>
>  <object data="#IDREF" class="include" type="text/html-frag"></object>
>  <a href="#IDREF" class="include" type="text/html-frag"></a>
>
> OR
>
>  <object data="#IDREF" class="include" type="text/x-html-frag"></object>
>  <a href="#IDREF" class="include" type="text/x-html-frag"></a>
>
> Thoughts?
>
> Either way, I do believe we should define it to maximize the semantics that
> are provided in include-pattern usage.
>
> Thanks,
>
> Tantek
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>


-- 
Chris Messina
Agent Provocateur, Citizen Agency &
  Open Source Ambassador-at-Large
Work  / citizenagency.com
Blog  / factoryjoe.com/blog
Cell  /  412 225-1051
Skype / factoryjoe
This email is:   [ ] bloggable    [X] ask first   [ ] private