HTML comments are pretty much a non-starter as they are not part of the semantics of the document. That being said, if you could provide URLs to the previous include-formats then we could document them on that page[1] for reference and to make sure we're not reinventing anything we don't need to.
Thanks, Tantek [1] http://microformats.org/wiki/include-formats On 7/9/06 12:41 PM, "Chris Messina" <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> wrote: >> On 7/9/06 3:04 AM, "Andreas Haugstrup" <[EMAIL PROTECTED]> wrote: >> >>> On Thu, 06 Jul 2006 20:13:51 +0200, Ryan King <[EMAIL PROTECTED]> 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 >> [email protected] >> http://microformats.org/mailman/listinfo/microformats-discuss >> > _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
