[uf-discuss] proposal: a.include

[Tantek Ç elik]

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