[whatwg] framesets

Peter Brawley pb at artfulsoftware.com
Tue Oct 13 08:51:07 PDT 2009


Ian

Thanks for your interest in the issue.
>>>
>>> > > > I quoted Andrew Fedoniouk
>>> > > > (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html), 
>>> > > > "There are use cases when frames are good. As an example: online (and
>>> > > > offline) help systems ... In such cases they provide level of usability
>>> > > > higher than any other method of presenting content of such type."
>>> > > >
>>> > > > I've not seen a counterexample. Have you?> >
>>> > > I believe Andrew's statement to be incorrect.> 
>>> > If your belief is correct, there must be sites which accomplish this 
>>> > spec with tables + iframes (for example). No contributor has managed to 
>>> > point to them.
>>>       
>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.

 >However, in the interests of moving this on, I made an example here in
 >about ten minutes:
 >http://damowmow.com/playground/demos/framesets-with-iframes/001.html

Yes, iframes can implement some features of the spec. See above.

PB

-----

Ian Hickson wrote:
> On Mon, 12 Oct 2009, Peter Brawley wrote:
>   
>>>> I quoted Andrew Fedoniouk
>>>> (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html), 
>>>> "There are use cases when frames are good. As an example: online (and
>>>> offline) help systems ... In such cases they provide level of usability
>>>> higher than any other method of presenting content of such type."
>>>>
>>>> I've not seen a counterexample. Have you?
>>>>         
>>> I believe Andrew's statement to be incorrect.
>>>       
>> If your belief is correct, there must be sites which accomplish this 
>> spec with tables + iframes (for example). No contributor has managed to 
>> point to them.
>>     
>
> 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.
>
> However, in the interests of moving this on, I made an example here in 
> about ten minutes:
>
>    http://damowmow.com/playground/demos/framesets-with-iframes/001.html
>
> It doesn't do the resizing, and I didn't test it in IE so it probably 
> needs some hacks to work around some bugs there, but it works fine for me 
> in Safari. Resizing in a single page in general is a solved problem, you 
> can probably slap a little JS on there and it would be supported too. (It 
> should be easier to do, mind you; that's a CSS problem though, and affects 
> more than just frames.)
>
>
>   
>>> search engines can't index into them (search is a critical part of help
>>> systems), pages in them can't easily be bookmarked
>>>       
>> A DB row is a tree node and it must be possible to block bookmarking of such
>> rows.
>>     
>
> Framesets don't block bookmarking of such rows. They just make it harder. 
> (A user can always right-click a frame and get the URL to bookmark it.)
>
> AJAX can block bookmarking of such rows, though.
>
>
> On Mon, 12 Oct 2009, Peter Brawley wrote:
>   
>> There are good database reasons to block bookmarks to table rows, so 
>> that must be doable.
>>     
>
> That's fair enough, but framesets don't provide that possibility. They 
> only make bookmarking significantly harder; they don't make it impossible. 
> Indeed there have been a number of browsers over the years who have 
> implemented various hacks whereby the user can bookmark the entire state 
> of a frameset. The usability of such hacks has been poor, but the point is 
> that if the requirement is that bookmarking not work, frames don't 
> actually fulfill that need.
>
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.421 / Virus Database: 270.14.11/2430 - Release Date: 10/12/09 04:01:00
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091013/c8f97080/attachment-0002.htm>


More information about the whatwg mailing list