[whatwg] framesets
Peter Brawley
pb at artfulsoftware.com
Wed Oct 14 00:01:53 PDT 2009
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-0002.htm>
More information about the whatwg
mailing list