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
render tree.
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.
- Maciej
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
