<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Brian,<br>
<br>
>You have specified that your requirement is to prevent people from
linking to or <br>
>bookmarking individual pages inside of frames. Framesets
do not satisfy that <br>
>requirement. They make it a little more difficult,
but they do not prevent it.
<br>
<br>
Of course the frameset <i>by itself </i>doesn't satisfy that
requirement. It permits us to meet the requirement with little code.<br>
<br>
>Ian posted one, had-written just for you, which you dismissed
without giving any reason.
<br>
<br>
It's a nice, partial demo---side-by-side scrolling & no node
bookmarking. But no borders, no resizing, no horizontal scrolling
within frames, it requires a separate html page for each node, &c.
So it would take a fair bit of time to see if a whole implementation of
the spec could be built on it. So it does not answer the question: if
framesets are as you claim not needed for the full spec, there should
be lots of non-frameset sites which meet this spec as efficiently as
ours does. <i>No-one has pointed to one.</i> Implementations of a part
of our spec without frames, like Google docreader & MSDN, require
ten times as much javascript or more, javadoc and other major help
sites still use framesets, &c.<br>
<br>
>Framesets suck because they combine both layout and embedding
semantics <br>
>into one syntax, which give them much less layout flexibility
than using CSS. <br>
<br>
If that blocks a use case, by all means don't use a frameset for it.
For this use, the above poses no problem at all. And if CSS were
actually as efficient for this spec as framesets, surely some
developers would have taken advantage of that by now.<br>
<br>
>Anything you can do with framesets (except resizing),
you can do with iframes and CSS. <br>
<br>
Not resizing as you say, and see above.<br>
<br>
>However, there are lots of things you
can do with iframes <br>
>and CSS that you cannot do with framesets.
<br>
<br>
Which is an argument for iframes, but is <i>not</i> an argument
against framesets, which remain useful.<br>
<br>
>Framesets are a completely different language than HTML; <br>
<br>
Not a completely different language, just a different control. So what?<br>
<br>
>you cannot use
framesets and any other content elements in the same document. <br>
<br>
No need in this case.<br>
<br>
>This
means that you are forced to, for example, use a frame for the header
of your page, <br>
>which may cause a scrollbar to appear if you don't
allocate enough space, rather than just <br>
>putting the header in the page
directly and using iframes to include the other pages.
<br>
<br>
Not an issue for this use. <br>
<br>
Here's an application for framesets which is valid on previous versions
of HTML, meets a need, is more efficient than known implemented
alternatives for this use case, and does not suffer from any of the
frameset deficiencies you have listed. Framesets remain useful,
excluding them from HTML5 undermines support for those uses, and that
weakens HTML5.<br>
<br>
PB<br>
<br>
<br>
</body>
</html>