[whatwg] <include> element

[Maciej Stachowiak]

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