RE: OBJECT, inheritance, and rendering

> -----Original Message-----
> From: Todd Fahrner [mailto:fahrner@pobox.com]
> Sent: Tuesday, August 04, 1998 2:53 PM
> To: braden@endoframe.com; 'David Perrell'; www-html@w3.org
> Subject: RE: OBJECT, inheritance, and rendering
>
>
> Braden N. McDaniel wrote (2:03 PM -0700 8/4/98):
>
>  " ...the most important thing here is
>  " that it looks like the spec doesn't say. Meaning, IMO, we
> really need a
>  " clarification.
>
> I agree. Or perhaps a new element, or a redefinition of
> OBJECT's behavioral
> semantics (seeing as it hasn't yet been implemented quite to
> spec yet(?)).
>
> I've been following the discussion with only one eye, but I
> think something
> along the lines proposed by David Baron would be great: a
> MIME type for
> HTML fragments (text/htmf?) - perhaps with the stricture that they be
> well-formed fragments. This seems in line with efforts to
> develop HTML 5
> into a modular XML application. The results of htmf inclusion
> via OBJECT
> would be comparable to a server-side include. Even better,
> perhaps: be able
> to include id's within complete HTML documents; e.g.,

I don't like the idea of a MIME type just for HTML file fragments. Does this
mean we need MIME types for fragments of other types? Sounds to me like this
solution addresses a very specific problem (importing HTML source into an
HTML document) with a very *general* solution (a MIME type). Why isn't a
specific solution more appropriate?

I don't like the idea of attaching this behavior to OBJECT. "Subwindow" or
"box"*, OBJECT has a consistent notion of its inclusion residing in a space
separate from the host document. Attaching behavior that is distinctly out
of line with this as a special case strikes me as violating the integrity of
OBJECT. Why should OBJECT be a catch all for any conceivable kind of
inclusion?

> <OBJECT data="http://www.prismaticbooger.com/index.html#chug"
> type="text/htmf">
>    <em>Unfortunately, your UA doesn't support OBJECT for
> inclusion of HTML
>    fragments, so you're reading this instead.</em>
> </OBJECT>

Why would a HTML source import mechanism need a means of providing alternate
content? Can we agree that, while useful to convey the meaning of an
example, the above alternate content is pretty useless in practice? Can we
think of examples that would include both useful *and* maintainable
alternate content?

> This would render the element whose id="chug" and all its
> children, exactly
> as if the element had been included server-side, with all the usual
> inheritance rules applying.
>
> Servers could pre-process such files as they were being
> served in order to
> take care of legacy UAs, or just to speed things along as
> load permitted.
> UAs could fetch their own includes if bandwidth were high, or let the
> server do it if low.

An interesting aside. Raising the question: do we need a standardized
client-side mechanism for this, or a standardized *server-side* mechanism?

I suggest that if we do need a standardized client-side mechanism, a new
HTML element is the best way. It can work independently of the MIME
type--that is, it will *always* expect to be directed to text/html, and will
always attempt to interpret the resource as such.

Braden

* Term deliberately left undefined. Use your imagination.

Received on Tuesday, 4 August 1998 18:26:00 UTC