This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
*new feature suggestion* -problem statement- Separating further the document structure from the document content will have 3 benefits 1) would allow for separation of the design workflow and the application developer workflow such that the design of a web page could be changed independently of the need to make application changes 2) reduces the amount of data in subsequent calls for pages using common document structure, thus providing a more optimal experience for mobile devices and incrementally reducing the stress on busy servers 3) allows for the possibility that the end user can choose the document structure. - solution - w3c to release a framework for client side templates. eg extend the use of src attribute to other elements extend the VAR element to contain an id attribute add a new url scheme var: that takes as its source the named var element. - working prototype - I have developed an open source, fully working, cross browser/cross platform prototype using Ajax. I would be willing to transfer this to the w3c and continue further development with the w3c. downloaded at http://sourceforge.net/projects/fabiola/ viewed at http://www.paglis.co.uk/meob/ thankyou
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.
It's worth pointing out that anything like this will increase the number of HTTP requests needed for an initial page view, though. That will always be a painful tradeoff until we get something like SPDY that can send additional resources unsolicited.
(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
(In reply to comment #2) > It's worth pointing out that anything like this will increase the number of > HTTP requests needed for an initial page view, though. That will always be a > painful tradeoff until we get something like SPDY that can send additional > resources unsolicited. Hi. Tradeoff is one or two additional http requests for cached content against a reduction in data requested in subsequent requests. Document structure , if thats what I can call it, can be cached on the browser in the same way as an image or other embedded content is.
If you want to update cached document structure incrementally, then something modelled on XUL overlays is IMHO best: https://developer.mozilla.org/en/xul_overlays and it could be implemented using XHR+DOM+pushState with pretty good backwards compatibility.
(In reply to comment #5) > If you want to update cached document structure incrementally, then something > modelled on XUL overlays is IMHO best: > > https://developer.mozilla.org/en/xul_overlays > > and it could be implemented using XHR+DOM+pushState with pretty good backwards > compatibility. Hi Kornel, is it possible for you to put up an example of your suggestion? Thanks SV
Mass move to "HTML WG"
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: No spec change. Rationale: This is actively being worked on. See the various Web Components documents that are coming out of the WebApps WG. Here's an intro to the work: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html