This is the addition to my message concerning Pure HTML Client Master Pages.
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
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.