This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This is the whole message consisting of two messages sent by me to public-html-comments@w3.org. I repost it here because I'm not sure that this text will reach the right people. I would like to make a strategic feature request to HTML. May be it is not too late. I may missed something while reading drafts of new HTML standard, but I seriously think, there's one feature that HTML really lacks. I'm talking about Master Pages done with pure HTML only. You may object, saying that there are tons of server technologies including SSI, ASP.NET, PHP, at least JavaScript, to accomplish this task. But there are also applications where these HTML-based Master Pages would be essential. They are the servers which have server scripting turned off or don't have it at all, such as mini web servers, possibly done on the hardware router base. There is one truth about server-based master pages: each time such a page is loaded the client should download the web site design again and again instead of downloading master page once, caching it and then applying to each content page. Such a waste of traffic! In comparison to JavaScript solutions Client Master Pages wouldn't require any programming from the web designer. There may be also some profit from Master Pages on client side when saving downloaded web sites to disk (disk space save). I think, there already are great drafts for this technology present - no need to invent something new from scratch. Look at ASP.NET Master Pages for example. There are basic elements: 1. Link to master page in the content page 2. Named content placeholders in the master page 3. Named structures with contents, which correspond to named placeholders in master page Some people denote that there are FRAME and IFRAME tags to do the task which Client Master Pages should do. But these instruments have big disadvantages (otherwise Server-Side-Include wouldn't exist and Microsoft wouldn't give birth to their Server Master Pages). The main disadvantage is that in both - FRAME and IFRAME - cases the container chooses contents for itself. Master Pages do the opposite: the content page chooses its container. So if you have multiple designs in multiple Master Pages, the design can be switched easily in each particular content page. Now imagine that you should have two master page designs on your web site. For instance, each even content page should have design number 1, and each odd - design number 2. But the web site should look consistent while clicking on links and going to another page. This task can not be done easily using FRAMESET. I don't like an idea that each anchor tag is aware of in which frame a linked document should be displayed (I mean the frequent use of "target" attribute). Additionally, frames aren't consistent in a meaning of DOM (you have to "jump" somehow over frame border). Pages created using Master Pages are consistent. The difference between Server Master Pages and Client Master Pages I suggest is that Client Master Pages remain in two pieces but should be considered by the browser as a solid document, especially from the DOM point of view. Another disadvantage of frames is that they are scrollable individually - each in its own rectangualr area. The document created using master pages looks consistent and scrolls as a whole sheet. As an example how in my imagination the master pages should work - refer to linking external CSS or JavaScript files to HTML document. After loading an external CSS file browser doesn't distinguish between CSS from external file and inline CSS in STYLE tage of HTML-document's header. The same about JavaScript files - browser doesn't distinguish between external JS and script from inline SCRIPT tag. And think about nested Master Pages - they also could be useful. Please reply me about your opinions concerning implementation of this feature. And please remember - I am at least one user who needs this technology :) I had enough time to think about that.
*** Bug 12878 has been marked as a duplicate of this bug. ***
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: Rejected Change Description: no spec change Rationale: <iframe seamless> solves this. Also, markup ought to be the least of your bandwidth worries. :-)
(In reply to comment #2) > 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: Rejected > Change Description: no spec change > Rationale: <iframe seamless> solves this. Also, markup ought to be the least of > your bandwidth worries. :-) You definitely didn't read the post carefully. As I mentioned, IFRAME doesn't solve this. IFRAME does the opposite thing: with IFRAME the host page chooses the content for itself. With master pages the content page chooses the host for itself. And IFRAME boundaries are not DOM-transparent. And IFRAME isn't officially supported in every browser available.
> Also, markup ought to be the least of your bandwidth worries. :-) Please comment this. What did you meant with this? According to my humble English skills this sounds a bit rude, literally: that it is not my deal to propose markup changes. By the way, many people have dial-up connection and will have it during next 10 years.
mass-move component to LC1
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: Rejected Change Description: No change Rationale: Hi Paul, If I understand correctly, you are trying to request a resource and have that resource choose its "parent" content. For example, requesting a top-level page, article1.htm would automatically cause articlehost.htm to be downloaded which would host article1 inside of it. Alternatively, some kind of templating model for hosting the requested top-level resource would need to be available. There is currently no notion in HTML for a page being able to specify its host, as you note with regards to frame and iframe. Conceptually it sounds plausible to link to an external HTML file as you would a CSS or JS file, however the binding behavior would be incredibly difficult to specify and would likely require some kind of templating or content host-targeting scheme. That is, the content would require a great deal of knowledge of the hosting environment to make the binding work. Furthermore, any content page requiring a master page would of necessity need to make a 2nd http request. In many cases, especially on slow networks, this could significantly slow down the time to fully render the combined master content page. For this reason, master pages on the server make a lot of sense, but would be far less efficient on the client. There are alternate proposals to build reusable components that in effect enable content pages to host reusable components, such as articles. The HTML Components effort, for example, provides a lot of the rich functionality needed to make this possible. You might be interested in: http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Layout_Manager