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

[Tantek Ç elik]

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" <chris.messina at gmail.com> 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 <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
>> 
>