[Bug 12311] new feature - client side templates

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

Aryeh Gregor <Simetrical+w3cbug@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Simetrical+w3cbug@gmail.com

--- Comment #1 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-03-16 14:06:47 UTC ---
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.

<iframe seamless> would probably be more useful.  But it's limited by the fact
that it has to be a single box, and it has to be a whole separate document
instead of just adding things to the current document.

I don't think extending <var> is a good idea here at all.  If new features are
needed, a new element should be used.  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.

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.)

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.

-- 
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 14:06:50 UTC