Brian.P.Campbell at dartmouth.edu
Tue Oct 13 22:28:03 PDT 2009
On Oct 13, 2009, at 11:20 PM, Peter Brawley wrote:
> > Your requirements aren't met by framesets
> Eh? Our solution meets the requirement and uses framesets.
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.
> > <iframe>s have been demonstrated to work as well as framesets
> No-one's been able to point to a working non-frameset solution that
> meets this requirement.
Ian posted one, had-written just for you, which you dismissed without
giving any reason.
> >, and, well, framesets suck.
> Unargued, subjective.
Framesets suck because they combine both layout and embedding
semantics into one syntax, which give them much less layout
flexibility than using CSS. Anything you can do with framesets (except
resizing), you can do with iframes and CSS. However, there are lots of
things you can do with iframes and CSS that you cannot do with
framesets. Framesets are a completely different language than HTML;
you cannot use framesets and any other content elements in the same
document. 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.
> >I agree that there's
> >lots of legacy content using framesets; that's why HTML5 defines
> how they
> >should work (in more detail than any previous spec!).
> ?! According to http://www.html5code.com/index.php/html-5-tags/html-5-frameset-tag/
> , "The frameset tag is not supported in HTML 5."
That is not the draft HTML5 spec. I'm not sure what that is, but as
far as I know, it has no official affiliation with either the W3C or
the WHATWG. Try: http://whatwg.org/html5 or more specifically:
The HTML5 spec includes two types of conformance requirements;
conformance requirements for authors (or other producers of HTML), and
conformance requirements for user agents (browser and other consumers
of HTML). It is non-conforming in HTML5 to produce documents with
framesets, however a conforming user agent must parse and process them
consistently with the spec.
> >The only thing that is easier with framesets than otherwise appears
> to be
> >resizing, which I agree is not well-handled currently.
> Unsubstantiated claim absent a working example of the spec
> implemented without framesets.
Did you take a look at Ian's example?
> >As noted before,
> >though, that's an issue for more than just frames; we need a good
> >for this in general, whether we have framesets or not. Furthermore,
> >a styling issue, not an HTML issue.
> For those who have to write or generate HTML, that's a distinction
> without a difference.
> Ian Hickson wrote:
>> On Tue, 13 Oct 2009, Peter Brawley wrote:
>>>> I don't know if there are pages that do this (and I sure hope
>>>> none are
>>>> using <table> for it!), but the lack of an existence proof is not
>>>> proof of the lack of existence.
>>> Of course. The point is if no-one can point to a working iframes
>>> solution, ie, to an instance of them actually being preferred, the
>>> that iframes provide a preferable alternative is simply not
>>> credible, to
>>> put it mildly.
>> At this point I don't really understand what you want framesets
>> for. Your
>> requirements aren't met by framesets, <iframe>s have been
>> demonstrated to
>> work as well as framesets, and, well, framesets suck. I agree that
>> lots of legacy content using framesets; that's why HTML5 defines
>> how they
>> should work (in more detail than any previous spec!). But that
>> mean we should encourage them.
>> The only thing that is easier with framesets than otherwise appears
>> to be
>> resizing, which I agree is not well-handled currently. As noted
>> though, that's an issue for more than just frames; we need a good
>> for this in general, whether we have framesets or not. Furthermore,
>> a styling issue, not an HTML issue.
>> No virus found in this incoming message.
>> Checked by AVG -
>> Version: 8.5.421 / Virus Database: 270.14.13/2432 - Release Date:
>> 10/13/09 06:35:00
More information about the whatwg