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

[whatwg] framesets

From: Peter Brawley <pb@artfulsoftware.com>
Date: Fri, 09 Oct 2009 13:55:57 -0500
Message-ID: <4ACF873D.6000308@artfulsoftware.com>
Aryeh,

 >I don't see why that's beneficial.

It's not your brief to decide what's beneficial for a client.

 >It conflicts with expected
 >behavior.

It does not conflict with what these users expect.

 > If you follow a link and then click "back", your
 >link-following should be undone. You shouldn't be taken to a totally
 >different page that you left half an hour ago.

You are arguing for imposing one way of doing things. Ugh.

 >That's not how the W3C or the WHATWG or any standards bodies operate.
 >If you want a feature in HTML5, you have to argue that it would help
 >the web to support it, not just that some authors want it.

Framesets are part of the current HTML standard and should remain.

PB

-----

Aryeh Gregor wrote:
> On Fri, Oct 9, 2009 at 1:47 PM, Peter Brawley <pb at artfulsoftware.com> wrote:
>   
>> It suggests no such thing. Your "suggestion", applied to surgery, would be
>> that primum non nocere implies surgery should never remove hurt or remove
>> useful tissue. The inference is overinclusive, to put it mildly. W3C's job
>> is to enable, not function like a commissariat.
>>     
>
> The W3C's and WHATWG's jobs are to make standards that promote the
> overall health of the web.  This isn't always compatible with allowing
> all authors to do everything they want.  To take a more clear-cut
> example, a lot of authors would like to be able to stop users from
> downloading videos.  <video> deliberately doesn't try to support this
> use-case, because it's viewed as harmful.  So those authors will have
> to hack up solutions using Flash or JavaScript or whatever, or else
> give up and allow it.
>
> Of course, no one actually has to follow the standards.  You can still
> use frames.  Your page just won't validate.  If you think the W3C and
> WHATWG are commissariats, this shouldn't worry you, since all it says
> is your page doesn't follow what the W3C and/or WHATWG say.
>
>   
>> These are not external links. You want these pages to make each item
>> externally linkable. The client does not. The client wins this debate hands
>> down.
>>     
>
> That's not how the W3C or the WHATWG or any standards bodies operate.
> If you want a feature in HTML5, you have to argue that it would help
> the web to support it, not just that some authors want it.  Your
> current arguments are very unlikely to get the spec changed (although
> I don't have any say in that).
>
> Users of a site using frames will have a worse experience, because
> features like link-sharing and bookmarking won't work.  You've said
> that you would *like* these features not to work.  Why, exactly?  This
> kind of degradation needs to be justified.
>
>   
>> Already explained. So that a user may enter and exit the frameset as one page
>>     
>
> I don't see why that's beneficial.  It conflicts with expected
> behavior.  If you follow a link and then click "back", your
> link-following should be undone.  You shouldn't be taken to a totally
> different page that you left half an hour ago.
>
> On Fri, Oct 9, 2009 at 2:09 PM, Thomas Broyer <t.broyer at gmail.com> wrote:
>   
>> Framesets, iframes, AJAX+innerHTML all allow this; you can't present
>> this as an argument for frameset or against their removal
>>     
>
> I don't see how iframes would allow you to deliberately mess up
> navigation in the same way as frames do.  AJAX would, and does, but
> that's a lot harder for authors to implement, so asking for an easier
> way seems legitimate.
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091009/cf168eee/attachment.htm>
Received on Friday, 9 October 2009 11:55:57 UTC

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