[whatwg] <include> element
jonas at sicking.cc
Tue May 1 15:19:26 PDT 2007
Maciej Stachowiak wrote:
> On Apr 27, 2007, at 3:36 AM, Jonas Sicking wrote:
>> Martin Atkins wrote:
>>> Christian Schmidt wrote:
>>>> In practice, the result effect is often achieved by wrapping your
>>>> include file in a document.write() and including this using script a
>>>> <script src="...">. However, this makes it harder to write these
>>>> includes by hand (you have to escape certain characters, ' " \ \n \r
>>>> \t), and debugging also gets more difficult.
>>> This last point made me think of a related issue:
>>> When you use the above technique, the included script runs in the
>>> security context of the including page, and this technique therefore
>>> requires complete trust of the included document.
>>> Would documents included via <include> run in the security context of
>>> the including page, as with the script technique, or would they run
>>> in the context of the included document, as with iframes?
>>> Personally I favor the latter, but I wonder if this impact's anyone's
>> They would run in the context of the included page, just like an
>> iframe. The processing of <include> is exactly that of <iframe> the
>> only difference is in the rendering.
> In that case, wouldn't it make more sense to make in an attribute on
> iframe, or some setting of the CSS properties, instead of a whole
> different element? Different elements with identical processing model is
> a red flag, at least when the processing model is complex.
Using iframe would be very nice from a security point of view. I've been
trying to think about it from a semantic point of view to see if they
are similar enough that using the same element would be ok, and I don't
really feel strongly either way there. But since it solves the security
problem it sounds like the way to go.
> One question I have is whether the <include> element would be limited to
> being a rectangular area, or if it could participate in inline flow, or
> act as multiple separate blocks that lay out independently. If the
> former, then I would suggest appropriate values of the CSS height and
> width properties make sense. If the latter, I think it could be pretty
> impractical to implement, and probably not worth the effort. Layout
> engines tend to assume that there is a CSS canvas and viewport at the
> root of the document and may not be prepared to inject content from
> another document into arbitrary points in the render tree.
It would not be limited to rectangular areas and needs to take part of
the main flow of the outer document. I do realize that this is
non-trivial to implement, however I think it would be very valuable to
Also, rendering content that lives in another document is something that
implementations that plan on implementing XBL is going to have to
> In fact, if it is limited to same-site references as you suggest, I'm
> not sure what it really buys you over XMLHttpRequest and then setting
> innerHTML on the target element.
The main advantage is ease of use. See my two examples in the original
post where AJAX behaviours were done using basically a single statement
Another advantage is the fact that the the content can stream in.
Granted, this will be doable with XMLHttpRequest once progress events
are implemented, but that requires yet again much more effort on the
part of the developer. Additionally performance will never be as good
since you'll have to reset .innerHTML multiple times.
More information about the whatwg