[Bug 12311] new feature - client side templates

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12311

--- Comment #3 from Sunil <sunil.vanmullem@btopenworld.com> 2011-03-16 15:16:09 UTC ---

(In reply to comment #1)
> XSLT and SDCH come to mind, but are probably unsuitable -- XSLT is (I think)
> incompatible with incremental rendering, not to mention far more complicated
> than necessary; and SDCH requires changes on the HTTP level, which means you
> can't use static files without hacking the web server.
thanks, Yes I did think about XSLT - as used in Microsoft Sharepoint but that
added a level of complexity and significantly increased the amount of tagging. 

>  
> I don't think extending <var> is a good idea here at all.  If new features are
> needed, a new element should be used.  
Agreed that extending var isnt a good idea. 

> You didn't explain how exactly your
> proposal works, but it seems like something along the following lines would
> work: have a new empty element <include src="">, and when the browser
> encountered it, it would synchronously fetch the specified resource and set the
> innerHTML of the <include> to that resource before continuing parsing.  Or
> maybe it would be asynchronous by default, and you could optionally force it to
> be synchronous.
> 
ok will add a description

> You could do this already using AJAX, but in the case where the designated
> resource is cached, browsers could probably optimize it to be cheaper than
> including the resource inline.  Of course, if it's served with the wrong cache
> headers, it would be a really big performance hit due to extra round-trips, but
> it could still be useful.  
For instance, Wikipedia currently generates things
> like donation banners using JavaScript, because it caches static HTML
> aggressively on its end and doesn't want to clear caches every time the banner
> size changes or whatnot.  (<iframe seamless> would also work for this, though.)
> 

Indeed, my fully functional prototype uses Ajax, but I'm considering changing
it to use <DIV src="" />



> I think something in this direction would be useful.  I suspect you're going to
> be told that the correct way to proceed is to get at least one browser
> implementer interested in working on it, though, before asking that a
> specification be written.
Thanks again for your comments

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 16 March 2011 15:16:11 UTC