[whatwg] <include> element

[Jonas Sicking]

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 
>>> 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.

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 
users.
Also, rendering content that lives in another document is something that 
implementations that plan on implementing XBL is going to have to 
implement anyway.

> 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 
of javascript (and not a single statement of XForms ;) ).

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.

/ Jonas