[whatwg] Client-side includes proposal

Greg Houston gregory.houston at gmail.com
Mon Aug 18 14:36:25 PDT 2008

On Mon, Aug 18, 2008 at 4:01 PM, João Eiras <joao.eiras at gmail.com> wrote:
>> <include src="static-header" />
>> <include src="user-specific-data" />
>> <include src="dynamic-daily-content" />
> This is something that would probably not be represented with a new element,
> because elements are  preserved in the DOM tree so they can be accessed and
> queried.
> So then you'd have a question: keep <include>in the dom and allow access to
> children like an iframe, or replace <include> entirely ?
> The answer could be intuitive, but that can open a can of worms. Then you
> can do all sorts of dynamic manipulation, which would have to be very well
> specified.
> I think the way to go would be a processing instruction.
> The idea is good though ! But I think could be better implemented with a css
> template like feature. I don't like the idea of a new element.
> Bye.

This seems to be mostly useful for people creating small websites that
are afraid of server side scripting languages like PHP, Python and
Ruby. That being the case, if something like this is implemented the
included content should definitely not be accessed like with an
iframe. The elements included should be in the DOM tree of the parent
just as if the includes were done server side. Accessing the DOM of an
iframe from the parent and vice versa causes people a lot of
confusion. I don't think we need to add that level of confusion to the
group of users that would most likely use this feature.

Also, a bonus of keeping <include src="some-content.html" /> in the
DOM, is that changing the source could reload the content of that
element. You would have instant AJAX/XHR for dummies.

- Greg

More information about the whatwg mailing list