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
-- 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 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
