[whatwg] framesets

Brian,

 >You have specified that your requirement is to prevent people from 
linking to or
 >bookmarking individual pages inside of frames. Framesets do not 
satisfy that
 >requirement. They make it a little more difficult, but they do not 
prevent it.

Of course the frameset /by itself /doesn't satisfy that requirement. It 
permits us to meet the requirement with little code.

 >Ian posted one, had-written just for you, which you dismissed without 
giving any reason.

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. 
/No-one has pointed to one./ 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.

 >Framesets suck because they combine both layout and embedding semantics
 >into one syntax, which give them much less layout flexibility than 
using CSS.

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.

 >Anything you can do with framesets (except resizing), you can do with 
iframes and CSS.

Not resizing as you say, and see above.

 >However, there are lots of things you can do with iframes
 >and CSS that you cannot do with framesets.

Which is an argument for iframes, but is /not/ an argument against 
framesets, which remain useful.

 >Framesets are a completely different language than HTML;

Not a completely different language, just a different control. So what?

 >you cannot use framesets and any other content elements in the same 
document.

No need in this case.

 >This means that you are forced to, for example, use a frame for the 
header of your page,
 >which may cause a scrollbar to appear if you don't allocate enough 
space, rather than just
 >putting the header in the page directly and using iframes to include 
the other pages.

Not an issue for this use.

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.

PB


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091014/2a585844/attachment.htm>

Received on Wednesday, 14 October 2009 00:01:53 UTC