W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2008

[whatwg] Client-side includes proposal

From: Greg Houston <gregory.houston@gmail.com>
Date: Mon, 18 Aug 2008 16:36:25 -0500
Message-ID: <29ae901a0808181436v71e5184by59e23a9274835f73@mail.gmail.com>
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
Received on Monday, 18 August 2008 14:36:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:04 UTC