[whatwg] <include> element

Hi All,

This is an idea I have had floating around in my head for a while and
a recent couple of threads reminded me I really need to post it here.

Basic idea:
The idea is basically an element like <iframe> but that renders the
linked page, instead of inside a square area, in flow with the main
page. This idea is really rough still, but I hope to try to implement it
in a not too distant future to solidify it a bit. One thing very much up
in the air is what the element would be called. Suggestions welcome, but
I'm using the name <include> below.

Examples:

Example 1.
Something like http://google.com/suggest could easily be built using 
markup like this:

<input oninput="dropdown.src = urihead + this.value"><br>
<div style="position:absolute;">
<include id="dropdown"></include>
</div>
<script>
var dropdown = document.getElementById('dropdown');
var urihead =
"http://www.google.com/complete/search?hl=en&client=suggest&js=true&qu="
</script>

The document contained at the search uri would then simply contain a
list of the result in the form of:

<html>
<body>
<p>
hello world<br>
foo bar<br>
...
</p>
</body>
</html>

The first nice thing to note in this is that it requires very little
javascript on the part of the web author. Currently a lot more code is
written to set up an XMLHttpRequest, send a request and insert the
response into the rendered page.

Another nice thing is that the result can stream in. Even when just half
of the response is downloaded the UA can still render what is available.

You'd obviously need more code to deal with the user navigating into the
suggested results list, but that is needed anyway.

Example 2.
Similarly, the listing of a emails in a mailbox could be done using
something like this:

<div onclick="mailbox.src = urihead + event.target.textContent + '#b'">
<div>inbox</div>
<div>junk</div>
<div>drafts</div>
<div>work</div>
</div>
...
<table>
<tr>
<th>Subject</th>
<th>From</th>
<th>Date</th>
</tr>
<include id="mailbox"></include>
<tr>
<td rowspan="3">(c) Example Inc.</td>
</tr>
</table>


The returned page would contain the following markup:
<html>
<body>
<table>
<tbody id="b">
<tr>
<td>How's it going</td>
<td>Ted</td>
<td>2pm</td>
</tr>
<tr>
<td>Where're your taxes?</td>
<td>IRS</td>
<td>Yesterday 8am</td>
</tr>
...


This uses the ability to specify a fragment identifier in the uri to 
render just that element and its content.

Another thing to note is that the <include> element has to be allowed to 
be parsed as a child of <table>.

API:
The API and behavior from a scripting point of view of an <include> 
would be exactly that of <iframe>. There would be an inner document 
accessible through a .contentDocument property. This document would have 
a full window object and script context. Scripts in the document would 
execute just like for an <iframe>.

Security Concerns:
The first limitation this tag has to have is that it'll be limited to 
same origin uris. Otherwise it would be possible to extract data from 
another site by setting fragment identifier uris and measuring the 
resulting size.

One unsolved problem is that sites currently use blacklists to block 
tags like <iframe>. However this problem is mitigated by the fact by the 
same origin policy.

We might be forced to either use an opt-in mechanism in the header to 
allow <include> (which would suck a lot), or we could reuse the <iframe> 
element and add an attribute to indicate the new rendering model (which 
would suck slightly less).

Open Issues:
Should the stylesheets of the outer or the inner document be used?
When a fragment identifier is specified, should we render that element, 
or its children?
Should style be inherited from the parent of the <include>, or from the 
DOM parent in the inner document?
Should the inner DOM be rendered inside of, or in place of the <include>?

All above could potentially be configurable by the author using 
attributes on the <include>.

The following will probably not work:
<select><include src="..." /></select>
HTML5 has a solution for that though, so I think it's fine.

Best Regards,
/ Jonas

Received on Monday, 23 April 2007 15:19:49 UTC