W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2009

[whatwg] framesets

From: Brian Campbell <Brian.P.Campbell@dartmouth.edu>
Date: Wed, 14 Oct 2009 01:28:03 -0400
Message-ID: <98038259-77F7-42FD-8A4A-097BB3E9EA3B@dartmouth.edu>
On Oct 13, 2009, at 11:20 PM, Peter Brawley wrote:

> Ian,
>
> > 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:

http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#frames-and-framesets

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?

http://damowmow.com/playground/demos/framesets-with-iframes/001.html

>
> >As noted before,
> >though, that's an issue for more than just frames; we need a good  
> solution
> >for this in general, whether we have framesets or not. Furthermore,  
> that's
> >a styling issue, not an HTML issue.
>
> For those who have to write or generate HTML, that's a distinction  
> without a difference.
>
> PB
>
> -----
>
> 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  
>>> claim
>>> 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  
>> there's
>> lots of legacy content using framesets; that's why HTML5 defines  
>> how they
>> should work (in more detail than any previous spec!). But that  
>> doesn't
>> 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  
>> before,
>> though, that's an issue for more than just frames; we need a good  
>> solution
>> for this in general, whether we have framesets or not. Furthermore,  
>> that's
>> a styling issue, not an HTML issue.
>>
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG -
>> www.avg.com
>>
>> Version: 8.5.421 / Virus Database: 270.14.13/2432 - Release Date:  
>> 10/13/09 06:35:00
>>
>>
>>
Received on Tuesday, 13 October 2009 22:28:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC