[whatwg] <include> element
mjs at apple.com
Fri Apr 27 03:55:54 PDT 2007
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 use-cases?.
> 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.
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
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.
> In fact, for security reasons we might end up having to use <iframe
> type="include"> or some such rather than <include>
> This is all detailed in my original proposal.
> / Jonas
More information about the whatwg