[whatwg] Client-side includes proposal

[Martin Ellis]

I still get the feeling that this is an element that is being invented for the purpose of being invented and doesn’t solve any existing problem, or resolve any difficult to implement problems that are not already solved in layers below and above HTML.

I worry slightly from this and similar proposals that certain parts of the spec will end up being deprecated in the next spec due to lack of use.

With regards to instant AJAX for dummies, I struggle to accept that no-one is able to download an already existing javascript library that provides this functionality in a few simple lines.

Maybe I've missed something but is there a mandate which sets out the audience HTML5 is trying to satisfy?

Do we really need to reinvent the wheel? 

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jonas Sicking
Sent: 19 August 2008 03:36
To: Greg Houston
Cc: whatwg at lists.whatwg.org; Bill Wallace; João Eiras
Subject: Re: [whatwg] Client-side includes proposal

Greg Houston wrote:
> 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.

This is basically what i've suggested in a thread some months back. 
Basically an <iframe> but that renders as if the inner was included inline.

This is far from easy to implement since you have to do layout across 
several documents. But I think it would be a pretty useful feature to 
simplify AJAXy pages.

If I ever get time I'm going to attempt an implementation in firefox 
which will hopefully provide experience to build a spec on.

/ Jonas

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.