- From: <bugzilla@jessica.w3.org>
- Date: Wed, 16 Mar 2011 15:16:09 +0000
- To: public-html-bugzilla@w3.org
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